走向架构师必备的技能，你都会了吗？

中国有不少年轻人，他们18,9岁或21,2岁，经过自学也写了很多代码，他们有的代码写的很漂亮，一些技术细节至关出众，也颇有钻研精神，可是他们被一些错误的认识和观点左右，缺少对系统，对程序的总体理解能力，这些人，一个网上的朋友说得很好，他们实际fans，压根没有资格称为程序员，可是据我所知，很多小网络公司的Cfans,拿着吓人的工资，作着吓人的项目，项目的结局一般也很吓人。

　　程序员基本素质：

　　做一个真正合格的程序员，或者说就是能够真正合格完成一些代码工做的程序员，应该具备的素质。

 

1. 团队精神和协做能力

　　把它做为基本素质，并非不重要，偏偏相反，这是程序员应该具有的最基本的，也是最重要的安身立命之本。把高水平程序员说成独行侠的都是在呓语，任何我的的力量都是有限的，即使如linus这样的天才，也须要经过组成强大的团队来创造奇迹，那些遍及全球的为linux写核心的高手们，没有协做精神是不可想象的。独行侠能够做一些赚钱的小软件发点小财，可是一旦进入一些大系统的研发团队，进入商业化和产品化的开发任务，缺少这种素质的人就彻底不合格了。

2. 文档习惯

　　说高水平程序员历来不写文档的确定是乳臭未干的毛孩子，良好的文档是正规研发流程中很是重要的环节，做为代码程序员，30％的工做时间写技术文档是很正常的，而做为高级程序员和系统分析员，这个比例还要高不少。缺少文档，一个软件系统就缺少生命力，在将来的查错，升级以及模块的复用时就都会遇到极大的麻烦。

3. 规范化，标准化的代码编写习惯

　　做为一些外国知名软件公司的规矩，代码的变量命名，代码内注释格式，甚至嵌套中行缩进的长度和函数间的空行数字都有明确规定，良好的编写习惯，不但有助于代码的移植和纠错，也有助于不一样技术人员之间的协做。

　　fans叫嚣高水平程序员写的代码旁人历来看不懂，这种叫嚣只能证实他们本身压根不配自称程序员。代码具备良好的可读性，是程序员基本的素质需求。

　　再看看整个linux的搭建，没有规范化和标准化的代码习惯，全球的研发协做是绝对不可想象的。

4. 需求理解能力

　　程序员须要理解一个模块的需求，不少小朋友写程序每每只关注一个功能需求，他们把性能指标所有归结到硬件，操做系统和开发环境上，而忽视了自己代码的性能考虑，有人曾经放言说写一个广 告交换程序很简单，这种人历来不知道在百万甚至千万数量级的访问状况下的性能指标是如何实现的，对于这样的程序员，你给他深蓝那套系统，他也作不出太极链的并访能力。性能需求指标中，稳定性，并访支撑能力以及安全性都很重要，做为程序员须要评估该模块在系统运营中所处的环境，将要受到的负荷压力以及各类潜在的危险和恶意攻击的可能性。就这一点，一个成熟的程序员至少须要2到3年的项目研发和跟踪经验才有可能有心得。

5. 复用性，模块化思惟能力

　　常常能够听到一些程序员有这样的抱怨，写了几年程序，变成了熟练工，天天都是重复写一些没有任何新意的代码，这实际上是中国软件人才最大浪费的地方，一些重复性工做变成了熟练程序员的主要工做，而这些，实际上是彻底能够避免的。

　　复用性设计，模块化思惟就是要程序员在完成任何一个功能模块或函数的时候，要多想一些，不要局限在完成当前任务的简单思路上，想一想看该模块是否能够脱离这个系统存在，是否能够经过简单的修改参数的方式在其余系统和应用环境下直接引用，这样就能极大避免重复性的开发工做，若是一个软件研发单位和工做组可以在每一次研发过程当中都考虑到这些问题，那么程序员就不会在重复性的工做中耽误太多时间，就会有更多时间和精力投入到创新的代码工做中去。

　　一些好的程序模块代码，即使是70年代写成的，拿到如今放到一些系统里面做为功能模块都能适合的很好，而如今我看到的是，不少小公司软件一升级或改进就动辄所有代码重写，大部分重复性工做无谓的浪费了时间和精力。

