《Beautiful Code》原來好的程式碼是這樣子寫出來的！

Beautiful Code

程式設計師最討厭的工作，並不是撰寫難度很高的程式，而是維護一堆缺少完整文件又長得醜的程式。尤其現在能具備完整文件的系統專案已經少得可憐，所以美化 程式碼的要求才會日益增高，如果能做好基本功，即使沒有文件輔助，工程師也能輕鬆追蹤程式碼。不過，要寫出好的程式碼是需要功力的。

Beautiful Code＝專案問題最佳解法

要寫出完美的程式，需要透過實務經驗或前人智慧，一點一滴累積實力，並非一蹴可幾。但軟體專案常因時程要求，在系統開發上只求在時限內達到目的，往往忽略軟體工程上強調的重點（例如物件導向的觀念、設計模式的運用等）。

書名中的「Beautiful」一字，代表著解決程式難題的最佳撰寫方法，這些解法是專家在執行專案及設計系統架構的過程中，不斷地累積、歸納、 整理而得出，等同於系統設計好手們常高談闊論的設計樣式（Design Patterns）。閱讀本書，就如同站在巨人肩膀上，瞭望整個軟體開發世界，透過高手的文字描述，洞悉他們面對軟體專案發生問題時，如何思考出解決方案 的過程。

本書內容構成十分有趣，透過作者Greg Wilson的召集，將業界大師級的軟體設計師及科學家統統拉進來，貢獻出畢生所學，集結三十餘篇的文章，簡短且精闢的文字流露著專業及縝密的思路。本書 作者所有出版收入均做為公益之用，捐獻給國際特赦組織（Amnesty International）。

既然稱為程式「設計」，當然也需要融入美感。要寫出具有美感的程式，讓人稱為藝術之作，除了需要掌握程式語言本身的特性，多看、多研究高手的作品 之外；也要如同寫文章一般，具備足夠的知識、打好基礎，才能夠文思泉湧，寫出好的程式，就如同本書Ruby之父Yukihiro Matsumoto所提到的觀念：Treating Code As an Essay。

除了要Beautiful Coding，Beautiful Debugging也是一門學問，在開發過程中，除錯常是影響程式撰寫能否順利進行的關鍵。透過系統化流程處理程式錯誤的偵測，並有效找出問題徵結，才能有效率地在最短的時間內完成除錯。

想知道有經驗的專家們，在面臨軟體開發的難題時，如何發揮智慧迎刃而解？本書如同論文集般，收錄各領域技術大師的文章，以各式各樣的案例，搭配不 同的程式語言呈現多元化的應用。像是以極簡的正規運算式（Regular Expression）語法，比對複雜的檔案內容或應用在搜尋網站系統記錄檔內容；以Perl提供的現成Bio套件，辨識生物科技基因；利用NumPy快 速處理多維度的陣列資料等。

用對程式語言，才能事半功倍

一個系統或程式，可以用不同的程式語言撰寫，各家寫法也大不同。因此，需要考量到程式語言本身的特性，選用適合的語言開發。針對各種目的，運用不同的程式語言實作，不但能發揮該語言的優點，程式也不致過於繁雜，增加閱讀及日後維護的困難。

本書不限定於探討單一特定程式語言，包含XML、Ruby、Linux等，涵蓋領域很廣。從NASA太空總署專案，到作業系統核心設計等主題，你 可以從不同角度體會各類應用。雖然有許多案例是一輩子都不可能參與的專案類型，但都能從專家的經驗分享中，獲取這些程式撰寫技巧。

就實務而言，軟體專案時程的不合理壓縮已經成為常態，身為程式設計的一員，更應該以撰寫漂亮的程式碼為要務，在有限時間之內發揮最大的設計價值。

如何撰寫漂亮的程式碼？本書作者歸納整理出以下建議：程式碼需內容簡潔（brevity）；穩健低風險的方法（conservatism）；擁有 變更之彈性（flexibility）；並在這些特性之間取得平衡（balance）。如果你能夠掌握這些原則，再透過閱讀本書，思考咀嚼出一番心得，相 信你撰寫的程式碼，便能夠美得內外兼俱！

 

《High Performance Web Sites 》網頁加速的14條黃金法則

