code 架构

1. code 架构

1.1. 代码质量的评判的维度

• 可阅读性 (方便代码流转)
• 可扩展性 / 可维护性(方便修改功能, 添加新功能)
• 可测试性 (质量管理)
• 可复用性 (简化后续功能开发的难度)

1.2. 架构师

软件工程是一项非常复杂的系统工程, 它需要依赖一个能够掌控整个工程全局的团队, 来规划和引导整个系统的演变过程。这个团队就是架构师团队。

从根本目标来说, 软件架构师要对软件工程的执行结果负责, 这包括:

• 按时按质进行软件的迭代和发布
• 敏捷地响应需求变更、防范软件质量风险 (避免发生软件质量事故)
• 降低迭代维护成本

软件架构师和软件工程师最根本的差别又在哪里? 我认为关键在于四个字: 掌控全局。

怎么做到掌控全局? 核心在于对知识脉络的体系化梳理。这是架构能力构建和全面提升的关键。这种方法不单单是在软件工程中适用。

掌控全局的前提是: 在自己心中去重新构建出整个世界。在这个过程中, 你不需要一上来沉浸在某个技术的实现细节(除非它影响了你对这个世界构建过程的理解), 但是你知道整个世界的脉络, 知道整个世界的骨架。 这个时候, 你对这个世界的感觉是完全不同的, 因为, 你已经成为了这个世界的构建者。 而架构的本质, 不也正是构建和创造么?

与架构相关的图书, 大概有如下这些分类。

• 架构思维类。这类图书通常从一些著名的架构理论讲起, 比如开闭原则、单一职责原则、依赖倒置原则、接口分离原则, 等等。这种图书的问题在于过度理论化。计算机科学归根到底属于工程技术类, 实践第一。
• 设计模式类。这一类图书则一下子进入架构的局部细节, 每个模式的来龙去脉并不容易理解。就算理解了某个具体的模式, 但是也很难真正做到活学活用, 不知道还是不知道。
• 分布式系统架构设计