6. 测试习惯

　　做为一些商业化正规化的开发而言，专职的测试工程师是不可少的，可是并非说有了专职的测试工程师程序员就能够不进行自测；软件研发做为一项工程而言，一个很重要的特色就是问题发现的越早，解决的代价就越低，程序员在每段代码，每一个子模块完成后进行认真的测试，就能够尽可能将一些潜在的问题最先的发现和解决，这样对总体系统建设的效率和可靠性就有了最大的保证。

　　测试工做实际上须要考虑两方面，一方面是正常调用的测试，也就是看程序是否能在正常调用下完成基本功能，这是最基本的测试职责，惋惜在不少公司这成了惟一的测试任务，实际上还差的远那；第二方面就是异常调用的测试，好比高压力负荷下的稳定性测试，用户潜在的异常输入状况下的测试，总体系统局部故障状况下该模块受影响情况的测试，频发的异常请求阻塞资源时的模块稳定测试等等。固然并非程序员要对本身的每段代码都须要进行这种完整测试，可是程序员必须清醒认识本身的代码任务在总体项目中的地位和各类性能需求，有针对性的进行相关测试并尽早发现和解决问题，固然这须要上面提到需求理解能力。

7. 学习和总结的能力

　　程序员是人才很容易被淘汰，很容易落伍的职业，由于一种技术可能仅仅在三两年内具备领先性，程序员若是想安身立命，就必须不断跟进新的技术，学习新的技能。

　　善于学习，对于任何职业而言，都是前进所必需的动力，对于程序员，这种要求就更加高了。可是学习也要找对目标，一些小coding有些codingTO就是这样的coding上只是一些Cfans们，他们也津津乐道于他们的学习能力，一会学会了asp，一下子学会了php，一下子学会了jsp，他们把这个做为炫耀的资本，盲目的追逐一些肤浅的，表面的东西和名词，作网络程序不懂通信传输协议，作应用程序不懂中断向量处理，这样的技术人员，无论掌握了多少所谓的新语言，永远不会有质的提升。

　　善于总结，也是学习能力的一种体现，每次完 成一个研发任务，完成一段代码，都应当有目的的跟踪该程序的应用情况和用户反馈，随时总结，找到本身的不足，这样逐步提升，一个程序员才可能成长起来。

　　一个不具有成长性的程序员，即使眼前看是个高手，建议也不要选用，由于他落伍的时候立刻就到了。具有以上所有素质的人，应当说是够格的程序员了，请注意以上的各类素质都不是由IQ决定的，也不是大学某些课本里能够学习到的，须要的仅仅是程序员对本身工做的认识，是一种意识上的问题。

　　那么做为高级程序员，以致于系统分析员，也就是对于一个程序项目的设计者而言，除了应该具有上述所有素质以外，还须要具有如下素质：

1. 需求分析能力

　　对于程序员而言，理解需求就能够完成合格的代码，可是对于研发项目的组织和管理者，他们不但要理解客户需求，更多时候还要自行制定一些需求，为何这么说呢？

　　通常而言，进行研发任务，也许是客户提出需求，也许是市场和营销部门提出的需求，这时候对于研发部门，他们看到的不是一个完整的需求，一般而言，该需求仅仅是一些功能上的要求，或者更正规些，可能得到一个完整的用户视图；可是这都不够，由于客户因为非技术因素多一些，他们可能很难提出完整和清晰，或者说专业性的性能需求，可是对于项目组织者和规划者，他必须可以清醒认识到这些需求的存在并在完成 需求分析报告的时候适当的提出，同时要完整和清晰的体如今设计说明书里面，以便于程序员编码时不会失去这些准则。

　　程序设计者必须正确理解用户需求所处的环境，并针对性作出需求的分析，举例而言，一样一个软件经过ASP租用方式发布和经过License方式发布，性能需求可能就是有区别的，前者强调的是更好的支撑能力和稳定性，然后者则可能更强调在各类平台下的普适性和安装使用的简捷性。

2. 项目设计方法和流程处理能力

