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