按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
行C＋＋代码的软件时，他竞在十几分钟内就指出多处重大的设计错误，使我目瞪口呆地意识到整个软件系统的价值为零。那种心痛啊，就象眼睁睁看着孩子被狼吃掉一样。
1998年10月，这位朋友再一次从北京飞到杭州，三下五除二替我把只活了一年的公司给关闭掉。他放心不下，觉得我“恶病需用猛药补”，于是意尤未尽地把我捉到北大方正插在他管辖的部门，让我学习怎样做事情。北京寒冷的冬天可以营造一种凄凉的气氛，冲去一切可以自我原谅的借口。我并不是太爱虚荣的人，知道这次失败是我的毛病积累到一定水准忍不住喷发出来的结果。我绝不能以年纪尚轻不太懂市场与管理为理由轻率地敷衍过去。我把自己察觉到的数十个毛病列出来，日后一个一个克服掉。……本书的大部分内容取自我在一年前的教训录。
改错之后，现在我不仅不难过而且挺快乐。觉得第一次失败很浪漫，值得怀念。刚开始写这本书时，我那位北京的朋友把脚伸到杭州来散步，顺手又给了我几帖药，可以用到我毕业。看来缺点是改不完的，补短和扬长要一起来。
2。6 提高综合素责
前面给软件开发人员加了过多的赞誉。一个技术出色的程序员可以自豪，但不可以目空一切。上天不可能赋于一个人太多的优点，以致于他没有表示谦虚的余地。
我们在求学时可能太功利太挑剔，导致知识结构非常单薄，只怕到了晚年也成不了大器。当程序员擅长技术时，还要时刻留意弥补自己并不擅长的非技术才能。扬长补短才能提高综合素质。
假如能回到中学时代，我希望能把文科学好。那时侯盛传“学好数理化，走遍天下都不怕”。我读中学时很无知，鄙视一切文科，现在后悔莫及。高考语文成绩54分（只比我的期望值低6分）。写作文的最高目标就是不逃题，考试前我总是反复祈祷：我没干过坏事，保佑我作文不逃题吧！上大学的第一天我竟然无法用普通话说出“去洗澡怎么走”，只好晃动澡票与辅导员打哑语。中学的历史、地理课也被我糟踏了，考试时只会填写任课老师某年某月某日在我家乡英勇就义，比谁的成绩更接近零分。更让我沮丧的是，这些行径都不是我发明的，我顶多是个跟屁虫而已，一点回忆的自豪感都没有。
扔掉文科只学理科并不等同于“放下包袱，轻装前进”，倒象是摘掉了控制系统的机车，开不了多远就翻车了。我搞了八年的软件开发，没做出象样的软件来。倒是有同行意外发现我的文笔不错，是当作家的料。我发现自己在不该开花的地方结了一颗瘦涩的果子。曹操之子曹彰曾建议：“大丈夫当学卫青、霍去病，立功沙漠，长驱数十万众，纵横天下，何能为博士耶？”要后悔的事情太多了，只能现在做得勤快些。明知自己不成大器，但愿意亡羊补牢，力求学得更深更广。
不要让人觉得程序员只管钻研技术，可以不懂世事并且应该自由散漫。程序员不该因为幼稚而显得单纯，应该是成熟了才变得单纯，才配得上这个充满活力的职业。
2。7 小 结
本章讲述做好程序员和程序经理的一些道理，为了剥去阻碍我们进步的那些虚伪，多唠叨了几个故事。
中国经历了很多打斗、整人的革命，却没有一次赶上工业革命。在如今计算机横行的形势下，我们不能再掉队了。90年代初期，中国出现了一些程序员英雄，曾让我们激动过、崇拜过。但这些孤胆英雄们很快地几乎全消亡了，他们只留下故事，没留下更多的价值。再一次让我们意识到“振兴民族软件产业”不能依靠几个人一朝一夕的辉煌。软件人员勤奋学习和工作，不该只图将来能做成几件事情的快意，而应力求事业长盛不衰，才能推动整个民族软件产业持久稳健地发展。
第三章 项目计划与质量管理
在可行性分析之后，项目计划与质量管理将贯穿需求分析、系统设计、程序设计、测试、维护等软件工程环节。
项目计划是要提供一份合理的进程表，让所有开发人员任务明确、步调一致，最终共同准时地完成项目。项目计划是要付诸实施的，不象用嘴巴喊政治口号，可以很夸张。软件的项目计划重在“准确”而非“快速”。
提高质量是软件工程的主要目标。但由于软件开发是一种智力创作活动，很难象传统工业那样通过执行严格的操作规范来保证软件产品的质量。世上最小心翼翼、最老实巴脚的程序员未必就能开发出高质量的软件来。程序员必须了解软件质量的方方面面（称为质量因素），如正确性、性能、易用性、灵活性、可复用性、可理解性等等，才能在进行系统设计、程序设计时将高质量内建其中。软件的高质量并不是“管理”出来的，实质上是设计出来的，质量的管理只是一种预防和认证的手段而已。
3。1 项 目 计 划
做项目计划，如同给一个待出生的婴儿写传记那样困难。如果允许项目结束后再写计划，那就轻松多了，并且可以100％ 地准确。
历史教训让我们明白一个道理：如果一万年以后才会有一条阳光大道通向共产主义，那么现在就不要忙着砸锅炼钢赶英超美，免得在跑步奔向共产主义时把自己累死饿死。在做软件的项目计划时，应屏弃一切浮夸作风。只有“知已知彼”才能做出合理的项目计划。这里“知彼”是指要了解项目的规模、难度与时间限制。“知已”是指要了解有多少可用资源，如可调用的程序员有几个？他们的水平如何？软硬件设施如何？
3。1。1 知己知彼
首先要了解项目的规模、难度与时间限制，才可以确定应该投入多少人力、物力去做这个项目。在可行性分析阶段就要考虑这个问题。但不幸的是，人们在陷入项目不能自拨之前总难以准确地估计项目的规模与难度。这里经验起到了最重要的作用。
项目的时间限制有两类。第一类，项目应该完成的日期写在合同中，如果延期了，则开发方要作出相应的赔偿。第二类是开发自己的软件产品，虽然只确定了该产品大致的发行日期并允许有延误，但如果拖延太久则会失去商机造成损失。
项目的资源分为三类：“人”、“可复用的软构件”和“软硬件环境”，如图3。1所示。（１）人是最有价值的资源。项目计划的制定者要确定开发人员的名单，要根据他们的专长进行分工。
（２）可复用的软构件是次有价值的资源。1。2。1节论述了复用软构件可提高软件的质量与生产率。软构件并非一定要用自己的，可以向专业的软件供应商购买。
（３）软硬件环境虽然不是最重要的资源，却是必需的资源。原则上软硬件环境只要符合项目的开发要求即可。有些项目可能要用到特殊的设备，则要事先作好准备，以免用时找不到而担搁了进程。
图3。1 项目的资源
3。1。2 进度安排
有一位程序员忙着编写程序，经理问他还需要多久才能完成。
“明天就可以完成。”程序员立即回答。
“我想这是不切实际的，实话实说，到底还要多少时间？”经理说。
“我还想加进一些新的功能，这需要花两个星期。”程序员想了一会儿说。
“即使这样也期望过高了，只要你编完程序时告诉我一声，我也就满足了。”经理说。
几年以后，经理要退休了。在他去退休午餐会时，发现那位程序员正趴在机器旁睡觉：可怜的家伙整个晚上都在忙于编写那个程序。＇James 1999＇
程序员也期望每天早晨能在7：00准时起床，可老是一觉醒来就到中午了。项目落后于进度表乃是家常便饭，不必大惊小怪。以下一些事件经常会导致项目被延误：
（1）上级领导主管臆断，制定了不现实的期限。项目经理与程序员们被迫按照不合理的进度表开展工作。
（2）客户的需求发生了变化，但没有对进度表作出相应的修改。
（3）低估了项目的规模与难度，导致投入的人力和物力不足。
（4）并未预见到存在难以克服的技术障碍。
（5）并未预见到开发人员会发生问题，如生病，辞职等等。
（6）开发人员之间不能很好的交流、协作，导致各阶段任务难以如期完成。
所以写进程表不能象小学生写决心书那样充满幻想。以下是一些有益的建议：
（1）制定进度表的人最好就是项目负责人，他最了解项目和开发人员。进度表要经过开发