自底向上的开发

在这个急功近利的时代，自顶向下的开发模式能够帮助我们快速完成项目，争取眼前利益，于是几乎所有懂点程序的人就把自顶向下奉为圣经。然而自顶向下给我们带来了一些麻烦。由于价值观的转变，为了保证顶层结构而牺牲底层实现，导致了大量的一次性代码。每个项目都是新的，于是就有了大量的加班。

如果真的想写好代码，就不能从顶层开始设计。重写一个架构要比重写一套底层容易得多，我宁愿架构错了也不希望有底层的Bug。写过大量代码的程序员应该能够体会底层调试有多么的麻烦。

底层开发需要遵循一些原则，否则就不能算是正确的自底向上。我总结了以下原则：

1. 底层代码必须与项目需求无关。显而易见，如果我们的底层代码都和某个项目需求绑定了，那么对于其他的项目就会很不公平，也就是会变得很难用。底层代码只能是对系统功能和数学算法的简化，不能有具体的项目需求。
2. 底层代码必须以结构化为目标，在此前提上进行性能优化。底层代码的第一原则是能够保证稳定，然后是有能力快速自由地搭建架构，并且尽量减少重复代码。程序的性能主要是由上层的算法决定的，不需要对底层进行太深的优化。为了保证稳定、自由，不得不放弃对底层的深度优化。适度的优化还是有必要的，底层算法的性能不需要达到极限，不拖后腿就可以了。
3. 底层代码不能变成小架构。为了保证底层的适应性，不该在底层代码中提供太多的重载接口和监听器，也不能因为底层设计不自由而导致上层架构必须反过来照顾底层。如果API函数或SDK本身有这种东西，尽量把它重新封装成普通方法和类型。重载接口和监听器以及一些消息机制很可能会影响到上层总架构的开发，限制了上层的自由度。Lambda是推荐使用的，它几乎不会限制上层。如果需要监听函数，尽量用Lambda而不是继承什么接口再声明一个对象或者发出信号让监听器去处理。信号、监听应该是架构的事情，底层应敬而远之。
4. 底层代码中相似的功能要有统一的接口。这是为了使上层更容易实现多态。如果底层代码都是独立的，上层代码就必须为每一个相似的功能重新封装。这显然又是一种重复代码。
5. 对混乱的系统函数进行二次封装，开放的标识符要有规则。有时候系统函数已经能够满足我们的需求，但是系统函数的名字或类型很乱，不便记忆。这时候对它进行改名封装是很有意义的。编译器会自动对这种封装进行内联。假如现在不会，以后也会的。如果不这么做，下次想找一个比较冷门的功能的时候又要查文档，很浪费时间。这某种程度上也是自顶向下在自底向上的应用。让系统来适应我们而不是我们去适应系统。而我们自己能够决定的开放的标识符应要能够让人容易猜到是什么名字，不要再把希望寄托在文档上了。
6. 多做无用功，少做有用功。做底层代码不是为了完成项目赚钱、不是为了让用户认可，而是为了我们自己用起来方便。不要在乎它能干什么。每一个API都是有用的，只是你还不知道。等你知道了它的用途，时间就不够了。底层开发需要大量的调试时间。它可没有顶层的架构那么天马行空，想干就干。甚至你无法为底层的开发制定项目进度表，因为你自己都不知道进度是什么。做每一个你突然想到的功能，不要管它是做什么的，不要管它有没有用户。这样，当你突然遇到一个没有见过的需求的时候，你就会庆幸自己曾经做过一个看起来很适合的底层代码。而当时是怎么做出来的你早就忘了。

底层代码是一个开发单位的核心技术，底层代码决定了可以使用的架构的范围。自顶向下的开发就是在此范围内选择可行的架构，再回到底层代码中选择可以丰富架构的支持。没有好的架构可以很容易自己设计一个，而好的底层软件包可能花钱都买不到。如果读者有创业的想法或有自己的创意，切记先要完善一套底层软件包，自顶向下的开发可救不了一无所有的团队。