这个bug我都忘了是怎么处理的了，因为处理不了啊！改这里错那里，改那里错这里，咋整？应该是交给我们老大去头疼了，他可以联系国外的一个家伙——都不能说是同事，因为我们是外包公司，国外这家伙是发包公司的。据说他是现存的、唯一的一个从项目开始跟到现在的开发人员，像大熊猫一样保护起来的，像老祖宗一样贡着的人物。
我们项目组几个同事有时候就会聊：其实要做到在公司里“不可替代”也很简单，熬上十年就可以了。
这个“熬”字用得很传神，因为一般人真熬下来。很枯燥，没有成就感。每天都是debug，就像我上面这个bug，一个月，实际上啥都没做。本来还写了几行代码，但因为影响了其他地方，最后还得revert回来！
又学不到什么新技术，都是些历史遗留代码、老古董的技术。计算机技术日新月异，在这里面待上十年，真的会和外界脱节的。也就是说在公司里面，你会被当菩萨一样的贡着；但一旦离开公司，那就比较凄惨了，大概就是监狱里蹲了几年出来睁眼看世界的感觉。
代码质量也让人沉醉。if...else...啥的前面已经说了，我印象深刻的还有一次，改完了bug，老大让我跑一跑单元测试。
“哇塞！我们的代码居然有单元测试？高档货啊！这么牛逼……”当时我刚看书知道了TDD（Test Drive Design），一直没见过活的，心情非常之鸡冻啊。结果测试用例一跑，傻眼了，这么多叉，跑不过啊，完全懵了。
挺忐忑地找到老大，老大没当回事：“哦，本来就跑不过！”晕死，我。
“那跑这一遍又什么用呢？”我问，“我怎么知道我的改动有没有影响之前的测试结果呢？”以为理论上来说，在任何时候，单元测试都必须全部跑过。你改动前，全部能跑过；然后你改动后，还是全部能跑过：这样才能证明你的改动没有影响之前的代码测试结果。
“你先记录一下改动之前那些跑不过，然后对比一下改动之后那些跑不过，没有变化就OK啦。”老大笑着对我说，“只能这样啦，那些测试用例我们以前搞过，搞不定……”
所以绝大多数的程序员，其实是不愿意干这活的，他们更愿意使用新技术开发新项目，满满的成就感。我知道很多公司都这样：技术“高手”开发新项目，技术渣留下来做后续维护支持。
但我特别感谢这段经历，让我学到了太多的东西，很多书上以前看不懂的东西都慢慢地清晰起来。这些东西，比什么算法底层新技术有用得多——至少对于我来说是这样的。
比如，“一个项目，开发和维护的成本是2:8，开发是2，维护是8”。以前觉得怎么可能呢？因为以前搞装修，房子装完了就完了，几乎就没有维护成本。质保金，3%而已，不过是给业主一个放心。但软件开发，那就真是这样，维护的成本太高了。我估算了一下：
为什么小作坊的效率最高？因为他压根都不考虑后面维护的事，呵呵。而树雍多花出来的时间，做设计写文档，其实就是为了能够减少后期维护的成本。
当你不考虑维护的时候，你就没办法理解软件工程中很多“脱了裤子放屁——多此一举”的做法，比如文档，比如面向对象，比如分层、模块化，比如敏捷和测试驱动，等等。而更重要的是，只有当你亲身体会到了维护的艰难和痛苦之后，你才有可能相对客观中正的拿捏开发效率和代码质量的平衡。我的观察，十个程序员，九个都会有意无意地忽略代码的可读性、可维护性：这是人性。忙的时候，可以推说是“工期太紧赶着上线”，但闲的时候呢？我也没看见多少程序员会主动地把以前的代码弄出来重构一下。
也是通过这段经历，我发现除了数据结构和算法的复杂度，还有另外一种复杂度的管理，随处可见，而且相当具有挑战性：业务逻辑的复杂度。而企业级应用架构的核心命题，就是管理这种复杂度。
+++++++++++++++++
欢迎评论评价、传播分享，你的任何操作，都是我坚持的助力。
多快好省！前端后端，线上线下，名师精讲
更多了解 加：
