歡迎您光臨本站 註冊首頁

高質量C++/C編程指南 -- 前言

←手機掃碼閱讀     火星人 @ 2014-03-12 , reply:0
  本文作者: 林銳 博士

前 言



軟體質量是被大多數程序員掛在嘴上而不是放在心上的東西!

除了完全外行和真正的編程高手外,初讀本書,你最先的感受將是驚慌:「哇!我以前捏造的C++/C程序怎麼會有那麼多的毛病?」

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

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



一、編程老手與高手的誤區



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

如今在Internet上流傳的「真正」的程序員據說是這樣的:

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

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

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



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



三、版權聲明



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

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

版權聲明如下:

(1)讀者可以任意拷貝、修改本書的內容,但不可以篡改作者及所屬單位。

(2)未經作者許可,不得出版或大量印發本書。

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

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



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



[火星人 ] 高質量C++/C編程指南 -- 前言已經有144次圍觀

http://coctec.com/docs/program/show-post-71992.html