我老爸经常对我说,“慢点,儿子,这样事情会完成的更快。” 我曾经在旧金山湾区的多家高科技初创公司工作过。现在,我52岁了,我编码时速度慢了、思考的东西多了。 我像一个写代码的设计师;当你读这篇文章的时候你会明显地感觉到这一点:) 最近当我和一些年轻的程序员一起开发一个项目时,慢速编程对我来说是个问题,他们信仰快速实现、迭代式修改代码。开发时,我们被鼓励使用相同的代码库,它就像一大锅汤,如果我们持续地、用力地搅拌它,一个完整的东西就会出现。 |
然而它不会。 这些程序员中的许多相信所有的工程师都是可替代的这个谬误,以及没人应为代码的任何一方面负责的观点;任何程序员都应能在任何时间改变代码的任何一个片段。毕竟,我们有像github一样能管理、合并任意多的,来自任意数目员工的异步提交的优秀服务。只要每个人经常提交commit,且不破坏任何东西,那么一切都会工作得很好。 扯淡。 你不可能仅靠心意就取代了设计过程。它自文明的曙光以来就一直存在着。而且,即使是那些最新的灵活开发工具,不管它们有多灵活,都不能取代能建立起大教堂,铺设出铁路,拍摄出唱片电影的良好的实践与真实的合作。 同样,再怎么多的编程总量也不能产生一件能节约软件开发时间,把开发速度加快到一堆代码猴子水平的编程工具。 |
节奏紊乱 让我从快速编程的程序员之中脱颖而出,成为一名慢速程序员的那次意外,其实是一中形式的 节奏紊乱 – 那时候我有一个被其他的程序员笑称是机关枪式迭代的编码节奏. 我的编程风格被描述成拥有各种各样的大小和时间尺度的有机弧线, 其中每一个的开始都是探索、反复尝试以及各种错误、小伎俩,以及临时变量. 基本上,还算是感觉良好. 看上去还是像模像样的. 过段时间后,我会回过头来圈圈点点。每一段弧线的结尾都像是某种准备实现的代码. (“打扫战场”是每个回合结束后必须要折腾的事情). 我编写代码做出贡献的同时,策略、设计方案以及架构上的突发情况不断. 而有时,在一个成熟的机制出现之后, 我却会回过头去重新开始, 因为我那时候就会想到实现某个东西的更好方式. 有时候我是错的。有时候我又是对的. 除非完全成型之后让我眼见为实,否则永远都没办法知道对错. |
总而言之,让我们回到一起搞大掺和的程序员们身上. 问题就成了这样: 如果整个软件生态系统没有任何的迟滞和停顿——在发展和应用设计的整个过程中按部就班风平浪静,那么一个人,或者甚至是一个快速的编程者,他是如何做出一个好的设计来的呢? 任何生成快速编程同慢速编程其实一样 (除开前者比较快之外), 都是没有真正理解设计过程的. 同样的原因,很多的神经学家现在都认为类似流体流动的神经元放电会在整个大脑有一种临时占据所有思想和意识的浑(混)响,那就是好的设计需要花费时间. |
处在旧金山湾区的,由风险投资所支撑的软件开发都是行进在热火朝天的快车道之上的. 在一个流程中资金被动态的投入到了非自然的需求上,其实应该最好是留给设计革新的自然行业节奏上去的. 快并不总是好主意. 事实上,慢一点实际上有时候就意味着更快 – 那种时候所有的东西都是讨论和做好过的. 数字科技是如何侵入我们的自然规律式的节奏的,这一个主题早就被 Rushkoff 的 现实冲击 一问所阐释. 还有另外一个问题: 对技术近乎狂热的崇拜和追求– 迷信般的迷恋着工具. 人们很想知道软件问什么这么烂(是的,它很烂). 软件很烂大都是因为纸上谈兵. 快速的编程者会围绕一些拥有小伎俩的工具去构建一些拥有小伎俩的工具来帮助他们编写代码. |
这也是为什么, 我相信软件开发需要各种老人参与其中, 包括: 女性, 教育家, 艺术家. 需要更多的"人-人", 更少的"事-人". 我指的参与, 不是让他们在咨询台服务, 或是装饰下界面(UI flower arranging). 我指的是真正参与开发– 让软件更加人性化. 还好, 我不是码字员. 我的一个朋友, 一个成熟的女性软件工程师, 她有一句名言: “编程不等同于码字”. 虽说这个道理大家都知道, 不过, 常用它来提醒下自己, 也不是什么坏事. Brendan Enrick 也在讨论这方面的问题. 正是因为敲击键盘的是程序员, 才使得这项工作变成了编程, 而不是码字. 说白了, 编程其实就是, 把各种想法, 设计 语言, 逻辑和心智建构(mental construction)存入计算机记忆体中的一项活动. |
我的妻子经常走到院子里问我:“你在编程吗?”我的答案常常是“是的”。我经常是在用花园剪修剪树枝或是在移动堆肥。 植物、泥土和剪刀对于编程的作用就像键盘和发光的屏幕一样。 我们正从工业与经济时代过渡到一个可持续发展的年代。是的,新的软件与生意需要生长。然而,为了可持续性,它们需要缓慢地生长,需要我们的呵护,一如我们对待美酒,对待孩子一般。 |
from:http://www.oschina.net/translate/the-case-for-slow-programming