马良项目的总结

轻视了新内容的风险

docker、可视化搭建、sequelize、TypeScript、老项目的熟悉等等。

一个新内容就仿佛是一座冰山，我们只看到了海面上的一点点内容，殊不知还下面还有整整一座大山！

iceberg

这里就以构建 puppeteer 的 docker 为例，遇到了如下这些坑：

  • 熟悉 docker 的基本命令
  • 安装进程管理工具 S6，不熟悉这个设计，又搞了一阵，最终问了同事
  • 安装 puppeteer，发现 Chrome 装不上，然后安装各种依赖，装了一个又发现还差另一个，搞了特别久
  • 最终发现这样装 Chrome 不是个办法，然后又推倒重来，用 CentOS7 重新安装了一遍，终于把 Chrome 装上了
  • 发现 Chrome 的 sandbox 在 docker 中跑不起来，折腾了一阵，后面发现人家 Chrome 本身就支持不好，然后改为非 sanbox 模式跑
  • 将镜像推送到内网仓库
  • 文件字体问题，又重新打包 docker
  • 发现 node 程序没跑起来，排查过程又花了 4 个小时，最终发现是因为我解决文件编码问题的时候，是直接/bin/bash 进入容器修改，然后 commit 生成新的镜像，导致新镜像里面带进去了/bin/bash，然后跑新镜像的时候，执行完内部脚本，就会执行/bin/bash，然后就退出了
  • 晚上发现测试环境 puppeteer 无法生成截图，折腾了 2 个小时，最终发现是因为测试环境访问不了静态资源，所以无法截图。。。。。。
  • 周日早上本地虚拟桌面全局安装了 puppeteer，但是程序中一直提示找不到 puppeteer 这个模块，又折腾了 1 个小时，还是没找到原因，最终选择了在开发环境将 puppeteer 安装在项目下的方案来临时解决(npm install –save-dev puppeteer)

在本身有很多问题待解决的情况下，一旦遇到一个新的未知问题就会很慌，很担心影响了其他问题的解决进度，这样越是慌张，就越是乱，总是想找一些快速的临时解决方案来处理问题，结果就会埋下很多坑。而且这种慌乱的状态，反而会让自己思路混乱，效率愈发低下。

基于别人的业务项目进行二次开发

前后端初期都是准备基于开户部门的项目进行开发，结果到后面发现这样存在很多问题(我们得熟悉他们的设计、他们用到了很多我们没有用到的技术和组件、业务差异很大导致很多现有功能用不上，得清理删除代码等)。

没有需求文档

只有交互稿，没有需求文档，到后面很多交互都忘记了。

没有明确标准

没有明确什么是完成的标准，导致大家只关注了自己那一块的内容。

没有方案设计文档和数据库 ER 图

特别是 ER 图，这导致我们是一边做一边发现缺少数据表，然后又去补，断断续续，不知道终点。

从这次的项目来看，初期即使我们花费一两天专门做方案设计和数据库设计，也是很划得来的。

越是大家经验不足的项目，这一块的投入越应该大一些；等需要确定的内容都 OK 了，剩下的就是填空题了，风险就很小了。

分工稍乱

初期的工作量分配不均衡，到了后面经常需要做 A 功能的人去做 B 功能救火。

没有及时且阶段性的联调和验收

一旦涉及联调，问题就逐渐暴露出来了，这部分工作量其实非常多。

没有阶段性进行 CodeReview

这次通过 CodeReview 发现的问题也很多，比如硬编码、配置地址有误、逻辑错误等等。

可以通过工具+人工审核的方式进行。

外部资源没有处理好

这就是我经常说的捕鱼，一定要尽早撒网，并且及时收网，否则你是捕不到鱼的。

很多操作绑定在了我身上

比如发布，这个应该交给组员，否则我不在就没法发布了。

命名未统一

后面代码很乱，方法名，接口名，变量名，形式各异，大小写也不统一，根本无法见文知意，导致后面修改别人的代码时，可读性很差，效率低下。

程序逻辑中缺少异常处理

比如 LY 的代码，后面我花了很多时间在测试环境调试。

不同环境的配置自动读取功能

进入测试阶段，因为配置的问题，耗费了不少时间。

没有分清楚轻重缓急

应该集中力量先把实例生成给搞定了，结果我们直到最后一个周末的周六，都还没完全跑通实例生成功能。简直难以想象。。。。。。

流程没有通过日志透明化

比如生成实例这部分，就应该早早的通过记录日志将其透明化。

基建不完善

这个项目结束后，需要联系各个组的前端组长，搜集他们目前的基建内容，然后吸纳过来补充我们的基建。

后端业务开发框架

我们应该有一个标准的基于 Egg.js 的后端业务开发框架，内置符合我们标准的文件结构目录、日志功能、常用的中间件(内外网判断、鉴权、文件上传、邮件通知、Vanish 通知等等)

前端业务开发框架

基于 Vue 的，包括文件结构、不同环境的配置规范

ESLint 与代码自动格式化

全组需要统一规范，采用同一份配置文件，否则写出来的代码风格比较乱，而且一旦有同事进行了格式化，提交上来 CodeReview 的时候就发现一大片都是修改过的，难以快速定位具体改动的代码。