网站建设douyanet,如何开发一个手机网站,网站系统名称是什么,企业网站建设推广含义文章目录28 Epilogue 结语28 Epilogue 结语
Don’t let it end like this. Tell them I said something. 不要让它就这样结束。 告诉他们我说了些什么
—Pancho Villa
您已到达旅程的尽头。 辛苦了
我们希望您能从本书中找到一些有价值的收获。 我们建议该列表应包括以下内…
文章目录28 Epilogue 结语28 Epilogue 结语
Don’t let it end like this. Tell them I said something. 不要让它就这样结束。 告诉他们我说了些什么
—Pancho Villa
您已到达旅程的尽头。 辛苦了
我们希望您能从本书中找到一些有价值的收获。 我们建议该列表应包括以下内容
什么是架构为什么重要什么影响以及什么影响。架构在业务技术项目和专业环境中扮演的角色。架构和质量属性之间的至关重要的共生关系如何指定质量属性要求以及您快速沉浸在十几种最重要的质量保证中。如何捕获对体系结构的架构上重要的要求。如何设计架构对其进行记录指导其实施对其进行评估以查看其是否适合您的需求对其进行反向工程以及围绕该项目进行管理。如何评估架构的成本和收益在架构上胜任意味着什么以及如何将架构用作整个软件产品线的基础。当前技术前沿上的系统的架构概念和模式边缘应用程序和云。
好。 怎么办
用一本令人振奋的命令来结束本书并设计出色的系统是非常诱人的。 但事实是生活并非如此简单。
本书的作者共同在软件架构教学方面拥有大量令人尴尬的多年经验。 我们在教室里为学生提供此类书籍从工业短期课程到从“有抱负”到“老手”的各行各业的软件架构师我们都通过这种方式教书。而且我们经常知道 学生会认真学习我们所提供的知识他们走进的组织在架构上不像现在的学生那么精明而且我们的学生没有实践的方法将所学知识付诸实践。
如果您尚不存在大多数人将无法为要分配给您的项目指定基于架构的哲学。 您将无法说“这个敏捷项目需要首席软件架构师”如果团队负责人认为敏捷方法不允许任何总体设计那么它就会坚持下去。 您将不会说“我们将在项目进度表中包括明确的架构评估”并且每个人都遵守。 您将不会说“我们将使用Views and Beyond方法和模板作为我们的体系结构文档”并遵守您的指示。
为了避免您将所有时间都花在吸收本书上的时间上是浪费在迷茫的事业上我们希望在本书结尾时提供一些建议以将您所学的知识带入专业领域
说正确的语言。 您现在知道架构是达到目的的手段而不是目的本身。 您组织中的决策者通常关心目标而不是手段。 他们关心的是产品而不是那些产品的架构。 他们关心确保产品在市场上具有竞争力。 并且他们关心执行组织的营销和业务策略。 他们可能不会以结构上重要的术语来表达他们的担忧而是以您必须翻译的市场术语来表达。说正确的语言第2部分。项目经理关心降低技术风险可靠和切合实际的日程安排和预算以及计划这些产品的生产。 在某种程度上您可以证明专注于这些架构是合理的那么您更有可能成功地获得执行本书中所倡导的一些实践的自由。 您确实可以证明这一关注点是正确的健全的架构是无与伦比的降低风险策略可靠的工作估算器和生产方法的良好预测器。参与进来。将架构问题插入项目的最好方法之一是向没有机会看到它的利益相关者展示其价值。需求工程师就是一个很好的例子。通常他们会与客户和用户会面捕捉他们的疑虑将其写下来然后将要求从围栏通常是很高的围栏上扔给设计师。挑战这种种族隔离尝试参与需求捕获活动。邀请自己参加会议。假设作为架构师您想通过直接从马口中听到问题来理解问题。这将使您与需要帮助设计评估和处理文档的非常重要的利益相关者接触。此外这将使您有机会为需求捕获过程增加价值。因为您可能会考虑一种设计方法所以您可能会提供比客户所想的更好的质量属性响应这可能会使我们的营销人员感到非常满意。或者您也许能够及早发现麻烦的需求并帮助推动客户做出完全适当但在架构上更可口的质量检查响应。另外您可以自己联系组织的营销人员。他们通常是提出产品概念的人。您最好了解他们如何做到这一点最终您可以指出可能使用相同架构的现有产品的有用变化从而为他们提供帮助。这是经济愚蠢的。思考并以经济术语表达您的观点。如果您认为架构贸易研究架构文档或架构评估或确保代码与架构相符是您的项目的好主意请为其提出业务案例。尽管有漫画中尖尖的老板但经理们确实是在这里相信我们理性的人。但是他们的目标很广泛几乎总是与经济学有关。您应该能够辩解道理例如当系统进行重大更改时生成架构文档的更新版本是值得的例如。您应该能够辩称与没有指导性架构的情况下进行的那些相同活动相比使用新架构文档进行的活动将更少出错因此成本更低。保持文档更新的工作量远远少于预期的节省量。您可以在电子表格中插入一些数字作为此参数。这些数字不一定是准确的只是合理的它们仍然可以证明您的情况。开始游击运动。在您的组织中找到志趣相投的人并培养他们对架构的兴趣。开始一个自带的午餐时间阅读和讨论小组讨论小组讨论书籍书籍章节或论文甚至有关架构的博客。例如您的小组可以阅读本书中有关架构能力的一章并讨论您希望组织采用哪些实践以及采用这些实践需要采取什么措施。或者小组可以就架构的联合文档模板达成一致或者提出适用于您的集体项目的一组质量属性方案。尤其吸引人的是提出一套适用于您正在构建的系统的模式。或从您的单个项目中提出一个令人烦恼的设计问题然后让小组为之编写书面解决方案。或者让该小组作为其他项目的巡回架构评估团队提供服务。您的小组应定期定期召开会议并采取一系列具体的具体目标。热心且敬业的领导者您呢的重要性是谁他们渴望成熟于组织的架构实践所以不要夸大其词。宣传您的会议宣传您的结果并不断要求更多成员加入您的论坛。享受小胜利。您不必一夜之间改变世界。您所做的每一项改进都会使您和您的组织处在比以前更好的地方。 通过后门将架构审查纳入组织 如果您在网络上搜索“代码审查计算机科学”则会发现数百万次匹配它们描述了代码审查以及执行代码审查的步骤。 如果您搜索“设计评论计算机科学”那么您会发现有用的内容很少。 其他学科通常会练习和教授设计评论。 搜索“设计评论”您会发现许多热门歌曲以及相关说明。 设计是试图解决特定问题无论是美术问题用户界面设计问题还是软件问题的任何类型的决策集。 重要的设计问题的解决方案应经过同行评审就像代码应经过同行评审一样。 大量数据指出在生命周期中越早发现并解决问题发现和解决问题的成本就越低。 设计先于代码因此进行适当的设计审查似乎在直观和经验上都是合理的。 此外围绕评估的文档包括原始设计文档和评论对于新开发人员而言都是宝贵的学习工具。 在许多组织中开发人员经常切换系统因此他们不断学习。 这种观点并未得到普遍认同。 一家大型软件公司的软件工程师告诉我即使该组织渴望编写和审阅设计文档也很少发生。 高级开发人员倾向于将他们的评论限制在粗略的范围内。 另一方面高级开发人员非常重视代码审查。 我的软件工程师朋友针对这种情况提供了两种可能的解释 代码评审是影响构建内容的最后机会“对其进行审查或与之一起使用。”这种解释假定高级开发人员不相信设计审查的输出是可操作的因此要等到以后再参与。 过程。代码比设计更具体因此更易于评估。 此说明假定高级开发人员无法理解设计。 我认为这两种解释都不具有说服力但我无法提出更好的解释。 怎么办 该软件工程师所做的是寻找可以秘密执行设计审查的替代流程。 该个人注意到当组织进行代码审查时经常会问诸如“您为什么这样做”之类的问题。 这些问题的结果是对基本原理的讨论。 因此个人将为问题编写解决方案将其提交给代码审查然后等待将导致基本原理讨论的问题。 设计评审是对设计决策及其基本原理进行介绍的评审。 通常会探索设计替代方案。 是以代码审查还是设计审查的名义完成此任务并不比完成任务重要。 当然我朋友的秘密方法有缺点。 编写可能不得不扔掉的解决方案效率很低。 此外将设计评论嵌入代码审查意味着最终将设计和审查嵌入代码审查工具中从而很难在该工具中搜索设计和设计依据。 但是这些低效率与为特定问题寻求错误解决方案的低效率相形见绌。 —LB 软件系统架构的实践和纪律已经成熟。 您可以为加入一个一直努力并且仍在努力变得更加有纪律更可靠更有生产力和更有效率的职业以创造能够改善其利益相关者生活的系统而感到自豪。 有了这样的想法现在该到书本式结束的时候了继续并设计出色的系统。 您的前任设计的系统已经改变了世界。 轮到你了。
