宛如泥潭的大型项目开发困境

导言

当时我选择一线的原因是决定能最解决客户，每个工作能产生最大的价值。

通过一段时间的开发，我感觉在一线开发就像在泥潭里前进：走得越快越远，泥潭陷得越深，前进阻力越大。

困境为何而来，如何解决困境，是我想讨论的重点。

泥潭

1. 开发者：
   1. 缺少全局视野，只专注于自己需求的交付；导致代码质量参差不齐、风格差异大、冗余导致极速增长，(e.g., MindSpeed-MM半年内代码变成14万)
   2. 方案: 1. 重构代码，提高重用率，易读易用性。
2. 外部模块：
   1. 在当前项目很庞大的情况下，涉及的外部仓库也众多；在一些难以覆盖的冷门用例里，往往会出现当前项目的项目修改，通过模块A的接口，在模块B里产生报错。(e.g.,PTA中lazyinit GE的启动，会通过CANN接口，在torchair里出现报错)；但是模块A/B不仅文档缺乏而且代码也不开源，导致debug困难。
   2. 临时方案: 只能通过二分代码修改，二分commit来测试, 定位到是哪个commit导致bug。
   3. 长期方案: 开发中要求 1. 每个coomit要保证功能原子化，并且能够测试。 2. 持续测试，来监控开发中每个commit修改。（在每天晚上的时间内跑更多的测试用例）
3. 封装：
   1. 大型项目封装抽象之后，都变成了开发者在框架上开发一个可选的选项，用户侧只需要json里设置选项就能使用。问题就是在debug时，有20层的调用栈都是共通的，导致VizTracer特别大。
   2. 临时方案: VizTracer提供了选项，可以只记录关系的函数。
4. 流水化串行路径：
   1. 项目为了加速，往往会选择并行化，串行任务流水化切分。常见方式是线程A处理完之后，把数据封装传给接口，线程B开始处理。这会导致debug时调用栈中断，加上过度封装，导致前20层是无用的调用栈信息。
   2. 方案: 流水化加速往往有环境变量开控制开启或者关闭，关闭之后串行执行debug，问题才更明晰。

Next

开发：

1. 搭建测试框架, 持续监控每个commit修改。
2. 二分commit测试脚本

参考文献

评论