　　程序设计者必须可以掌握很多于两到三种的项目设计方法（好比自顶至下的设计方法，好比快速原型法等等），并可以根据项目需求和资源搭配来选择合适的设计方法进行项 目的总体设计。设计方法上选择不当，就会耽误研发周期，浪费研发资源，甚至影响研发效果。

　　一个程序设计者还须要把不少功夫用在流程图的设计和处理上，他须要作数据流图以确立数据词典；他须要加工逻辑流图以造成总体的系统处理流程。一个流程有问题的系统，就算代码多漂亮，每一个模块多精致，也不会成为一个好的系统。固然，作好流程分析并选择好项目设计方法，都须要在需求分析能力上具备足够的把握。

3. 复用设计和模块化分解能力

　　这个彷佛又是老调重谈，前面基本素质上不是已经说明了这个问题吗？做为一个从事模块任务的程序员，他须要对他所面对的特定功能模块的 复用性进行考虑，而做为一个系统分析人员，他要面对的问题复杂的多，须要对总体系统按照一种模块化的分析能力分解为不少可复用的功能模块和函数，并针对每一模块造成一个独立的设计需求。举个例子，比如是汽车生产，最先每辆汽车都是独立安装的，每一个部件都是量身定作的，可是后来不同了，机器化大生产了，一个汽车厂开始经过流水线来生产汽车，独立部件开始具备必定的复用性，在后来标准化成为大趋势，不一样型号，品牌甚至不一样厂商的汽车部件也能够进行方便的换装和升级，这时候，汽车生产的效率达到最大化。软件工程也是一样的道理，一个成熟的软件行业，在一些相关项目和系统中，不一样的部件是能够随意换装的，好比微软的许多桌面软件，在不少操做模块（如打开文件，保存文件等等）都是复用的同一套功能模块，而这些接口又经过一些类库提供给了桌面应用程序开发者方便挂接，这就是复用化的模块设计明显的一个佐证。

　　将一个大型的，错综复杂的应用系统分解成一些相对独立的，具备高度复用性的，并能仅仅依靠几个参数完成数据联系的模块组合，是做为高级程序员和系统分析员一项最重要的工做，合适的项目设计方法，清晰的流程图，是实现这一目标的重要保证。

4. 总体项目评估能力

　　做为系统设计人员，必须可以从全局出发，对项目又总体的清醒认识，好比公司的资源配置是否合理和到位，好比工程进度安排是否能最大化体现效率又不至于没法定期完成。评估项 目总体和各个模块的工做量，评估项目所需的资源，评估项目可能遇到的困难，都须要大量的经验积累，换言之，这是一种不断总结的累计才能达到的境界。在西方一些软件系统设计的带头人都是很年长的，好比4，50岁，甚至更老，他们在编码方面已经远远不如年轻人那样活络，可是就项目评估而言，他们几十年的经验积累就是最重要和宝贵的财富。中国缺这么一代程序员，主要还不是缺那种年纪的程序员，而是那种年纪的程序员基本上都是研究单位做出来的，都不是从专业的产品化软件研发做出来的，他们没有能积累那种产品化研发的经验，这也是没有办法的事情。

5. 团队组织管理能力

　　完成一个项目工程，须要团队的齐心合力，做为项目设计者或研发的主管人，就应当有能力最大化发挥团队的总体力量，技术管理因为其专业性质，不大同于通常的人事管理，由于这里面设计了一些技术性的指标和因素。

　　首先是工做的量化，没有量化就很难作到合适的绩效考核，而程序量化又不是简单的代码行数能够计算的，所以要求技术管理人员须要能真正评估一个模块的复杂性和工做量。

　　其次是对团队协做模式的调整，通常而言，程序开发的协做一般分为小组进行，小组有主程序员方式的，也有民主方式的，根据程序员之间的能力水平差距，以及根据项目研发的需求，选择合适的组队方式，并能将责权和成员的工做任务紧密结合，这样才能最大发挥组队的效率。

　　一个代码水平高的人，未必能成为一个合格的项目研发主管，这方面的能力欠缺每每是容易被忽视的。

