Z2 项目的吐槽

Z2 项目也许不是最糟糕的项目，但无疑是让我最痛苦的项目。

接下来的吐槽不是目的，目的是“前车之鉴后车之师”。

（提示：字有点多，看粗体即可）

搭建环境

以前搭建过很多项目，无非是需要老员工指点一下，还是几下的问题。

而这次是先看文档，然后经常请教，最后配合自己的反复“琢磨研究”才搞定。

• 一般而言，需要的“指点”的内容基本上都是配置
  • 可能是某些路径，或者开关，或者账号，或者队列名称、接口名称等等，也可能是数据库地址、注册中心地址、RPC服务名称等等
  • 另外一些配置则是工具的配置（比如插件）
  • 这些内容是必须的吗? 不能 0 配置吗?
    • 我们都知道生产上的配置是绝对不可能是开发去配置的，测试环境大概率也不是开发去配置的，那为什么开发环境需要做这些配置呢？
    • 开发手册中确实包含了大部分的配置信息，但是为什么会有漏掉的地方、错误的地方？还有的配置信息在截图中，截图中的也不一定准确......难道之前没有人发现果，还是懒得补充和更新？即便是开发环境的配置信息，也不应该频繁变动到来不及更新文档吧？ 更何况，微服务的配置信息基本上都应该在“注册服务”上，怎么会需要那么多的本地配置。
• 一些插件的说明，只是简单的讲了如何安装，使用的部分就不讲了。当然我们可以手机联网查询（现场不能带个人电脑，开发用的电脑不能联网），多查询几次也都能搞定，但是每个人都自己查询怎么使用，难道不低效吗？
• 上面都不是大麻烦，真正的大麻烦是：我只要运行一个交易应用，结果要下载10+个 module，然后逐个 compile 和 install，由于没有文档明确介绍 module 之间的依赖关系，所以只能不断猜测和尝试（一定会有人说难道 maven 文件中看不出来吗? 或者 Maven tree 命令或者其他工具不能分析出来依赖关系吗? 当然可以，只是要梳理 10+ maven 文件上百个 artifact，谁看了不叹气）。
  • 我找同事问过，但他们也只清楚大致的依赖关系...
  • 而且好不容易成功一次，下次一更新代码，又可能需要再来一遍，最终在我熟悉将近一个月之后，自己摸索出了其中的更新和编译技巧（还写了一个简单的批量编译脚本，其实掌握了技巧之后并不会常用这个脚本，框架组在我们忍无可忍的反馈下也对 maven 仓库和 module 的管理做了一些改进）。

需求分析

我自认为大多数的项目，在需求分析这块还凑合。

都会有需求文档，有些是开发自己写，有些是别人（有些是业务、有些是需求分析人员，也有叫产品经理）写的。

但在做 Z2 项目的时候，真的有点崩溃了，需要我们：

1. 去看 cobol 代码反向分析需求（开发过程中还要求尽可能的翻译旧代码，而不是重新写逻辑），
2. 参考旧的操作手册
3. 阅读新的需求文档（写的及其简陋，而且在都要进入测试阶段的时候，还在确认和修改），
4. 参考第三方的标准规范文档。

四者有冲突的时候，“标准规范文档”是最标准的，其他3者则需要找 ZYM 领导去确认。

15~20个人去找同一个领导确认的时候，干活的人痛苦, ZYM 领导也痛苦。

问题：

• 既然是重新开发，为什么要尽可能的翻译旧代码？
• 既然是重新开发，为什么不能只参考新的需求文档和第三方标准文档?
• 为什么会出现 4 个参考？难道不应该提前整合到一起？ 将来维护难道还要参考 4 个地方？

程序过度设计

在 Z2 项目里，写一个接口给前端页面，竟然需要写20 个文件：

XxxCtrl/XxxSvc/XxxSvcImpl/XxxIbb/XxxIbbImpl/XxxDbb/XxxDbbIml/XxxDao,

XxxReq/XxxResp/XxxBo/XxxIReq/XxxIresp/XxxDReq/XxxDResp/XxxPo,

XxxStruct*3,

Mapper.xml

修改 XxxBusixx.xml 和 XxxxEnuxx.java 2 个文件。

由于 maven 缓存也好，或者 Mapstruct 编译问题也好，免不了需要手动 compile、reload，甚至 install。

而这 20 个文件又分别存放到了 2 个大的 Project 的7 个小 module 中，而关联依赖的还不止 7 个 module, 而是高达 10 几个 module 中。

即便是没有写代码，每天也免不了更新代码，每次编译一堆 module 都会让人“欲仙欲死”。 特别是“初来乍到的新手”，总是难以置信这个地狱般的开头，而接着他会发现还有地狱般的日常。

