高質量C++/C程式設計指南(前 言) (轉)[@more@] 

言

 

質量是被大多數員掛在嘴上而不是放在心上的東西！

  除了完全外行和真正的高手外，初讀本書，你最先的感受將是驚慌：“哇！我以前捏造的C++/C程式怎麼會有那麼多的毛病？”:namespace prefix = o ns = "urn:schemas--com::office" />

  別難過，作者只不過比你早幾年、多幾次驚慌而已。

  請花一兩個小時認真閱讀這本百頁經書，你將會獲益匪淺，這是前面N-1個讀者的建議。

 

一、程式設計老手與高手的誤區

 

自從問世以來，就成了令人羨慕的職業，程式設計師在受人寵愛之後容易發展成為毛病特多卻常能自我臭美的群體。

如今在Inte上流傳的“真正”的程式設計師據說是這樣的：

(1)  真正的程式設計師沒有進度表，只有討好領導的馬屁精才有進度表，真正的程式設計師會讓領導提心吊膽。

(2)  真正的程式設計師不寫使用說明書，應當自己去猜想程式的功能。

(3)  真正的程式設計師幾乎不寫程式碼的註釋，如果註釋很難寫，它理所當然也很難讀。

(4)  真正的程式設計師不畫流程圖，原始人和文盲才會幹這事。

(5)  真正的程式設計師不看參考手冊，新手和膽小鬼才會看。

(6)  真正的程式設計師不寫文件也不需要文件，只有看不懂程式的笨蛋才用文件。

(7)  真正的程式設計師認為自己比使用者更明白使用者需要什麼。

(8)  真正的程式設計師不接受團隊開發的理念，除非他自己是頭頭。

(9)  真正的程式設計師的程式不會在第一次就正確執行，但是他們願意守著機器進行若干個30小時的改錯。

(10)真正的程式設計師不會在上午9:00到下午5:00之間工作，如果你看到他在上午9:00工作，這表明他從昨晚一直幹到現在。

……

具備上述特徵越多，越顯得水平高，資格老。所以別奇怪，程式設計師的很多缺點竟然可以被當作優點來欣賞。就象在武俠小說中，那些獨來獨往、不受且帶點邪氣的高手最令人崇拜。我曾經也這樣信奉，並且希望自己成為那樣的“真正”的程式設計師，結果沒有得到好下場。

 

我從讀大學到博士畢業十年來一直勤奮好學，累計編寫了數十萬行C++/C程式碼。有這樣的苦勞和疲勞，我應該稱得上是程式設計老手了吧？

我開發的軟體都與科研相關（積體電路CAD和3D圖形學領域），動輒數萬行程式，技術複雜，難度頗高。這些軟體頻頻獲獎，有一個軟體獲得首屆中國大學生大賽軟體展示一等獎。在1995年開發的一套圖形軟體庫到2000年還有人買。羅列出這些“業績”，可以說明我算得上是程式設計高手了吧？

可惜這種個人感覺不等於事實。

 

讀博期間我曾用一年時間開發了一個近10萬行C++程式碼的3D圖形軟體產品，我內心得意表面謙虛地向一位真正的軟體高手請教。他雖然從未涉足過3D圖形領域，卻在幾十分鐘內指出該軟體多處重大設計錯誤。讓人感覺那套軟體是用紙糊的華麗衣服，扯一下掉一塊，戳一下破個洞。我目瞪口呆地意識到這套軟體毫無實用價值，一年的心血白化了，並且害死了自己的軟體公司。

 

人的頓悟通常發生在最心痛的時刻，在沮喪和心痛之後，我作了深刻反省，“面壁”半年，重新溫習軟體設計的基礎知識。補修“內功”之後，又覺得腰板硬了起來。博士畢業前半年，我曾到中國研究院找工作，接受微軟公司一位資深軟體工程師的面試。他讓我寫strcpy的程式碼。

太容易了吧？

錯！

這麼一個小不點的函式，他從三個方面考查：

（1）程式設計風格；

（2）出錯處理；

（3）演算法複雜度分析（用於提高）。

在大學裡從來沒有人如此嚴格地考查過我的程式。我化了半個小時，修改了數次，他還不盡滿意，讓我回家好好琢磨。我精神抖擻地進“考場”，大汗淋漓地出“考場”。這“高手”當得也太窩囊了。我又好好地反省了一次。

 

我把反省後的心得體會寫成文章放在網閱，引起了不少人員的共鳴。我因此有幸和國產大型IT企業如華為、上海貝爾、中興等公司的同志們廣泛交流。大家認為提高質量與生產率是軟體工程要解決的核心問題。高質量程式設計是非常重要的環節，畢竟軟體是靠程式設計來實現的。

我們心目中的老手們和高手們能否編寫出高質量的程式來？

不見得都能！

 

就我的經歷與閱歷來看，國內大學的計算機教育壓根就沒有灌輸高質量程式設計的觀念，教師們和學生們也很少自覺關心軟體的質量。勤奮好學的程式設計師長期在低質量的程式堆中滾爬，吃盡苦頭之後才有一些心得體會，長進極慢，我就是一例。

現在國內IT企業擁有學士、碩士、博士文憑的軟體開發人員比比皆是，但他們在接受大學教育時就“先天不足”，豈能一到企業就突然實現質的飛躍。試問有多少軟體開發人員對正確性、健壯性、可靠性、、易用性、可讀性（可理解性）、可擴充套件性、可複用性、相容性、可移植性等質量屬性瞭如指掌？並且能在實踐中運用自如？。“高質量”可不是幹活小心點就能實現的！

 

