主要观点:意识不同、层次不同是“将军”和“士兵”的主要差异
我刚刚从业时,主要从事网站开发、数据库设计,后来专注于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应该关注的是技术如何能给公司带来价值,带来利益。要把握技术方向、管理技术风险,维护公司的核心竞争能力。
技术常常是次要的,关键是满足用户的需求。拿“没技术含量”的技术,一样可以做出非常赚钱的产品,只要对需求把握的准确。计算机软件技术能够不断进步的根源其实是经济上的:消除非创造性劳动,提高工作、生活的效率和品质,降低成本,带来快乐和享受。违背经济规律、不能低成本的满足用户需求的所谓技术必然被淘汰出局。