合格程序员七⼤基本素质与五⼤必备能⼒
程序员基本素质：
作⼀个真正合格的程序员，或者说就是可以真正合格完成⼀些代码⼯作的程序员，应该具有的素质。
1：团队精神和协作能⼒
把它作为基本素质，并不是不重要，恰恰相反，这是程序员应该具备的最基本的，也是最重要的安⾝⽴命之本。把⾼⽔平程序员说成独⾏侠的都是在呓语，任何个⼈的⼒量都是有限的，即便如linus这样的天才，也需要通过组成强⼤的团队来创造奇迹，那些遍布全球的为linux写核⼼的⾼⼿们，没有协作精神是不可想象的。独⾏侠可以作⼀些赚钱的⼩软件发点⼩财，但是⼀旦进⼊⼀些⼤系统的研发团队，进⼊商业化和产品化的开发任务，缺乏这种素质的⼈就完全不合格了。
2：⽂档习惯
说⾼⽔平程序员从来不写⽂档的肯定是乳臭未⼲的⽑孩⼦，良好的⽂档是正规研发流程中⾮常重要的环节，作为代码程序员，30％的⼯作时间写技术⽂档是很正常的，⽽作为⾼级程序员和系统分析员，这个⽐例还要⾼很多。缺乏⽂档，⼀个软件系统就缺乏⽣命⼒，在未来的查错，升级以及模块的复⽤时就都会遇到极⼤的⿇烦。
3：规范化，标准化的代码编写习惯
作为⼀些外国知名软件公司的规矩，代码的变量命名，代码内注释格式，甚⾄嵌套中⾏缩进的长度和函数间的空⾏数字都有明确规定，良好的编写习惯，不但有助于代码的移植和纠错，也有助于不同技术⼈员之间的协作。
fans叫嚣⾼⽔平程序员写的代码旁⼈从来看不懂，这种叫嚣只能证明他们⾃⼰压根不配⾃称程序员。代码具有良好的可读性，是程序员基本的素质需求。
再看看整个linux的搭建，没有规范化和标准化的代码习惯，全球的研发协作是绝对不可想象的。
4：需求理解能⼒
程序员需要理解⼀个模块的需求，很多⼩朋友写程序往往只关注⼀个功能需求，他们把性能指标全部归结到硬件，操作系统和开发环境上，⽽忽视了本⾝代码的性能考虑，有⼈曾经放⾔说写⼀个⼴告交换程序很简单，这种⼈从来不知道在百万甚⾄千万数量级的访问情况下的性能指标是如何实现的，对于这样的程序员，你给他深蓝那套系统，他也做不出太极链的并访能⼒。性能需求指标中，稳定性，并访⽀撑能⼒以及安全性都很重要，作为程序员需要评估该模块在系统运营中所处的环境，将要受到的负荷压⼒以及各种潜在的危险和恶意攻击的可能性。就这⼀点，⼀个成熟的程序员⾄少需要2到3年的项⽬研发和跟踪经验才有可能有⼼得。
5：复⽤性，模块化思维能⼒
经常可以听到⼀些程序员有这样的抱怨，写了⼏年程序，变成了熟练⼯，每天都是重复写⼀些没有任何新意的代码，这其实是中国软件⼈才最⼤浪费的地⽅，⼀些重复性⼯作变成了熟练程序员的主要⼯作，⽽这些，其实是完全可以避免的。
复⽤性设计，模块化思维就是要程序员在完成任何⼀个功能模块或函数的时候，要多想⼀些，不要局限在完成当前任务的简单思路上，想想看该模块是否可以脱离这个系统存在，是否可以通过简单的修改参数的⽅式在其他系统和应⽤环境下直接引⽤，这样就能极⼤避免重复性的开发⼯作，如果⼀个软件研发单位和⼯作组能够在每⼀次研发过程中都考虑到这些问题，那么程序员就不会在重复性的⼯作中耽误太多时间，就会有更多时间和精⼒投⼊到创新的代码⼯作中去。
⼀些好的程序模块代码，即便是70年代写成的，拿到现在放到⼀些系统⾥⾯作为功能模块都能适合的很好，⽽现在我看到的是，很多⼩公司软件⼀升级或改进就动辄全部代码重写，⼤部分重复性⼯作⽆谓的浪费了时间和精⼒。
6：测试习惯
作为⼀些商业化正规化的开发⽽⾔，专职的测试⼯程师是不可少的，但是并不是说有了专职的测试⼯
程师程序员就可以不进⾏⾃测；软件研发作为⼀项⼯程⽽⾔，⼀个很重要的特点就是问题发现的越早，解决的代价就越低，程序员在每段代码，每个⼦模块完成后进⾏认真的测试，就可以尽量将⼀些潜在的问题最早的发现和解决，这样对整体系统建设的效率和可靠性就有了最⼤的保证。
测试⼯作实际上需要考虑两⽅⾯，⼀⽅⾯是正常调⽤的测试，也就是看程序是否能在正常调⽤下完成基本功能，这是最基本的测试职责，可惜在很多公司这成了唯⼀的测试任务，实际上还差的远那；第⼆⽅⾯就是异常调⽤的测试，⽐如⾼压⼒负荷下的稳定性测试，⽤户潜在的异常输⼊情况下的测试，整体系统局部故障情况下该模块受影响状况的测试，频发的异常请求阻塞资源时的模块稳定测试等等。当然并不是程序员要对⾃⼰的每段代码都需要进⾏这种完整测试，但是程序员必须清醒认识⾃⼰的代码任务在整体项⽬中的地位和各种性能需求，有针对性的进⾏相关测试并尽早发现和解决问题，当然这需要上⾯提到需求理解能⼒。
7：学习和总结的能⼒
程序员是⼈才很容易被淘汰，很容易落伍的职业，因为⼀种技术可能仅仅在三两年内具有领先性，程序员如果想安⾝⽴命，就必须不断跟进新的技术，学习新的技能。
善于学习，对于任何职业⽽⾔，都是前进所必需的动⼒，对于程序员，这种要求就更加⾼了。但是学习也要对⽬标，⼀些⼩coding有些codingTO就是这样的coding上只是⼀些Cfans们，他们也津津乐
道于他们的学习能⼒，⼀会学会了asp，⼀会⼉学会了php，⼀会⼉学会了jsp，他们把这个作为炫耀的资本，盲⽬的追逐⼀些肤浅的，表⾯的东西和名词，做⽹络程序不懂通讯传输协议，做应⽤程序不懂中断向量处理，这样的技术⼈员，不管掌握了多少所谓的新语⾔，永远不会有质的提⾼。
善于总结，也是学习能⼒的⼀种体现，每次完成⼀个研发任务，完成⼀段代码，都应当有⽬的的跟踪该程序的应⽤状况和⽤户反馈，随时总结，到⾃⼰的不⾜，这样逐步提⾼，⼀个程序员才可能成长起来。
⼀个不具备成长性的程序员，即便眼前看是个⾼⼿，建议也不要选⽤，因为他落伍的时候马上就到了。具备以上全部素质的⼈，应当说是够格的程序员了，请注意以上的各种素质都不是由IQ决定的，也不是⼤学某些课本⾥可以学习到的，需要的仅仅是程序员对⾃⼰⼯作的认识，是⼀种意识上的问题。
那么作为⾼级程序员，以⾄于系统分析员，也就是对于⼀个程序项⽬的设计者⽽⾔，除了应该具备上述全部素质之外，还需要具备以下素质：
第⼀，需求分析能⼒
对于程序员⽽⾔，理解需求就可以完成合格的代码，但是对于研发项⽬的组织和管理者，他们不但要理解客户需求，更多时候还要⾃⾏制定⼀些需求，为什么这么说呢？
⼀般⽽⾔，进⾏研发任务，也许是客户提出需求，也许是市场和营销部门提出的需求，这时候对于研发部门，他们看到的不是⼀个完整的需求，通常⽽⾔，该需求仅仅是⼀些功能上的要求，或者更正规些，可能获得⼀个完整的⽤户视图；但是这都不够，因为客户由于⾮技术因素多⼀些，他们可能很难提出完整和清晰，或者说专业性的性能需求，但是对于项⽬组织者和规划者，他必须能够清醒认识到这些需求的存在并在完成需求分析报告的时候适当的提出，同时要完整和清晰的体现在设计说明书⾥⾯，以便于程序员编码时不会失去这些准则。
程序设计者必须正确理解⽤户需求所处的环境，并针对性做出需求的分析，举例⽽⾔，同样⼀个软件通过ASP租⽤⽅式发布和通过License ⽅式发布，性能需求可能就是有区别的，前者强调的是更好的⽀撑能⼒和稳定性，⽽后者则可能更强调在各种平台下的普适性和安装使⽤的简捷性。
第⼆，项⽬设计⽅法和流程处理能⼒
程序设计者必须能够掌握不少于两到三种的项⽬设计⽅法（⽐如⾃顶⾄下的设计⽅法，⽐如快速原型法等等），并能够根据项⽬需求和资源搭配来选择合适的设计⽅法进⾏项⽬的整体设计。设计⽅法上选择不当，就会耽误研发周期，浪费研发资源，甚⾄影响研发效果。
⼀个程序设计者还需要把很多功夫⽤在流程图的设计和处理上，他需要做数据流图以确⽴数据词典；他需要加⼯逻辑流图以形成整体的系统处理流程。⼀个流程有问题的系统，就算代码多漂亮，每个模
块多精致，也不会成为⼀个好的系统。当然，做好流程分析并选择好项⽬设计⽅法，都需要在需求分析能⼒上具有⾜够的把握。
第三，复⽤设计和模块化分解能⼒
这个似乎⼜是⽼调重谈，前⾯基本素质上不是已经说明了这个问题吗？作为⼀个从事模块任务的程序员，他需要对他所⾯对的特定功能模块的复⽤性进⾏考虑，⽽作为⼀个系统分析⼈员，他要⾯对的问题复杂的多，需要对整体系统按照⼀种模块化的分析能⼒分解为很多可复⽤的功能模块和函数，并针对每⼀模块形成⼀个独⽴的设计需求。举个例⼦，好⽐是汽车⽣产，最早每辆汽车都是独⽴安装的，每个部件都是量⾝定做的，但是后来不⼀样了，机器化⼤⽣产了，⼀个汽车⼚开始通过流⽔线来⽣产汽车，独⽴部件开始具有⼀定的复⽤性，在后来标准化成为⼤趋势，不同型号，品牌甚⾄不同⼚商的汽车部件也可以进⾏⽅便的换装和升级，这时候，汽车⽣产的效率达到最⼤化。软件⼯程也是同样的道理，⼀个成熟的软件⾏业，在⼀些相关项⽬和系统中，不同的部件是可以随意换装的，⽐如微软的许多桌⾯软件，在很多操作模块（如打开⽂件，保存⽂件等等）都是复⽤的同⼀套功能模块，⽽这些接⼝⼜通过⼀些类库提供给了桌⾯应⽤程序开发者⽅便挂接，这就是复⽤化的模块设计明显的⼀个佐证。
将⼀个⼤型的，错综复杂的应⽤系统分解成⼀些相对独⽴的，具有⾼度复⽤性的，并能仅仅依靠⼏个
参数完成数据联系的模块组合，是作为⾼级程序员和系统分析员⼀项最重要的⼯作，合适的项⽬设计⽅法，清晰的流程图，是实现这⼀⽬标的重要保证。
第四，整体项⽬评估能⼒
作为系统设计⼈员，必须能够从全局出发，对项⽬⼜整体的清醒认识，⽐如公司的资源配置是否合理和到位，⽐如⼯程进度安排是否能最⼤化体现效率⼜不⾄于⽆法按期完成。评估项⽬整体和各个模块的⼯作量，评估项⽬所需的资源，评估项⽬可能遇到的困难，都需要⼤量的经验积累，换⾔之，这是⼀种不断总结的累计才能达到的境界。在西⽅⼀些软件系统设计的带头⼈都是很年长的，⽐如4，50岁，甚⾄更⽼，他们在编码⽅⾯已经远远不如年轻⼈那样活络，但是就项⽬评估⽽⾔，他们⼏⼗年的经验积累就是最重要和宝贵的财富。中国缺这么⼀代程序员，主要还不是缺那种年纪的程序员，⽽是那种年纪的程序员基本上都是研究单位作出来的，都不是从专业的产品化软件研发作出来的，他们没有能积累那种产品化研发的经验，这也是没有办法的事情。
第五，团队组织管理能⼒
完成⼀个项⽬⼯程，需要团队的齐⼼协⼒，作为项⽬设计者或研发的主管⼈，就应当有能⼒最⼤化发挥团队的整体⼒量，技术管理由于其专业性质，不⼤同于⼀般的⼈事管理，因为这⾥⾯设计了⼀些技术性的指标和因素。
⾸先是⼯作的量化，没有量化就很难做到合适的绩效考核，⽽程序量化⼜不是简单的代码⾏数可以计算的，因此要求技术管理⼈员需要能真正评估⼀个模块的复杂性和⼯作量。
其次是对团队协作模式的调整，⼀般⽽⾔，程序开发的协作通常分为⼩组进⾏，⼩组有主程序员⽅式的，也有民主⽅式的，根据程序员之间的能⼒⽔平差距，以及根据项⽬研发的需求，选择合适的组队⽅式，并能将责权和成员的⼯作任务紧密结合，这样才能最⼤发挥组队的效率。
⼀个代码⽔平⾼的⼈，未必能成为⼀个合格的项⽬研发主管，这⽅⾯的能⼒⽋缺往往是容易被忽视的。
综上可以看到，作为⼀个主管研发的负责⼈，⼀个项⽬设计者，所需要具备的素质和能⼒并不是程序代码编写的能⼒，当然⼀般情况下，⼀
个程序员通过不断的总结提⾼达到了这种素质的时候，他所具有的代码编写能⼒也已经相当不简单了，但是请注意这⾥⾯的因果关系，⼀个⾼⽔平的项⽬设计者通常已经是代码编写相当优秀的⼈了，但是并不是⼀个代码相当优秀的程序员就可以胜任项⽬设计的⼯作，这⾥⾯存在的也不是智商和课本的问题，还是在于⼀个程序员在积累经验，逐步提升的时候没有意识到应当思考哪⽅⾯的东西，没有有意识的就项⽬的组织和复⽤设计进⾏揣摩，没有经常性的⽂档习惯和总结习惯，不改变这些，我们的合格的项⽬设计者还是⾮常⽋缺。
另外，为防⽌有⽆聊的⼈和我较真，补充⼀点，本⽂针对⽬标是作商业化的软件项⽬和⼯程，那些科研机构的编程⾼⼿，⽐如算法⾼⼿，⽐如图象处理⾼⼿，他们的⼯作是研究课题⽽⾮直接完成商业软件（当然最终间接成为商业产品，⽐如微软研究院在作的研究课题），因此他们强调的素质可能是另外的东西，这些⼈（专家），并不能说是程序员，不能⽤程序员的标准去衡量。
最后补充⼀点东西，⼀个软件项⽬研发的设计流程是怎样的呢？以通常标准的设计⽅法为例，（不过笔者喜欢快速原型法）。
第⼀个步骤是市场调研，技术和市场要结合才能体现最⼤价值。
第⼆个步骤是需求分析，这个阶段需要出三样东西，⽤户视图，数据词典和⽤户操作⼿册。⽤户视图是该软件⽤户（包括终端⽤户和管理⽤户）所能看到的页⾯样式，这⾥⾯包含了很多操作⽅⾯的流程和条件。数据词典是指明数据逻辑关系并加以整理的东东，完成了数据词典，数据库的设计就完成了⼀半多。⽤户操作⼿册是指明了操作流程的说明书。
请注意，⽤户操作流程和⽤户视图是由需求决定的，因此应该在软件设计之前完成，完成这些，就为程序研发提供了约束和准绳，很遗憾太多公司都不是这样做的，因果颠倒，顺序不分，开发⼯作和实际需求往往因此产⽣隔阂脱节的现象。
需求分析，除了以上⼯作，笔者以为作为项⽬设计者应当完整的做出项⽬的性能需求说明书，因为往往性能需求只有懂技术的⼈才可能理解，这就需要技术专家和需求⽅（客户或公司市场部门）能够有真正的沟通和了解。
第三个步骤是概要设计，将系统功能模块初步划分，并给出合理的研发流程和资源要求。作为快速原型设计⽅法，完成概要设计就可以进⼊编码阶段了，通常采⽤这种⽅法是因为涉及的研发任务属于新领域，技术主管⼈员⼀上来⽆法给出明确的详细设计说明书，但是并不是说详细设计说明书不重要，事实上快速原型法在完成原型代码后，根据评测结果和经验教训的总结，还要重新进⾏详细设计的步骤。
第四个步骤是详细设计，这是考验技术专家设计思维的重要关卡，详细设计说明书应当把具体的模块以最‘⼲净’的⽅式(⿊箱结构）提供给编码者，使得系统整体模块化达到最⼤；⼀份好的详细设计说明书，可以使编码的复杂性减低到最低，实际上，严格的讲详细设计说明书应当把每个函数的每个参数的定义都精精细细的提供出来，从需求分析到概要设计到完成详细设计说明书，⼀个软件项⽬就应当说完成了⼀半了。换⾔之，⼀个⼤型软件系统在完成了⼀半的时候，其实还没有开始⼀⾏代码⼯作。那些把作软件的程序员简单理解为写代码的，就从根⼦上犯了错误了。
第五个步骤是编码，在规范化的研发流程中，编码⼯作在整个项⽬流程⾥最多不会超过1/2，通常在1/
3的时间，所谓磨⼑不误砍柴功，设计过程完成的好，编码效率就会极⼤提⾼，编码时不同模块之间的进度协调和协作是最需要⼩⼼的，也许⼀个⼩模块的问题就可能影响了整体进度，让很多程序员因此被迫停下⼯作等待，这种问题在很多研发过程中都出现过。编码时的相互沟通和应急的解决⼿段都是相当重要的，对于程序员⽽⾔，bug永远存在，你必须永远⾯对这个问题，⼤名⿍⿍的微软，可曾有连续三个⽉不发补丁的时候吗？从来没有！
第六个步骤是测试。测试有很多种：按照测试执⾏⽅，可以分为内部测试和外部测试；按照测试范围，可以分为模块测试和整体联调；按照测试条件，可以分为正常操作情况测试和异常情况测试；按照测试的输⼊范围，可以分为全覆盖测试和抽样测试。以上都很好理解，不再解释。
总之，测试同样是项⽬研发中⼀个相当重要的步骤，对于⼀个⼤型软件，3个⽉到1年的外部测试都是正常的，因为永远都会⼜不可预料的问题存在。
完成测试后，完成验收并完成最后的⼀些帮助⽂档，整体项⽬才算告⼀段落，当然⽇后少不了升级，修补等等⼯作，只要不是想通过⼀锤⼦买卖骗钱，就要不停的跟踪软件的运营状况并持续修补升级，知道这个软件被彻底淘汰为⽌。
写这些步骤算不上卖弄什么，因为实话讲我⼿边是⼀本《软件⼯程》，在⼤学⾥这是计算机专业的必修课程，但是我知道很多程序员似乎从来都只是热衷于什么《30天精通VC》之类的，他们有些和我⼀
样游击队出⾝，没有正规学过这个专业，还有⼀些则早就在混够学
分后就把这些真正有⽤的东西还给了⽼师。
fans乱嚷嚷，混淆视听，实际上真正的技术专家很少在⽹上乱发帖⼦的，如笔者这样不知天⾼地厚的，其实实在是算不上什么⾼⼿，只不过看不惯这种对技术，对程序员的误解和胡说，只好挺⾝⽽出，做拨乱反正之⾔，也希望那些还fans们能认真想想，⾛到正途上，毕竟那些聪明的头脑还远远没有发挥应有的价值。沉迷于⼀些错误⼈⼠的coding
从程序员升级到⼯程师⼤多数象我这样对软件有浓厚兴趣的⼈，毕业后义⽆反顾地⾛进了企业，开始了程序员的⽣涯。那时，我们迷恋“⼤全”、“秘籍”⼀类的书籍，⼼中只有代码。当我看到⼀⾏⾏枯燥的代码变成了能够打电话的设备，变成了屏幕上漂亮的表格，变成了动听的⾳乐，成就感油然⽽⽣。我觉得⾃⼰也是⼀个出⾊的程序员了。在⽤户的机房中苦熬三昼夜解决软件的bug，也成了⼀种可以夸耀的资历。五年前的某⼀天，我把曾经让我兴奋⾃豪的⼤量代码和少得可怜的⽂档移交之后，来到了华为。这⾥有更多的年轻⼈，我如鱼得⽔，可以充分发挥
⾃⼰的想象⼒。依然是代码，依然是匆匆地在纸上记下稍纵即逝的灵感（我们把它称作⽂档），依然是⽆休⽌地和bug作⽃争。当有⼀天，⼀个新来的同事拿着署着我的⼤名的⽂档，⼩⼼翼翼地来问我时，我发现⾃⼰好象有点不认识它了。我⼼⾥有点沮丧，再看看代码，发现⽂档上记录的⼀些灵感已
⾯⽬全⾮。我当时不知道那位新来的同事感受如何，但我从那时起，好象意识到什么。现在来看，那时的很多事情都是事倍功半。
程序员一般工资多少钱一个月
去年年底，公司派我到印度从事项⽬开发，学习印度的软件开发管理⽅法。⼀种久违的冲动在⼼底升起。印度，我已去过两次，虽说是⾛马观花，但是，印象还是⽐较深刻。我在访问过程中和印度的⼯程师交流过，他们⾔谈中透着⾃信。他们给我讲解正在做的软件的测试环境，给我看他们写的单元测试⽂档。当我看到⼀个软件模块的单元测试⽤例有三百多页时，我觉得⼼⾥很是沉重。当我第三次踏上这⽚⼟地时，我⼜见到了熟悉的⼈们，明亮的眼睛，温和的笑容，随意的穿着，风驰电掣的摩托，还有⼤学校园中穿着拖鞋，⼿抱书本的年轻⼈。
我也见到了我的项⽬经理，⼀个个⼦较⾼，瘦瘦的年轻⼈，据说刚从美国回来，已⼯作了五、六年。我听了⼼⾥很⾼兴，这回要⼀招⼀式地
学两⼿。需求分析的时间是⼀个⽉，项⽬经理和我们（实际上代表客户）讨论了proposal中的内容，确定每⼀项都是需要的。然后他把模块⼤致划分了⼀下，开始进⼊计划中的学习阶段。每个⼈在学习阶段要写出功能描述的胶⽚，给其他⼈讲解，不知不觉中，项⽬组的所有⼈对项⽬有了整体的了解。
他还安排了⼀些培训，如他们公司的软件开发模型、项⽬组中各⾓⾊的定义，以后及时的培训不断，只要项⽬组中有需求，他总是把qa或相关的⼈请来，培训很专业。需求分析完成后提交了⼀份四⼗多
页的⽂档，当我看到这份英⽂⽂档中我写的部分整整齐齐地列在其中时，我的感觉很复杂，有些喜悦，但更多的是苦涩，我以前怎么就从来没有这样做过需求分析呢。
在我写⽂档的过程中，qa给我们培训过srs的写作模板，后来我还是不放⼼，让他们⼀个有经验的⼯程师写了⼀段，我们再琢磨着照着写。这份srs虽然是多个⼈合写，但风格⼀致，内容详实。更为可贵的是，⼀直到最后，这份需求分析的内容都没有改过，以⾄于我们没有机会⾛⼀下他们的需求更改流程。
需求分析是项⽬的第⼀阶段，第⼆阶段的开发时间要根据需求分析的结果来确定。当对⽅的⾸席技术官（相当于我们业务部的总体组长）来和我们讨论计划时，他们已列出了对每个模块的代码⾏数的预测，可能存在的风险。根据他们公司的⽣产率－－300⾏/⼈⽉，他得出了项⽬第⼆阶段需要多少周。
我们当时就提出了异议：1）公司对该项⽬需求很急；2）每⽉300⾏是否太少；3）我们还有下载的源代码参考。他解释说，300⾏/⼈⽉是使得项⽬能达到他们质量标准的经验数据，考虑到有源代码参考，⽣产率最多不能超过350⾏/⼈⽉。
当他问我们公司的⽣产率时，我脑袋⾥转了三个圈，没敢多说，⼤概六、七百⾏吧。他沉默了⼀会⼉，然后坚定地说，我们这个计划是建⽴在确保质量的基础上的，我想你们到印度来开发软件，⾸先看中的应该是我们印度公司的质量保证。我知道你们不缺乏软件开发⼈员，你们为什么不选择下载的
软件呢。⼏句话说到了我的痛处，现在国内的弟兄们还在为使⽤下载软件移植的产品四处奔波呢！
随后的开发活动有条不紊，我们⽼⽼实实地跟着做。系统测试计划、⽤例，概要设计，集成测试计划、⽤例，详细设计，单元测试计划、⽤例，编码，单元测试，集成测试，系统测试。⼀个完整的v模型开发过程，其中每个过程都有review。当我们对⼀些设计的⽅法不太明⽩时，项⽬经理给我们发来了相关的资料，我不知道他当时是怎么想的，⼀些基本的分析、设计⽅法是⼗年，甚⾄⼆⼗年前的软件⼯程书中就讲到的，印度每个计算机专业的⼈员都是必修这些内容的。⽽我们除了对⼀些具体协议的代码很熟之外，对这些常⽤的⽅法似乎⼀⽆所知。我感到⼀些羞愧，进城直奔书店，把他给我开列的书了出来，晚上躺在床上，仔细研读，我仿佛突然⼜遇到了能给我指点迷津的良师益友。现在印度所已形成了强烈的学习风⽓。我回来后也推销了700多本书，这些书教我们如何⽤⼯程化的⽅法开发软件，是成为⼀个软件⼯程师必读的资料。
我们的项⽬经理的计划控制能⼒很强，当有什么影响到项⽬计划的事情发⽣时，如⼈员辞职、实验室搬家、某⼀模块预测不准（该模块是我们预测的），他总是采取必要的措施，减少延期，调整计划。刚开始，我们对他们每天上午11点，下午4点下楼喝咖啡还有点意见，后来也跟着喝去了，原来，喝咖啡时的交流⾮常丰富，从项⽬管理到设计⽅法，从技术发展到风⼟⼈情，⽆所不包，对我们互相之间的理解，对团队的⽓氛很有帮助。我们项⽬的qa也在适当的时候出现在我们的⾯前，我们对她的⼯作只有⼀些感性认识。她每次参加会议时，⼿⾥时常拿着⼀个check list，项⽬经理准备相应的资料，回
答⼀些问题，她打着勾，或写着项⽬经理的解释。她给我们做培训时也很耐⼼，体现出很好的职业素养，我⾄今还在怀念她给我们的帮助。
我从事软件开发已有九个年头了，可我现在仍然不能说⾃⼰是个合格的软件⼯程师，更不⽤谈什么合格的管理者。我看到⼀份报道说，瑞⼠洛桑⼀权威机构把中国的科技综合竞争⼒从原来的第⼗三位调到⼆⼗多位，原因是他们调整了⼀些评估标准，其中有⼀条是中国合格⼯程师的可获得性⾮常低。想着弟兄们熬红的双眼，四处奔波升级的疲惫⾝影，我有⼀个强烈的愿望：快把我们⾃⼰升级成合格的⼯程师吧!  以下这个贴⼦转⾃“中国计算机世界”，原作者不详。我看了以后觉得很不错，特把它推荐给各位。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。