开发者需要了解五个与软件架构相关的事实
极客时间编辑部
讲述：杜力大小：1.97M时长：04:19
因为软件系统的分布式特点以及开发团队的分布性，了解软件架构的基础就变得越来越重要。而在过度设计和毫无设计之间，我们应该把注意力放在对软件系统有重大影响的决策和权衡上。好的架构师应该是团队的活跃分子，不仅能够进行代码协作，还能为团队提供技术指导。此外，软件架构中的沟通环节也极具挑战性。独立软件架构顾问 Simon 撰文分享了他对于软件架构的思考，以下为具体内容。
1. 软件架构不只是前期的“大设计”
传统的观点认为，软件架构就是在前期进行“大设计”，然后通过瀑布模型进行交付，架构团队要确保软件的每一个元素在进行编码之前都要考虑妥当。
而在 2001 年，“敏捷开发宣言”提出“拥抱变化而不是遵循计划”时，很多人误以为不应该制定任何计划。结果有些开发团队直接从原先的“大设计”变成了零设计。在 Simon 看来，这两种行为都是不可取的，事实上在过度设计和毫无设计之间，开发者应该把注意力放在对软件系统有重大影响的决策和权衡上。
好的前期设计就是要充分理解什么是“重要的决策”。这些决策通常与技术选型和结构，也就是分解策略、模块化、功能边界等有关。前期设计就是要了解影响软件成型的重要决策，而不是具体的技术细节。
2. 每个开发团队都需要进行软件架构
上述的内容适用于每一个开发团队，从一个单人团队到数百人的分布式团队。设置起点和方向其实就是要建立技术领导力。如果做不到这一点，就可能出现混乱，比如结构混乱的代码库，难以理解，难以维护，质量不达标。简而言之，任何一个开发团队都需要技术领导力。
3. 软件架构师要会写代码、指导他人以及参与协作
在大部分人看来，软件架构师就是给开发团队下达指令的人，但事实不是这样的，现代的架构师喜欢编码、指导他人并参与协作。Simon 认为，好的架构师应该是团队的活跃分子，不仅能够进行代码协作，还能为团队提供技术指导。
4. 不一定非要用 UML
传统的软件架构通常包含大量的 UML 模型图，试图充分展现软件系统的每一个细节。可惜的是，建模和 UML 在很大程度上与前期“大设计”相耦合，而这些技术在近几年已经过时了。现在完全不懂 UML 的软件开发团队比率在逐步上升。
现如今，大部分人只是“在白板上画几个方块和线条”，并将其作为沟通想法的手段，但很多时候，这种方式模糊不清、难以辨认，如果一个团队无法就软件架构进行沟通，那么就无法设置起点和建立技术领导力。
Simon 建议使用 C4 模型对软件架构进行沟通，C4 模型独立于具体的表示方法，从一个上下文图表开始，再逐步深入到系统的各个技术层面。
5. 好的软件架构是敏捷的
现在仍然存在一种误解，认为“架构”和“敏捷”之间是一种竞争和冲突的关系。但其实不是的。相反，好的软件架构也是敏捷的，它有助于应对业务变更，不管是需求变更、业务流程变更还是混合变更。当然，什么才是“好的架构”仍然有待商榷，但我认为，好的架构与好的模块化息息相关。
现如今，很多团队都存在一个很大的问题，他们采用了一种不需要考虑权衡因素的架构风格。在现实中，开发团队使用微服务架构代替单体代码库。但实际上，他们有可能是创建出了一种分布式的混乱架构，可见软件设计和分解过程是多么的重要，不管是要构建一个单体还是一个微服务架构的系统。敏捷和好的软件架构不是那么容易就能实现的，它需要一些精巧的设计，也需要作出一些权衡。这也再次说明为什么设置起点和建立技术领导力是如此的重要。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(2)
- 最新
- 精选
加菲猫也要有迭代，精益开发的我能力
Bob分布式的混乱架构是更可怕的东西
收起评论