英文：Kent Beck

译者：伯乐在线 - Kenneth

链接：http://blog.jobbole.com/102515/

这几年来我观察了很多大师级的程序员, 发现他们的工作流程中有一些共通的模式。几年来在辅导很多有经验的资深码工（程序员）时, 却没有观察到这些模式。在这个过程中，我见到这些模式的引入能带来很大的差别。

 

接下来谈谈高效的程序员应该如何好好运用他们生活在地球上 30 亿秒的时间。（译注：约等于 95 年）

 

这裡的主旨是规模化你的大脑。工匠通过一次性解决越多问题来解决更庞大的问题；大师则每次尽量解决少量的问题，来解决更庞大的问题。 这其中的智慧是，如何将大问题细分成数个小问题，使得整合之后将会比一次解决全部的问题还要来得轻鬆。

 

时间

细分

 

将一个大项目细分成数个小切片，并且重新排列以符合你的现况。我随时可以将这些项目再切得更细小，而且还能重新组合来面对不同的需求。

 

一次只做一件事

 

由于我们相当注重效率，因此我们总是试图减少回馈周期的次数，以避免重新检视的无谓开销。但这往往反而导致了侦错难度的提升，其付出的成本常大于原本想避免回馈周期所产生的开销。

 

让它动起来，正确且快速动起来

 

（「细分」、「一次只做一件事」、「简化更动」的例子）

简化变动

 

当我们面对困难的变动，首先要进行简化 (警告, 这可能很难)，然后再实施简化后的变动。 (例如：「切割」、「一次只做一件事」、「集中」、「离析」等原则) 这是「切割」原则的一个例子。

 

集中/专注

 

如果你需要一次修改很多元件，先重新整理代码（译注：或重构），使得只需要修改一个元件。

 

剥离

如果你只需要改变一个元件的一部份, 把这部分抽离出来使得只要修改这个子元件。

 

基准测量

 

在项目开始时先考量真实环境的状态。这违背工程师马上动手修东西的本能，但是有了基准线之后，你才知道你真的有把东西修好。

学习

 

表明意图

 

在执行程序前, 先大胆的预测将会发生什麽事。

具体假设

 

当程序执行不合预期时，在做修改前, 先明确指出你觉得什麽事做错了。如果你有两种以上的假设，分析这些假设有哪些差异。

 

移除外部细节

 

当报 Bug 时，找出最简短的重现步骤。 当把错误离析出来后，找到最短的测试案例。当使用新的API时，从最基本的范例开始。「这些部分应该无关紧要吧」，错误假设的代价只有出事的时候才能察觉。 举例：在手机上发现错误，用 curl 来重现。

 

多重规模

 

时时在不同规模中游走。「这也许是设计问题, 而不是测试问题」。「也许这是人的问题，而不是技术问题」。 [这有点作弊，因为永远都是人的问题]

逻辑之外

 

对称性

 

几乎等同的事物，可以被切割成重複到的部分跟完全不一样的部分。

美感

 

「美感」是一个难以攀爬、有影响力的梯度，同时也是一个常被嘲笑忽视的、奔放的梯度。(例如： 行内定义一堆函数然后变得一团乱)

节奏

 

等待时机，储备精力，避免混乱, 直到时机成熟时。 时机成熟时, 将爆发力化为行动。

 

折衷

 

所有决策都有可能要面对折衷。更重要的是，去了解这些决策取决于什麽，而不是今天（或昨天）选择了哪个选项。

风险

 

趣事清单

 

当离题的灵感一来，记下来然后快速地回到工作上。当你空闲下来时，再回来查看这些清单。

 

培养灵感

 

灵感就像受惊吓的小鸟，如果你吓跑牠们，牠们就不会再来了。当你有灵感时，培养它，一点一点培养。即时抛弃不可行的点子，但是用数据说话，而不是因为单纯没自信而这麽做。

 

80/15/5 法则

 

把 80% 的时间拿来从事低风险/合理报酬的工作。把 15% 的时间拿来从事高风险/高报酬的有关的工作。剩下 5% 的时间拿来从事会让你开心且不在意是否有报酬的事。训练下一代来做你 80% 的工作，等到有人准备好代替你，你那15%的工作（或者，你那5%的事，虽然很少见）就能收成而成为你新的 80%。 不断重复这个过程。

 

结论

 

这份纲要中的流程说明了：从通过管理时间、加强学习来降低风险，到用你的大脑来谨慎地承担风险，还有快速分类你的灵感。