本文同步发表在 http://lawlietxxl.github.io/2016/06/09/mastering-programming-from-kent-beck/

翻译自Kent Beck的博客,原文地址. 个人翻译水平有限, 如果有更好的建议请留言, 谢谢.

从我多年观察高级程序员的工作流程中, 我发现了一些普适性的固定的模式. 而从我对一些业务娴熟的低层次程序员的训练中, 我发现他们并没有这样的工作模式. 当我把这些工作模式告知他们之后, 我已经可以看到他们的巨大变化.

下面是那些最有效率的程序员使用他们在地球上的3e9秒的方法.

本篇文章的主题是扩展大家的思路. 低层次程序员总是学着通过一次解决更多的问题来解决更大的问题.而高级程序员总是学着通过一次解决更少的问题来解决比前面大的多的多的问题.智慧的其中一部分是细分: 通过细分大问题得到的小的问题, 各个击破再组合它们的解决方案比直接解决大问题要轻松很多.

节省时间的方法

• 切片. 当拿到一个大的项目的时候, 把它分割成小的切片, 然后重新安排这些切片来满足你的需求.我一直能够更好的对项目进行切片, 并且找到它们的不同的组合方式满足不同的需求.

• 一次做完一件事. 我们都对效率看得很重, 所以很多人都为了试图省事而减少反馈周期的个数.这就造成了综合调试起来很困难的情况, 而且这种情况会导致比我们省下的力气更大的消耗.

• 可运行/正确性/快捷性(这是一次做完一件事, 切片, 使需求简单的例子)

• 使需求简单. 当面对一个很困难的需求的时候, 首先, 把它变得简单(警告, 这步可能会很难),然后实现这个简单的需求(切片, 一次做完一件事, 聚集, 隔离).切片的例子.

• 聚集. 如果你需要一次改变数个元素, 首先重新安排代码, 使这些改变集中在一个元素中.

• 隔离. 如果你只需要改变某个元素的一部分, 把这部分从元素中解绑成为子元素(使得该元素的全部都会改变).

• 基线测评. 在开始项目之前, 先测评一下现实世界的现状. 这其实是与我们工程师的直接下手解决问题的本能相对的,但是当你做好测评之后, 你就会明白你到底是不是在解决问题.

学习

• 控制运行结果. 在你运行你的代码之前, 必须要真真切切的预测运行结果是什么.

• 具体化假设. 当你的程序运行有误时, 如果你要修改你的代码, 那你必须要明确说出哪里有问题.如果你有多个假设, 寻找一个可以区别这些假设的诊断方法.

• 移除无用的细节. 当上报一个bug的时候, 寻找最直接的复现步骤.当分离一个bug的时候, 寻找最短的测试用例. 当使用一个新的api, 从最基本的例子开始.当出现错误的时候,"那些东西有问题"是一个很有价值的论断.

比如, 发现移动端有一个bug的时候, 用curl复现它.

• 多角度. 要能够从任意角度进行转换. 可能这是一个设计问题, 不是一个测试问题.可能这是一个关于人的问题, 不是一个技术问题.[骗你啦, 其实都是技术问题]

超越逻辑

• 对称. 几乎一样的事情可以分成一模一样的部分和完全不同的部分.

• 审美. 优雅是难以攀爬的一座山, 也是可以蔑视的一座. (比如在一大块代码里面包装了很多函数)

• 节奏. 一直等, 节省力量避免杂乱, 直到那个正确的时刻, 然后用最大的力量行动.

• 权衡. 所有的决定都需要做权衡. 知道你的选择以放弃什么为前提远远比你今天做什么选择更重要.

冒险

• 娱乐清单. 当离题的点子来了, 记录下它们然后赶紧回去干活.等你到了你的休息时间了, 再去看看这份清单.

• 喂食idea. idea就像是受惊的小鸟. 如果你不小心吓跑它们, 它们也许会回来在你身旁停驻.当你有一个idea的时候, 稍稍喂食(培养)一下它. 但是当你的数据不支持它的时候, 以最快速度作废它(而不能是因为你不自信).

• 80/15/5. 把你的80%的时间花费在低风险/回报率稳定的工作上.把你15%的时间花费在高风险/高回报率的工作上. 把你的5%的时间花在你的兴趣上(不计回报).教会你的下一任做你那份80%的工作. 在有人能接替你的工作的之前, 你那15%时间中的某个实验(或者5%的)将会回报你并且成为你的新的80%. 重复这个步骤.

结论

本文脉络是从通过规划时间和不断学习来减少风险, 到通过运用全部头脑和快速分析idea合理接受风险.