优秀软件工程师的品质 - 这是本人05年写的文章，现在看来仍然不算过时

    主要观点：意识不同、层次不同是“将军”和“士兵”的主要差异

    我刚刚从业时，主要从事网站开发、数据库设计，后来专注于Windows平台上的软件设计和开发，工具是VC++.随着工作实践和本人的思考，陆续有了些心得和体会。

    一次，我拿了一篇文章“The Joel Test:软件开发成功12法则” 给我的一个做CTO职务的朋友看，他沮丧的发现自己的得分是零蛋。第二天，他把这篇文章发到全公司，表示警醒。
    这并不稀奇，大多数软件开发者把精力和思路拘泥于具体的技术，热衷于且仅仅热衷于单一技术上的进步，充其量也只是“技术高手”罢了。但是，随着软件复杂度的提高和软件产业的发展，单一素质的“软件高手”越来越难以适应实践的需要。
    第一层：合格的技术人员
    观点一、高手和低手的差别，如果用最简单的一句话涵盖就是－知道和不知道。注意，我写的是软件工程师，不是高级软件专家－比如微软的海尔斯伯格（如果做程序不知道此人，那可是有些说不过去）因为自身还不能达到那样的境界，无从写起，写了也是错的。
    "Do the right things and do the things right."高手知道如何正确选择技术方案以及合理的使用它们。其实很多时候技术实现并不难，问题是怎么想到用这个办法。
    在Windows平台，我觉得判断程序员的水平有个重要的标尺
    －看你是否好好学习过《Programming Applications for Microsoft Windows》，它是美国技术作家Jeffrey Richter的杰作，中文版名字是《Windows 核心编程》。当然，没有一定的水平和经验，也读不懂书中的内容。中文翻译的内容有很多错误，我干脆高价买来英文版研读了半年多。这本书之所以重要，是因为如果你不了解其中讲述的内容，那么你在编程的道路上一定走不远，在和系统打交道的时候一定漏洞百出，频出昏着，因为你根本不明白你自己在干什么。比如某位仁兄的代码里面是这么写的(C++)：
    ……
    HANDLE hThread = CreateThread(NULL , 0 , ThreadFun , NULL , 0 , &dwThreadId);
    ……
    TerminateThread(hThread , 0);

    问题在哪里？
    首先在C++的代码里面，不应该使用CreateThread函数来创建线程，应该使用_beginthreadex来代替，否则可能会有内存泄漏等问题。
    最糟糕的事情是他不知道TerminateThread意味着什么，估计是根本没搞明白线程的相关知识，就在MSDN里面搜索了一下，看到这个函数能KILL掉线程，哦，拿来用吧……
    几乎所有的高级软件技术都以你掌握了这些核心内容为前提，比如COM技术，作者在书中也提到：他非常同情那些陷入COM技术的泥潭无法脱身的人，而之所以没有在书中讲述COM技术，是因为COM不过是一些已有的技术、概念的混合体－线程、DLL、内存管理等等，如果掌握了这些内容，COM是很容易上手的。
    还有，某些程序员不知道系统提供的便利接口，也不懂得有效利用他人已有的成果，什么都要自己来写。遇见问题谁都不问，自己闷头解决，其实实践中涉及到的很多问题你并不是第一个遇到的，搜索一下或者询问一下他人就知道了答案，比自己研究快的多了。

    观点二、"功夫在诗外"
    这里不说基础的数据结构、离散数学等东西，因为这是每个程序员必备的知识储备。这里说的是开发工具。例如：如果使用VC++做开发，Numega的BoundsChecker工具是必备的，特别是涉及到开发Windows服务等需要长期稳定运行的程序，如果你的产品有内存泄漏的毛病，别指望它能连续跑几个星期而不崩溃。还有其它的辅助工具，可以有效的提高工作效率和质量。
    随着软件产业的发展，软件开发工具本身，也注入了新的内容，比如微软的VS.NET 2005，就结合了MSF 4.0，做了一套Team System。它可以有效的统一项目团队的成员进行合作。问题是，实践中我发现很多程序员抵触各种辅助工具，宁愿相信自己的代码完美无暇，结果是程序漏洞百出。拒绝的具体原因大概是嫌麻烦， 懒得接受这些新思维，因为要改变旧的习惯并不容易。

    观点三：要有积极进取的心态和快速的学习能力
    海纳百川，有容乃大。计算机软件发展很快，知识淘汰更新的速度也惊人。可能没几年，你所炫耀的技术能力就成为了没用的废物。 举个例子，软件的发展规律之一就是专业化的不断提升，比如以前使用ASP技术做B/S架构的程序，你要做很多和业务毫无关系的事情－登陆、注册、管理界面、报表处理等等，可如今在ASP.NET 2.0版本的技术中，这些重复任务都被做成了组件，你可以用非常快的速度完成以前用很长时间才能做好的事情。
    所以，懒散的人是不行的，必定被社会的技术进步甩开。
