「漫谈」软件设计的目标和途径是什么？(3)

2.项目遗留的代码太烂是失控的原因吗？其实也不是，这是失控的一种表现结果。
3.团队成员水平参差不齐是失控的原因吗？也不是，这虽然是客观存在的事实，但是你这样把责任推到队友身上不合适吧，说不定队友也是这么看你的呢。
4.工期太紧张导致你无暇做设计规划是失控的原因吗? 当然也不是，这个是借口。。。就像你今天起床快要迟到了，你会选择光屁股不穿衣服就出门吗？
除了上述的一些事实，当然还有其他的一些因素，看起来都不像是导致失控的罪魁祸首。那么究竟是什么导致的失控？？？仔细回想一下，当我们觉得项目失控的时候通常是什么场景？
1.有个已知的bug，你改动的时候发现牵扯的东西太多了，牵一发而动全身，你不敢下手。你觉得代码无法控制了。。。
2.有个未知的bug，你找了好久找不到，代码太乱了。你觉得一股无力感。。。
3.有个新功能来了，你发现你要改这里那里，但是完全不知道改了会不会破坏现有的功能，也不知道新功能是不是真的可以work。你觉得你无法掌控这些代码了。。。
4.还有一些其他的情况，总之就是你觉得你无法掌控代码的真实行为了，你不知道你的代码会产生什么样的结果，就像薛定谔的代码一样。。。
那么还有一个场景，当你要开展一个新的项目，所有的一切都是新的，没有任何历史债务负担，这时候你是什么感觉？信心满满啊肯定是，这时候你不会觉得你会对接下来的代码失去控制，因为你现在一行代码都还没有。。。
所以是什么导致的失控？现存的无力维护(bug、新功能都是维护)的代码导致的失控，同时这也是失控的表现结果。那么你为什么会无力维护这些代码，因为它的真实行为和你理解的行为出现了偏差，你觉得它不可控了。这时候就是真的失控了，代码烂不烂其实并不是重点，只要你还能维护，这些都不是问题。
代码只会按照你编写的行为去执行，而不是按照你认为的行为去执行。
那么如何避免失控？编写可维护的代码。打死你噢，解释这么半天憋出这么一句废话，谁不知道要编写可维护的代码啊。。。
我只能说别着急，继续慢慢往下看。。。
5 目标-可维护性
既然我们的目标是避免失控，避免失控的途径则是编写可维护的代码。那么我就把可维护性作为软件设计的终极目标，而且没有之一。也称之为元原则，就是说我们目前所接触到的各自编程原则、建议和最佳实践等等都可以通过可维护性推导细化出来，并且不可与之相违背。