深刻的认识到：代码的可维护性是多么的重要。
在刚开始学编程的时候，我成天梦想的是要“写一般人都看不懂的”牛逼哄哄的代码，代码要“跑起来像风一样”。所以什么“究竟该用+还是string builder”、“为什么比较字符串时不要使用ToLower()，而应该用ToUpper()”、“为什么我不使用Linq：看反射造成的性能开销”，等等之类的文章，我都无比膜拜。
直到我到了某家公司，开始修他们代码里的各种bug。
代码的跨度超过了10年，从最早的c，vb，到java，最后.net，反正我看到的，就这么多种语言。代码量之大，嗯，我还真说不出来：因为我们下载的源代码都是“分段”的，一些“老”的不常用的，我们就只用编译后文件而不用源代码了，就这样，我记都几个G了，反正check out的时候我们就不知道能干嘛（公司没外网，那时候也没智能手机），只能苦等啊……
修bug更是一把辛酸泪。这故事我以前讲过：
在我花了两周的时间找到一个bug的位置之后，我以为我终于明白了为什么会说：“维护和开发的花费比是80:20”。但这只是我以为——现实更加残忍：差不多一个月后，我又花了一个星期的时间，找到了另外一个bug的根源，正是我fix前一个bug所产生的。泪流满面，有没有？脑子里一下就蹦出个词：“按下了葫芦浮起了瓢”！总之，如果fix前一个bug就会导致后一个bug；如果fix后一个bug，就会导致前面的bug。我忘了最后是怎么处理这个问题的，依稀记得是让项目经理去和稀泥去了。因为这不是一个很关键很常用的功能，所以最后大概是不了了之吧。有同学问公司写的程序代码是什么样子的？
我告诉你，公司的代码大，超级大！里面最复杂的是逻辑，超级复杂，一堆的if...else...，先别急着说人家傻不懂什么设计模式，是你不懂。你不懂“重构”一下这些代码的后果！绝对是灾难级的，所以最保险的做法就是小心翼翼的加一个if。你看svn log，这些if都是这样一点一点的添加进来的。
真的，有一段时间我要带眼药水到公司，满屏的if...else各种嵌套，我眼泪都看出来了，/(ㄒoㄒ)/~~
也就是在这样一段艰难岁月里，我逐渐明白了以下这些看起来奇奇怪怪的论调：
所以我的架构，始终是以代码的可读性、可维护性为最高宗旨的。
之后，发布了架构之路（二）：性能，没想到有115/3的赞成/反对比。反对的声音里，我觉得有一条说得对：
不同的意见只是经历不同我只是没被性能的问题坑过而已。（其实也被坑过，但都很快解决了，坑得少）
但我想（确实只是想，没这方面的经历），如果代码看都看不懂，举最极端的例子，都是01010000100000010001……，我怎么做性能优化？你算法再怎么奇崛险怪，至少要让人看得懂吧？看都看不懂，还怎么优化？
所以，怎么看待“祖传代码”？它其实是一笔财富，个人成长的养分，让你能够一眼看到时光会如何侵蚀代码，让它不复当年的俊俏模样。然后，让你开始思考和探索，应该怎么做，才能更好的、更久的抵抗岁月的力量，延长代码的生命。
毕竟，我们都渴望不朽。
多快好省！前端后端，线上线下，名师精讲
更多了解 加：
