一位39岁程序员的困惑：知道得越多编程越慢怎么办？

Zilk1988 年 14 岁时就开始编程，此后尝试过几种职业，最终仍是在 1997 年决定成为职业程序员（又称码农），如今已经 39 岁，对此选择依然无怨无悔。

可是后来他发现一个问题，本身的经验越丰富，完成项目或任务的时间反而越长。由于他见过了太多可能会出问题的状况而对选择踌躇。比方说，假设他刚想 到要写一段写入文件的代码时，电光火石之间他就已经开始担忧起下面的一系列的问题：权限、锁定、并发、原子操做、迂回 / 框架，不一样的文件系统、目录中的文件数、可预测的临时文件名、PRNG（伪随机数生成器）的随机性质量够不够、操做过程当中断电怎么办、API 怎么写才好理解、文档应该怎么写等等。

简而言之，他的问题已经从“怎么作”变成了“怎么作最好 / 最安全”。

结果就是他他作出来的版本坚如磐石，可是也致使他完成项目的时间比菜鸟还要长。

Zilk 说，他本身精通算法、热爱数学，享受复杂项目，专一度也没有问题。也许经验是有问题（尽管已经 39 岁了），致使惧怕犯错，使得项目费时。因此他在StackExchange上邀请同行帮助他解决这个问题。

下面就是精选出来的解决方案：

Telastyn：

你完成项目并不慢。之前你认为本身的菜鸟项目作完了但实际上并无完。你应该把质量卖给客户。“公司能够作得更快成本更低，但项目真的完成了吗？或者说你愿意花几年的时间找 bug 吗？”此外，你还应该知道并接受那句老话：“完美是好的敌人。”

sevenseacat：

“好、快、省只能 3 选 2”。之前你懂得少因此牺牲了“好”，如今你懂得多了却牺牲了“快”。

mouviciel：

彷佛你的经验的确不足:)。教训：遵照需求便可，不要想其余。这样才不会实现不须要的功能。

Satish:

应考虑敏捷方法论而不是瀑布流。先交付而后迭代交付。此举有助于下降风险和成本。

DXM:

彷佛你加入黑暗面：管理的时候到了。

我不是要建议你放弃编程变身经理。但从你的描述来看你的经验仅限于技术层面。写文件这么简单的事情你竟然能想到 10 个方面的问题，稚嫩一点的开发者绝对是想不出来的。这不是什么坏事，可是……

黑暗面的一切都与现值有关。它要考虑的是如何用最小的投入实现最大的产出（成本效益分析）。商业上的一切事情都要归结到成本、成功概率、失败概率、潜在回报等问题。作好这方面的数学而后采起相应行动。

哪怕你是开发者也无妨：忽略权限和命名冲突的状况下建个临时文件只需 5 分钟的时间。净收益：团队其余成员能够开始依赖此文件的代码编写工做。这是否是一个完美的解决方案？固然不是。99% 呢？95%？90%？这些可能性是存在的。

还要问你一个问题：你对技术债务（注：快速解决但会增加后续维护成本的作法）感受如何？有人认为不该该有技术债务。我不一样意。跟商业同样，技术债 务 让你能够借到“金钱”和“时间”以便晚点交付某样东西。2 年作出一个完美解决方案，或者用 4 个月时间快刀斩乱麻做出客户可使用而且购买的东西，哪个更好？判断固然要因状况而定，可是大多数状况下若是你要让客户等两年的话，客户可能早就跟竞争 对手签约了。

关键是像管理商业债务同样管理好你的技术债务。借的钱不够的话就拿不到最佳的投资回报。可是负债过高的话利息会把你压垮。

个人建议是用番茄工做法。专一于小的时间间隔（番茄），而后为将来的工做 / 研究分配这些时间段，而且在执行的过程当中不断根据事情的优先级进行调整。

Saul:

编程的一个关键是管理并控制好复杂性，这是个人最高优先级之一。忽略了复杂性管理，要么缺陷频发，要么软件的 ETA（预计到达时间）急剧增长。

软件复杂性有不少不一样的管理层次和办法，好的作法能够是这样的：“任何软件项目的最高优先都是客户满意度，这是客户指望的函数。”

换言之，软件复杂性取决于你控制客户指望的水平如何。

若是你接受这个观点，那么下面两点也很显然：

1. 客户指望必须明示

2. 客户指望永远均可以改变且经过协商完成。

你举了一个很好的例子，“直接写”仍是“无数的其余考虑”。考虑一下，若是有人详尽写下了此两者的需求，双方的功能描述仍是同样的吗？

一样是造飞机，F16 能飞，航模也能飞，但那能同样吗？

原本我打算把全部建议都摘录出来的，可是考虑到上述的精彩看法足以解决 Zilk 的困惑，而且为了践行这些建议，本文就此打住，感兴趣者可参见完整讨论。

最后我只补充一句：

你还能够看看麦当劳理论。

[本文编译自：programmers.stackexchange.com/36kr]