[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~

?

?

?