網站的視覺設計及內容，是能否吸引訪客的重要因素之一，但也不能因而顧此失彼，造成網站效能的瓶頸。從過去的訪客行為研究 分析指出，等待一個網頁的呈現時間不能超過9秒鐘，但面對目前網頁內容多媒體化的現實挑戰，要達到這樣的目標，在前端頁面的設計上，也就需要多花些心思。

著重網頁前端的效能改善

《High Performance Web Sites》內容主要針對網站前端的設計人員所設計。作者曾經擔任雅虎CPO（Chief Performance Officer），在雅虎負責研究改善網站效能的方法，他以多年的經驗整理出14個網站前端設計需要注意的準則。全書內容簡明扼要，具有網站設計經驗的讀者，可以快速領略要點；初次接觸的生手，也可以透過本書建立良好的網站設計觀念。

14條必勝定律

如何有效提升網站效能？作者針對網站效能最佳化歸納出以下方針，並舉例加以說明：

1. 減少需要發出HTTP Request的數量

當你設計的網頁中包含的元件數量越多，Client需要對網站伺服器發出的HTTP Request也會增加，同時也會延長網頁處理的時間。

2. 採用Content Delivery Network服務

由Mirror Image、Akamai、SAVVIS等業者所提供的Content Delivery Network（CDN，內容遞送網路服務），可以供應強大的全球網路基礎架構，將網站以最有效的方式傳送給全球使用者，並自動幫網站選擇最佳路徑傳送資 料，例如，根據瀏覽者所在地、網路品質及流量狀況，選擇距離用戶端最近的資料中心傳送資料，確保網頁的瀏覽品質及運作速度。

3. 在網頁中加入過期檔頭

你可以利用這個設定讓網頁具備快取機制，縮短頁面載入時間，尤其是針對內容不常變動的網頁。當然這樣的運用，得視你的網頁性質而定，若內容變動頻率高的網頁，則不適用此方式。

4. 善用Gzip壓縮機制

以XML/HTTP做為資料交換的開放格式已經十分普遍，傳輸的檔案體積，較過去單純的 EDI方式增加許多，用傳送壓縮時間換取傳輸時間，也是一種提升效率的策略，目前常見的網站伺服器大都支援此項技術。你甚至也可以視情況選擇壓縮 HTML、CSS及JavaScript的檔案內容。

5. 將Stylesheet置於網頁頁首

將樣式表（Stylesheet）置於頁首，可以讓CSS設定先行載入，在第一時間套用設定直接呈現網頁。相較於把樣式表放置在頁尾，等所有內容都下載完畢後才套用，樣式表置於頁首的作法，除了頁面呈現速度較快，載入過程中也較不易造成空白頁的出現。

6. 將Script內容置於頁尾

許多實際狀況中，網頁包含的Script程式，本身並不需要在載入後立即執行，所以作者建議將這些程式碼置於頁尾，至少內容可以在傳輸前段時間即備妥，讓使用者有較佳的瀏覽體驗。

7. 避免CSS Expression的撰寫方式

CSS Expression的目的，在於讓自訂樣式的語法可以取代部分的Script內容，雖然這麼做很好用，但因網頁顯示過程中花費較多的邏輯判斷時間，造成網站效能的致命傷。

8. 將JavaScript及CSS內容獨立於網頁內容之外

透過獨立內容的方式，讓HTML本文檔案縮小，而且可以同時被瀏覽器下載，以縮短網頁呈現的時間。

9. 減少DNS查找的次數，縮短取得網頁內容之前的前置時間

雖然網頁可以串連不同網站來源的內容，但是不同網站來源的內容一旦太多，便會延遲頁面載入速度；如果能夠減少網頁內不同網站來源的內容，就可以減少從用戶端發出的DNS Request數量，縮短DNS的查詢時間。

10. JavaScript內容精簡化

網頁中的JavaScript也是下載的一部分，所以當程式碼內容較多時，亦會直接影響網頁下載的速度。檢視一下程式碼，移除不必要的部分。

11. 避免重導向

網頁重新導向是很方便的功能，但對於使用者而言，他必須等待更多的時間直到最終頁面被載入，所以應該盡可能避免使用重導向轉址功能。

12. 移除重複的Script程式碼

重複的Script程式碼需要花費更多的下載時間，這個問題通常發生在程式碼未能妥善模組化的情況下，檢查一下你的Script程式吧。

13. 善用Etag