第二层：主力程序员
    如果作为开发项目小组负责人，能否带着小组成员一起有效的完成工作任务？
    当项目中的人变多，工程量变大，问题就麻烦起来。组织得不好，2个人半年完成的任务，4个人3个月未必能够做完。
    如何分配工作量？几个人并行开发，如何归并？当代码量变大的时候，要注意什么问题？产品需要多个不同的版本，稍有差别却又差不多，怎么在开发中处理？如果选择技术方案？
我观摩的半条命游戏代码，在自己的台式机上编译就需要2个小时，而此产品的代码质量、体系结构的设计还是非常出色的。如果没有控制较大规模软件系统的知识和理论基础，系统一定麻烦不断，漏洞百出，质量低劣。
    如何让程序员快乐的工作、尽量出活其实是个很重要的问题。现有的体会是多用自动工具避免重复劳动(为什么使用源码管理系统的重要理由)，不能折腾人，要对发生的问题及时关注解决，打气鼓励。
    还要采用各种活动来提高团队整体水平，比如每周1次的CODE REVIEW，可以观摩别人的实现，并解决潜在的问题所在。
    设计软件结构的时候，需要考虑软件的物理层次结构，尽力避免循环依赖问题，使得软件组件能够分层次、递进式的测试。如果不考虑软件的“可测试性”，软件产品质量难以保证。为了编译的顺畅，还要注意组件之间的“绝缘”，避免过分耦合等等。
    此类问题已经超出了具体的某项技术，更多的是系统的组织管理和工作经验。

    这里列出让我的朋友得零分的测试题目以供参考（每题1分）：
    1、你们用不用源文件管理系统？
    2、你们可以把整个系统从源码到CD映象文件一步建成吗？
    3、你们每天白天都把系统源码到CD映象做一遍吗？
    4、你们有软件虫管理系统吗？
    5、你们在写新程序之前总是把现有程序里已知的虫解决吗？
    6、你们的产品开发日程安排是否反映最新的开发进展情况？
    7、你们有没有软件开发的详细说明书？
    8、你们的程序员是否工作在安静的环境里？
    9、你们是否使用现有市场上能买到的最好的工具？
    10、你们有没有专职的软件测试人员？
    11、你们招人面试时是否让写一段程序？
    12、你们是否随便抓一些人来试用你们的软件？
    大多数的软件公司只能得到2到3分，而微软公司从来就没有低过12分，它的成功绝不是毫无道理的。
    尽管其中的内容并不全是项目组长的责任，但是这个层次的人员必须有这样的意识和远见，才能配合其他人做好开发工作。
    软件开发发展的趋势之一就是自动化－尽量消除非创造性的手工劳动，这样才可以提高工作效率，避免低级错误，增进产品品质。自动化现在已经包括了自动编译（每晚构建）、自动测试等等，值得进一步研究关注。
    当然，所有问题不可能一次解决，需要一个渐进、迭代的过程。
第三层： 程序经理、CTO
    首先，做为主管项目的程序经理，必须懂得找到适合公司使用的软件开发模型、过程。
    微软解决方案框架-MSF是我比较推崇的软件开发模型和过程，主要是经过微软的培训和一些实践，感觉灵活敏捷，结合了很多软件过程的优点，而且可操作性非常好，有具体的工作指南和步骤，适合很多项目的类型。当然，其实并没有一种普适的软件开发过程，不能把指导思想变成教条，要灵活对待。
    就我的理解，在微软解决方案框架中，程序经理的角色举足轻重。对内，他要负责整个项目的规划、管理，对外，要协调各种资源、人员和处理各种事宜。更多的是统揽全局，能够对产品进行远景规划，有效的组织开发、测试。
    CTO应该关注的是技术如何能给公司带来价值，带来利益。要把握技术方向、管理技术风险，维护公司的核心竞争能力。
    技术常常是次要的，关键是满足用户的需求。拿“没技术含量”的技术，一样可以做出非常赚钱的产品，只要对需求把握的准确。计算机软件技术能够不断进步的根源其实是经济上的：消除非创造性劳动，提高工作、生活的效率和品质，降低成本，带来快乐和享受。违背经济规律、不能低成本的满足用户需求的所谓技术必然被淘汰出局。