　　综上能够看到，做为一个主管研发的负责人，一个项目设计者，所须要具有的素质和能力并非程序代码编写的能力，固然通常状况下，一个程序员经过不断的总结提升达到了这种素质的时候，他所具备的代码编写能力也已经至关不简单了，可是请注意这里面的因果关系，一个高水平的项目设计者一般已是代码编写至关优秀的人了，可是并非一个代码至关优秀的程序员就能够胜任项目设计的工做，这里面存在的也不是智商和课本的问题，仍是在于一个程序员在积累经验，逐步提高的时候没有意识到应当思考哪方面的东西，没有有意识的就项目的组织和复用设计进行揣摩，没有常常性的文档习惯和总结习惯， 不改变这些，咱们的合格的项目设计者仍是很是欠缺。

　　另外，为防止有无聊的人和我较真，补充一点，本文针对目标是做商业化的软件项目和工程，那些科研机构的编程高手，好比算法高手，好比图象处理高手，他们的工做是研究课题而非直接完成商业软件（固然最终间接成为商业产品，好比微软研究院在做的研究课题），所以他们强调的素质多是另外的东西，这些人（专家），并不能说是程序员，不能用程序员的标准去衡量。

最后补充一点东西，一个软件项目研发的设计流程是怎样的呢？以一般标准的设计方法为例，（不过笔者喜欢快速原型法）。

• 第一个步骤是市场调研，技术和市场要结合才能体现最大价值。

• 第二个步骤是需求分析，这个阶段须要出三样东西，用户视图，数据词典和用户操做手册。用户视图是该软件用户（包括终端用户和管理用户）所能看到的页面样式，这里面包含了不少操做方面的流程和条件。数据词典是指明数据逻辑关系并加以整理的东东，完成了数据词典，数据库的设计就完成了一半多。用户操做手册是指明了操做流程的说明书。

　　注意，用户操做流程和用户视图是由需求决定的，所以应该在软件设计以前完成，完成这些，就为程序研发提供了约束和准绳，很遗憾太多公司都不是这样作的，因果颠倒，顺序不分，开发工做和实际需求每每所以 产生隔阂脱节的现象。

　　需求分析，除了以上工做，笔者觉得做为项目设计者应当完整的作出项目的性能需求说明书，由于每每性能需求只有懂技术的人才可能理解，这就须要技术专家和需求方（客户或公司市场部门）可以有真正的沟通和了解。

• 第三个步骤是概要设计，将系统功能模块初步划分，并给出合理的研发流程和资源要求。做为快速原型设计方法，完成概要设计就能够进入编码阶段了，一般采用这种方法是由于涉及的研发任务属于新领域，技术主管人员一上来没法给出明确的详细设计说明书，可是并非说详细设计说明书不重要，事实上快速原型法在完成原型代码后，根据评测结果和经验教训的总结，还要从新进行详细设计的步骤。

