
李伟 吴庆海著
架构是设计一切系统的基础和核心。随着用户需求的变化及技术的发展,我们身边各式各样的系统也日趋复杂。如何在万象中剥离繁华,提炼事物的本质和精髓,“系统架构”正是化繁为简、打通两极世界的一门艺术。架构之美,在于和谐。本套“架构之美”系列丛书,以期从业务梳理、流程建模、软件架构、设计模式等方面进行系统、全面地介绍。强调理论与实践相结合,国外发展趋势与国内本地应用相结合,打造华人精品书籍,给国内读者提供真正有指导意义的美食大餐。
二零二零年读完的第十四本,依旧还是跟软件架构相关的,这本书重点在于了解软件架构的一些概念及其历史发展的流程。其中也有介绍到一些重构的方法,不过关于重构的内容我建议大家还是去读读2019年发行的《重构2》这本书,会来得更具体。
本书涵盖了软件架构生命周期中涉及的创建、评审、执行、演化恢复等重要活动、流程及实践经验。提纲挈领、高屋建瓴、深入浅出,从方法论的高度,系统性地介绍了关于软件架构方面的基本概念、体系及方法。
软件实现需要架构去总结提炼,从而应对变化,提高质量,提高效率,优化资源利用与成本。
本书属于认知层次的书籍,全书围绕架构师的角色职责、工作范围、工作内容、工作重点、工作质量这些方面来一一讲解。 按照本书的说法,系统架构师属于一个十分复合、十分中心的岗位,在整个系统的生命周期中无处不在,需要照顾并平衡各个利益相关方(商业、产品、TL、开发、测试、实施等)的利益,为系统的定义、架构、设计、实现、实施、演化负责。 正是因为承担了这么多重要的责任,同时和各利益相关方打交道,所以系统架构师需要具备综合的能力素质,比如专业强、自驱动、能规划、懂商业、勤沟通、擅平衡等。这意味着成为架构师,需要丰富的经验,入过很多坑且最终从坑中爬出来总结血泪教训,并且要持续学习持续进化,看到这难免不令人感到瑟瑟发抖并敬畏。要成为架构师不是一朝一夕的事,得只争朝夕。 具体来讲,架构师的工作活动是有基线可循的: 1. 依据成熟的商业概念、商业模型、商业流程等商业知识开始进行商业理解、商业剖析,和市场销售等人员一起形成需求规格说明书; 2. 与产品方针决策和计划人员一起明确产品发展路线图和时间计划; 3. 负责利用架构模式、架构原则界定子系统级别的结构和行为,主要包含子系统的组成、职责、交互、约束等; 4. 协助构件设计人员利用设计模式、设计原则对构成子系统的构件进行结构和行为的设计,确保架构原则的的执行; 5. 指导、监督开发人员的开发实现和测试人员的测试,量化、分析和汇总单元测试、集成测试及系统测试的结果,以对实现质量进行跟踪和控制; 6. 配合销售及产品服务人员,收集和分析产品反馈意见,逐步为未来的产品家族和家族成员的演化及升级进行准备; 另外,本书也详述了架构活动的典型流程以及各阶段输出的流程卡可供工作时参考和比对; 不过本书理论知识很多,阅读起来比较抽象枯燥,并没有借助案例来做分析,要串联起知识点还是得花很多功夫。 对架构流程环节描述比较丰富,但是对于架构活动每一步如何实操并未做过多的解读,比如子系统如何拆分,如何灵活运用架构模式、架构原则,如何量化、评估系统运维质量等。 另外,本书出版于09年,距离现在也11年了,很多新兴的领域都没涉及到,比如敏捷、容器化、大数据等,稍显脱节。
这是一本可以快速浏览得书,从整体流程介绍了软件架构以及软件架构师的职责范围和边界,更多的是提供了框架和流程,在于广度而不在于深度,在于理论而不在于实践。书里面的流程,以及提出来的各种方法论,可以在遇到相关问题时进行更深入学习的索引,所以个人觉得这本书更适合作为作为整体性的参考,而且也可以作为大部分热门架构书籍都是通过技术来讲架构的补充。。
从架构概念入手,由建筑工程中引发的一次事故,而引入了架构设计概念。从而分析架构师的应该有那些职责,分门别类讲述了软件架构生命周期,架构师应该承担怎样的角色。值得一读。大体读了一遍 [偷笑] 以后有时间再细读。
教科书式的讲解,这是最大的诟病。
软件架构产品线是一套完整的、标准化、流程化的面向客户全套解决方案[微笑]
本书基本全是理论,看起来不是那么轻松
能通过本书系统了解架构方法论,但实操性不足。