透過設定Web Server中的Entity Tag方式，能決定網頁中被快取的內容，以加速網頁呈現，但也得視網頁內容特性而定，Etag主要運用在靜態頁面上，而動態顯示內容的網頁則不適用此方式。

14. 讓Ajax程式可做到暫存快

Ajax架構透過非同步的傳輸方式，讓使用者具有較佳的使用體驗，卻不見得是效能的保證。除了可以透過利用Gzip壓縮、避免DNS查找次數、簡化JavaScript內容之外，控制HTTP過期檔頭來快取Ajax網頁，也能發揮明顯效果。

拿知名網站開刀，保證你大呼過癮

本書最後以全球十大網站做為案例分析的對象，包括Yahoo、Google、Amazon、YouTube等。這些網站之所以成功，除了透過內容及社群機制吸引訪客，在網站效能的表現上，也必須克服流量提高所帶來的問題。

作者使用3個度量值（Page Weight、Response Time、YSlow Grade）逐一檢視這些網站，找出問題點以及可以改善的地方，配合前述建議的14項準則，解決效能表現不佳的現象。

作者表示，這些準則都經過實務證明為有效的解法，可以幫網站減少平均二至三成的網路傳輸時間。對照本書，檢視你的網站架構出了哪些問題，並對症下藥加以落實，我相信可以讓訪客感受到明顯的效能提升。

 

《Communicating Design》專案文件應重質而非重量

專案進行的過程中，階段性的文件產出（Deliverables）一直是被視為十分重要的一環。而許多專案也常常將文件列為重要的驗收項目之一，筆者曾經 手接受兩大箱的系統文件要求驗收，可能這樣客戶端才會覺得付了錢，獲得拿到東西的滿足感吧。還真懷疑這些人到底會不會看這些文件。

先不論客戶是否會看，文件內容必須符合實務需求，才能夠在真正需要的時候發揮參考價值，如果只為了驗收交差了事，而硬擠出一堆不具任何參考價值的陳腔濫調，還不如響應環保，少砍點樹比較好。

文件應重「質」，而非「量」

針對專案文件的規範，在許多系統分析設計的參考文獻中都能找到不少範例，如果你採用物件導向分析及設計方法，UML系列的文件必然也不陌生。

就實務面來看，許多專案因時程及人力不足的雙重壓力下，一人球隊從頭到尾「校長兼撞鐘」的悲慘案例，已不再是什麼稀奇的事，文件撰寫常常變成事後補件的作業程序。所以，目前專案的當務之急，是提高文件品質而非數量。

《Communication Design》希望從事網站設計開發專案的相關人員，能花對的時間在對的文件上。在規畫網站設計專案過程中，本書針對專案進行過程中的3種不同角色設計， 包括文件製作者、文件審核者，到最後文件使用者。在文件的架構及撰寫用意上，本書則提出三層式資訊表達方法，依文件內容的詳細程度，分別適用3種不同的閱 讀需求。

提供多種文件撰寫綱要及範本

本書針對3類用途列出10種文件，分別著重在使用者需求文件（User Need Documentation）、策略性文件（Strategy Documentation）以及設計文件（Design Documentation）。

● 使用者定義文件（Personas）：定義主要使用者（Stakeholder），並清楚描述他們會如何使用這套系統。將所有可能會使用網站的使用者都列進來，在設計流程及測試過程時會更完整。

● 可用性測試計畫（Usability Test Plan）：系統上線前必然經歷測試的項目及方式過程，定義這些內容之前，針對網站對於不同對象的使用方式均需要充分了解，才能掌握正確方向。

● 可用度報告（Usability Report）：針對上述的計畫執行後所產生的報告文件。

● 競爭力分析（Competitive Analysis）：就網站而言，競爭力分析等於是與其他競爭對手的優劣比較分析，從網站內容、提供的產品服務以及使用者經驗比較。

● 概念模型（Concept Model）：在系統分析中，在概念上定義出與系統有關的物件及彼此之間的關係，後續系統分析設計的主要基礎得以紮穩。

● 資訊內容（Content Inventory）：呈現網站的資訊架構及分類方式。

● 網站地圖（Site Map）：這應該是最常見、也最基本的網站階層架構示意文件，讓網站規畫人員與設計人員可以明確得知，每個網頁的內容及功能之間的關連性。

● 網站流程圖（Flow Charts）：架構是靜態的呈現，透過流程圖能分析使用者使用網站的行為動線，以及例外狀況處理。

