课程大纲

一、特有编程技能

    ● 跨领域、语言能力

           深入理解语言本质，能跨领域、跨语言，甚至在从未见过的语言中，进行重构和优化

           曾为COBOL程序员指出其语言中必定存在“多态”概念以处理多分支，并在两周后被证实

           曾在学Java第8天，以1/10以下的代码重构其曾为从事过的金融领域代码

   ● 抽象建模能力

           能凭借抽象建模能力，以简洁优雅的方法，现场解决陌生领域

   ● 某电信设备中的一个“最大难题”，仅以3行示例代码即得以解决

   ● 曾以300行可运行代码，实现某15万行系统中的核心功能

   ● 现场实战能力

          能现场点评和修改任意语言、业务领域的代码

   ● 已修改过的代码包括C/C++电信设备、C#/Java金融、保险、环保、销售、航空等系统

          能现场编写任意给定可理解需求的代码

   ● 已实现的内容包括某电信设备10个不同模块代码、金融交易系统、OA工作流引擎等 

二、创新知识体系

   ● 编码终极奥义

         以朴素的 “编码即人类语言”“编码即信息”指导编码，可绕过各种繁琐的设计模式、面向

对象等抽象概念，直击整洁代码根源

   ● 编码主观分体系（首创）

        以评审者自己可达到的最高标准为100分，将所审查代码按“不存在瑕疵的代码百分比”

来打分的体系

        Java/C#一般中值为30~40分左右，但也存在5%的人能达到90分以上

        C/C++中值一般在20分左右，超过80分非常罕见

  ● 编码整洁指数（首创）

        通过大约10组数据，对海量代码进行直接度量以给出评分的体系

        评分标准面向代码的架构层面问题，包括：超长文件占比、超长方法占比、圈复杂度、分支

语句密度（else/case）等，已在某电信公司内部推广

        按当前的设定阈值，一般C++项目评分在1.5分左右（满分为5），重构后项目可达到3.8分

  ● QAC量化敏捷编码（包括量化敏捷重构）

        通过编码消耗率、编码整洁指数等数据，对海量代码进行管理

        通过量化指标，对编码和重构活动进行决策

 三、案例

      案例6：某电信设备商

      关键字：编码质量；自动度量；量化敏捷重构；敏捷导入

      背景

      此团队多达200多人（软件约50人），正在将其某型4G基站升级为5G基站。原产品的某些模块缺陷率过高，极大地影响添加新功能，因此希望能进行重构，同时形成编码规范和质量意识。