我們有充分的理由疑慮：

（1）程式設計老手可能會長期用隱含錯誤的方式程式設計（習慣成自然），發現毛病後都不願相信那是真的！

（2）程式設計高手可以在某一領域寫出極有水平的程式碼，但未必能從全域性把握軟體質量的方方面面。

 

  事實證明如此。我到上海貝爾工作一年來，陸續面試或測試過近百名“新”“老”程式設計師的程式設計技能，質量合格率大約是10％。很少有人能夠寫出完全符合質量要求的if語句，很多程式設計師對指標、管理一知半解，……。

領導們不敢相信這是真的。我做過現場試驗：有一次部門新進14名碩士生，在開歡迎會之前對他們進行“C++/C程式設計技能”摸底考試。我問大家試題難不難？所有的人都回答不難。結果沒有一個人及格，有半數人得零分。競爭對手公司的朋友們也做過試驗，同樣一敗塗地。

 

真的不是我“心狠手辣”或者要求過高，而是很多軟體開發人員對自己的要求不夠高。

要知道華為、上海貝爾、中興等公司的員工素質在國內IT企業中是比較前列的，倘若他們的程式設計質量都如此差的話，我們怎麼敢期望中小公司拿出高質量的軟體呢？連程式都編不好，還談什麼振興民族軟體產業，豈不胡扯。

 

我打算定義程式設計老手和程式設計高手，請您別見笑。

定義1：能長期穩定地編寫出高質量程式的程式設計師稱為程式設計老手。

定義2：能長期穩定地編寫出高難度、高質量程式的程式設計師稱為程式設計高手。

根據上述定義，馬上得到第一推論：我既不是高手也算不上是老手。

 

在寫此書前，我閱讀了不少程式設計方面的英文著作，越看越羞慚。因為發現自己連程式設計基本技能都未能全面掌握，頂多算是二流水平，還好意思談什麼老手和高手。希望和我一樣在國內土生土長的程式設計師朋友們能夠做到：

（1）知錯就改；

（2）經常溫故而知新；

（3）堅持學習，天天向上。

 

二、本書導讀

 

  首先請做附錄B的C++/C試題（不要看答案），考查自己的程式設計質量究竟如何。然後參照答案嚴格打分。

（1）如果你只得了幾十分，請不要聲張，也不要太難過。程式設計質量差往往是由於不良習慣造成的，與人的智力、能力沒有多大關係，還是有藥可救的。成績越差，可以進步的空間就越大，中國不就是在落後中趕超發達資本主義國家嗎？只要你能下決心改掉不良的程式設計習慣，第二次考試就能及格了。

（2）如果你考及格了，表明你的技術基礎不錯，希望你能虛心學習、不斷進步。如果你還沒有找到合適的工作單位，不妨到上海貝爾試一試。

（3）如果你考出85分以上的好成績，你有義務和資格為你所在的團隊作“C++/C程式設計”培訓。希望你能和我們多多交流、相互促進。半年前我曾經發現一顆好苗子，就把他挖到我們小組來。

（4）如果你在沒有任何提示的情況下考了滿分，希望你能收我做你的徒弟。

 

  程式設計考試結束後，請閱讀本書的正文。

  本書第一章至第六章主要論述C++/C程式設計風格。難度不高，但是細節比較多。別小看了，提高質量就是要從這些點點滴滴做起。世上不存在最好的程式設計風格，一切因需求而定。團隊開發講究風格一致，如果制定了大家認可的程式設計風格，那麼所有組員都要遵守。如果讀者覺得本書的程式設計風格比較合你的工作，那麼就採用它，不要只看不做。人在小時候說話發音不準，寫字潦草，如果不改正，總有後悔的時候。程式設計也是同樣道理。

  第七章至第十一章是專題論述，技術難度比較高，看書時要積極思考。特別是第七章“記憶體管理”，讀了並不表示懂了，懂了並不表示就能正確使用。有一位同事看了第七章後覺得“野指標”寫得不錯，與我切磋了一把。可是過了兩週，他告訴我，他忙了兩天追查出一個，想不到又是“野指標”出問題，只好重讀第七章。

光看本書對提高程式設計質量是有限的，建議大家閱讀本書的參考文獻，那些都是經典名著。

 

  如果你的程式設計質量已經過關了，不要就此滿足。如果你想成為優秀的軟體開發人員，建議你閱讀並按照CMMI規範做事，讓自己的綜合水平上升一個臺階。上海貝爾的員工可以嚮應用事業部軟體工程研究小組索取CMMI有關資料，最好能參加培訓。

 

三、版權宣告

 

  本書的大部分內容取材於作者一年前的書籍手稿（尚未出版），現整理成為上海貝爾網路應用事業部的一個規範化，同時作為培訓教材。

  由於C++/C程式設計是眾所周知的技術，沒有秘密可言。程式設計的好應該大家共享，我們自己也是這麼學來的。作者願意公開本書的電子文件。

  版權宣告如下：

（1）讀者可以任意複製、修改本書的內容，但不可以篡改作者及所屬單位。

（2）未經作者許可，不得出版或大量印發本書。

（3）如果競爭對手公司的員工得到本書，請勿公開使用，以免發生糾紛。

  預計到2002年7月，我們將建立切合中國國情的CMMI 3級解決方案。屆時，包括本書在內的約1000頁規範將嚴格受控。

 

  歡迎讀者對本書提出批評建議。

 

 

林銳，2001年7月