将程序记在脑子里

作者 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

1. 返回顶部

   记忆大师

   2007年10月22日 下午8时1分 发表人 cao yunfei

   把程序记在脑子里肯定对编程是有很大好处的，但是对记忆力的要求太高了。

   回复

2. 返回顶部

   关于第七条

   2007年10月22日 下午8时11分 发表人 凉粉 小刀

   只有实践过的人才有发言权，不要想当然的以为对项目有利还是不利。

   回复

3. 返回顶部

   不太同意！

   2007年10月22日 下午8时48分 发表人 wake jong

   不太同意！
   当程序放在脑子里，那么，其他没写过（看过）该程序的怎么办？
   他们靠什么来理解这些代码的意思？还是要依赖注释，或者其他文档。
   ---
   在中国，人来人往是常事。维护程序的时候，大家都要一个共同的沟通基础。

   回复

4. 返回顶部

   Re: 不太同意！

   2007年10月22日 下午9时50分 发表人 霍 泰稳

   作者不是让你把代码只记在自己的脑袋里，而不和别人分享。他的本意是你应该记住那些编程中非常熟悉的场景或者案例，这样在下次遇到相同问题或者类似的项目时就不会从头再来。
   
   这种方法不仅对开发人员，对其他职业者同样适用，因为总结经验对下一步的行动总是有帮助的。看来有点“万物相通”的道理。

   回复

5. 返回顶部

   Re: 关于第七条

   2007年10月22日 下午10时35分 发表人 cao yunfei

   避免多人编辑同一代码块，不是拒绝pair programming。pair gramming 的时候对一块代码是一个人在编辑，另一个是在看。当然代码块有粒度的问题。合理的粒度下应该是没有多人编辑同一代码块的。

   回复

6. 返回顶部

   不轻易落笔

   2007年10月26日 上午5时16分 发表人 Necromancer B

   还有一点，就是在动手写代码之前，就应该先想想清楚。或许Tdder会说，不继持续的重构中，这些都会自然显理的。那你要是没想清楚，你的Test是从何而来？
   
   个人经验，每天上班要有三十分钟公交车程，那是最好的思考时间了。

   回复

7. 返回顶部

   Put a model, not a program, in your head!

   2007年11月5日 上午3时12分 发表人 Charlie Zhang

   Paul Graham 认为“代码就是你对某个问题的理解。所以，只有当你把代码牢记在脑子里，才算真正地理解问题”。
   
   这好像明显是错误的。我们知道，软件开发的一个基本模型是 Problem - Solution 模型。理解问题，当然要依靠需求模型和分析模型。代码和程序是针对问题的实现。显然代码是问题的 Solution，而不是问题本身。依靠“把代码牢记在脑子里”来“真正地理解问题”，这是缘木求鱼。
   
   根据张恂本人 14y+ 的编程经验看，把程序记在脑子里，实在是非常笨拙的方法！有没有真正敏捷的做法？有：把模型（程序模型）记在脑子里！不要忘了，敏捷大师 Martin Fowler 同时还是 OOAD 大师。我这里所说的模型或者程序的模型就是通常理解的软件设计模型（Design Model）。
   
   模型是对程序、代码的抽象。什么是抽象（Abstraction）？简单的说，抽象就是对事物的简化。举一个最最简单的抽象模型的例子：1 + 1 = 2，不错，您在幼儿园小班时已经学过了抽象，是吧。抽象能力可以说是人类的本能。建模和抽象思维是数万年前，原始人类，咱们的老祖宗就已经掌握的技能。您是否还记得欧亚大陆、非洲大陆上的古老岩画和壁画？怎么如今的新新人类就不会了，忘祖了呢？
   
   在十多年前，学生时代，发奋学习计算机编程的张恂和同学们就普遍知道在编写程序代码之前，首先要把程序的基本流程和计算步骤，也就是程序的设计原理搞清楚，不管你是否真的画出了流程图（如今的 UML 活动图），至少在自己的脑子里要有一张流程图。连流程图都错了，你的程序还可能正确吗？
   
   专业程序员和软件工程师们还知道，软件的算法、数据结构、设计模型（也就是针对软件问题 Problem/需求的抽象解决方案 Solution）远比真实的程序代码（具体 concrete 的解决方案）更重要，用高级程序设计语言编写的软件程序不过是这些软件设计思路和方案的具体体现，一种实现方案，而实现方案往往有很多种可能。
   
   往往同一个算法（数学模型），同一个设计模式（软件模型），同一种数据结构（信息模型），既可以用 Java 实现，用 C# 实现，也可以用 Ruby 实现，用不同的程序代码、风格实现。而算法错了，数据结构错了，架构设计错了，你的程序编写得再漂亮，那也不过是一堆废物，优美的垃圾（呵呵，行为艺术？），这也就意味着，你在大脑里记忆的是一堆废物。还记得 Garbage In, Garbage Out 的谚语吗？
   
   我不知道，是否真的有人，会一行一行地去死背、默写程序代码。你能记忆多少行？5000 行，1 万行，还是 20 万行？普通人的大脑记忆容量是非常有限的，人类最不擅长的是机械式、大容量记忆，这点无法与电脑相比。把关键的流程图/活动图、类图、状态图、交互图记在脑子（或者画在文档）里不是更简单、更敏捷吗？
   
   模型与程序，一个更简单，因为抽象而更接近事物的本质，因为图形化而便于人类大脑记忆和识别，同时数量也少，另一个更复杂、行数更多、规模更大，而且为了便于 Compiler 处理可读性也较差。您更愿意把哪个放在自己的脑子里？
   
   所以，按照张恂勇敢提出的中式敏捷理论，OOAD 和 UML 建模其实都是非常敏捷的，最佳敏捷实践！很遗憾，不知道为什么现在众多西方的敏捷专家有意或无意地忽略/忽视了这一点。
   
   我们认为，21 世纪不懂 OOAD 的程序员，应该属于半拉子程序员。半拉子程序员的其他症状还包括，不知道、不确切地明白自己编写的程序到底解决啥问题（不会分析需求的程序员），不知道、不确切地明白如何测试、验证自己编写的程序（不会测试的程序员）。有关半拉子程序员的问题，我将另文讨论，这里就不扯远了。
   
   Graham 推荐的那八点建议好像也不大靠谱。
   
   最后来个 [技能小贴士]：
   
   您如何记忆常用的设计模式，比如 GoF 模式？专业程序员常用的最简便、最有效和最敏捷的方法是把 GoF 模式的 UML 模型（类图、交互图）刻在自己的脑子里，而通常没有必要去死背/记忆那些实现程序和代码。不信，你试试看。
   
   太极敏捷/OO派
   www.zhangxun.com

   回复

• 更早的 >