地铁设计和代码设计

来帝都一年了，对北京的一个感受就是地铁很方便，哪里都能去，虽然上下班高峰期人非常多，然后手机地铁上经常信号不好，于是在坐地铁的时候就会去思考一些问题，主要是想到了一些地铁的设计和代码设计的一些相通的地方，所以来总结一下。

• 地铁和代码都要考虑维护性，除非那种写完就扔掉的代码，否则大部分代码还是要有一定的持续维护的特性的，但是区别在于地铁的设计至少是以10年为维度来考虑的，但是代码能考虑一两年的时间就属于很有长期眼光的了。
• 地铁和代码都要考虑持续的运行，地铁设计出来是用来运行——拉人的，代码设计出来也是用来运行——解决某些现实中的问题的，区别在于地铁运行出现问题结果很可怕，代码运行出问题可能看实际项目来区分结果的危害程度，不管怎么样跟地铁出问题相比属于比较小的问题。
• 可扩展性，代码和地铁也都需要这个，因为地铁可能会有更多的路线开发，代码也会有更多的功能需要开发，区别在于地铁如果前期设计有问题，那么后期几乎难以弥补，代码如果前期设计有问题，即使费一些力气去重构，虽然代价也很大，但是总会是有方法去解决的，所以从这个方面来说，地铁的设计是需要更加慎重的。

在这里再讲一讲不同吧，地铁一旦决定开发，那么就几乎是必然成功的大项目，但是代码不一样，在初期没人能确定这个项目一年、甚至半年后是否还存在，所以在项目开始之初的心态就不一样，所以地铁更谨慎，更加严谨，也更加的考虑到了未来的扩展，北京的地铁都是挖那么深就是一个佐证。但是代码项目初期很可能几个月后就被放弃，所以一开始大家都是抱着能快速完活的心态去做，然后慢慢成功了，可能之前写这些代码的人也慢慢不维护了，后续的人员也就持续在这个不是很好的初期设计上缝缝补补，没有人有动力维护，也没有人想要去重构一下，可能很多人的想法都是能做一天是一天，没准过一段时间就被调去别的项目了，所以很多知名的大项目，或者大公司经常会被吐槽代码写的垃圾，代码设计也很不合理，这个只是一次次的项目迭代让项目逐渐的“老去”，一旦无法维护，那么这个项目就相当于“死掉了”，补救的方式要么重构，要么另起炉灶。

那么我们反过来想，是否可以在项目的初期就想尽办法去用最好的设计，用最严格的审核方式，保证项目的“纯洁性”呢？这个恐怕也不是那么可行的，因为现在很多项目都要拼速度，如果你慢了一步，那么就会一直被甩在后面，永远做一个追赶者，而现实是“赢者通吃”，只要从初期做到了头部，那么优势会无限扩大下去。所以从开始的时候只能放弃一部分质量去追求速度。况且，很多时候从一开始没办法预测用户的数量和喜好，也就没办法从一开始就去做优化，因为方案的设计和目的是息息相关的，用户量一万和一亿的设计方案是完全不一样的，我们不可能从一开始就假象一亿的用户量，因为成本是耗不起的。

所以代码设计方面的很多问题都是有点像电车难题，没有那么完美的解决方案，只能具体问题具体分析，这可能就是那么多程序员存在的意义吧，如果问题都是千篇一律的，那么少数一些人去设计方案，剩下的人做一个无情的打字机器就好了。

最后总结一下，《人月神话》的观念是：所有项目的最终结局都是死亡，就和人一样，即使再良好的设计，再称职的管理人员，再优秀的程序员也只能减缓这个时间，因为就和墒增原理一样，只要增加新模块、新功能就是在增加项目的复杂度，当重写一个项目的成本甚至低于维护现有项目的时候，这个项目在事实上就已经被判了死刑了。