[Project Euler, Problem 24] 一道编程题引起的思考
最近和同事们讨论了一道小编程题, Project Euler的第24题.
有的同事能够解出来, 有的同事解不出来,有的同事很快, 有的同事比较慢.
虽然只是有道小问题, 但我们一起还是观察到了不少差别,
?
为此我想到了一个问题:
我们要如何把"解决这些问题"的知识或者能力, 传递给解决不出来这道问题的朋友呢?
是的, 我指的是提高大家的编程能力, 提高今后解决问题的能力, 而不是只给大家能运行出答案的代码.
?
为此, 我做了一些思考. 整理如下.
?
首先, 题目是这样的:
?
为此, 我们可以先聊一聊如何拆解问题
如何把整个问题拆解成更小的问题, 拆解成更小的函数,
经过这样的层层分解, 我们再从叶子节点(最小的问题开始)反过来, 就可以编写出我们的程序.
推而广之, 在真实的开发环境中, 为了写出漂亮可读的代码, 这些拆的学问, 仍然十分必要.
?
虽然如何拆解问题需要具体问题具体分析,
但是一些通用的法则仍然适用, 比如单一职责,DRY, 正交性, 概念完整性等等.(ps. 有很多进阶的经典书, 你懂的)
如果小问题拆解的恰当, 那么大的问题会迎刃而解,
如果没有拆解,或者小问题拆解的不恰当, 大的问题的求解以及描述就会复杂而不清晰.
?
接下来, 我们可以聊一聊如何抽象问题
自然语言真的很奇妙, 很多时候这两个次得含义差不多,
因为我们在说抽象一个问题, 设计一个问题的时候,
往往也就是把问题从混沌的状态拆解成可以实现,可以执行的若干部分.
?
然而有意识的区别一下抽象和拆解这二者还是有区别的.
比如: 发现一个好概念, 给他一个好名字, 在抽象问题时,这很关键, 而对于拆解问题则不尽然
比如: 有些时候抽象问题会往更泛化,更高层的方向去, 并不像拆解那样更容易把我们引向更小更细的方向.
?
?
二. 算法写了出来, 但是执行结果总是不对, 狂Debug, 但是仍找不到原因.
?
之所以想到这一问题, 是因为我观察到了这样的现象:
?
puts (0..9).to_a.to_a.permutation(10).to_a[999999].join?
?
写在最后:
最近从一个新同事那里得知了这个网站: Project Euler, 在它上面有很多有趣的编程问题(多与数学相关)
我在最后, 必须要感谢我这个同事, 他告诉了我一个如此有趣的网站~? ^-^
我想在今后, 我要学习一门新语言的时候, 我一定会拿这上面的题练练手.
无聊的时候, 他也一定会给我带来很多的乐趣.
thx, end~
?
?
?