• 第四个步骤是详细设计，这是考验技术专家设计思惟的重 要关卡，详细设计说明书应当把具体的模块以最‘干净’的方式(黑箱结构）提供给编码者，使得系统总体模块化达到最大；一份好的详细设计说明书，可使编码的复杂性减低到最低，实际上，严格的讲详细设计说明书应当把每一个函数的每一个参数的定义都精精细细的提供出来，从需求分析到概要设计到完成详细设计说明书，一个软件项目就应当说完成了一半了。换言之，一个大型软件系统在完成了一半的时候，其实尚未开始一行代码工做。那些把做软件的程序员简单理解为写代码的，就从根子上犯了错误了。

• 第五个步骤是编码，在规范化的研发流程中，编码工做在整个项目流程里最多不会超过1/2，一般在1/3的时间，所谓磨刀不误砍柴功，设计过程完成的好，编码效率就会极大提升，编码时不一样模块之间的进度协调和协做是最须要当心的，也许一个小模块的问题就可能影响了总体进度，让不少程序员所以被迫停下工做等待，这种问题在不少研发过程当中都出现过。编码时的相互沟通和应急的解决手段都是至关重要的，对于程序员而言，bug永远存在，你必须永远面对这个问题，大名鼎鼎的微软，可曾有连续三个月不发补丁的时候吗？历来没有！

• 第六个步骤是测试

　　测试有不少种：按照测试执行方，能够分为内部测试和外部测试；按照测试范围，能够分为模块测试和总体联调；按照测试条 件，能够分为正常操做状况测试和异常状况测试；按照测试的输入范围，能够分为全覆盖测试和抽样测试。以上都很好理解，再也不解释。

　　总之，测试一样是项目研发中一个至关重要的步骤，对于一个大型软件，3个月到1年的外部测试都是正常的，由于永远都会又不可预料的问题存在。

　　完成测试后，完成验收并完成最后的一些帮助文档，总体项目才算告一段落，固然往后少不了升级，修补等等工做，只要不是想经过一锤子买卖骗钱，就要不停的跟踪软件的运营情况并持续修补升级，知道这个软件被完全淘汰为止。

　　写这些步骤算不上卖弄什么，由于实话讲我手边是一本《软件工程》，在大学里这是计算机专业的必修课程，可是我知道不少程序员彷佛历来都只是热衷于什么《30天精通VC》之类的，他们有些和我同样游击队出身，没有正规学过这个专业，还有一些则早就在混够学分后就把这些真正有用的东西还给了老师。

　　fans乱嚷嚷，混淆视听，实际上真正的技术专家不多在网上乱发帖子的，如笔者这样不知天高地厚的，其实实在是算不上什么高手，只不过看不惯这种对技术，对程序员的误解和胡说，只好自告奋勇，作拨乱反正之言，也但愿那些还fans们能认真想一想，走到正途上，毕竟那些聪明的头脑还远远没有发挥应有的价值。沉迷于一些错误人士的coding

　　*****************************

　　从程序员升级到工程师大多数象我这样对软件有浓厚兴趣的人，毕业后义无反顾地走进了企业，开始了程序员的生涯。那时，咱们迷恋“大全”、“秘籍”一类的书籍，心中只有代码。当我看到一行行枯燥的代码变成了可以打电话的设备，变成了屏幕上漂亮的表格，变成了动听的音乐，成就感油然而生。我以为本身也是一个出色的程序员了。在用户的机房中苦熬三昼夜解决软件的bug，也成了一种能够夸耀的资历。五年前的某一天，我把曾经让我兴奋自豪的大量代码和少得可怜的文档移交以后，来到了华为。这里有更多的年轻人，我如鱼得水，能够充分发挥本身的想象力。依然是代码，依然是匆匆地在纸上记下稍纵即逝的灵感（咱们把它称做文档），依然是无休止地和bug做斗争。当有一天，一个新来 的同事拿着署着个人大名的文档，当心翼翼地来问我时，我发现本身好象有点不认识它了。我内心有点沮丧，再看看代码，发现文档上记录的一些灵感已面目全非。我当时不知道那位新来的同事感觉如何，但我从那时起，好象意识到什么。如今来看，那时的不少事情都是事倍功半。

　　去年年末，公司派我到印度从事项目开发，学习印度的软件开发管理方法。一种久违的冲动在心底升起。印度，我已去过两次，虽然说是蜻蜓点水，可是，印象仍是比较深入。我在访问过程当中和印度的工程师交流过，他们言谈中透着自信。他们给我讲解正在作的软件的测试环境，给我看他们写的单元测试文档。当我看到一个软件模块的单元测试用例有三百多页时，我以为内心非常沉重。当我第三次踏上这片土地时，我又见到了熟悉的人们，明亮的眼睛，温和的笑容，随意的穿着，风驰电掣的摩托，还有大学校园中穿着拖鞋，手抱书本的年轻人。

　　我也见到了个人项目经理，一个个子较高，瘦瘦的年轻人，听说刚从美国回来，已工做了5、六年。我听了内心很高兴，这回要一招一式地学两手。需求分析的时间是一个月，项目经理和咱们（实际上表明客户 ）讨论了proposal中的内容，肯定每一项都是须要的。而后他把模块大体划分了一下，开始进入计划中的学习阶段。每一个人在学习阶段要写出功能描述的胶片，给其余人讲解，不知不觉中，项目组的全部人对项目有了总体的了解。

　　他还安排了一些培训，如他们公司的软件开发模型、项目组中各角色的定义，之后及时的培训不断，只要项目组中有需求，他老是把qa或相关的人请来，培训很专业。需求分析完成后提交了一份四十多页的文档，当我看到这份英文文档中我写的部分整整齐齐地列在其中时，个人感受很复杂，有些喜悦，但更多的是苦涩，我之前怎么就历来没有这样作过需求分析呢。

　　在我写文档的过程当中，qa给咱们培训过srs的写做模板，后来我仍是不放心，让他们一个有经验的工程师写了一段，咱们再琢磨着照着写。这份srs虽然是多我的合写，但风格一致，内容详实。更为难得的是，一直到最后，这份需求分析的内容都没有改过，以致于咱们没有机会走一下他们的需求更改流程。

　　需求分析是项目的第一阶段，第二阶段的开发时间要根据需求分析的结果来肯定。当对方的首席技术官（至关于咱们业务部的整体组长）来和咱们讨论计划时，他们已列出了对每一个 模块的代码行数的预测，可能存在的风险。根据他们公司的生产率－－300行/人月，他得出了项目第二阶段须要多少周。

　　咱们当时就提出了异议：1）公司对该项目需求很急；2）每个月300行是否太少；3）咱们还有下载的源代码参考。他解释说，300行/人月是使得项目能达到他们质量标准的经验数据，考虑到有源代码参考，生产率最多不能超过350行/人月。

　　当他问咱们公司的生产率时，我脑壳里转了三个圈，没敢多说，大概6、七百行吧。他沉默了一下子，而后坚决地说，咱们这个计划是创建在确保质量的基础上的，我想大家到印度来开发软件，首先看中的应该是咱们印度公司的质量保证。我知道大家不缺少软件开发人员，大家为何不选择下载的软件呢。几句话说到了个人痛处，如今国内的弟兄们还在为使用下载软件移植的产品四处奔波呢！

　　随后的开发活动有条不紊，咱们老老实实地跟着作。系统测试计划、用例，概要设计，集成测试计划、用例，详细设计，单元测试计划、用例，编码，单元测试，集成测试，系统测试。一个完整的v模型开发过程，其中每一个过程都有review。当咱们对一些设计的方法不太明白时，项目经理给咱们发来了相关的资料，我不知道他当时是怎么想的，一些基本的分析、设计方法是十年，甚至二十年前的软件工程书中就讲到的，印度每一个计算机专业的人员都是必修这些内容的。而咱们除了对一些具体协议的代码很熟以外，对这些经常使用的方法彷佛一无所知。我感到一些羞愧，进城直奔书店，把他给我开列的书找了出来，晚上躺在床上，仔细研读，我仿佛忽然又遇到了能给我指点迷津的良师益友。如今印度所已造成了强烈的学习风气。我回来后也推销了700多本书，这些书教咱们如何用工程化的方法开发软件，是成为一个软件工程师必读的资料。

　　咱们的项目经理的计划控制能力很强，当有什么影响到项目计划的事情发生时，如人员辞职、实验室搬家、某一模块预测不许（该模块是咱们预测的），他老是采起必要的措施，减小延期，调整计划。刚开始，咱们对他们天天上午11点，下午4点下楼喝咖啡还有点意见，后来也跟着喝去了，原来，喝咖啡时的交流很是丰富，从项目管理到设计方法，从技术发展到风土人情，无所不包，对咱们互相之间的理解，对团队的气氛颇有帮助。咱们项目的qa也在适当的时候出如今咱们的面前，咱们对她的工做只有一些感性认识。她每次参加会议时，手里时常拿着一个check list，项目经理准备相应的资料，回答一些问题，她打着勾，或写着项目经理的解释。她给咱们作培训时也很耐心，体现出很好的职业素养，我至今还在怀念她给咱们的帮助。

　　我从事软件开发已有四个年头了，可我如今仍然不能说本身是个合格的软件工程师，更不用谈什么合格的管理者。我看到一份报道说，瑞士洛桑一权威机构把中国的科技综合竞争力从原来的第十三位调到二十多位，缘由是他们调整了一些评估标准，其中有一条是中国合格工程师的可得到性很是低。想着弟兄们熬红的双眼，四处奔波升级的疲惫身影，我有一个强烈的愿望：快把咱们本身升级成合格的工程师吧!