
Simon Brown
通常,人们对软件架构师持两种错误的看法。有人认为软件架构师是一种高高在上的职位;有人认为软件架构师完全不懂开发,只是会画条条框框的指挥家。本书将打破这些传统的认知,模糊软件开发和架构在流程中的界限,进而为软件架构正名。本书是一本强调实践、注重实效、轻量级、面向开发者的软件架构指南。如果你是一名想成为软件架构师的程序员,那么本书就是为你准备的。
罗列了不少需要思考的点,可根据实际自由选择,但是还得思考所选择的在当下的场景如何符合自己的需求。
找到了一些不错的观点,比如恰如其分的预先架构设计等等,书中有些内容(额,还是说所要表述问题痛点)需要经历过太有更深的理解与感悟。所以这本书说是对开发实践着的指南,不知道是翻译的问题还是...并没有达到预期的效果,当然我觉得是值得再review一遍的价值
该书最有用的部分就是第一、第二、第三部分涵盖的软件架构概念和软件架构要遵循的方法论以及理论知识的介绍和诠释,剩余部分都是一些过时的实操方法以及工具的该如何使用,完全可以不看。要真正理解这些理论部分必须有很多年实际的软件架构和编码经验做为支撑,不然会觉得这些理论都是虚无缥缈,无法指导现实。从我的过往经验来看,作者是对的,作者确实精准描述了团队软件架构涉及的方方面面,并且能做了理论化,让软件架构可以以这样的理论方式传授给其他正在进入这个领域的架构师。
没有废话,直接了当。无论是对软件开发人员,软件架构师,还是公司的领导者都应该读一读。看看什么是软件架构,怎么做软件架构。
这是一本‘指南'型图书。作者会给你一个图景以及达到它的关键技术指引,你可以得到一个思考问题的框架,而非一条道路或一套方法。
架构反映了使一个系统成型的重要设计决策,而重要性则通过改变的成本来衡量。 从本质上讲,格雷迪认为重要决策即“架构”,其他的都是“设计”。 在现实世界中,架构和设计的区别并不明显,但该定义确实为我们提供了一个基准,去思考在我们的软件系统中哪些可能是重要的或者说“架构的”。比如说,这可能包括: ❑ 系统的形态(例如,客户端-服务器、基于Web、原生移动客户端、分布式、异步,等等); ❑ 软件系统的结构(例如,组件、层、交互,等等); ❑ 技术选择(即编程语言、部署平台,等等); ❑ 框架选择(例如,Web MVC框架、持久性/ORM框架,等等); ❑ 设计方法/模式选择(例如,针对性能、可伸缩性、可用性等的方法)。
只有深度参与过软件开发,踩过坑碰过壁才能理解本书的精髓——架构即关键决策。至于用什么工具用什么方法来做架构设计没那么重要,初学者不理解架构即关键决策,用了这些工具也不会产生太多价值。在AI时代这句话的价值还在不断提升,TDD, DDD这些方法论AI比人更清楚,遵守的更好,这时人的价值就是做关键决策,一旦制定且团队共识,便是AI开展工作的限制条件,不得越线。关键决策要少,不能让AI束手束脚,但又不能缺,不能让AI天马行空,烧了大量token结果不能用
相较于普通的开发者,架构师需要关注的不是实现的细节,而是一个完整的软件交付周期,囊括了对软件的良好设计、软件实现的监控、技术风险预估与规避、及时的项目交付等。
软件开发文档部分可能有点意思,其他部分有点啰哩啰嗦的。快速浏览式看完!
我可能更期待作者举几个具体的例子来说明他的观点。书里现有的内容过于泛泛而谈了。