William 在〈軟體的庖丁解牛能力〉中引述了 Peopleware 第 29 章的話:
工作流程愈是獲得改善,工作內容就愈艱難……一、沒有被替除掉的工作,就是更加知識密集、需要更多技術與經驗……二、經過改善的工作流程,讓你能夠面對更艱難挑戰,而你也會面對這些挑戰……
當工作流程獲得實際改善,我們也同時需要更多更有能力、更有經驗的員工。
William 後來特地在〈工作流程愈是獲得改善,工作內容就愈艱難〉附上了這段話的原文,有興趣可以自行參閱。
這裡我就不談工作流程了,只談談作為一門專業,程式設計有哪些值得我們關注的小細節:
Coding Style
這裡不捲入哪種 Coding Style 較好的爭論。只強調一點,選擇特定的 Coding Style ,是為了要把程式的邏輯結構強調出來,使其看起來條理分明。並不是為了排版的好看與否。
這方面議題,就我所知,寫得最好的,出現在《Code Complete》的第十八章。裡面列出各種 coding style ,由程式的縮排一直到註解的寫法,都有各種例子,並以程式的「邏輯結構」被凸顯的情形,逐一進行比較。
Editor
好的文字編輯工具是很重要的,諸如:可以讓人自訂的 Syntax Highlighting、自訂字型,自訂背景顏色、自動縮排(auto-indent)、多檔管理、Project based 的 Find/Replace/Regular Expression、Auto-Completion, 甚至 Code Folding, Refactoring 的支援等,都要仔細評估,找套合用的。
作為 coding 的 Editor ,新版的 UltraEdit 用起來很順手,這裡強烈推薦。
此外,作為跨平台及 open source 軟體, CodeBlocks 是一套非常符合我胃口的 C/C++ IDE ,雖然還有些不足的地方,但其改善的速度也是令人印象深刻。
Font
專業的程式設計師,不會放過任何可以改善其 coding 方式的機會,連 coding 用的字型,也要挑剔一下:我們選用的字型,要能方便長期閱讀 code ,一些易發生混淆的字元,諸如大寫的 O 和數字 0 間;數字 1 、大寫 I ,及小寫 L 間等,也要能很明確區分。甚至括號在顯示時也要作特別的強調。
好的 coding 字型,還要允許我們清晰地在同一個畫面閱讀更多行的 code 。這裡強烈推薦在 Proggy fonts 中,選一套來用。此外,〈Programming Fonts〉中也有相關的介紹。
Once and Only Once
Once and Only Once 是要我們剔除重複的程式片段,重複的邏輯要合併,重複的敘述要改寫,多餘的變數要刪除。重複不但顯得累贅,在修改時還容易發生遺漏、不一致的情形。要真正作好這點,其實就是要極力找出軟體系統的模式,其精神是「尋找模式,並反覆利用這些模式」
Unit Test Framework
如果還沒想清楚如何測試某段 code ,那就不要去編寫它。把測試及比對結果的工作,交給電腦來執行,是 Unit Test Framework 最大的用意。花些時間,找個所用語言及編程環境適用的 Unit Test Framework 是非常划算的投資。如果你在找 Embedded Systems 的 Unit Test Framework ,也許可以參閱拙作〈An Array Implementation of Queue〉中的例子。
Documentation
講起 Documentation ,就不得不提提高德納先生極為推崇的 Literate Programming 。這是種以寫文件為主,coding 為輔的程式設計方式。其背後的想法是基於,程式主要是寫給人看的,而非只為了給電腦執行。Literate Programming 的 code 穿插在文件段落間,要餵給電腦前,再用工具把 code 抽取出來,交給編譯器處理。
不過 Literate Programming 也只有高德納那樣的學院派高手,才能玩得盡興。像我這種在街上混吃的,還是較適合寫 code 為主,文件為輔的方式。這種作法的精神是,code 本身就要寫得能讓專業程式員很容易閱讀,然後再加上意圖性的註解,使其趨於完善。
像 doxygen 這樣的工具,讓我們在註解時,使用標準化的標記,然後再由程式源碼中,抽出特定註解,作為說明文件。
Version Control
想起學生時代,最常使用的 version control 方式,就是在 project 目錄下建立 /v0, /v1, /v2... 的子目錄,或者乾脆將整個 project 給它 zip 起來,然後在壓縮檔名附加版號及日期。這方法用於個人開發、幾千行以內的小規模程式,還算堪用。
後來接觸了 open source 的東西,所以 CVS 用了好一陣子。現在也不能免俗地,改用 Subversion 。如果你還沒選定適用的 Version Control Tools ,這裡推薦 Subversion,其 Windows 下的 Client, TortoiseSVN 當然也不容錯過。
Issue Tracking
在 team work 下,bug 或 feature 的追蹤,變得繁雜起來。此時,選套合用的 issue tracking tools 可以省掉很多人工。
Trac 跟 Subversion 能作很好的搭配。對於小規模的應用,已經足夠了。
3 comments:
謝謝你的推薦
Code Complete真是好書
以前都沒有注意到這幾點
謝謝提醒
Joel on Software 有一篇〈讓錯的程式看得出錯〉也很值得參考。
Post a Comment