开发工作中的一些好习惯
大家好，我是简单猿。
我们今天分享一下在工作中开展新业务的一些好习惯！
1、整理文档并落实形成笔记
我们通过业务文档自我梳理并记录笔记，找出关键点(1,2,3,4.......)理清业务，有疑问的点记录下来。可以先和内部沟通疑问点，之后再找到需求方沟通交流疑问点，达成共识，确定方向没有问题。
目的：
- 快速梳理业务逻辑 （我们自己脑袋里已经有比较清晰的分支，考虑问题会更全面）
- 方便有目标的沟通 ( 组内讨论，与需求方确定，最起码讨论的目标是一致的)
- 便于后期项目复盘 (针对自我业务的完成度与项目业务情况的分析会更具体)
2、先主线再细节并多版本迭代
我们很多人都习惯拿到需求看完，直接动手写代码，想着一次性完成，可能带来一些问题。
比如不知道我们有没有遇到自己代码全部写完了，最后和需求方一讨论，别人其实想要A,但我们给做了B出来，导致我们要重新来过。一方面浪费时间，另一方面也会打击我们的自信心，没有成就感。
如果我们采用另外一种做法，先打通主线逻辑再添加一些细节问题并分多个版本完成。一个需求为们可以多个模块完成，多版本迭代完成。
目的：
- 把风险降低，保证小面积修改 （小版本保证范围可控）
- 降低时间成本，避免浪费时间 (前期浪费太多时间，可能会影响工期，带来加班)
- 先完成核心业务，不会过度设计 （先完成主线再思考重构细节）
3、按照优先级逐级完成
我在工作中一直比较喜欢用四象限法则来对需求进行优先级排序。
不管我们有没有多任务，工作中难免会遇到，我们在做一个任务，但突然领导又给了一个任务或者运营团队，产品团队又需要我们配合。这时候我们就要充分利用好这个优先级。我们的大脑不是多线程的，是单线程的。就算我们很厉害，多线程切换也需要消耗时间。
我们可以沟通确定任务的优先级并不急不慢的处理事情。
目的：
- 知道轻重缓急 （核心业务才是最重要的）
- 把控任务节奏 （针对其他任务，合理评估后能严格把控）
- 以结果为导向 （我们最后的产出是最主要条件，过程是次要条件）
4、定期反馈与同步信息
不知道大家有没有遇到过类似的情况。比如你和其他人合作完成需求：
当你去问别人有没有做完，他直接告诉你：“我昨天晚上就完成了，你咋今天才问我”。
还有一种是，他会问你：“我昨天下午遇到一个问题到现在还没有解决，你帮我看看吧”。
这个时候可能会比较无语。不论我们完成了还是遇到问题了，我们都应该及时反馈，同步信息，尽快解决问题。
目的：
- 固定节点进行反馈（解决问题才是我们的共同目标）
- 共享信息 （最起码组内相互知道在做什么，需求方来询问进度能给出结论）
5、构造数据自测再发布测试
我当时遇到一个现象就是：
组内同事只要给到测试人员测试，别人反馈的最多的问题就是，“根本测不了，太多问题了、能不能自己测完再给到我们呀，浪费时间。”导致我们组内加了好几个班
组内复盘了一下开发流程，有没有按照我们的步骤来。发现他们并没有严格按照自测，构造数据写task来单元测试。他们给出的理由是：“构造数据太麻烦了，浪费时间”。
沟通下来，分享给他们可以先把代码扣出来执行一下，并且自己完成测试用例和测试人员的版本进行对比。
目的：
- 技术上自己满意（提高自我要求）
- 严格准守流程 （不断优化与改善流程）
- 用最简单的方式达到最优解
6、主动推动进度
我们可以看一下公司内部的管理层人员，他们有一个最统一的品质就是 主动
主动推动进度、主动解决问题、主动优化流程、主动承担责任。
我们要学习别人的做事方式并内化。
目的：
- 主动成就自己 （主动起来就会发现步伐更快）
希望这些习惯对大家都帮助，希望大家都可以从生活中，工作中发现一些对自我有帮助的小习惯。