|混乱代码的代价 - 辽宁红网

只要你干过两三年编程，就有可能曾被某人的糟糕的代码绊倒过。如果你编程不止两三年，也有可能被这种代码拖过后腿。优秀的人千篇一律，有趣的灵魂万里挑一，然而我们却很少会碰到这群优秀的人，找到这样有趣的灵魂。往往意难平，要跟一群糟糕的程序员为伍，去收拾他们的坑以及残局。
几乎所有的创业公司，或者项目初创时期，追求的是速度，采用的是敏捷开发，往往不会顾及架构以及代码之美之道。所以说这个时期如果进来两三个害群之马，会让项目变得臃肿不堪，代码总能影响到本不属于你的模块。在项目初期进展迅速如火如荼，但是到后面却慢如蜗行。对代码的每次修改都影响到其他两三处代码。修改无小事。每次添加或修改代码，都得对那堆扭纹柴了然于心，这样才能往上扔更多的扭纹柴。这团乱麻越来越大，再也无法理清，最后束手无策。
随着混乱的增加，团队生产力持续下降，趋向于0 。当生产力下降时，管理层就只有一件事可做了：增加更多人手到项目中，期望提升生产力。可是新人并不熟悉系统的设计。他们搞不清楚什么样的修改符合设计意图，什么样的修改违背设计意图。而且，他们以及团队中的其他人都背负着提升生产力的可怕压力。于是，他们制造更多的混乱，驱动生产力向零那端不断下降。
然后就会频繁的有人入职离职， hr要招合适的人没有，造成程序员断层的现象。更可怕的是，如果主管不是做技术的，往往不会去体谅一个工程师的苦楚，这就是职场人士的悲哀。如果你能收拾残局，并不会获得更多的回报，如果你无法收拾残局，主管往往会把你定位为无能。这个时候你的心情无法复加，就会萌生跳动的心。
当然到最后，可能项目也会处于成熟阶段，可能也不需要向上突破了，这就决定了一家公司的规模和格局。如果像阿里那样的，分布式，高并发的计算肯定要提升上去，而且随着用户增长，服务器这些随时会突破上限，这个时候原来臃肿不堪的架构已经不适应新时代的发展，这就要求有个牛逼的人物重新设计架构，重新优化算法以及各个分部模块。
【|混乱代码的代价】