问题：

• 真的有必要写 Ibb/Dbb 相关的内容吗? 一个简单的接口代码有必要分割到 5~7 个module 中吗？
• 为什么需要经常逐个手动编译 10+个module ，难道底层的 module 不应该很少变动吗？不能写成一个自动化编译脚本吗？

数据库设计

我有个习惯，就是搭建完环境，了解完大致需求，接下来会去看一下主要的数据库表。

大家都知道“数据为王”，数据库表是最底层的也是最重要的，是系统的记忆。

然而在 Z2 项目中，我遇到了这样的问题：数据库表不能由开发人员设计，也不没有人给开发集中讲解过。

这个问题看起来似乎问题不大，毕竟数据库表一般都有注释，而且配合代码，一般也能分析出来具体字段的含义。

但是，实际上有些内容是真的不好分析，比如一张 MSG 表中有 3~4 个机构编号，并且命名相似，你知道这些机构的区别吗？还有 1~3 个人员编号，区别又是什么呢？

可能会有人说，一问不就清楚了，结果我问了 2 个人都不清楚，在自己思索了 1 天后，找第 3 个同事问的时候才确定。（你可能要问，这种基础的东西都不清楚，他们怎么开发的？还记得我说的，编码的时候他们翻译的 cobol 代码，基本上可以理解为无脑翻译；你可能说不是有需求文档吗？新的需求文档写的太简陋，甲方的开发有一次被我问的没办法了，说“新的需求文档你可以不看”....）

也许仍旧有人会说，这也不是多大问题，最后还不是问清楚了？确实，我觉得甲方可能也是这么想的。

但是当接到一个任务后，本来一上午就能搞定的，最后硬是折腾了3天的时候，这个事情该怎么解释？

有一次组长问我工作进度，我就把本周做了什么先讲了一下，结果没讲完，就被打断了：“你只需要告诉我哪些做完了，哪些些没有就行（至于中间做了什么我不关心，也不想听）”。

还有一个事情让我不知该怎么说：我在一份文档中看到了有7、8个字段已经明确说明以后会废弃掉，建议不要再使用，可是我在代码中仍旧有很多地方使用了，在我提出疑问之后，这些地方全都改掉了（没有发现的地方就不清楚改了没）。

细致而繁琐的文档

在 Z2 项目里，我们被要求写大量的文档：

• 前端设计文档（往往是表单界面、接口参数）
• 概设文档、详设文档
• 接口清单（内容在前端设计文档中都有，此文档做了重新梳理，并增加了接口地址、负责人）
• 单元测试案例（有硬性要求80%覆盖率）
• 组件测试案例(POSTMAN，有硬性要求每个接口不低于5个)
• 组装测试案例(数量有硬性要求原则上每个接口不低于4个，使用前端界面测试，那么专业测试做什么？他们做的测试叫集成测试，虽然也是操作界面做测试)
• 代码 review 记录
• 错误码文档（不严谨的说，每个接口都必须有一份独立的错误码，包含了大量重复的错误码）

从这个角度看，似乎我们的工作又被要求做的很规范。但是：

1. 前端设计文档该我们写吗？
2. 测试是必要的，但是第一次需要手动编写3套测试案例，前端也是，而测试人员只需要一套（没有确认，只是针对测试环境的交流过一次，当然 UAT 和准生产的可能还需要重写，但是我觉得应该可以复用）
3. 需求的细节，需要后端向前端和测试输出...(我觉得这里有些逆天)

(其他比如代码扫描修复，需要写3份工作日报或周报之类的非开发相关的事务不做赘述)

写在最后

也许有人说，上面这些问不大都解决了吗？没解决的不也不影响程序运行吗？

而我想说：在商业社会中，有时候慢一点就意味着活不下去的，而处处慢一点，最终就是慢如牛。

那就只有被宰杀的结局。

而实际上我们在 Z2 项目中是“狂飙的蜗牛”，一方面我们要做很多无意义的工作，比如写大量的接口文档（项目中已经使用了 swagger，那就可以自动生成和导出），比如写大量的测试案例，比如总是需要经常性的编译，比如需求要反复核对字段......我们 996 加班就是在做这些低效的工作.....而且哭笑不得的是：干完了手上的任务也必须例行加班，而多的做不完的时候还不能“过度加班”（因为不给审批）。

对于脑力型的劳动，工作量的增加往往是“无形”的，而这种“无形”增加的工作量，累加到极限的结果就是质量不可保证，人困马乏，出事故是迟早的问题。