(简评)建造可进化的系统构架

这是一本讲战略决策的书。

这是一本给小到一个小组的tech leader，大到部门技术负责人, CTO，看的书。它讲述了如果想要建造一个可以随着世界的变化而变化的计算机系统，应该考虑什么问题，对什么进行怎么样的取舍。这是一本教你应该如何做决定的书，如何应对"we don't know what we don't know"这个unknown unknowns问题的书。如何在一个探索项目里，应对业务需求持续变化的书；这是一本讲述：与其和PM打架，争论不能随意更改需求，我们应该去和PM合力建造强竞争力，强生命力的计算机系统，去拥抱变化，适应环境，甚至先发制人，利用科技实验占领先机，取得成功的书。

这是一本非常high level的书(注意这里high level／low level没有褒义贬义，他们只是来描述系统构架分层中上层下层而已) 。在highest level所有的编程技术语言，各种框架，数据库。都只是无关紧要的细节而已。所以你几乎看不到对分布式框架，数据库，程序的任何讨论，有的只是在high level的论述。怎么分组，人员应该怎样构成，为什么SOA is dead，为什么microservice兴起。为什么不要使用过度复杂的技术。
这本书非常好的讲述了我们应该朝什么样的目标前进，我们在原则上应该遵循什么样的考虑来决定行动。而对框架，技术，语言的选择则应是作为顺应我们在high level上选择的细节选择，从而能顺利的支持high level的目标。


缺点：就像amazon上某位给3星的reviewer给的评价一样，这本书很好，但是讲的太抽象和high level，能看懂的人不用看也自然明白这些道理；而无法从自己的工作经验中找到实感，或较少参与系统的high level决策的读者会非常难读懂因为此书缺乏细节。对Agile Development, Continuous Delivery, DevOps, BDD, DDD, SOA, Microservices等有所了解的同学，理解书里的内容可能会容易些。


但是这本书我是满分推荐的。
第一，就算你只是学生或者junior SDE，它也能让你大概了解所谓构架师，所谓技术负责人，CTO，这些人都在考虑什么问题，他们在会议上都讨论什么东西（特别是最近在写一个给Director Review的建议一个新点子的文档，这点深有体会。什么东西是重要本质大方向的东西，而什么是细节应该放在附录里。。。）如果你可以看懂，那么这是一本可以让你在会议上和Principal Engineer， Director讨论的有来有回，甚至用你的知识来思考验证他们的高层战略是否对错的书。
第二，组里的成员实力达到一定程度，不同的方案在“做出来”这个问题上都不会出错的。区别就在于更长远的影响，然而就算一个”次优解“也是可以成功的。就算你的方案再好，如果无法说服别人，无法convince别人，那么一个没有得到应用的方案就永远比另外一个在实践里获得了成功的方案差（因为这个世界不可能从头用你的方案再来一次从而做并行比较，重要的决定只有一次）。很多SDE觉得Sr. SDE甚至PE只是嘴炮厉害而已， 然而，嘴炮背后真的需要深深的思考和多方面的取舍考虑(测试，开发，部署，数据，监控，metrics，人员，业务，分组，环境，文化，奖惩，预算。。。等等)，大方向错了，细节做到再好，那也是无用功。而如果连嘴炮都赢不了，那么你就只能被别人牵着走，而不是lead整个项目按自己的想法去发展。
虽然这本书里的东西我在其他书里都了解过了，但是这本书提供了无数我可以用来打嘴炮的精彩论述（所以你看薄薄一本书我打了n多标签。。）可以提供很多以后我论述观点用来解释和自洽的方式，和例子。


能够Convince高层，这是一个技术负责人的必备能力；而用high level的思路去论述问题，不涉及细节也可以把东西解释清楚，考虑全面而长远，在unknown unknowns的情况下说服能做决定的人做出我们需要的决定，则是我们需要学习的方向。


这是一本讲战略决策的书，任何一位程序员都必须了解战略，才能够正确的执行战术。

总而言之，五星强荐。