将程序记在脑子里

 

作者 Kurt Christensen译者 乔梁 发布于 2007年10月22日 上午7时50分

社区

Agile

主题

敏捷技术,

协作

最近，在一篇名为《将程序记在脑子里》的文章中，Paul Graham认为“代码就是你对某个问题的理解。所以，只有当你把代码牢记在脑子里，才算真正地理解问题“。不幸的是，正如每个程序员所知，说起来容易做起来难：

把程序记下来不是件容易的事儿。如果你想要捡起几个月前的一个项目，并再一次真正想清楚它是怎么一回事，那可能要花上几天的功夫。即使是你手头上的一个程序，在每天开始工作时，你可能也要花上半个小时才能真正回想起来。这里有个最好的例子。那些在经典办公环境下工作的普通程序员从来不会遇到这种情况，说得更严重一些，工作在经典办公环境下的普通程序员从来没有真正地理解他们正在解决什么样的问题。

因此，开发人员怎么做才能让程序牢记在脑中呢？Graham给出了八点建议：

1. 避免分心
2. 一口气做久一点
3. 使用简洁的编程语言
4. 持续重构
5. 写易读的代码
6. 小团队工作
7. 避免多人编辑同一代码块
8. 从小事做起

敏捷过程和实践可以看作是一个“将创业起步阶段公司的成功做法引入到大型组织”的一个途径，而且看上去这也是可行的。作为种子投资公司Y Combinator的合伙人, Paul Graham的大部分建议是针对刚起步的小公司提出的，因此，问题就变成了以上建议如何对应到敏捷实践？当然，大多数敏捷开发者习惯于写可读性代码，持续重构，小团队工作，以及从最小却提供真正价值的小事儿做起。而且很多敏捷开发者还不断采纳更有威力的语言，如Ruby、Erlang、Haskell，甚至Common Lisp。

但是，对于不太容易映射到敏捷实践的那些建议又怎么认识呢？（1）和（2）是紧密相连的，而且有些人会认为，共享工作空间反而容易分心。另一个常见的敏捷实践就是代码集体所有制，与（7）相矛盾。这么说来，是敏捷拥趸们做错了吗？还是这些实践之间的冲突反映了大公司和小公司工作方式有某种不可避免的差异呢？

英文原文链接：Holding a Program in Your Head

标签

评论,

反模式,

最佳实践,

补充实践