程序员生涯回顾，并响应“自由飞”的《架构之路》

博客好久没写了，因为转行了，不干程序员了，

偶然读了“自由飞”的《架构之路》，同感强烈。

我的从业历史与“自由飞”略有相似，

02年开始读了四年的金融，毕业干了两年装修，

08年开始做程序员，7年中从零开始，

程序员生涯中以RealProgrammer为自我要求，

最终成就了架构师和全栈工程师的状态，

无论是Web、Client、Mobile、跨平台，

还是各种数据库和BI平台，都曾深入使用，

首次看到Windows Continuum真的是会心一笑，

最后以领域专家身份转身进业务领域，

别人看到了辉煌的华丽，7年苦痛却只有自己知道。

 

文科经济类入行IT，视角真的是大为不同，

会思考一些工程领域不太多见的问题，

例如：

计算量守恒问题，即在计算硬件能力不进行大幅提升的情况下，不同语言经过最佳实践算法优化之后，同样的计算量所消耗的时间差异不会超过两个数量级，所谓架构的性能问题，甚至包括并行计算，核心就是在计算量在时空中进行平衡的问题，当前发展阶段中专用加速硬件不成熟的情况下，预计算才是王道。

由计算量守恒会衍生很多原理，其中之一：操作体验的根基是UI线程与计算线程分离，以空间换时间，无论什么平台什么系统，屏幕白掉或者卡顿，都是不能接受的，可以动画转圈或听歌，就是不能无响应。

另一个衍生：计算量阶段分布问题，Complier时计算（数据类型优化和代码分库），Runtime时计算（内外存分布和算法），Renderer时计算（UI构成方式），程序生命周期中不同阶段的计算量分配均衡是好系统的标志，最佳案例就是各代Windows启动过程的差异，8之后的快速启动就是这个问题处理的好。

还有程序内部的关系问题，基本上就等同于进线程通信问题（RPC），源头可以追溯到微内核单内核争论，或者安卓IOS优劣问题。首先，架构解耦决定鲁棒性，即大规模系统其中部分程序故障，不要引起其他部分的失灵，也就是说好架构的系统无论常规程序员怎么胡闹，日志记录和查看、存储接口和备份都是不能当掉的。由此，架构中进程拆分是必须要有的，这种场景中可维护性最重要，性能真的要很次要考虑了（我赞同“自由飞”关于性能的观点），但是，不能拆分的高计算密度功能，必须是线程间通讯的，因为还是要照顾计算时间（性能）的。

架构解耦了，危害才能控制住，不断发生的危害互相独立，不受侵犯者才能顺利演进不受干扰，此时，组件间通讯就是必须的了，通讯总线的概念一定要有（例如E-MVC架构），通讯问题不解决，再好的计算能力也没法调动。但是，功能比较全重量级的流行框架（Framework）都没有内嵌通讯总线，就像城市建好了没有电话系统一样，构建强健高效低耗的通讯中枢真的是很费心费力。

另外，编程成本是一定要考虑的，IDE一定要好用，门槛要足够低，团队协作开发不能要求人人是大师；同时，需求变更引起的成本，大多数时候是体现在版本管理的失败的，所以，版本管理失败才是真正的万恶之源。

 

以上这些问题，工程类课程中都有所涉猎，

但工程类的做事方法是方法论为主客观约束为辅，

可是IT架构和大规模编码层面上核心诉求就是

“程序生命周期的成本控制问题”，

方法论反而是能商量的，所以文科经济类出身的人，

基本上都是从成本倒着往回看的，

也就更容易跳出技术的门派之见，

采用更多的最佳实践的原因了。