● 視覺版面設計（Wireframes）：使網站主要內容的樣式及視覺化呈現具有一致性，包括版面格局、圖片色系的制定、文字內容。

● 畫面設計（Screen Design）：在許多系統設計方法論中，畫面的呈現設計一直被視為與使用者溝通的重要文件內容。唯有使用者看到實際的畫面，才有辦法確認設計的成品是不是他所想要的，並且降低認知上的差異。

審視、最佳化手邊的系統文件

上述文件，在本書都有專章說明如何撰寫，包括文件所應具備的文件大綱，而讀者在撰寫的過程中，必須與其他文件之間相互參照，例如在進行畫面設計時，也需要同時參照概念模型內容，以維持文件資訊的一致性。

也許你手邊已經有不少系統文件規範格式，但本書可以當作檢視既有文件完整度的工具，讓文件更臻完美。

 

從工作中學習，提升開發戰力《Agile Retrospectives》

在軟體專案運作期間，團隊成員經過長期高壓折磨後（請容許筆者用這樣的形容詞，但軟體專案確實是個壓力密集度高的工作），團隊成員會出現腦力疲乏、反應不佳、情緒偶有失控、思緒無法有條不紊地運作的症狀，就像顆電力被消耗殆盡的電池，執行效能處於殘弱的狀態。

專案成員理應經常充電，以保持良好的使用效能。企業不斷地倡導從A到A+的觀念，套用在資訊軟體專案中，專案團隊也會遭遇到相同的問題：你要選擇向上提升，抑或向下沉淪？

想要向上提升，你可以選擇透過坊間的充電課程提升戰力，不過，對於大多數企業而言，課程需要的成本及耗費時程，無法允許已經忙到抽不出空的軟體專案團隊去充電，使得教育訓練大多落於理想而難以付諸實現，造成專案成員異動頻繁，軟體專案品質嚴重低落。

就管理技巧而言，「從作中學」是學習專業能力及養成經驗效果最好的方式，也就是所謂的On-Job Training。《Agile Retrospectives》即強調從工作中來學習、強化你的專案團隊。

作者設計許多演練的方式，只要按表操課，相信會有不錯的效果。閱讀本書可以有助於：

● 設計出有效的專案團隊實戰準則
● 學習找出專案問題，進而思考得出最佳解法
● 試著強化團隊的優勢，發揮超出預期的團隊績效
● 不只是強調技術專業能力，也重視人在團隊中可能的影響
● 有效運用建議的管理技術及方法

往覆式開發讓專案開發保持在正確方向

Retrospective就字義上而言，著重在過去事物的回顧及反省，以記取過去的經驗，有「知古推今」、「前人種樹後人乘涼」的味道在。

運用在軟體專案上，則代表曾經在專案中遭遇的技術及管理難題、團隊成員間有待改善的合作方式，或是未臻完美的專案成果及實務教訓，這些都是身為專案領導者或成員的你，在過去專案經常遇到的問題，以期在未來能找出改善的做法。

也許你也有這樣的經驗：在執行專案的過程中，面對眾多管理或是技術上的抉擇時，會有「這樣做是不是最好？」、「這樣做是不是對的？」的疑惑。在專案邁向下一個階段時，也不斷地思考，如何在眾多做法中找出最佳方案。

一般傳統式專案開發都是到執行末期才發現問題所在，這時候早已回天乏術、付出慘痛的代價。但透過Agile往覆式開發精神，在專案各個階段結束時，即可以 針對問題進行改善，持續修正方向直到專案結束，不會等到整個專案結束後，才能回顧與檢討。因此往覆式的專案開發所造成的偏差，遠低於傳統式專案開發。

5個步驟將管理技巧導入專案開發

本書重點在於讓軟體團隊可以在專案進行過程，透過作者建議的工具及方法降低失敗機率。敏捷開發的迭代式開發特性，可以讓專案成員在進入下一個Iteration時，發現問題並及早因應，提出改善方法。

本書有5個步驟，從設定目標、收集資訊、激發想法、決定做法、到最後的結束，這些步驟是經歷實務考驗的累積成果。各個步驟都提供許多活動 （Activities）以達到每階段的目標，從這些活動你可以學習許多管理實務上的技術及方法，例如：用來找出問題根本原因的魚骨圖 （Fishbone）、找出多個面向計量標準的雷達圖（Radar），以及利用3M便利貼及色點貼紙收集資料及定義重要性，這些都是可以被應用在不同層面 的通用方法。

