最近，在一篇名为《将程序记在脑子里》的文章中，Paul Graham 认为“代码就是你对某个问题的理解。所以，只有当你把代码牢记在脑子里，才算真正地理解问题“。不幸的是，正如每个程序员所知，说起来容易做起来难：
把程序记下来不是件容易的事儿。如果你想要捡起几个月前的一个项目，并再一次真正想清楚它是怎么一回事，那可能要花上几天的功夫。即使是你手头上的一个程序，在每天开始工作时，你可能也要花上半个小时才能真正回想起来。这里有个最好的例子。那些在经典办公环境下工作的普通程序员从来不会遇到这种情况，说得更严重一些，工作在经典办公环境下的普通程序员从来没有真正地理解他们正在解决什么样的问题。
因此，开发人员怎么做才能让程序牢记在脑中呢？Graham 给出了八点建议：
- 避免分心
- 一口气做久一点
- 使用简洁的编程语言
- 持续重构
- 写易读的代码
- 小团队工作
- 避免多人编辑同一代码块
- 从小事做起
敏捷过程和实践可以看作是将创业起步阶段公司里的自发形成的做法映射成可在大组织里推行的措施。作为种子投资公司 Y Combinator 的合伙人, Paul Graham 的大部分建议是针对刚起步的小公司提出的，因此，问题就变成了以上建议如何对应到敏捷实践？当然，大多数敏捷开发者习惯于写可读性代码，持续重构，小团队工作，以及从最小却提供真正价值的小事儿做起。而且很多敏捷开发者还不断采纳更有威力的语言，如 Ruby 、 Erlang 、 Haskell ，甚至 Common Lisp 。
但是，对于不太容易映射到敏捷实践的那些建议又怎么认识呢？（1）和（2）是紧密相连的，而且有些人会认为，共享工作空间反而容易分心。另一个常见的敏捷实践就是代码集体所有制，与（7）相矛盾。这么说来，是敏捷拥趸们做错了吗？还是这些实践之间的冲突反映了大公司和小公司工作方式有某种不可避免的差异呢？
英文原文链接： Holding a Program in Your Head
暂无签名
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论