入参、出参应该尽可能禁用万能字段(如map)和共享内存(如threadlocal)。
参照现有FB系统,总结出缺点如下:
1、引发逻辑混乱。参数的自由度过高，使得多人开发时，无法进行约束。长期开发后，会积累大量，输入输出不明的逻辑，并导致最终实现与原有设计不符。
2、阻碍单元测试。所有模块严重依赖上下文，难以独立拿出测试。设计测试用例时，难以准确构造完整的入参。
3、阻碍重构、优化。已有实现与设计严重不符，且难以梳理。大量无关数据一同进行传输，浪费性能。
具体缺点表现：
1、FB现有代码中，PUnit之间使用threadlocal共用数据，针对threadlocal的各种get/set操作散落代码各处，并存在大量无效逻辑。
2、FB自动化测试工具，迟迟没有进展，目前只能模拟对XXXXserver进行数个类别的新增发帖提交请求。真正需求开发时，完全靠人工进行功能测试，难以发现间接引发的各种bug。
3、FB拆分的XXXXcheck项目中，因无法理清XZ校验各个模块的有效出、入参数，沿用了threadlocal方式，并将原有XXXXserver中后步骤下的完整threadlocal数据，作为XXXXcheck的入参（较原有XXXXserver入参更为庞大），进而使得FB拆分后，性能严重恶化。
设计的成因推测：
1、设计者无法在设计初期，严格定义模块的功能与参数。
2、开发过程中，无法容忍频繁的参数变更。
3、一旦采用了万能字段、共享内存的设计，后期不但难以清除，还会诱发更多的类似设计。
制止的必要性分析：
1、单元可测，才能确保真正的快速开发，及系统稳定。
2、高内聚、低耦合是先进设计理念根本。再优秀的设计形式，在大量运用万能字段、共享内存后，都会形同虚设。
3、万能字段、共享内存本质上，是贪图早期开发的灵活多变，寄希望于后期重构的设计。
改进建议：
1、主管应该明确禁止，不明确的各种数据传输设计。
2、开发过程中，主管应给予足够的参数变量容忍度。
3、阶段性代码审查，并制止万能字段、共享内存的设计、实现。
网友评论