本書提供不少管理層面的技巧及作法，讓專案團隊可以透過敏捷開發搭配管理技巧，改善團隊績效、發揮潛力。雖然本書強調的是管理技巧與敏捷（Agile）專案開發製程的搭配，不過它提供的準則及方法，也都適用於一般專案團隊。

 

《Prioritizing Web Usability》設計用起來最直覺的網站

談到如何設計出以使用者為中心的網站，你不能錯過在Web Usability領域享譽盛名Jakob Nielsen的作品，在這位大師的眾多著作中，針對Web設計及可用度研究領域的《Prioritizing Web Usability》，是設計網站時不可或缺的參考工具書。 Web已是大眾廣泛接受的操作方式

應用程式Web化已經是系統設計演進發展的趨勢，不論是開放式或企業內部的應用系統，為求異質系統間的高度整合性，Web-based已經是系統設計的首選。加上大多數的使用者已經熟悉Web平臺的特性，點選超連結的行為及網頁呈現方式，對於現今使用者是十分直覺的動作。

目前硬體、寬頻、軟體技術等條件以及資訊環境，已經跟上內容複雜的需求，網路人口大幅成長，這些使用者不只是單純的資訊接收者，同時也是資訊提供 者（透過文字／影音部落格，C2C拍賣交易平臺等數位媒介發布訊息），全球網站的數量及資訊內容已呈現爆炸性的成長。如果網站設計得不夠人性化，便無法加 強對使用者的黏度。

本書根據近年來網路在使用及技術上的發展趨勢，彙整作者所在公司過去所完成的研究調查報告，建立紮實的實務統計數據，並強調如何從可用性 （Usability）的角度提升網站設計的層次，讓使用者能更快速且有效地使網站達到他造訪的目的，包括資訊提供、商業交易及服務取得等。

Web設計老問題依舊存在

Web發展至今已經十餘個年頭，雖然技術演進上已經有大幅度的成長，但一些積存已久的問題並未因此而減少：

● 彈跳視窗（Pop-Up Windows）的不當使用，造成使用者反感。
● 套用CSS效果使得超連結點選後未改變顏色，浪費使用者時間。
● 點選連結後未在原視窗呈現，而是開啟新的瀏覽視窗，破壞瀏覽動線。
● 破壞了「回上一頁」按鈕的原本功能，使用者需重新輸入資料。
● 提供密密麻麻的資訊內容，使用者無法在最短時間內找到所需資訊。
● 內容設計讓使用者覺得像是廣告，而忽略不去留意。

資訊基礎建設的興起，常會讓一些設計問題被隱蔽而未突顯，例如Flash動畫、Table版面配置等設計如果濫用過度，便成為網站效能的殺手。

透過設計問題模式，為網站體檢

針對網站設計常見的問題，書中將其優先順序一一列出，供讀者依序審視及處理：

● 搜尋功能：避免該查的資訊查不到，不該查的，跑一堆出來。
● 網站的資訊及導覽架構：使用者是否能在最短路徑找到他要的東西。
● 內容的簡潔及易讀性（包括文字、圖片、其他多媒體內容）：不會有訪客願意多停個幾秒，去猜內容是否有隱含寓意。
● 網站上產品元素的完整性，是否能有效促成交易的實現。
● 是否有足夠的網頁寫手，能幫網站豐富內容。
● 在使用者需求及技術層面上取得雙贏的局面。

也許會有讀者表示：「網站架構（SiteMap）及頁面流程通常都是由行銷人員規畫後，請視覺設計人員將頁面框好，再交給我們套程式，所以IT人 員在整個設計規畫的過程中並沒有主導的地位。」不過話說回來，同事在未考量使用及技術層面的可行性之前，所提出的天馬行空式網頁需求，身為IT人員的你， 必定常常會遇到。本書能讓行銷同仁們在需求與技術之間取得平衡，提出符合Web Usability的網站企畫書。

要求所有訪客都依照你的設計方式使用網站，是本末倒置的想法，在網站功能日益複雜的同時，你無法預測使用者的行為，任何的網頁流程都有可能被點選或使用。當你規畫、設計的網站，不需要透過大量的頁面說明文字或手冊協助使用者操作，網站就算是成功了。