程序员必读之软件架构
总结
软件架构不是预先设计；
每个团队都需要考虑软件架构；
架构师参与编码；
UML 不是必须的；
软件架构的本质
包含一个软件产品从端到端的完整的、与之相关的、重要的完整元素的综合考虑。
软件架构的好处
- 让团队跟随一个清晰的愿景和路线图，无论这个愿景是一人所有还是整个团队共有；
- 形成技术领导力，能够更好的协调；
- 与人交流的刺激因素，以便回答与重要决策、非功能需求、限制和其他横切关注点相关的问题；
- 识别和减轻风险的框架；
- 方法和标准的一致性，随之而来的结构良好的代码库；
- 正在构建的产品的坚实基础；
- 对不同的听众，以不同层次的抽象来交流解决方案的结构
软件架构的职责
理解业务目标
- 需求。包括功能性需求和非功能性需求等；
- 限制。包括环境、人员水平和预算等；
设计软件
- 技术选型；
- 架构设计；
- 模块拆分；
风险管理
技术选择其实就是风险管理。
- 当复杂度或不确定性高的时候降低风险，有利可图时再冒点险；
- 主动发现、减轻和承担高优先级的技术风险；
架构演化
贯穿软件交付整个过程，持续关注架构演进。
参与开发
- 从开发角度看架构；
- 不一定完成日常的编码任务，但要持续地参与到交付中;
保证软件质量
保证一条基线，它可以是引入一些标准和工作实践，如编码标准、设计原则和工具。
软技能
领导力
创造共有愿景，并带领同事向其前进的能力。
沟通
不解释。
影响力
说服他人、倾听他人的能力。
信心
信心不是傲慢，是领导力、影响力和沟通的基础。
合作
倾听、谦虚和响应反馈。
导师
辅导、引导和指导下属。
动力
不解释。
润滑剂
凝聚团队，达成共识。
政治
远离但要了解。
责任感
不解释。
授权
适当授权。
软件架构的经验
引入约束
先从部分控制开始，倾听反馈，以便随着项目的推进再微调。
包容
让组内成员参与到软件架构的过程中。
参与编码
不解释。