第3部分 软件研发工作总结
完毕第一个新需求
在入职后不久，我得到了第一个新任务：完毕某个版本号的一个新需求。所谓的“需求”，就是用文档的形式告诉我们要做什么。要实现什么功能。
在得到需求文档之后，我仔细致细地阅读了好几遍。发现有些地方自己并非非常明确。假设在自己都不是非常确定的情况下改动代码，其后果是非常严重的，项目经理以前这样告诫我。我把自己的疑惑以邮件的形式发给了SE(系统project师)。让他把需求讲明确。在我们公司，SE负责写需求，他们要把用户想要实现的功能写成文档，然后让软件开发project师来实现。能够说是起到了“桥梁”的作用。
非常快，SE便回了邮件。一一为我答疑解惑。在明确了自己究竟要做什么之后，我便着手改动代码了。一般说来，作为新人。不太可能一開始便做非常复杂的东西，都是从最简单的開始的。也就是说，先是要在别人的基础之上改动代码。
对比着“需求文档”和“具体设计文档”，我非常快便找到了要进行改动的地方。接下来是不是应该立即就写代码呢？还不是。
接下来要做的是找出“编程规范”，依照上面写的来办事，包含：怎样命名变量？假设写凝视？怎样加入或删除代码？“没有规矩。不成方圆”，我们做不论什么事情都要遵守一定的“游戏规则”。
一切准备工作都做好了之后，就能够动手编代码了。在此过程中。我总是小心翼翼的。生怕出错。完毕一定的代码量之后，我回过头去检查几遍。再接着做下去。如此重复。直到完毕该需求。
我本以为编好代码便万事大吉了，但事实并非如此。导师告诉我，编完代码之后要进行自測，在自測无误之后才干提交。
这也纠正了我之前的一个想法：代码測试是測试人员的事情。
在我们公司，大部分的測试工作都是开发project师在做。
在自測多次之后才干将代码提交到指定的地方。
我总结了一下，一般说来。在整个研发项目中，除了编码之外。我们还须要做下面事情：
第一，自測
所谓的“自測”，与測试人员做的測试有差别。我们自測的目的是验证自己编写的代码的正确性。要确保让别人发现的错误尽量少。
假设要完毕多个功能，我的做法是在完毕一个功能之后，便对其进行測试。
第二。编写文档
一般说来，涉及到的文档的种类繁多，包含：单元測试文档、集成測试文档、具体设计文档、用户文档、协议文档等。假设涉及到升级，那么还有升级文档。
对于单元測试文档的编写。是要对自己编写的单个函数功能进行验证。要在文档中写出自己设计了哪些用例，达到的效果是什么，以及測试过程中出现了什么问题。
对于集成測试文档的编写，重在对接口进行測试。“集成”的目的就是将不同功能的模块组合起来，要看它们能否够协同工作。
编写的方法和单元測试文档几乎相同。
对于具体设计文档的编写，要体现出自己设计的整个过程。
也就是说，自己的思路是什么，为什么要这么做，哪些模块最重要，哪些函数是关键函数。具体设计文档是非常重要的，我们以此来编写代码。
对于用户文档的编写。要慎重。用户文档通常是拿给用户和现场的project人员看的，假设写得不好，那么对于现场版本号的安装是非常不利的。
其他协议文档或者由用户提供，或者由业务规划部门提供，我们能够參考。
第三，走同行评审流程
我们做出来了东西，要想得到别人的认可，就须要同行评审。
“同行评审”顾名思义。就是让专家或同事来看一下我们做的东西怎么样，有哪些不足，怎样改进等。
这个流程比較重要，通过它。我们能够发现自己想法的不足、自己思维的漏洞，并加以改正。
第四，提交并构建版本号
这里的提交版本号，不是像我们在学校那样把文档或代码一放就了事了。而是要依照规格来办事。哪里放代码。哪里放文档。文件结构怎样组织，都是有严格规定的。
一切都要遵循规范和做事流程，这是公司和学校的差别。
在版本号提交过后，下一步工作就是构建一个版本号。表示我们开发者的工作到此已经告一段落了。接下来该測试人员“粉墨登场”了。
回首自己完毕需求的过程。有这几点体会：
第一。做不论什么事情都要积极主动，不懂就要问。
第二，开发者做事要认真细致，要确保自己编写的代码的正确性，为自己的工作负责。
第三。凡事都要遵守规范，不能凭自己的想法办事情。
经验是一点点积累起来的，完毕第一个需求的经历让我学到了非常多东西。它为我之后的工作打下了基础。
(本人微博：http://weibo.com/zhouzxi?
topnav=1&wvr=5，微信号：245924426，欢迎关注！
)