文章吧-经典好文章在线阅读:架构实战读后感10篇

当前的位置:文章吧 > 经典文章 > 读后感 >

架构实战读后感10篇

2022-05-16 12:44:36 来源:文章吧 阅读:载入中…

架构实战读后感10篇

  《架构实战》是一本由[英] Peter Eeles / Peter Cripps著作,机械工业出版社出版的平装图书,本书定价:45.00元,页数:241,文章吧小编精心整理的一些读者的读后感,希望对大家能有帮助。

  《架构实战》读后感(一):雾里看花,看了评论,火大

  这本书看到网上推荐的很多,而且评论都是溢美之词,我心动啊,掏了大洋,美滋滋的细品。

  童鞋们啊,你们不知道我这些天是怎么熬过来的,不知道是我经验不多呢,还是我理解能力差,真是火大。每个汉字都认识,连起来也知道没段的意思,就是读完后,不知道怎么用啊。

  尤其是第四章《编写软件架构文档》的内容,应该说是本书的核心内容,后面讲解的内容都在架构文档中有所体现。在这一章中,把概念列举了很多,如何用?最后一个章节介绍了 本书要引用的架构描述框架,该介绍怎么写架构文件了吧,没有,失望,“视图”概念一大堆罗列在哪里,比如需求视图,功能性视图,部署视图。。。。。。,请问作者或译者告诉我这些视图怎么画?怎么画啊?

  《架构实战》读后感(二):架构实战

  身为公司的系统架构师,很长一段时间,我都不知我真正的职责是什么.实际上,在工作上,跟架构师的角色对应的任务也不多.更多的是项目的实施,代码的开发,当然.系统设计是必不可少的.只是,没有本书中所罗列的这么详细,这么复杂.分工也没有这么清晰.毕竟咱们不是IT公司,更多的是身兼数职的多面手.

  看过此书,对架构师的概念总算是有了一个比较深入的理解,知道架构师是干什么的,是靠什么吃饭的.架构师与项目经理的区别在哪里. 每每做系统,做平台时,更多的只是三层架构,很少考虑其它因素,素不知架构架构,这两个字的满园大得很,用句不地道的话来说:这趟手很深,没两把刷子,还真玩不转.好歹也算是混了一个IBM高级架构师的证书,看过此书后,只能感觉自己只略知皮毛而已.

  一个优秀的架构师通常平衡掌握软件开发知识和业务领域知识.当架构师理解软件开发但不能业务模型时,可能会开发出一个不满足需求但反映这种架构师所熟悉内容的解决方案.

  有效沟通是项目成功的基础.架构师应该既是优秀的聆听者,也是优秀的观察者.

  软件架构设计代表的是一个架构的定义、文档的编写 、维护、改进和验证正确实现的活动。

  所有的架构都是设计,但不是所有的设计都是架构.架构代表塑造一个系统的重要决策,换句话说,架构可以看作是战略上的设计,而详细设计可以看作是战术上的设计.

  所有的系统都存在架构.

  架构师的角色可能由一个团队来履行.包括首席架构师,应用架构师,基础设施架构师,数据架构师

  项目经理与架构师的区别

  架构师是根据需求分析人员跟客户沟通后,拿回的客户需求,将面向客户的需求文档变成面向开发人员的开发文档,同时要从功能实现和编程实现的角度出发来做系统的总体规划。

  架构师的工作完成后,下一步就是开发团队沟通,然后每个开发人员各自依照开发文档负责一个或多个部分的开发工作。

  而项目经理则是整个项目从头到尾的管理者,监督者,他的任务是随时保持和客户、和团队成员的沟通。对团队成员的工作进行监督和审核,以确保整个项目按时、按质、按量完成。包括处理项目实现过程中的一些特殊情况。在需求分析阶段。

  简单点理解,以盖房子为例,架构师是建筑设计师,而项目经理就是工头或者说监工。一个管结构,一个管进度。

  瀑布流程的缺陷:

  项目进度不能精确地度量.

  直到后期才能得到用户的反馈.

  一些风险解决方案延迟到项目后期

  软件架构的4+1视图模型:逻辑视图->开发视图->物理视图->过程视图

  软件架构文档的大纲应该包含以下内容:前页 目标 架构概览 架构决策 需求视图 功能性视图 部署视图 验证视图 应用视图 基础结构视图 系统管理视图 可用性视图 性能视图 安全视图 附录

  成功的架构师通常是那些知道可利用资源的人

  需求影响架构,定义良好的需求导致高质量的架构,架构的决定影响需求,架构定义了子系统的需求.

  一个名称,一个简要描述,有关参与者的确认,用例中主要的数据流和关键的非主要数据流的确认,这些通常用是在流程的这一步骤中所需要的关于用例的全部内容

  成功地设计一个软件架构的前提之一是采用迭代式的开发生命周期,它有助于架构师在任何时候都把注意力集中在试图完成的结果上,而不被一件工作产品是否完成所拖累.

  架构师由结果驱动,而不是由文档驱动.

  架构除影响开发的内容和测试环境之外,对开发系统需要的技术也有重大的景程,需要在完成项目需要的理想情况和现实情况之间权衡.这种特殊的考虑突出了架构师和项目经理之间需要密切的联系.

  逻辑架构尽可能地确保组件和技术无关,因此,能够使用不同的技术和产品来实现逻辑架构.在实际情况中,当选择了实现逻辑架构的技术的产品这后,必须记住每项技术都有自己的特性,这意味着你必须对这些差异进行一些解释以确保组件的说明没有歧义,从而使得这些组件可以进一步细化和实现.

  架构师所做的最大贡献是确保考虑到最具有技术性的系统用户,从而确保能够捕获那些最具有技术性的需求并进行适当的细化,也有助于定义请求的优先级和最终需求的优先级.

  架构师和项目经理的角色都很重要,而且通常都需要花费很多时间.这两个角色关注点差异也很大.由一个人同时扮演这两个角色的项目很少有成功的.因为一个人总会有倾向于这一个或那一个角色.结果,其中的一个角色执行得不恰当.架构师和项目经理之间相互影响的好处也不互存在.

  《架构实战》读后感(三):这本书标题为实战是很准确的

  什么是软件架构?本书的开头列举了很多观点。越是普遍存在的东西定义起来越复杂,就如同定义什么是桌子。本书的强项并不在于此处,因此它只是列举和引用了以往各理论大师的定义,从组成论和决策论两个方面进行了阐述,而这样的阐述是为了后续的实践过程即流程活动作为出发点的。

  本书并没有说什么好的架构是怎么样的。这个问题是很多大不部头的理论书籍讨论的东西,对于工程领域,什么是好的东西,并没有一个统一的评价标准,现在流行的阐述方式是模式,即告诉你在什么场景和条件下,根据以往的实践,这个解决方案可能是最佳的参看。要注意模式只是参看,因为模式的定义是做了很高层次抽象的,普适性好的东西并不一定对特定的场景就是最佳的,因此,对于架构师而言决策是真功夫。

  架构是一门艺术,但是艺术大师一定是具备良好的基本功的。

  本书重点阐述的是,通过一个什么样的推导过程,在过程中有哪些工具和方法可以用,使用这些工具和方法有哪些考虑因素(checklist),可以让引导你有50%以上的概率设计并落地一个好的架构。

  要记住,西方管理科学的核心观点:流程方法是历史优秀实践的沉淀,最优秀的理论是可文档化,强调的是成功的可复制性和持续改进性。从这个方面来说,现在的敏捷理论等等模糊性太强可操作性都太差,也给各类培训机构有了忽悠和生存的空间。

  这本书是基于目前而言在软件工程领域在大型软件开发上较为成功和主流的RUP理论为基础的,小的软件项目开发可以作为参考做适当的裁剪。从这个意义上来讲,敏捷流程是裁剪的流程,之所以可以裁剪怎么裁剪是要依照你所面临的环境确定的。如果没有全流程的视角去实践敏捷是比较危险的,类似于没有素描的基本功就去画抽象派的画,那只能是小学生水平。

  本书的最大优点就是比较系统而又简练的把RUP流程中与架构设计相关的内容摘取出来了并做了着重的描述。

  概括的讲,这本书给出了一种可复制的推导从好的软件架构的流程模式,并给出了该模式的推导思路,工具方法列表和应用环境。所谓师傅领进门,修行靠个人。给了你iphone,你拿去切菜,也未尝不可。

  这本书不适合刚进入软件开发领域的人员,适合有一定工作经验特别从事过大型软件开发全流程有经验的人。

评价:

[匿名评论]登录注册

【读者发表的读后感】

查看架构实战读后感10篇的全部评论>>

评论加载中……