在工作中，老大突然给你了一个需求（bug也算在内），这时应该三思而后行，将问题想明白了在动手，否则后患无穷。这些道理非常简单，每个码农都知晓，但是在真正的工作中却往往容易被忽略
分析任务的需求
- 弄清需求是如何描述的：
如果你做的是一款数据库系统，又搞mysql兼容，那么一定要想清楚mysql的表现是什么样的。这里可以通过若干种方法来获知答案：
- 这可以查文档来获得；
- 文档中描述不够清晰的，又可以通过mysql进行验证；
- 咨询组内做过相关实现的同学；
- 最后的大招，就是直接看mysql的源码了。
- 理解需求：
需求不应该仅仅是按部就班的翻译成代码。而是要真正的理解需求，对于数据库系统来说，要理解每个语意的合理性，以及在我们当前系统中是否同样的语意仍旧合理。（注：对于一个事情，不仅仅应该掌握what，更应该想想why）
- 预先思考这次任务中有哪些点可以成为学习点
- 在完成工作的阶段，也应该产生尽可能多的疑问，制造更多的学习点
- 将任务进行分解
- 如果直面一个很大的任务，肯定会被压的喘不过气来，通脑无法分析出问题
- 这时应该将问题拆解，逐条列出可能会遇到的问题，然后各个击破
- 在完成每个任务点时，一定要描述一下工作的流程；这样便于思考，同时不会让自己拉下一些细节点
- 理解别人的代码。在一个很大的项目中，很难自己完全开放一个模块，或多或少都需要与其他人的代码打交道；这时，应该做到以下几点：
- 理解别人的代码，要知道在做什么（what），最好知道（why）为什么这么做；
- 评定别人代码的合理性，如果看出了问题，应该及时的修正，而不是置之不理。
- 详尽描述自己的代码做了什么，这是对自己工作的很好梳理，能帮助自己找到代码中不足的地方
- review自己的代码
- 一方面看看，是否有低级的错误，在编码时很容易被漏掉；
- 另一方面看看是否存在思考遗漏的地方
- 测试
- 还是测试，尽可能的测试，这是提前暴露问题的最好方法
- 总结完成这次任务过程中的收获
- 总结这次任务中有哪些不足
- 代码提交了并不代表万事大吉，首先心里要有准备，接受代码会出bug的事实
- 自己做了一个功能后，其他人难免会对其更改；对于这种更改一定要进行关注