此外，团队还希望能突破以往3个月发版一次，达到每2周一迭代，每迭代都进行集成、测试的敏捷状态。但软硬件甚至工业设计等多个团队的协作是个难题。

      方案

      38天，量化敏捷重构 + 端到端流程。

      详情

      需求条目化

      问题：最初的用户故事定义是为常见的有用户互动的场景设计的，因此用于嵌入式或准嵌入式设备时就很难拆分需求。尤其是不同专业的需求都纠缠在一起，很难说拆到哪个层次是需求，哪个层次是设计和任务。

      方案：实践中采用了SEA需求分析法，将需求分为三层（场景层Scenario，实体层Entity，行为层Action）。实践中对设备进行了拟人化，按设备划分了边界。由于SEA是建立在人类自然语言上的，因此只要能用语言描述的都可以进行拆分。其中一个团队的产品大约有5万行代码（大约20人年的开发量），在短短一个上午大约两个半小时，就完成了实体层的描述和拆分；这是团队数年来第一次完整看到自己产品的需求条目。

      跨部门协同

     问题：之前团队也进行过需求拆分，甚至一直拆分到各软、硬件、算法、工业设计团队的开发任务。但在看板上很难表达这些任务，集成测试团队面对众多很难理解的专业任务，也不清楚这个迭代完成时，到底什么功能可用，应该测试什么。

      方案：实践中扩展采用了SEA需求分析法，将需求的行为层Action（可理解为对外接口、页面）拆分为不同团队的开发任务。在看板上，同时显示一个行为Action，以及其下各个不同团队的开发任务。通过调整行为的优先级，开发任务的优先级也跟着调整，从而可以让某些高优先级需求可以提前完成。而测试团队跟踪行为Action而非专业任务，针对行为编写测试用例并进行验收，这对他们而言是绰绰有余的。

      极简编码规范 + 代码审查

      问题：这是此次咨询的主要内容。此公司已经“采纳”了谷歌的C++编码规范，但实际执行情况不好，处于常见的“规范面面俱到，实际处处违反”的常见状态。

      方案：咨询师介入后，采用“极简编码规范”策略，花费大约5个轮次，根据当场代码审查的结果，形成了一个9~11条（缓慢增加中）的极简规范。这个规范仅包含最关键的命名、函数长度、消除常数、消除else等核心规范。通过开发特定的脚本，可以自动检查执行情况。

      此编码规范在试点组X代码库中执行情况极佳，在15000行代码中，超长（30回车）的函数低于10个，而else关键字降低到只有30多个。总代码行数下降了一半，代码结构大为改观。

      截止咨询结束时，已经有十多个团队在执行此代码规范。

      宏观代码度量工具

      问题：这是此次咨询的意外收获。对于少量代码，可以采用代码审查发现问题，再用现场指导改善代码。但对于海量代码，撇开改善，即使仅仅想知道哪些代码的质量较差，都无法通过人力实现。

      方案：在咨询师的指导下，企业通过各种开源工具，实现了对11个核心数据的准自动化度量。不同于sonar等工具只能识别语法级别的问题，此度量全部面向架构级别，即最终决定代码优劣的问题，比如：超长类占比，超长函数占比，else-case不良分支结构，超复杂文件占比，代码克隆率等。

      在对这些度量项赋予不同阈值之后，按0~5分打分并平均，每两周统计一次数据。

      在经过半年多的度量，11个团队的代码评分从平均约1.5提升到3.0左右，部分团队达到3.9。若参与统计的早期代码也进行重构，此分数可持续提升。

      重构演示

      问题：此团队的某些代码结构复杂难以维护，希望能进行重构。但大家又感觉自己的水平与当年并没有实质性的差异，担心重构之后时间被花费了，但代码并没有本质区别。

      方案：咨询师介入后，为试点团队进行了几次重构演示。重构活动很快吸引了其他团队的注意，最终实际上有5个团队参与了重构活动。咨询天数也从原定的33天扩充到38天。

      重构升级版：实战编码演示

      问题：在几次重构之后咨询师发现，由于某些代码的过于混乱，很难从中直接弄清楚实际需求，甲方程序员也没有人能完全解释清楚。其难度不亚于让一个蒙着眼睛的人通过摸索，把一个已经建好的筒子楼改成三室一厅。

      方案：在重构的后期，将重构方式改为：这也是未来咨询方案推荐的模式！

      1.  完全不看代码，请一个熟悉业务的人，用自然语言描述一下某个需求。描述过程要避开专业术语，而是转化为逻辑、数据结构问题（对需求描述人要求很高）。

      2.  咨询师每听到一段文字，编写一段代码，同时要说出这样编码的思路。

      3.  描述人根据代码，判断咨询师是否理解并解决了问题。可以增加新的信息让咨询师进一步编码。

      此方式后来被证明效果极佳，共进行了10~12次左右，每次时长1~3小时，编码量3~60LLOC（逻辑行）。由于能从需求根源入手，因此咨询师常常能给出非常直观优雅的设计。极端情况只要3行代码即可令团队茅塞顿开。

      自动化测试代码的封装 + 提升自动化率

      问题：此公司的其他团队有的已经在使用自动化单元测试，但是覆盖率不高，原因是大约需要10~20行代码才能完成一个单元测试用例。若要实现覆盖率和合理密度，代码行数将远超过工作代码。

方案：咨询师介入后，之后第一个迭代将局部测试用例降低为3行1个；之后在看到用这种方法改写的大量测试用例之后，重新封装为1行1个。这相当于把工作量降低到了1/5~1/10左右。

      量化重构决策

      问题：由于原来的总代码量超过50万行，因此对于只是局部重构，还是整体重构一直存在争议。这是大规模重构时常常存在的问题。

      方案：咨询师对整个开发团队建立了一个量化模型，以下的数字来均自于团队自己的估算。

      整个代码量50万物理行，其中前2年完成了80%，后4年只陆续新增或修改了20%，即10万行。

      后期工作量 = 4年*50人*250天/年 = 50000人天，即每人天实际只能增加或维护2行代码，换算成逻辑行只有1行。

      以这个速度，根本不可能在合理的时间内完成从4G到5G的升级。 

      通过这次量化决策，公司决定除了原定的试点组外，其他组也要参与到重构咨询中。迄今已有5个组进行了深度参与。