软件设计如何落地

二十年左右的时间，敏捷(agile)软件开发走完了从一小撮人的游戏到软件业内的某种政治正确的慢慢征途。agile成为了一个good- words,和所有类似命运的词(as democracy、liberty、 republic etc.)相似，它的所指和能指实际上发生了分离。所以真实世界中的软件设计水平，就我看到的情况而言，并没有发生什么质的提升。大部分实际工作中的代码还是毫无设计，如一盘纠缠在一起的的意大利面。

我猜kent Beck或者Linus这种有些天才的人(或者说非常适合这一行的人)，是很难理解那种随手代码(不顾及单一职责，随便加到某个函数以实现功能的代码)是怎么产生的。SOLID原则也好，设计模式也好，DDD也好，甚至做到clean code,做好依赖关系管理，抽象都是第一步。但需要承认，抽象和设计，这本身是很困难的。有可能大部分人就不具各抽象思考问题的能力。能不能在工作中教会大家抽象思考呢?很难，少数人可以学会，大部分不行。想在项目中落地，几乎不可能。即便某些有设计的代码合入具体项目，如果没有非常明确的边界和维护的手段，也会很快的腐败，这样的例子太多了。

精英(专业)团队，当然可以落地软件设计。敏捷是价值观驱动的方法论集合。价值观这东西，本身就充满了精英主义的味道。软件设计并不带来当期利益，大部分项目线的领导者其实只关心当前版本。当大型软件腐化到大部分人都觉得它应该改造一下 了，它的改动成本已经太大了，或者性能恶化的太严重了的时候。这个时候肯定已经不是改造代码，改动架构的好时机了。改动引入故障的巨大风险，几百上千人的编程习惯，捉襟见肘的人力，和不确定的结果都会让这种努力变得艰难而危险。打个比方，肝癌感到疼的时候，已经是晚期了。

某种程度上，我们也并不希望大型项目中所有的人都是能力全面，价值观正确的精英。要求一个程序员编码的时候，要关注业务拆分的正确性，关心软件设计的合理性，同时还要关心性能。人应该专注于一个点，专业分工才是效率的源泉。业务团队就应该全心全意的关心业务。可运行、 可监控的架构设计就是来支撑这个目标的。架构不应该落在文档和pPT中，编程规范，xxx规范， 培训这都不够。架构应该可以约束分析和编码过程，提供合适的目录结构、依赖关系、拆分方式、实现模板(或者DSL)、非业务优化方法和某些业务/代码分析工具(以获得某些feature间可能的关联性)。这样，才可能从根本上落地软件设计、以及减缓代码的腐化(和性能的持续恶化)。我们没办法期望所有开发人员都是经验，但架构师，或者架构团队需要承担这个责任。对于大型项目来说(数百上千人)，这倒是有可能实现的。

再具体的描述-下架构师的职责吧。

1.  合理的将系统拆分为组件，组件的规模应该控制在7-10人可以维护，组件的边界应该非常清晰，不存在函数调用，不存在共享数据:只有消息接口; 在这个基础上，做好组件内设计，这是软件设计落地的主要战场:

2.  组件内分层，基础设施，实现，逻辑描述;逻辑描述和实现是非常不同的，被杂合在一起是一 般项目的常态，是实现引入的非本质复杂性之源;

3. 逻辑描述层，DSL可能是必须的选择，用通用语言(特别是c/C++) 描述某种特定业务的逻辑，表达力欠奉:

4.单一职责拆分原则，如果是以module和feature的交点进行拆分，那么必须在框架结构中明确的提供实现这两个概念的元素，或者在DSL中也应该有描述它们的关键字;

5.依赖关系管理，应该有机制让逻辑描述层生成接口，而让实现层依赖这些接口，向抽象和接口依赖;

6.  基础设施抽取，甚至可以将基础设施库(数据结构)某些业务常用的操作封装成DSL的语法元素:

7.  非业务优化，主要是内存亲和性优化，最好能在DSL的转换器中实现， 这是嵌入式系统相对专业和小众的领域;

8. 分析工具， 代码规范检测、代码质量评价(主要是拆分结果和依赖关系方向进行评价)和业务不同feature关系形式化分析的工具;

大概就是这些内容，2-5是更核心的。 1往往是业务本质决定的。