昨天，我们班的老谢同学问了我一个很基础性的问题，他正在帮助我们学院的一位讲师编写一个诗词集的软件，讲师要求他按照完整的软件流程来撰写相关文档，可他之前没有过完整的软件成型的经验，所以在这上面犯难了，要说写代码我们班可没几个人能超过他的，但什么叫软件开发的流程呢，需要编写哪些相关文档呢，如何编写这些文档呢？如果在一年前问我，我只能说：这个嘛去百度google吧！不过经过了这一年的参与真实软件项目的经验，我还是有点心得可以分享的，索性把相关的内容都写下来吧，当然，写的很片面大家不要见怪吧，就当做小说看看吧。
当然，如果你参加真实的软件项目就会发现，作为一名初级的程序员，我们根本没有机会能够接触的完整的软件流程，比如需求项目阶段可能经理做好了，设计阶段可能项目组长或小组长做好了，后期的测试有专门的测试部门来完成，发布后的维护有技术支持部分维护，而你只负责前期工作做完后的编码过程以及测试部测出bug来的debug过程。这是在一个有成熟软件开发经验的项目组中的任务分工，我们每个人就像一个螺丝钉，只要能够拧紧每一颗螺丝整个软件项目就能够正常运行，这对于项目组来说的确不错，于是便有很多人抱怨从中无法得到提高，我们只做分内之事，无法窥见整个工程的全貌，如果我也只是做到这点的话，现在也无法回答老谢的问题了，但人总要有进取心，要随时准备着，当你的顶头上司因为某些特殊原因离开时你要能马上接应上去，所以我也抽空学习了软件工程的相关知识，这样让我可以站在高处看风景。
目前主流的软件开发流程有：Agile敏捷开发（Agile Software Development）、RUP（Rational Unified Process）、极限编程XP（Extreme Programming）、MSF（Microsoft Solution Framework）、CMMI能力成熟度模型集成（Capability Maturity Model Integration）等，我所参与的这家公司沿用V模型开发，本来这是一个很好的开发模型，可以这家公司不肯根据实际软件需求来调整开发流程，导致每个项目的开发流程冗长不堪，使很多不必要的重复性劳动附加给整个项目组，作为一位新人，我虽然提过很多次，可项目经理就是不听，哎，我人微言轻啊！废话又说多了，还是说正事，这么多软件开发的方法，我们如何去挑选呢？这里引用世界著名的软件项目管理专家Alistair Cockburn的一句话：“不同的项目需要不同的方法论，一个项目的最佳过程是这个项目所能负担的最小过程。”从这句话中我们不难看出实际上没有什么十全十美的过程，也不存在更好的过程，关键是什么样的过程适合自己的团队。
至于说文档的撰写就得从需求阶段谈起了。
需求阶段包括问题的分析和进度的安排：问题分析包括和客户的沟通，在有条件的情况下设计相关的demo并进行需求的重新确认，总之就是把客户想要的弄清楚；弄清楚客户所想之后需要形成一份类似软件项目建议书（Project Proposal）的文档，这份文档一般由开发经理和项目经理完成，包括对项目的认识和建议。之后项目经理和项目组长需要共同完成一份文档，根据需求抽象的功能点，确定工程目标的规范说明书（SRS），以及制定项目的工作分解结构（WBS），然后根据工作包的工作量和关联关系来安排项目的进度，并对这个项目进行风险的估计，接下来就安排参与项目的相关人员。这只是一个“平均过程”，大多数正常的软件流程都会有相对应的地方，并非一定会有或是一定一样的文档，
需求做完了之后就会开始设计阶段，这个阶段一般来说是最忙的，因为目前来看了解整个项目的只有项目经理和项目组长两个人，要把这些工作分配给一群不了解情况的程序员来做的确是一门艺术，根据项目的复杂度可以进行概要设计或是详细设计，如果是较小较简单的项目及可以直接做出一个demo，在其基础上进行提交修改就可以了，并非一定要编写文档。设计工作无外乎分模块，大的分小，小的打散。设计工作做的越细致后期编码越简单，当然，如果是那种客户需求不明确或更改较大的情况就需要项目组和客户进行密切的沟通过程，否则后期编码将相当痛苦，因为是程序员都知道更改代码比直接编写代码要困难的多，它牵扯到很多关联性问题。我的建议是在设计阶段采取迭代的方法，即设计一部分和需求进行比对或是和客户进行确认，再进行设计下一部分，这样可以降低整体设计方案全部推翻重改的风险。而程序员在这个阶段非常关键，他唯一能接触到项目全面机会就在这里了，他需要花大量的精力去弄懂项目经理和客户达成的共识，他还要了解整个项目的计划和后期编码会遇到的困难，在这个阶段我的建议是程序员最好能记录一份文档，描述设计阶段可以预见到的困难和风险，因为在之后的编码阶段这些问题就需要去解决了，而要去解决那些问题的人就必然是你了。早点意识到这个问题对谁都好，呵呵。在我们的项目组的V模型开发中在设计阶段还需要完成系统测试用例的撰写（STC），为每一个设计的功能点提供测试用例，为系统测试阶段做准备。大多数软件流程的测试阶段都是分开的，等到了这一阶段才记得去看设计文档撰写测试用例，或是根本没有一个系统的测试，只是进行随机性的黑盒测试，这一点倒是我们项目组做的比其他组强的地方。
设计做完了下面就是编码了，编码阶段是一个短暂而美丽的阶段，程序员根据划分好的模块进行编码，这是硬实力的体现，好的程序员编写的代码质量可靠高效，而一个差的程序员编写的代码在后期debug阶段一般来说是改动最大的地方，平时需要自己养成编写可靠代码的习惯。无论是作为一名程序员还是作为一个人，我们都要对我们承担的事情负责，不能因为我们自己的原因导致项目延期或是质量变差，我们需要在平时磨好编程这把刀，多注意积累这方面的经验，多学习高手编写的开源代码对我们自己有很大的帮助。
当编码结束后程序员的工作并未做完，我们还需要对我们写的代码进行测试，设计测试用例（Test case），如果时间允许的话对每个函数进行测试，然后再对整个模块进行组内测试，必要的话可以进行组间测试，因为代码是自己可见的，所以进行白盒测试的时候要构造出所有的输入形式，虽然这只是功能型测试，但要求却不低，最好对每个测试出现的问题形成足够的重视，根据我的经验，这里被否决掉的很多问题到最后提交验收时大多被打回来重新修改了。
当自己测试通过之后项目经理就会组织文档和材料提交测试部门进行更加全面的测试工作，发现问题时会打包发回来然后由开发人员进行筛选和修改，这个阶段会引起很多的争论，因为开发人员和测试人员对项目需求的理解不同，所以会引起很多的矛盾，测试人员使用很多的测试用例在开发人员看来完全是无礼的行为，不会由用户输入，可测试人员会坚持他们的测试结果，这个时候就需要项目经理从中沟通，进行调解，当然这里面也涉及到很多情况，因为作为一名初级程序员后面的事情就不需要去了解了，以后会有很多机会学习，我在这篇文章里也就不再详述了。
综合上面我说的开发过程，我们不难看出程序员的工作其实是很细致很符合人们认知事物的过程的。我们发现问题，分析问题，解决问题，确认问题已经解决。当然以上说的作为一名初级的程序员来说差不多就这样了，但如果想往上爬就有的学了。让我想起一本书里看到的说程序员有三重境界：
第一重境界“昨夜西风凋碧树。独上高楼，望尽天涯路”。这是北宋诗人晏殊《蝶恋花》中的一句词，国学大师王国维在《人间词话》中提到的古今成功者的三重境界的第一重；表示程序员愿意跳出自己的小模块来窥探整个项目工程的全貌，看到一般程序员看不到的地方才能排除干扰，不为暂时的迷惑所困扰，能够抓住程序设计中的主要矛盾，从项目经理的角度去考虑问题。
第二重境界“衣带渐宽终不悔，为伊消得人憔悴”。这是柳永《凤栖梧》中的句子；讲的是程序员看准目标后为这个目标努力前进，遇到各种困难能够奋勇前进，为了目标一切在所不惜。
第三重境界“众里寻他千百度，蓦然回首，那人却在，灯火阑珊处”。这是辛弃疾《青玉案》中的句子；意思是一个程序员经过多个项目之后越来越成熟，比人看不到的东西他能够明察秋毫，别人不理解的东西他能豁然领悟，对迷惑的事情有自己独到的见解，这种程序员已经能够为整个团队带来很大的推动力和解决力，对于大家疑惑的问题他可以进行决断，这个时候他也就已经可以被提拔了，他在众多程序员当中已经显得非常特别了。
最后跟大家分享两个笑话吧：
1、上班这一天其实可短暂了，电脑一开一关，一天过去了，嚎~？电脑再一开一关，又一天过去了，嚎~？上班这一天最痛苦的事儿是啥，你知道吗？就是下班了，活还没干完！上班这一天最最痛苦的事儿是啥，你知道吗？就是还没下班呢，活，干完了！最最最痛苦的是，上班没有活，快下班了，来活了。
2、老板：“最近咱们产品有发现漏洞么？”技术总监：“恭喜您，没有！”老板：“那最近你们开发时间有问题么？”技术总监：“问题不大！”老板：“那就是有问题了？？？”技术总监：“有……还是没有啊？”老板：“你的部门，你不知道，这个又不差钱。”技术总监：“啊，那没有！”老板：“那最近我们的新用户注册量有没有提升啊？”技术总监：“没有”老板：“这个可以有~！”技术总监：“这个……真没有……”
