避免“一次交付，终身维护”

原文链接：https://javascript.plainenglish.io/a-former-client-told-me-my-code-is-bad-because-his-programmers-cant-fix-my-mess-157f0196c4c3

某天我突然接到前客户的电话，抱怨我之前编写的项目让他额外花了不少钱。

这个项目是我在之前为他的杂货业务所设计的一个支付自动化系统，在我交接完这个项目的很长时间以后，我听说，这个系统总是不能完成支付交易。现在的我不知道更多其他细节，虽然我向他解释了这个系统的工作原理，当时的反馈还不错，但是他还是希望我能够继续指导他项目当前的程序员来更改这份代码。面对前甲方的“骚扰”，我似有一种“一次交付，终身维护”的感觉，但在我看来，不应如此。我将当时回复他的内容做了一个总结：

1. 代码通常会随着需求的变化而增多，而这些需求在架构设计上还无法预见。所以需要在以后对架构进行调整来满足新的需求。然而，随着代码库的增长，改变架构的成本会更高，难度也更大。
2. 在设计任何的软件架构时，都要经过权衡再做出决定。但是，没有人能够预见未来。这意味着，程序员需要在没有任何依据的情况时做出决定。然而，客户或者部门总是习惯于隐瞒他们的计划。
3. 如果要满足新的要求，就需要对代码进行大规模整改。很显然，一般的程序员都具备可以在一个没有故障的系统上快速满足新需求的能力。
4. 这种情况一般出现在软件工程师从头开始一个新项目的时候。当然，有时候软件工程师也会参与项目的更改，但是很多时候，特别是当程序员要修改其他人代码时，就会面临一些混乱的局面，而且还必须要在不破坏任何其他东西的情况下进行操作。
5. 另外是关于技术债务的问题（技术债务指开发人员为了加速软件开发，在应该采用最佳方案时进行了妥协，改用了短期内能加速软件开发的方案，从而在未来给自己带来的额外开发负担），每次做出管理决策后，这种债务就会增加。而往往要等到维护和扩展成本增加的时候，才会意识到问题。
6. 坏代码往往不是源于执行层面的错误，而是来自想法层面的问题，比如想法过于飘忽不定，或者考虑的不够长远，只为客户着想而不考虑产品或者系统的发展。
7. 在最短的时间内以最小的努力创建代码，以最低的风险满足客户要求，这对销售是很有利的，但是也存在一个缺点。这样的代码在可维护性和可扩展性方面是不过关的。
8. 软件是很难真正全面了解的，软件工程师不能整天无所事事，想象系统是一个整体，可以一蹴而就。工程师需要按部就班的工作，每天一点点的开始迭代、改进、再适应。