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

[iamqk]

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]

[宁波朱超]

楼主真心是个好程序员，建议楼主往PM方向发展， 编码的事情交给年轻人，楼主更多考虑框架性能业务等方面的事情。

[winner2050]

可以外包你的工作出去。

[fdsdfdsf]

可以做架构师了

[神-气]

[designer2006]

应该转行去做QA，不适合做开发了。无论是做系统架构，或者系统设计，或者Coding，都不能奔着“最好、最安全”的目标来做事。研发人员应该是一名工程商人，需要考虑投入产出比。合格的产品指的是“达到客户期望的产品”，而不是“完美的产品”。

[高omg]

找些灵感，放松心情，逃离选择困惑症。

[xghabc]

引用 楼主 iamqk 的回复:

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]

看一这一句话。。我突然笑了 但是后来他发现一个问题，自己的经验越丰富，完成项目或任务的时间反而越长。因为他见过了太多可能会出问题的情况而对选择踌躇。比方说，假设他刚想到要写一段写入文件的代码时，电光火石之间他就已经开始担心起下面的一系列的问题：权限、锁定、并发、原子操作、迂回 / 框架，不同的文件系统、目录中的文件数、可预测的临时文件名、PRNG（伪随机数生成器）的随机性质量够不够、操作过程中断电怎么办、API 怎么写才好理解、文档应该怎么写等等。 哈哈。。我就是这样。。马上开思考各种问题。。项目进度慢。。

[caofeng891102]

[狐狸大仙]

这里很多问题不应该是开发时的考虑。很多问题应该在框架内，统一完成。

[love_rrr]

[proteinboy]

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

[「已注销」]

39岁做程序员，这不是发生在中国吧。

[顾明轩]

这种程度上可以摆脱编程程序员范畴了，可以忘架构师方向发展

[ylovep]

楼主的 文章是转载的？

[隐官城头坐]

[fangtaohbjjxy]

项目型的公司不适合你。你适合做一些对安全性要求较高的，产品类的公司发展。比如做军工，安全软件的。不是杀毒软件公司。

[品铭工作室]

你欠缺的是不知道如何取舍的问题或如何做到适度的问题，和技术无关 有段时间我也有类似的经历，看一下软件管理方面资料可能会有所帮助

[openweb]

楼主应该放弃编码了，去做主管或技术总监之类的。