Software Architecture : Organizational Principles and Patterns

 

1，组织与架构

想想90年代后期的微软和COM，Borland和VCL，现在的IBM和Eclipse

2，协作

就是“互相使用”，包括组件和架构间，组织间，关键是“明确公平的契约关系”

3，节奏

如果推动产品线太快进入不是其设计目标的领域，架构构想可能会遭到破坏

4，架构师：管理者？实施者？

做为一名架构师，更多的意味着理解如何平衡业务、组织运作和技术，而不仅仅是技术细节；受益人共享同一架构，但分别有不同视点，架构师要为不同的受益人展现正确的视点

5，Drop Pass

宁肯缩减范围，也不要延期发布，把不重要的特性推倒后续版本，后续里程碑

6，复用

类库形式的复用是最基本最原始的复用，类库并不能提供完整的业务逻辑功能，基于服务或组件的复用应是企业应用的首选

7，强制复用

建立组织级别的源代码树，将复用组件纳入其中，每个项目必须使用这棵源代码树

8，外包

君子性非异也，善假于物也；没有枪没有炮，别人给我们造

9，协作与契约

好篱笆产生好邻居

10，调整

a，我们现有的组织能开发什么架构？

b，我们想开发什么架构？调整组织去适应它！

11，参与

每个人都应该熟悉架构，每个开发人员都能得到足够多的实现细节，并调动所有人的热情，以各种方式参与其中

12，简化

一个核心，和一组围绕着它的适配器

13，坏味道

• • 构想：无法在短时间内就某个问题达成一致；产品支离破碎；如果读到某些东西时使你突然一惊或心烦意乱，说明构想落伍了
  • 节奏：某个小组极度缺少人手；与客户沟通不畅
  • 预见：被竞争对手蒙蔽，仓促作出决定
  • 协作：某个抱怨，疑问被重复好几次；开始有加班；客户选择竞争对手
  • 简化：打算用修修补补来处理大量特殊情况

14，摘要

• • 1，构想
    
    准则一：架构师的构想与其发起人、用户和最终客户期望实现的目标一致
    准则一模式：前端符合
    准则一反模式：反重力装置
    准则二：实施人员信任并使用架构
    准则二模式：建设性构想
    准则二反模式：潮流追随者
    准则三：关于架构和构件的潜藏知识对用户是可见的、可获得的
    准则三模式：轮转工作
    准则三反模式：惟命是从
    
    2，节奏
    
    准则一：经理们定期的再评估、同步和调整架构
    准则一模式：发布委员会
    准则一反模式：杀手特性
    准则二：架构用户对架构发布的进度和内容具有高度的信心
    准则二模式：弃球前进
    准则二反模式：短路
    准则三：通过节奏协调明确的活动
    准则三模式：同步发布
    准则三反模式：破裂的加载
    
    3，预见
    
    准则一：不断增强架构的能力以响应预见到的市场风险、客户需求、标准和技术的演变、战略性业务方向的改变
    准则一模式：领航员
    准则一反模式：遗漏的部分
    准则二：通过快速复审和开发周期，评估技术和业务上的风险与机会
    准则二模式：架构复审
    准则二反模式：滴血的刀刃
    准则三：当认识到关键的估计和假设有错时，及时调整特性、预算、计划和进度
    准则三模式：外包
    准则三反模式：隧道构想
    
    4，协作
    
    准则一：架构师不断的努力了解谁是最关键的受益人，他们如何贡献价值，以及他们需要什么
    准则一模式：了解你的受益人
    准则一反模式：电话铃未响
    准则二：受益人之间达成明确和强制性的契约
    准则二模式：互惠互利
    准则二反模式：口头一致
    准则三：通过社会行为制度和非正式规范强化合作
    准则三模式：杜绝意外，促进人际网
    准则三反模式：个人时间
    
    5，简化
    
    准则一：开发人员长期不断的使用架构，减少了总成本和复杂性
    准则一模式：由慢而快
    准则一反模式：克隆
    准则二：架构小组明确理解最小关键需求并将其构造成多应用共享核心元素
    准则二模式：迁移途径
    准则二反模式：榕树，根部肥大，捕蝇草
    准则三：把没有被共享、增加了不必要的复杂性、有专有业务理由的元素从核心特性中移走
    准则三模式：旋涡观察
    准则三反模式：高利贷