一直以来期望从事自己喜欢的事业的我，对软件开发有者及大的兴趣，可由说种种原因使我从事工作以来走了好几年弯路，心中的梦想迟迟不能得以实现，可程序员的梦想从来没有从我的心中抹去，但这扇大门好像并没有向我敞开，今天，贵公司给了我敲开这扇大门的机会，让我真实体验了程序员的诞生过程。早就听说，程序员的前几个月是最苦的，可从来没有感受到，海马实习基地让我提前感受到了刚刚进入软件行业的压力和困惑，再也没有在自己家里随便写段小程序后的那种“自豪”感了。要面对每天必须面对的问题，再也不可能以“逃避”而了之了。也让我感觉到做为一个程序员所应该具备的基本素质在这不到一个月的实习过程中也让我深深体会到了作为一个合格的程序员应该具备的基本素质。
团队精神和协作能力是程序员应该具备的基本素质，最近的工作中让我深深休会到了这一点，由于小组成员配合不好，使本来很方便的cvs给自己的工作带来的及大的麻烦，一不小心自己写的的东西就会被小组别的成员在上传文件的时候给覆盖掉，一整天的工作可能就这样被反工，我们小组这次就是因为协作不好，导致各模块之间不法连接，给工作带来了及大的麻烦，消耗了大量的劳动力还没有提高工作效率。这使我深深的体会到：一个成功商业性软件的开发必须有一个有强大凝聚力的团队，个人的力量是有限的，团队精神和良好的协作会使我们做出优秀的软件。
良好的文档是正规研发流程中非常重要的环节，作为代码程序员，30％的工作时间写技术文档是很正常的，缺乏文档，一个软件系统就缺乏生命力，在未来的查错，升级以及模块的复用时就都会遇到极大的麻烦。这次的这个小小的项目，就因为文档上的一点点理解错误让我们花了很大的工夫去改代码，改页面。很庆幸的是，这是一个小项目，要是大项目，这种问题可能就会导致大量的代码修改，可见文档在一个项目中起者巨大的做用。
此外，良好的代码编写习惯，不但有助于代码的移植和纠错，也有助于不同技术人员之间的协作。作为一个程序员，对需求的理解能力也是很重要的，只有真正理解了一个模块的作用，才会写出高效率的代码，才能使整个软件项目作出来更加优秀，具备更好的安全性和稳定性，我在写代码的过程中就遇到了需求理解上的问题，使得写出来的代码功能不全，幸好不是给客户发现在，要不，这个软件的商业价值可能就会打折扣了。单元测试对于一个程序员来说是不可不做的一项工作，不做好测试就会给后期的集成工作带来麻烦，往往为了一个小问题会让我们查找好多模块，给后期工作带来很大麻烦。
这一段时间的工作也让我明白了一点：一个优秀的程序员必须不断的学习，随时总结，找到自己的不足，这样逐步提高，才能让自己很快的成长起来。
建站侠客 发表于 2008-4-28 10:19
对软件开发的一点心得体会
一、前期规划：
我理解的前期规划是：在市场人员们汇总一个需求提交给产品专家带领的产品经理团队，然后经过这个团队根据公司具体情况再次分析和规划出一个最终需求文档。
这个需求文档应当首先提交给技术研发部门的负责人以及核心开发人员。由开发团队对其进行技术和风险分析。如果对此需求统一有异议的地方，需要返回给产品团队，重新修正需求。反复如此，直至需求完善准确，细致，清晰。
前期规划就像高楼的地基，如果马马虎虎，就算是一块砖块没摆好都可能导致整个高楼建设的失败。在规划中我认为，交流永远是需要双方积极主动，能认真听取每个人的建议。前期工作思维不慎重，不细致，不认真，不够完善，将产生连锁效应直接导致整个工程和项目的失败。
这种失败可能表现为：第一种，软件按需求实现但是功能根本不能满足用户需要。第二种，功能都有了，软件没有达到可用性、易用性。
对于第一种，当然是因为前期规划疏漏了某些细小功能，没能把需求文档做完善。应该是规划工作做的还不够认真和细致。
对于第二种情况，我认为更多是在产品设计规划方面经验还不够成熟。这种问题应该是很难避免的。因为每种新产品对产品团队来说都很陌生。即使以前做过类似的东西，也难免面面俱到。这只能通过不断努力和认真的态度来弥补。
前期规划的交流涉及了市场、产品和技术研发等多个团队之间。需要的不仅是团队内部的交流，更多需要协调好团队之间的交流。可能有时候需要公司高层和中层参与协调。
目前，很多开发人员深感项目的需求文档写的都很单薄。大家可以想一想，如果没有好的开始，怎么会有好的结束呢？需求文档单薄，不够细致，由谁来继续完善呢？难道让程序员们自己去完善。我想程序员也可能没有这种能力。对于程序员能把代码写的很健壮很稳定就已经是很不容易的事情了。
二、概要设计：
我理解的概要设计步骤：（以项目为中心的开发流程）
1〉 项目经理仔细阅读项目需求文档。
2〉 项目经理召集项目开发成员，开项目启动会议。具体商议项目的开发任务和责任分配。
3〉 核心开发人员开发确定，以及各模块开发人员确定。
4〉 由系统分析员和核心开发人员仔细阅读需求文档，对系统整个架构分析和做技术规划。
5〉 系统分析员整理和书写最终的系统架构和概要设计文档。
6〉 系统分析员在文档提交日，提交给项目经理。项目经理确认文档并审批。
7〉 项目经理召集项目开发成员，开一个概要设计以及系统架构确定的会议。向每个成员分发文档，并讨论确定最终概要设计文档。
8〉开始详细设计文档的工作
三、详细设计：
1〉 项目经理组织成立各个模块的开发小组，并确定开发小组组长（程序经理）。
2〉 各开发组长书写各自模块的详细设计文档，开发成员需要协助，配合。
3〉 在指定提交日，开发组长提交文档给系统分析员。由系统分析员审批。
4〉 系统分析员组织召开一个详细设计文档确认的会议。
5〉 然后开发组长分发各自模块的详细设计文档给程序员，程序员在指定时间内完成。
6〉 程序员做内部测试。开发组长协调并配合。
7〉 确认无bug提交给开发组组长。
8〉 所有模块整合工作，由整个开发组成员参与完成。由所有开发组长和系统分析员负责主要部分工作。程序员协助和配合。
9〉 对整合后工程做详细测试。
10〉 确认测试通过后，开发组长根据开发成员表现以及提交成果填写绩效考核表。然后提交给项目经理。
11〉 项目经理会召开项目总结会，同时向优秀成员颁奖。同时鼓励所有成员继续努力。对不能按时完成导致项目能按时提交，以及对导致失败的关键人员给与惩罚处理。
当然，以上只是一个简单的开发流程，一定是有很多不足的地方。希望能起到抛砖引玉的作用。大家都明白，流程和制度是死的，但人是活的，所以如何按流程做得好，关键还是在人本身了。没有一个流程和制度，一个团队也必将是一盘散沙。正所谓“无规矩无以成方圆”。这句话说得很有道理。
四、具体编码：
开发几个项目之后，对编写程序有了更进一步的了解。
好的程序应该具有: 易读性，易扩展性，容错性。
易读性: 所有变量和函数以及类名用简单易懂易记忆的命名方式。所有类和函数甚至变量都有关键的注释说明。这点很重要，也是最基础的。如果代码书写不够美观和易懂，我想自己以后也不想再看。就更别谈功能的扩展和新版本开发了。
易扩展性: 整体系统架构逻辑简单清晰。模块与模块之间尽量做到互不影响，也就是尽可能的。这部分工作主要体现在前期设计工作中，需要掌握好的设计经验和方法才能够做得比较好。
容错性: 对数据流和指针以及数组都做数据有效性检查；对第三方接口的调用失败的容错性。对所有代码都做调用失败后的错误处理。以及在大的工程中加入trace文件输出，把关键的数据流和关键处理部分的操作信息输出。以便对工程异常情况产生条件的定位，及时解决问题。
我觉得程序员能在这三方面做得很好就算一个优秀的programmer了。
五、调试、跟踪与测试：
1 测试需要注意的：
对每个模块的接口做测试，数据边界的检查。在对整个模块做测试。
主要测试稳定性，效率以及功能是否正常。
确认单个模块完全正常后，再加入工程。
在系统架构设计的时候，可能会引入原型参考。要对原型做完成测试后，确认没有问题后，才可使用。
2 可以采用VC自带Trace或者将信息输出为文本文件的方式跟踪程序并输出关键信息，以便定位程序异常的原因。
3 对于通信模块的测试，特别注意服务端和客户端的数据流。可以针对性的写一个客户端或服务端的测试程序，检验通讯过程是否正常。
4 在用VC做开发中，一定先要让Debug版本正常运行，保证没有任何异常，内存泄漏和Assert等调试警告信息。如果用到其他Lib,一定要保证Lib本身不存在问题。
这里只是提到一些自己容易忽略的东西，希望能对大家有所帮助，欢迎指正！谢谢。下载本文
