互联网公司做好需求的几点总结

这些内容很早就写在我的记事本上了，今天趁写博客的机会总结一下。

互联网公司后端开发的特点就是开发快、迭代快、上线快，以我来说一周平均有2~3个需求要上线，遇到大的活动期间还有大的需求。频繁的迭代早期对我来说不是一件轻松的事情，稍不留神就会制造bug。有bug就要随时随地快速响应修复，有时甚至在跑步也要去修改bug。

如何写出没有bug的代码成为至关重要的事情，以更长远的眼光来说如何能通过这种锻炼让自己的编程思想和技术更加高效成熟，直至独当一面。下面是我在近一年的时间里思考和总结的相关经验。

核心思想

痛苦 + 反思 + 执行 = 进步
快乐 + 反思 + 执行 = 进步

这两句话是核心思想，制造出bug是一件让人痛苦的事情，因此需要反思bug产生的原因，可能是需求不理解、业务不熟悉、测试不充分等。反思找到原因指定改进方法就是执行，形成一个闭环，逐步提高。
快乐也是如此，顺利的原因是什么，有什么值得借鉴的经验，利用好这些经验能将事情做的更高效。

这两句话不仅仅适用于做需求，也适用于生活中很多方面，生活更需要智慧。

工作中的案例

痛苦+反思+执行=进步
教资开营
痛苦：教资开营虽然写了技术文档，但是仍然有没想到的bug产生，并且在早上被电话连环call，给我的心理留下了阴影。在这个需求中做的好的地方和不好的地方都罗列出来：
好的地方：写了技术文档，接口和定时任务都详细罗列出来，避免了遗漏
不好的地方：没有对整个需求的流程做一个流程设计。需求中涉及到开营状态判断，user_plan状态修改的定时任务等没有搞清楚，也就是对整体流程不清晰。这其实是一个非常忌讳的事情。做任何需求都是要先有一个全局视角的设计，然后再细节设计。先设计细节后全局往往会陷入细节陷阱。
执行：大需求一定要有流程设计图，有全局视角

快乐+反思+执行=进步
14天打卡挑战
快乐：14天打卡挑战是对21天打卡挑战代码的重构，重构很成功，没有出问题。
反思：吸取之前的经验，从四个方面来做需求：1. 全局流程清晰；2. 拆解需求细致，将需要替换的代码都罗列出来 3.方便测试 4.多个定时任务不方便测试，多次自审代码
执行：这次需求，定时任务和流程基本对半分。对于不方便测试的定时任务，都手动执行了代码，也发现了数据类型的问题和code不对的问题。所以不方便测试的功能一定要手动执行验证。

做需求的两种层次

对于一个需求基本要求是准确无误的实现，能做到这一点就不错了。如果对自己要求更高就需要跳出程序员的身份，以技术负责人的角度去看待需求。

做好需求基本四点

1. 全局流程技术方案，状态随操作变换，随时间变化
2. 将大需求拆解成小步骤，每一步都保证是正确的
3. 技术设计上尽可能方便测试。测试做的好，压力就减小
4. 不方便自测的功能一定要自审代码

出色完成需求四点

1. 以技术负责人的态度去对待需求
2. 从技术角度做到高质量，无bug
3. 从技术角度可以快速迭代，兼容性和扩展性
4. 从产品角度思考设计缺陷，能够给产品提供建议

工作态度

1. 对于别人交接确定无误的代码一定要自己确认一遍没有问题。别人去年使用没有问题，不代表今年使用没有问题。对于别人交接的代码永远保持怀疑态度，并且不要偷懒不验证。
2. 对于发现异常的数据和异常逻辑一定一定要抛出异常，去检验异常，不能心存侥幸，心存侥幸的事情最终都会发生
3. 任何没有实现的需求都要告知需求方，心存侥幸的事情最终都会发生

对于工作态度，最重要的就是不偷懒。发现任何异常的情况都要及时搞明白，一个个小小的bug都潜藏在暗处，需要勤奋且细致的coder找出来。这一点很重要，我制造的bug里面，大部分都是完成需求时发现了异常且选择忽视，最终都会被用户反馈出来。

技术修炼

1. 学习技术不要华而不实。先熟练使用，再探究原理，不能操作都不熟练就开始搞原理。不懂linux命令就开始看内核源码基本上做无用功。
2. 不要做伸手党，不主动思考
3. 代码要自我review。review逻辑、review代码规范、review代码效率
4. 定时复盘总结，整理自己的核心规律 如何构建知识体系
5. 扩大核心规律。从核心规律出发去连通周围的知识，解决知识阻塞，融汇贯通。由点连成片，直到掌握整个项目，将认知提高一层

工作相关阅读记录

平时的工作如何体现一个人的技术深度？

1. 从需求角度有没有思考产品设计当中的缺陷，能不能反向为产品设计提供建议
2. 从技术角度能不能做到高质量高兼容性无bug，以及下次再有类似的需求能不能快速高效率的迭代

反思

当你自认为已经做好整个流程的每一件小事之后，接下来可以通过深入细节，思考整个流程是否存在问题:

1. 做需求过程中沟通协作的有没有问题
2. 流程规范的有没有问题
3. 机制环节哪方面问题
4. 代码公共基础能力的是否有缺失
5. 开发过程中你所遇到的问题是不是一个通用问题，能不能抽象出一个公共库解决大家的问题
6. 能不能制定一个SOP的解决方案流程，亦或是提炼出一个最佳实践在组内外分享经验

总结

故不积跬步无以至千里，不积小流无以成江海。先从做好每一件小事开始，把每个业务需求做到120分，深度思考，发现问题，解决问题，逐步建立起靠谱有责任心技术牛的人设，逐步负责有技术难度的事情。跟随公司业务发展积累自己的业务领域经验与技术深度，从而获得双赢的回报。