《众妙之门——网页设计专业之道》——2.4　总结

1.2 谁是架构师 如你所见,架构通常是关于难以更改的决定.需要有人做出这些决定. 架构设计基于需求分析.分析确定系统要做什么:架构决定如何去做.需要有人了解这个"什么"来确定这个"如何". 架构师正是把需求和规范关联起来的专家.但架构师的职责是什么?需要哪些技能? 1.2.1 架构师的职责 根据ISO/IEC 42010标准,架构师是负责系统架构的个人.团队或组织.架构师与分析师和项目经理互动,评估和提议系统方案,以及协调开发团队. 架构师参与开发流程的所有阶段,

前言 我们写这本书的主要目的是为你带来一个关于软件架构的坚实.可重用以及易于访问的知识库.在过去,我们使用Microsoft Windows DNA.分布式COM.多层CRUD.SOA.DDD.CQRS和事件溯源等技术完成了很多项目.我们用过Microsoft Visual Basic 6.C#.C++.Java和JavaScript.我们目睹了技术解决方案不断改变,对于这些方案的看法也进化了. 最终,我们和Fred Brooks得出的结论相同.我们不穿白袍,我们不是医生,我们不写处方.我们在这

2.2 软件项目的机制 如果你问:"什么导致项目失败?",你得到的最常见的回答可能会把失败归咎到与业务有关的问题,比如说,缺少需求,项目管理不到位,成本估算不正确,缺少沟通,甚至各个团队的人员相互不配合.你很难看到坏代码可能导致问题这种情况. 有鉴于此,我们认为未被发现的BBM可以严重损害软件项目,但未能处理的BBM却可以真的毁了它. 最终,个体以及个体之间的实际互动才能真的决定软件项目的成功或失败.但是,组织结构及其整体文化也会影响最终结果. 2.2.1 组织文化 Apple公司的组

第2章 为成功而设计 我们认为成功的软件项目是在充分了解业务需求的情况下采用靠谱解决方案的项目.我们认为成功设计的软件是在项目成功的前提下能够(在任何可能的地方)重用现有代码和基础设施,并根据可用的技术和广为人知的最佳实践不断改善的软件. 今天,成功设计的软件对于任何类型.任何规模的商业来说都是至关重要的,但更为关键的是避免质量低下的软件.烂的软件会使组织在很多地方遭受损失,比如说,响应很慢的页面会导致访问者离开你的网站,笨拙的用户界面会带来入口瓶颈,导致你提供的服务不得不面对处理队列,甚至未处

第1章 今天的架构师和架构 在计算机的最初年代,硬件成本远远大于软件成本.数十年之后,我们发现情况有了根本的变化.整个工业有了显著的进步,而硬件成本也急剧下降.另一方面,软件成本却大幅上升,这主要是因为开发自定义企业软件的复杂性提升了. 这种情况催生了一系列的准则,并以此指导工程师设计这类系统.架构这个术语源自建筑行业,现已普遍用于描述规划.设计和实现软件密集型系统的艺术.当我们两个还是青少年时,<爱是-->这部漫画(http://www.loveiscartoon.com)正值流行.每期漫画

2.3 走出混乱 即使做了最好准备,也不管团队的努力如何,系统的设计都可能在某个时刻陷入困境.BBM的形成通常是一个缓慢的过程,会在一段相对较长的时间里使设计恶化.在这个过程里,你的类到处都有修补和变通方案,最终大片代码开始变得难以维护和进化. 这个时候问题就很严重了. 管理者面临与魔鬼交易的抉择,要么采用更多修补和变通方案,要么根据审核的需求和新的架构选择做一次彻底的重新设计. 重新设计一个完整系统与完全从头开始开发之间的区别是什么?就采取的措施而言,区别是极小的,如果存在任何区别的话.但心理

1.3 总结 架构对于现代软件来说是必需品而不是奢侈品.即使架构曾经只是附属品,现在也肯定不再是,其中的区别在于现代软件的复杂性. 我们通常会拿软件和土木工程比较,但是,当土木工程师要建一座桥时,这座桥将会建成.除此之外,这座桥总能正常使用,而且建筑成本和原先的预算相差无几.这对于很多软件项目来说并非如此.放到软件上,有时候很难确定利益相关者的承诺最终有哪些能够兑现.但可以确定的是,可能会超出原先的预算,交付的东西可能在某种程度上与预期的不同. 为什么软件会这样? 总的来说,软件开发很难像土木工

2.4 总结 尽管名字包含工程,软件工程的重点并不是工程,至少不是我们平常理解的工程.软件充满动态性,它产生的问题无法通过一组固定的规则来解决. 软件项目的头号敌人是BBM,而BBM与碎步增长和项目期限密切相关.项目的碎步增长是不争的事实,关键是要找到高效的策略来应对.这可能需要有效率.有魄力地与项目经理.客户还有利益相关者协商.领域经验引导你理智地识别最需要的功能,帮助你更好地引导客户发现他们的需求. 并非所有项目都是平等构建的,了解项目期限是另一个至关重要的因素.你可不想在设计短期项目.关键

2.5 笑到最后 所有模型都是错的,但有些是有用的.(George E. P. Box) 在水上行走以及根据规范开发软件都是容易的,只要两者都已冻结. 石油泄漏会扩散.

1.4 笑到最后 以下是本章讨论的某些话题的冷幽默. 向已经延迟的软件项目增加人手会使之更加延迟.(Fred Brooks,<The Mythical Man-Month>,Addison-Wesley,1995) 没有东西可以按时.按预算完成构建. 失败不是一个选择,而是包含在软件里面.