原则:工作

原则:工作

目前工作已经快3年了，还是有些流程和工作上的问题不断发生和复现，这里做个记录，时刻警醒自己

1. 严谨性

做软件工作，严谨性应该是最重要的，也是最致命的。（BUG往往发生于这里，本人发生多次）

---

2. 文档的重要

刚开始工作的时候，没有什么流程，等一个排期后稍微确认下方案，就开始做，自测完成后就抛给测试了。

这样做的优点：快，省事

这样做的弊端：

1. 容易梳理漏掉某些点，这些往往是致命的点
2. 开发到最后发现需要推到重来，前功尽弃
3. 即使成功上线，后面因为需要优化、修改逻辑对不上，容易改错

重点：文档一定要写详细， 还要让别人能看懂，清晰

---

「+N」写文档： 写文档一定要写详细，还要别人看着清晰

---

「+N」看文档： 看文档也一定要看的详细，不然容易有理解出入， 最好有个技术评审

2.1 流程图

从初学编程理论的时候，就是从分支图开始。可是当业务越来越复杂的时候，却忽视了逻辑的重要性，而这是可以通过分支图定下来的

流程图是对功能的确定，要熟练，敢画，再丑也没关系。

---

3. 开发

3.1 注释

• 配置的注释（线上事故+1）
• 逻辑复杂接口的注释

3.2 日志

初不觉日志的重要，只有当出问题无计可施的时候才发现，日志是必不能少

• 通用日志
• 三方接口日志：调接口返回数据日志

3.3 表相关

---

「+1」建表：建表sql先在archer这类运维工具上测试下，否则很容易开发完成后，因为这里审核不过，然后推倒重新改类名称。

---

「+1」改表：如果有废弃表，哪怕废弃着，也不要在现有的表上改然后使用。 因为线上的代码使用表的实体类，字段，即使没有数据。但是一旦修改， 预发没法验证。 只能直接到生产验证

---

4 生产教训

1. 拆分、迁移不管任何时刻都要按新项目上线来做，来测，有什么都要提前抛出来
2. 一定要打好日志，尤其调用第三方系统，入参等等
3. 严谨性是第一目标

---

5 事故

• 迁移项目少一个拦截器，崩溃

---

6 一些重要的点

6.1 新接新功能

流程需要确立清楚，第一步肯定是看【接入文档】

1. 看接入文档， 着重看配置项
2. 梳理接入逻辑
3. 接入