如何面对新需求

在工作中，老大突然给你了一个需求（bug也算在内），这时应该三思而后行，将问题想明白了在动手，否则后患无穷。这些道理非常简单，每个码农都知晓，但是在真正的工作中却往往容易被忽略

分析任务的需求

• 弄清需求是如何描述的：
  如果你做的是一款数据库系统，又搞mysql兼容，那么一定要想清楚mysql的表现是什么样的。这里可以通过若干种方法来获知答案：

  • 这可以查文档来获得；
  • 文档中描述不够清晰的，又可以通过mysql进行验证；
  • 咨询组内做过相关实现的同学；
  • 最后的大招，就是直接看mysql的源码了。

• 理解需求：
  需求不应该仅仅是按部就班的翻译成代码。而是要真正的理解需求，对于数据库系统来说，要理解每个语意的合理性，以及在我们当前系统中是否同样的语意仍旧合理。（注：对于一个事情，不仅仅应该掌握what，更应该想想why）

预计关键的学习点

• 预先思考这次任务中有哪些点可以成为学习点
• 在完成工作的阶段，也应该产生尽可能多的疑问，制造更多的学习点

编码

• 将任务进行分解
  
  • 如果直面一个很大的任务，肯定会被压的喘不过气来，通脑无法分析出问题
  • 这时应该将问题拆解，逐条列出可能会遇到的问题，然后各个击破
  • 在完成每个任务点时，一定要描述一下工作的流程；这样便于思考，同时不会让自己拉下一些细节点
• 理解别人的代码。在一个很大的项目中，很难自己完全开放一个模块，或多或少都需要与其他人的代码打交道；这时，应该做到以下几点：
  
  • 理解别人的代码，要知道在做什么（what），最好知道（why）为什么这么做；
  • 评定别人代码的合理性，如果看出了问题，应该及时的修正，而不是置之不理。

代码review

• 详尽描述自己的代码做了什么，这是对自己工作的很好梳理，能帮助自己找到代码中不足的地方
• review自己的代码
  
  • 一方面看看，是否有低级的错误，在编码时很容易被漏掉；
  • 另一方面看看是否存在思考遗漏的地方

测试

• 测试
• 还是测试，尽可能的测试，这是提前暴露问题的最好方法

任务总结

• 总结完成这次任务过程中的收获
• 总结这次任务中有哪些不足

维护

• 代码提交了并不代表万事大吉，首先心里要有准备，接受代码会出bug的事实
• 自己做了一个功能后，其他人难免会对其更改；对于这种更改一定要进行关注

作为一个初入职场的码小农，要成长的还太多，要积累的还太多；珍惜每一天的时间，尽可能的让自己的进入融入到每一分每一秒！fighting!!!