公司第五届软件工程大会简记

• 领导致辞

1. 某外企优秀经验：优秀的设计落在代码中，用代码直接培养新人，传递优秀的设计思想

2. 核心代码重构总是不容易的，需要部门领导配合，也需要部门专家当责，能够主动重构

    领导说了一句，“我们什么时候才能不简单的以代码行数估算工作量”，深有感触。。。

• 敏捷软件产品线工程

1. 介绍了“软件产品线”这个概念，适合产品族的开发

2. 有两种流派，学院派更注重“从零开始”的设计，工程派更看重“产品线抽取”，从单一产品到产品族的扩展

3. 主要的实现方式有三个要点，“产生式编程”、“元编程”、“XML配置文件”

4. 比较重视代码自动生成，尤其是胶水代码的自动生成

5. 前期分析的工作量比传统流程只多不少，此方法最重要的阶段就是前期分析

6. 分析模型：Feature Model - 树形识别变化点的模型，与汽车工业类似，实心圆表示必选，空心圆表示可选组件

7. 此理论在技术实现上没有难点，重点是业务与架构上能否识别清楚变化点

8. 重构方向无非两类，一种是分支，一种是扩展

    这里我理解还是遵循“识别变化、封装变化、隔离变化”的理念，这种新概念是否是换汤不换药的炒作，没做深入了解前不好下结论。不过其中提到的建模方式到是可以借鉴，直接“拿来”

• 特性隔离实践

1. 设计时就要考虑扩展场景：耦合、性能、升降级、对接……

2. 特性间的关系要分析清楚：耦合关系、横切关系、层级关系、扩展关系

3. 技术层经验：接口隔离，工厂组装，通过隔离点变量是否为空判断组件是否加载

    这个实践我认为重点在于需求分析阶段，会后我追问了作者关于投入工作量与关键实践，作者所在团队开发7k-10k的版本，共3个迭代，每个迭代2-3周，前前后后用了1个迭代的时间来梳理特性，关键实践就是设计、开发、测试同时投入。这种方式和上个议题是一样的，前期分析工作量实际上是增加了的，能否应用到部门产品开发，实在是取决于领导定的产品发布时间啊。。。

• 接入网LLT能力提升经验分享

1. 内存泄露代码检测：启动时记录，结束时对比，查看前后内存是否全部释放

2. “消息记录回放机制”和“API录制回放机制”，保证所有测试点测试全面

    作者部门采用的SMART LLT工具，目前没有java版本，暂时无法应用于部门产品

• 应用产品平台-业务无码化开发

    作者介绍了一个代码自动生成工具，貌似对部门WFM产品没有借鉴作用

• 软件设计原则、模式和最佳实践

1. 重构前一定要梳理完整功能清单

2. 我们的开发就像深圳公交一样，大而全每个角落都拐到了，反而造成出行不便，公交体验差。典型的Blob开发模式，全能函数，上帝函数，把所有功能都事先了的大而全函数(熟悉深圳交通的同志们肯定深有感触)

3. 组合优于继承，其实就是黑盒复用要优于白盒复用

4. 要在同一抽象层次上进行功能抽象，所以一般的设计是先分层，后套用模式

    凡事套用模式是否可取，过度设计如何避免？就像任务管理的表单配置一样，最初的目标一定是应对变化，但是现在增加一个字段会影响各个模块的表，不得不说是过渡设计了。不过从WFM产品现状来说，模式套用的还是太少了，甚至有典型模式场景都没有套用。

• IPTV-SIS模块代码重构优秀实践

1. 处理复杂情况先分层

2. 识别topN问题，有重点解决

3. 定制分支问题，一般采用“接口+实现类”或“策略+配置”

4. 一般的分支主要有这么几类：校验、业务逻辑分支、版本分支、防御型编程。遇到一类问题，通常需要从框架层次上解决，比如通用的校验框架，采用配置文件族和热加载机制等

    会后追问作者得知，这里所说的参数校验，是指他们的业务场景通常需要几十个参数的校验，和我们一般的防御判空校验有一定的差别

• 核心代码安全重构

1. 缩小范围，重构时不顺手解决老代码缺陷（这里我理解为非既定目标不做修改，确定边界不跨越）

2. 从客户视角、交付视角去重构，比如“自愈算法”不需要尽善尽美，客户可以接受就可以

3. 一砖一瓦的把平房替换成高楼，不要全部推倒，不要影响软件交付和使用

4. 重构前一定要理清story依赖关系

5. 重构前建好防护网，LLT要准备充分，不然重构风险太大

6. 所有函数对应的功能、业务逻辑要一一列出与跟踪，虽然效率低，但是必须做

    多个优秀的重构经验其实有几个共同点，1、产品功能清单 2、防护网+LLT准备。如果部门WFM产品真想做好重构，LLT是必不可少的，但是如何做，是个问题。另外作者提出“客户视角”重构，确实是我以前没有想过的，很受启发

• 多地域跨产品Scrum管理和应用

1. 无线ALM平台，平台化跟踪，计划、执行状态、项目状态全员可见

2. 解决方案计划对齐，E2E进展跟踪

3. 配套联调依赖可见

    我理解这里面的精髓就是，用好信息化平台，全员信息共享，彼此状态可视，就可以减少大量的沟通成本

• Feature开发模式实践

1. OR需求零散，需要做二次整理，提炼、聚焦特性提取，明白什么才是用户想要的

2. 面向功能分析->面向场景分析 

3. 资料的地位：“手册驱动开发”

4. 资料从功能维度到Feature维度的转变

5. 晨会：特性组，以交付维度讨论；晚会：模块组，以技术重点，解决技术风险维度讨论。

    作者提出资料的新定位很有启发，有类似TDD的意思，但是还不太一样，比TDD更抽象的在客户视角编程。主持人介绍成果，说这次试点偶上百篇过程文档可以推广。我就一个感觉：“我的天，这可怎么看”。如此多文档如何看，推广成本要有多高？如何推广关键文档，或者说，推广经验究竟要如何做才合适？我想起某篇博客的话，知识性的经验推广靠checklist推广是不行的，经验通过了具体->抽象->具体的三重转化，很难把原有的经验真正的传承下来，传承下来的可能是似是而非的，甚至可能是错误的理解。也许只有人和人的直接传递经验才是最好的。

• 应用DSL领域语言提升开发效率

    主要是介绍了一款框架Web DSL，我理解是和jsp标签差不多的理念，简化末端开发人员的工作，主要用到的技术理念有下面几个

1. 基于Node.js的模块化开发

2. “脚手架”开发模式

3. Pagelet页面块组装

4. 预编译机制

5. 基础组件和业务组件的概念划分

• 基于用例的面向方面软件开发

1. 为何架构会慢慢腐烂

1. 缠绕： 硬塞代码

2. 散射：需求实现影响多个模块

3. 冗余：拷贝已有实现

2. 写use case 的时候，基本场景和扩展场景是分开的，但是到了写代码的时候，两者是混在一起的，aspect编程可以实现需求与实现的对应

3. use case也有自己的一些模式，另外作者给自己的书做了个广告《基于用例的面向方面软件开发》

    其中介绍的面向方面的语言恐怕难以在部门内推广，但是相关的思路是可以借鉴的，尤其第二点，是之前从来没有想过的事情，却非常有道理