52岁程序员的观点:编程要快还是慢?

我老爸常对我说,「孩子,别太着急。慢点来,你完成工作的速度会更快。」

我曾在旧金山湾区的很多高科技创业公司工作过。现在已经有52岁,我编程的速度不快,却经过深思熟虑再开始。我就像是一个写代码的设计师;随着你的深入阅读,这一点将会变得非常显而易见。

最近,我和一些年轻的程序员一起做项目,他们信仰快速开发,迭代修改,这使得我缓慢的编程遇到了困难。这份工作,鼓励我们在同一个代码仓库里面工作,就好像是一大锅汤,如果我们一起不停的大力搅动,一个奇迹就会从中诞生。

实际上并不会。

这帮程序员信仰“所有的工程师都是可以被取代的”这种谬论,因而没有人需要为这些代码的任何方面负责;任何一个程序员可以在任何时候,改变代码的任何部分。毕竟,我们有像Github 这样特别赞的服务,来管理和合并来自任意数量的程序员们提交的任意数量异步开发的代码。只要每个人都频繁的提交(commit),不破坏任何东西,那么所有的东西都会好好的。

扯犊子。

你不能期许省略设计过程。这一过程在人类文明开始时就存在了。当下最新最灵巧的开发工具,不论它多么灵巧,也不能替代那些建造了大教堂、铁路和拍出长篇电影的最佳实践和现实中的合作。

任何编程都没能创造这样一个工具,可以减少软件开发的时间,让一群猴子以它们可以接受的速度来工作。

心律不齐

在这样一群信仰快速开发的程序员中,做一个我这样缓慢编程的程序员的代价,就是某种形式的心律不齐——因为我自己的编程节奏都被其他程序员那机枪似的迭代开发搞乱了。我的编程风格是这样,由一些不同尺寸和时间尺度的弧线组成,开始是时候是探索、试验和出错,使用一些hacks和临时变量。基本上是在做一些构建工作。程序初露端倪。稍后,我会回头去做些修改。最后结束的时候,是完整实现的代码(「打扫战场」是完成我这个工作循环的一个必要的部分)我编写代码的这一流程与策略、设计方案、架构的出现是同步的。

有时候,当一个成熟的方案出现后,我会回头重新开始。因为我觉得我会有更好的点子。有时候我错了,有时候我是对的。在一个方案完整的呈现在我面前之前,我是没有办法去知道对错的。

总之,先回到“一锅汤程序员”吧。问题是这样的:总体上,软件生态系统并没有停一停的意思——没有机会去引入设计过程,那么怎么能有人,而且是快速开发程序员,做出好的设计呢?

那些认为快速编程和慢速编程一样(除了速度以外)的程序员,他们并不理解设计过程。同样,神经学家现在认为,像流体一样穿过大脑的神经元放电会产生颞混响,这和思考,意识息息相关,好的设计是需要花费时间的。

慢速编程运动

维基百科记载:「慢速编程运动是慢速运动的一部分。这是一种软件开发哲学,强调仔细的设计,高质量的代码,软件测试 和思考。 尽量避免豆腐渣工程,垃圾代码和过快的软件发布。」

维基百科同时还这样描述「慢速软件开发」:「作为『敏捷开发』运动的一部分,世界上各个软件开发者团体期待更有预见性的项目,意在获得可持续的职业生涯,同时保持工作和生活的平衡。他们进行了诸如结对编程代码审查代码重构等实践。这产生了更多可靠的,健壮的软件」

在旧金山湾区,那些由风险投资支持着的软件开发,火急火燎地开在快车道上。

资金被投资在研发过程中的那些非自然的需求上,实际上应该把它留给设计演进过程中那些符合自然节奏的点。快,并不总是一件好事。实际上,放慢速度有时候意味着快。数字科技是如何侵占我们自然的节奏的,这一个主题在 Rushkoff 的Present Shock 中有所阐述。

还有一个问题:对科技近乎宗教般的痴迷——以及对工具的迷恋。人们想知道为什么软件很糟糕(没错,它很糟糕)。软件之所以这样糟糕,主要是因为纸上谈兵。快速开发的程序员会编写一些工具,来帮助他们使用其他的一些工具,他们利用这些工具来编写自己的代码。

这就是我为什么认为我们需要一些年长的人,女性、教育者和艺术家参与到软件开发中。更多人与人的交流,更少工具与人的交流。我指的不是做一些外围的工作,提供问询或是装饰UI。我的意思是深入内部——确保软件能够和用户产生共鸣。

我庆幸自己不是打字员。

我的一位朋友是一个成熟的女程序员,她曾有过这样精彩的吐槽:「软件开发不是比谁打字快。」每个人都明白这一点,但是时常这样提醒自己也不是什么坏事。

Brendan Enrick讨论过这样的问题。实际上,程序员们不停地用手指在键盘上猛戳,就好像这种肢体活动是和编程同步的。但是实际上编程是这样一种行为,它把思考、设计、语言、逻辑和一些心理层面的东西变成某种可以存放在电脑内存中的形式。

我的夫人经常会走到小院里,问我:「你在编程吗?」通常情况下我的回答是「是的」。实际上我正在用钳子修剪枝叶,或是到处施肥。

植物、泥土和剪刀和编程有很大的关系,就像与键盘和发光的屏幕一样。

我们正在从工业时代和经济纪元过渡到一个可持续发展的年代。是的,新的软件和新的商业需要增长。但是需要具有可持续性,它们要慢慢的,有爱的增长。就像美酒,就像宝贝。

打赏支持我翻译更多好文章,谢谢!

打赏译者

打赏支持我翻译更多好文章,谢谢!

任选一种支付方式

1 收藏 2 评论

关于作者:艾凌风

初入职场小码农;翻译组的勤务员;C/Python/在线教育/英文翻译 个人主页 · 我的文章 · 76 ·    

相关文章

可能感兴趣的话题



直接登录
最新评论
  • 哈哈   2015/01/08

    我不是搞互联网的,我希望有一天我的东西像文章中说的那样有价值

  • kaylyun   2015/01/08

    这篇文章,值得每个程序员及其管理者思考。
    对代码的流程、策略、方案、架构会随着能力的增长而改变,就像看待这个世界的角度一样。
    所谓:"见山是山,见山不是山,见山还是山。" 可以试着去引导思考的方式,但通过阅历积累的思想上得鸿沟不可能一日之间抹平。
    一个团队内,即需要“慢速编程”的人,同样也需要“快速编程”的人,他们都是这个团队的重要组成部分。
    类似金庸笔下的气宗与剑宗,剑宗成长迅速,但天花板较低,后劲不足;而气宗成长慢、早期毫无战斗力;虽然气宗得道后天下无敌,但时间成本是不容小觑的关键因素。因为我们面对的是残酷的市场竞争,高效、顽强的对手。
    如果要将所有人按照“气宗”的模式打造到“见山还是山”的境界,恐怕市场不会给与我们这样得机会。所以,在一个团队中,“剑宗”模式同样重要。
    幸运的是,在编程的世界里,"剑宗"可以在“见山不是山”之后,优雅的向“见山还是山”的“气宗”境界转换,而这一过程是及其自然的。
    一个团队,急需要将军,也需要士兵。士兵在经历了战火洗礼后,随着对战略战术的认知可能成长为出色将军。但是一个部队中是不应该把所有的士兵培养为将军后再开赴战场的。

    所以,编程的思考模式都没有错,只要它是正向的,只要它符合团队利益及其当前环境。

跳到底部
返回顶部