程序员必读之软件架构
2020-04-02 18:48:10 0 举报AI智能生成
程序员必读之软件架构
作者其他创作
大纲/内容
Part Ⅳ 可视化软件
32 沟通障碍
抛弃UML
敏捷需要良好的沟通
33 对草图的需要
测试驱动开发与图表
为什么人们应该学习如何画草图
画草图不是艺术
画草图不是综合模型
画草图可以是协作活动
34 无效的草图
采购清单
只有框没有线
“功能视图”
航线图
一般正确
推迟技术
部署和执行上下文
太多假设
无家可归的C#对象（HOCO）
选择你自己的冒险
应该用白板
创建有效的草图
35 C4：语境、容器、组件和类
通用的抽象集合
总结软件的静态视图
通用标记法的通用抽象
图应该简单且脚踏实地
36 语境图
意图
结构
用户、演员、角色、人物等
IT系统
交互
动机
受众
示例
37 容器图
意图
结构
容器
交互
系统边界
动机
受众
示例
38 组件图
意图
结构
组件
交互
动机
受众
示例
39 是否包含技术选择
在设计过程中绘图
回顾性绘图
架构图应该概念化
明确技术选择
40 你会那样编码吗
共享组件
分层策略
图应该反映现实
41 软件架构和编码
职责驱动设计和组件分解
我们谈论组件但编写类
用层封装代码
用特性封装
用组件封装
对齐软件架构和代码
42 你不需要UML工具
有很多类型的UML工具
既有效又简单
UML的用途
没有银弹
43 有效的草图
标题
标签
形状
职责
线条
颜色
边框
布局
方向
要点
图表的评审清单
倾听问题
44 C4的常见问题
语境图上的系统名称
混合的抽象层次
共享组件
工具组件
从IT的角度勾画企业语境
45 问题
Part Ⅴ 为软件生成文档
46 代码不会讲述完整的故事
代码未描绘的设计意图
辅助信息
47 软件文档即指南
1．地图
2．景色
3．历史和文化
4．实用信息
保持短小简洁
注意“视图”
产品与项目文档
48 语境
意图
结构
动机
受众
是否必须
49 功能性概览
意图
结构
动机
受众
是否必须
50 质量属性
意图
结构
动机
受众
是否必须
51 约束
意图
结构
动机
受众
是否必须
52 原则
意图
结构
动机
受众
是否必须
53 软件架构
意图
结构
动机
受众
是否必须
54 外部接口
意图
结构
动机
受众
是否必须
55 代码
意图
结构
动机
受众
是否必须
56 数据
意图
结构
动机
受众
是否必须
57 基础设施架构
意图
结构
动机
受众
是否必须
58 部署
意图
结构
动机
受众
是否必须
59 运营和支持
意图
结构
动机
受众
是否必须
60 决策日志
意图
结构
动机
受众
是否必须
61 问题
Part Ⅵ 开发生命周期中的软件架构
62 敏捷和架构的冲突：神话还是现实
冲突1：团队结构
冲突2：流程和产出
软件架构提供了TDD、BDD、DDD、RDD和代码整洁的分界线
从象牙塔和大型预先设计中分离出架构
63 量化风险
概率与影响
设定风险的优先级
64 风险风暴
步骤1：画一些架构图
步骤2：分别识别风险
步骤3：汇总图中的风险
步骤4：对风险设定优先级
缓解策略
何时使用风险风暴
集体所有制
65 恰如其分的预先设计
回到方法学
要做到“恰如其分”
多少预先设计是太少
多少预先设计是太多
多少是“恰如其分”
把恰如其分的预先设计置于适当的语境
66 初识软件架构
软件架构应该容易理解
一些实用的建议
推动变革发生
软件架构的本质
67 问题
Part Ⅶ 金融风险系统
68 金融风险系统
背景
功能需求
非功能需求
Part Ⅷ 附录：“技术部落”的软件指南
...
介绍
语境
功能性概览
质量属性
约束
原则
软件架构
基础设施架构
部署
运营和支持
译者序2.0
软件架构培训
Part Ⅰ 什么是软件架构
1 什么是架构
作为名词
作为动词
2 架构的种类
它们的共同点是什么
3 软件架构是什么
应用程序架构
系统架构
软件架构
企业架构：战略而非代码
4 敏捷软件架构是什么
理解“敏捷”
好的架构带来敏捷
你需要有多敏捷
5 架构对上设计
找出区别
理解意义
6 软件架构重要吗
缺乏软件架构将引发问题
软件架构的好处
所有软件项目都需要软件架构吗
7 问题
Part Ⅱ 软件架构的角色
8 软件架构的角色
1．架构驱动力
2．设计软件
3．技术风险
4．架构演化
5．编写代码
6．质量保证
合作或失败
技术领导是一个角色而非级别
提出你自己对这个角色的定义
9 软件架构师应该编码吗
编写代码
构建原型、框架和基础
进行代码评审
实验并与时俱进
软件架构师和雇主之间的矛盾
你不必放弃编码
不要把全部时间都用于编码
10 软件架构师应该是建造大师
联盟的状态
回顾过去
建造大师真的会建造吗
象牙塔
建造大师角色的差异
实现角色
架构师要和团队一起工作
11 从开发者到架构师
经验是一个好的评价标准，但你需要看得更深
模糊的界线
跨越界线是我们的责任
12 拓展T
进一步的技术能力
知识面宽
软件架构师是通才型专家
软件架构是技术活
13 软技能
保持积极
14 软件架构不是接力运动
解决方案架构师
要有人负责大局
15 软件架构要引入控制吗
提供指导，追求一致性
控制的程度
控制因文化而不同
操纵杆，而非按钮
16 小心鸿沟
开发者关注底层细节
闭门造车的独裁架构师
拉近距离
软件架构的合作方式
17 未来的软件架构师在哪里
指导、辅导和师徒关系
我们正在失去技术导师
软件团队需要休息
18 每个人都是架构师，除非他们有其他身份
每个人都是架构师
除非他们有其他身份
敏捷需要架构吗
19 软件架构咨询师
领域知识
权威
20 问题
Part Ⅲ 设计软件
21 架构驱动力
功能需求
质量属性
约束
原则
理解影响
22 质量属性（非功能需求）
哪些对你重要
23 处理非功能需求
捕捉
提炼
挑战
24 约束
时间和预算的约束
技术约束
人员约束
组织约束
约束都是不好的吗
约束可以划分优先级
倾听约束
25 原则
开发原则
架构原则
谨防最佳实践
26 技术不是实现细节
你有复杂的非功能需求吗
你有约束吗
你有一致性吗
推迟与解耦
每个决策都是权衡
27 更多分层等于更高复杂度
非功能需求
时间和预算：没有什么是免费的
28 协同设计是一把双刃剑
经验影响软件设计
29 软件架构是对话的平台
软件开发不只是交付特性
30 SharePoint项目也需要软件架构
很多SharePoint实现都不只是SharePoint
非功能性需求仍然适用于SharePoint解决方案
SharePoint项目很复杂，也需要技术领导力
SharePoint解决方案仍然需要编写文档
强大的领导力和纪律不只是针对软件开发项目
31 问题
0 条评论
下一页
为你推荐
查看更多
