编程王道，唯“慢”不破
英文原文：The Case for Slow Programming
人和人之间编程速度的差异还是很大的，有的程序猿写代码非常快，有的却常常是龟速。Jeffrey Ventrella最近在一篇文章里探讨了这种编程速度的差异，他是绝对的龟速派代表，来看看他对编程速度的看法。
我爸常跟我说的一句话是，慢一点码，才能快点把程序写完。
我在旧金山很多家互联网公司工作过，现在已经 52 岁了，对于程序猿这个职业来说，我的年龄算偏大的。我写代码的速度近乎龟速，事实上，我更像是一个会写代码的设计师。
以前有一次，我和一些比较年轻的程序猿一起工作，他们信奉的编程宗旨是“速度快、更迭少”。我们在同一个 codebase 里合作，就像在共同煮一大锅汤一样。如果我们每个人都持续不间断的贡献代码的话，未来这个工程应该就会很美很壮观的呈现出来。
但是并没有。
问题在于，这些年轻的程序猿们在心里其实有这么一种思想，他们觉得：1、每个人都是可替代的；2、没人应该对某一部分的具体代码负责；3、所有人应该都可以任意修改整个工程的代码。
他们觉得，现在已经有了github这种神器用来管理异步时间内的代码贡献，只要每个人都持之以恒的贡献代码，工程和产品就会顺理成章的出炉了。
事实不是这样的。编程从来就不应该是拿工具来减少软件开发的时间的。
编程应该是一项有节奏感有韵律的运动。我倾向于把工程依照不同的规模和时间度量分成不同的涂层，每一个涂层再从探索、实验、error、临时变量这些细小的东西开始做起。有点像建设脚手架的形式。每一个涂层最终完成的时候是一段可以部署和扩展的 implementation-ready 代码。这种开发过程有点像是从策略到设计方案最后到完成一栋真正的建筑。
有时候当这栋建筑完成之后，我还会推倒重来一遍，因为我觉得我有更好的建筑方法。这种新的方法有时候是对的，有时候是错的，事实上除非真正去再做一遍，不然你永远无法知道究竟哪一种方法更好。
回到最初那锅汤的问题：在软件开发生态圈里，关于对整个设计流程产生推动与支持的混合思考是很重要的，没有这一部分的工作，再快的程序猿又能做出多好的设计？很多神经系统科学家相信神经元信息的流动在大脑的传导过程中会有一个短暂的堵塞和混响，这对思维和感知会有很重要的作用。编程的设计也应该是这样，需要时间。
慢速编程运动
慢速编程运动在维基百科里的解释是这样的：慢速编程运动是慢速运动的一部分，这是一种强调谨慎设计、高质量代码、软件测试和思考的软件开发哲学，反对混杂组装、布满 bug 的代码，以及过于快速的发布周期。
世界上的软件开发团队都在寻找更具预测性的工程项目，希望能促成更多的程序员拥有可持续性的职业生涯。他们提议了一些可以切身操作的实践方法，比如结对编程、代码审查和代码重构，以开发更可靠更健壮的软件应用。
在旧金山海湾地区，风险投资支持的软件开发正呈现出一种高烧般的热度。利益正驱动着软件开发以一种完全不自然的不对拍的节奏感在运动，它打乱了设计进化（design evolution）原本应有的周期节律和生物钟。关于这一点，Rushkoff在Present Shock里说得很明白了。
另一个问题在于，人们对科技越来越诡异的迷恋，以及开发人员对工具异常的狂热。大家总在说，为什么有的软件和应用做得这么烂？没错，确实很烂。烂的原因在于，太多一味求快的程序猿在忙着建设工具，然后用这个工具去支持和适配另一个他们建好的工具，然后再用这个工具去支持和适配另另一个他们建好的工具，然后再用这个工具帮他们写出更快的代码。
这就是我为什么觉得软件开发需要更多的“人”，而不是“工具”的原因。并且，这些人不仅仅只是帮忙做做外面的 UI 艺术之类的而已，应该要有更多的人深入软件开发的内部——确保软件更多的与人文产生共鸣和回响。
当我们谈论编程时，我们在谈论什么？
编程不是打字。
所有的程序猿都明白这一点，但是大部分人都容易忘记这一点。
在电脑前噼里啪啦、弹指挥间的感觉确实很爽，这种键盘上啪啪啪的快感却很容易让人忘记编程是一项脑力活动，而不是体力劳动。编程的真正奥义在于，把人类的思维、设计、语言、逻辑和精神创造以一种计算机可以识别和储存的方式记录下来。
我妻子有时会跑到院子里问我，你在编程吗？我说，对，我在编程。事实上我可能正拿着钳子修剪花盆里的花草，或者做做施化肥之类的事情。
植物、土壤、钳子，这些都是编程的好工具，正如键盘、鼠标和双屏幕一样。
目前，我们正在经历一个经济产业的转型期，从新兴到可持续发展之间的一次过渡。新的软件产品和商业模式是需要发展，但为了互联网行业发展的可持续性，这种速度应该降下来一些了。撸代码不仅仅只是在撸当下用户的需求，撸的更是未来某个行业领域的架构基础。代码应该在程序员的关爱下慢慢的、茁壮的成长。Like good wine. Like a baby.
