軟體開發基本功

 

         

 

                       軟體開發基本功:How to program better and faster

                                                            ——讀《編程珠璣I》有感：

 

 

           
Program.Program better. Program faster.

           
要從事軟體開發，首先要學會編程。如何編程呢？如何編寫更高效更優雅的程式呢？《編程珠璣》通過簡單而熟悉的樣本，揭示了許多非常有益的編程原理和技巧，極具啟發性。

 

           
基本流程：

           
問題定義—— 應用程式框架與介面設計 —— 選擇合適的資料結構和高效的演算法（對象和訊息）—— 效能估計 —— 介面聲明 —— 虛擬碼 —— 程式驗證—— 編碼 —— 測試與調試 ——
[代碼最佳化]——
代碼重審和回顧。

 

          
問題定義：贏在起點。清晰明確的問題描述和定義幾乎決定成功的一半。作為問題求解，如何正確地理解問題，從何種視角去思考問題，往往會產生天壤之別的結果；作為軟體開發，“有所為而有所不為”，應當作為基本準則。誰都期望能夠開發出效能強勁的、多能多才的軟體，但並不是誰都能夠承受這樣的研發成本（時間、資金和人力）。在成本與所能獲得的最終產品之間，必須作出合適的權衡和折衷。

          經過良好抽象的問題，更容易得到可複用的問題解決方案。比如，《編程珠璣I》第12章，取樣問題，從隨機選區列表抽樣，抽象成“從n個整數中隨機抽取m個有序整數”的問題；這樣，問題的解決方案還可以用於其它領域的抽樣問題。

     
  應用程式框架和介面設計：   在明確問題的求解目標之後， 就要思考如何求解問題了。  通常會有一個初步的思想，然後逐漸形成整個比較成熟的方案和應用程式框架。 與此同時， 定義良好的介面設計也是非常關鍵的。 在介面之上， 是依靠介面服務的應用程式的實現； 在介面之下， 是用來提供介面服務的資料結構與演算法的實現。 

          
資料結構與演算法：掌握一門語言，就可以開始編寫程式；而資料結構和演算法，則可以協助寫出更為強大的程式。 粗淺地將《編程珠璣》閱讀了一遍，發現：電腦程式的根本仍然是： 資料結構
+演算法。資料結構和演算法通常還是估算和提高系統期望效能的關鍵環節。

        對象和訊息， 實際上是資料結構與演算法的封裝。 在物件導向程式中， 每一個類都是一些綁定在一起的“小資料結構”和“小演算法”的攜帶者， 通過介面提供自己的服務；每一個對象都是狀態攜帶者， 通過狀態的變化來表徵系統的變化，從而實現系統的特徵和功能。

        資料結構有著非常重要的作用。有時候，複雜的邏輯，只要藉助一定的資料檢視，就能得到很大的簡化，比如日期計算。《編程珠璣I》中談到的重要資料工具有：超文本、值-對、字典、資料庫、表格、模板等。

 

       效能估計：通常，通過演算法的大O分析來粗略瞭解系統可能達到的效能；另外，一定的粗略估算能力也是非常必要的（見編程珠璣第七章）：常識、關鍵參數、經驗法則、量綱檢驗、安全係數。

 

         介面聲明：涉及到系統的設計。系統由哪些資料結構（或對象）組成，它們如何進行互動（函數，訊息）以完成系統的功能；
仔細定義每一個介面的聲明（功能描述、參數列表、傳回值、前置條件、後置條件），並使之良好地協作。

 

         
虛擬碼：不要急於編程。使用虛擬碼來表達思路，勾勒程式的大致架構。這常常也會讓思路更明晰：因為在這個過程中，通常可以發現系統有哪些子功能要實現，有利於模組化。

 

         
程式驗證：你能保證自己編寫的程式在任何時候都正確嗎？還是僅在你視線所及的範圍內正確？你期望寫出的程式僅僅是看上去正確嗎？當然，我們都希望能夠早早完工，可是，急不得，懶不得。學習一定的程式驗證技術，也是有益無害的事情。雖然起初可能麻煩一點，但一段時間習慣之後，就不會覺得怎麼樣了。萬事開頭難，過了檻就好了。

        
程式驗證的常用方法：迴圈不變式和斷言。這實際上是根據三種控制流程來確立的技術。

 

         
編碼：終於可以編寫程式了。恐怕經過上述折騰，編寫程式的興緻早就減得不剩多少了。可是，一切，都是為了編碼更加順利，更加有創造性。總不期望發現，編碼就是在Ctrl+C/V；當編碼到一定程度時，突然卡了殼；突然發現思路有問題；突然發現效能無法滿足所期望的；突然發現，之前的努力都白費了？

          
很多人抱怨工作中的編碼沒有創造性可言，可是，有沒有想過，你不去思考如何更有創造力的寫程式，難道期望創造性自動跑到你面前嗎？你不去努力使用演算法、資料結構，難道它會自動跑到你跟前要求你去使用嗎？你不去主動思考、勤於發現，難道你就指望奇蹟自動降臨於身？

         
編碼時，儘力遵循良好的代碼規範，使之可讀性良好，為後面的代碼重審和回顧打下良好的鋪墊。

 

         
測試和調試：如何得到一段值得信賴的、可以放心複用的程式呢？苛刻的、徹底的測試。不要怕麻煩。凡事習慣就好了。編寫自動化測試；掌握使用斷言來進行調試。

        程式測試通常可以分為兩種： 自動化測試和手工測試。對於小資料集，0-10，可以構建自動化測試；另外，還要構建手工測試，使得能夠對特殊情形進行測試。

 

         
代碼最佳化： 代碼最佳化通常意味著效能的小幅提升。通常是應用緩衝原理，這需要對電腦群組成和作業系統有深入的理解。代碼最佳化通常意味著程式可靠性、可讀性和可維護性的降低，程式複雜度的增加；因此要謹慎進行。

 

         
代碼重審和回顧：沒有總結就沒有進步；“寫了代碼就丟棄”也不能期望有進步。通過代碼重審和回顧，進一步改進代碼的品質：可用性、可讀性、可擴充性、可移植性、安全性、可靠性。

 

          
其它：

 

          
大資料集處理問題：初學者可能通常會考慮 1– 100
之內的小資料集處理；但進入到軟體開發領域，大資料集處理，海量資料處理，就成了一個必須考慮的問題。對於排序問題來說，當n < 50
，或許採用插入排序就可以了；但當n等於幾百萬，幾千萬時，就不能採用插入排序了。這說明：小資料集的處理方案和大資料集的處理方案往往會是迥然不同的。

 

           
公用程式和工具箱：卓越的工匠都會備用自己喜愛的工具箱。程式員也不例外。初學者可能主要在於編程練習；但進入一定階段之後，就必須考慮編寫實用性強的工具和程式，而不是總停留在玩具程式的層級上。

           
標準庫；公用程式；熟悉的IDE；開源小工具；常用資料結構；演算法技術；Regex；資料庫使用；編程技術；編程技巧；設計思路；問題求解方案；錯誤錄；等等。

 

           
自動化重複工作：時常注意日常生活中是否有能夠自動化的重複性工作，並通過編寫公用程式和工具去簡化它。如果當時因為時間來不及，那麼，過後也應當儘力補上。

 

           
習慣的變革：人天性通常都是“能躺著就不站著”的，因此，培養了很多不好的習慣。程式員呢，通常期望能夠快速編寫出滿足功能的程式，然後運行察看是否如預期，接著便丟到一邊不再理會了。什麼問題分析、虛擬碼？什麼程式驗證、測試？什麼代碼重審和回顧？都扔到一邊去。結果是，你逃掉了一分鐘的測試時間，卻用了將近一小時調試時間來補償。划得來嗎？

         
其實，培養好的習慣，是一種一本萬利的投資。只要最初一兩個月堅持住，習慣成自然；之後，你便只是盡享好習慣帶來的益處了。

 

          
從編程到軟體開發

 

           
從某種意義上來說，在懂得《資料結構、演算法技術、作業系統、組成原理》這些專業知識之後，再加上“勤于思考，善於追根究底”的探索精神，以及大量的編程實踐，就可以逐漸掌握編程的基本原理和能力。

          
在學會編程之後，就可以閱讀關於軟體架構的書籍了，理解軟體是如何構建起來的。資料庫，電腦網路等等，實際上也是通過“編程原理+軟體架構”的產物，只是它們可以被用來作為更大系統的組件。