軟件開發核心心得

在一個有效的組織中，一定擁有傑出的一線人才。軟件設計也是同樣的，一線人才的素質決定了軟件的質量。從敏捷的觀點來看，代碼是檢驗軟件過程是否有效的最終標準。目前爲止，以及在短期的將來，咱們都不太可能徹底脫離代碼進行軟件設計。因此，軟件過程當中的任何一個活動都是爲了可以產出優秀的代碼。因此，代碼纔是核心。文章出自惠集返利網http://www.huiji123.com

1. 代碼是軟件開發的基礎

　　編碼是軟件開發過程當中最基本、最底層的技藝，然而也是最重要的技藝。任何一個領域的專家都須要花費大量的時間來進行基本技藝的鍛鍊，木匠須要花費大量的時間來鍛鍊他們對各類工具的掌握，廚師則須要練習刀工和火候。程序員也是同樣的，對咱們來講，語言的各類特性必需要了然於胸。而對軟件的管理也須要從代碼作起。

　　從2000年到如今，國內興起了一股軟件工程熱，需求管理、配置管理、甚至CMM。面對紛至沓來的各類方法學、UML、OOA，你們彷佛已經熱衷於這些概念自己了，卻每每忽略了軟件開發中最基本的元素:代碼。在和不少軟件組織的接觸過程當中，咱們認爲大多數組織急切須要的並非這些工程理論，不是說這些理論不重要，而是這些組織的癥結不在於此。不少的組織連代碼的質量都管理很差，又何談其它呢？代碼管理是基礎的基礎，從管理的角度上來看，任何一個組織的管理都須要一個從上至下的管理過程，有基層的管理人員，也有高層的管理人員。對代碼的管理就是軟件開發中的基層管理，它起到的做用就是可以把需求、設計的思路貫徹到最終的代碼中。

　　「管理無大事」。對軟件的管理也是同樣，大部分的問題都是因爲很小的緣由引發的。例如，一個產品若是後期在debug上花費了大量的時間，那麼，這種現象是因爲什麼緣由引發的？一種可能的緣由是前期的代碼設計中對代碼質量的把握不嚴。每一次代碼功能的演化並不會產生太多的問題，可是當代碼累積愈來愈多的時候，問題也就慢慢出現了。那麼如何解決呢？能夠增強QA的力量，也能夠引入複審，還能夠引入單元測試。總之，要有一種方法對代碼進行控制。

　　軟件的開發過程就象是一部精密的機器，任何一個環節的變化，都會對其它的環節產生影響。把軟件過程按照瀑布的形式進行劃分是一種分解的處理思路，但同時咱們還應該看到不一樣活動之間的相互影響。軟件開發中的生命週期模型也是一個層次模型，從業務建模一直到軟件實現，須要跨越數個層次，一樣會出現執行不力的狀況，例如，代碼設計偏離需求、偏離設計的狀況比比皆是。

　　如何避免這種狀況呢？這就須要咱們從源代碼的角度，反思其上游的實踐活動，是否足以約束代碼設計？就拿XP來講，他解決這個問題的方式是儘快的進入代碼開發階段，從代碼開發中發現問題，並在下一輪的開發中解決。這種思路是正確的，但XP畢竟是方法論，他不會告訴你過於細節的東西，儘管XP已經提供了大量面向代碼的實踐。由於方法論的抽象級別比較高，使得他必須捨棄部分的細節。而這篇文章告訴你的，就是這些細節。就像咱們在下一節中討論的例子，須要在代碼中加入對異常的處理，那麼，異常的源頭在哪裏呢？是需求，在需求中，咱們發現了一些業務的非正常的處理序列，發現了一些業務實體的限制性的要求，因此在代碼實現中，就須要有相應的異常處理。在例如，一個優秀的異常處理，還須要讓客戶端程序員瞭解可能發生的異常，以保證不一樣代碼間正確的集成。

2. 面向對象的代碼

　　面向對象的代碼已經在如今的軟件開發中佔據了主流的位置，面向對象的思路也有其優點所在，就像後文所討論的，面向對象代碼有着非面向對象代碼的不少優點，而軟件業中不少新的思潮的產生，也都是基於面嚮對象語言的，因此咱們關注的代碼將是面向對象代碼。

　　面向對象的思想來自於抽象數據類型。對於面向對象來講，它最重要的改進就是把世間萬物都描述爲對象，而類則描述了同一種對象的特徵，而不是像傳統的開發方法那樣，按照機器指令的執行順序來進行設計。固然，面向對象代碼最終仍然是要按照時序來執行的，可是從程序員的角度看來，面向對象代碼更側重於對象之間的交互，多個對象各司其職，相互協做以完成目標。而面向對象技術的發展，也是朝着更加貼近咱們世界觀的方向發展。從這點來看，有人說徹底沒有程序設計經驗的人學習面向對象可能會更加的容易，由於他不須要從原先的時序程序的桎梏中擺脫出來，但這未必是事實。面向對象決不是一種簡單的程序設計思路。這是咱們的觀點，也會在下文中反覆的論證。

　　和全部的職業同樣，程序員，或者是面向對象程序員，始終堅持的一點就是嚴謹。你會看到各類各樣優秀的代碼，但那決不是一次可以寫成的，要不斷的嘗試，不斷的改進。爲何重構和測試優先是敏捷方法中很重要的一項實踐？由於程序員不是神，他們須要慢慢改進他們的代碼。雖然羅馬不是一天可以建成的，可是在編寫面向對象代碼的過程當中，有一些實踐是須要堅持的，它體現了咱們所說的嚴謹。

3. 編寫並管理面向對象的代碼

　　編寫優秀的面向對象代碼並非一件容易的事情，優秀的OO代碼如行雲流水，糟糕的OO代碼讓人以爲渾身起雞皮疙瘩。編寫優秀的OO代碼要求程序員有必定的自我修養，可以以抽象的思路看待問題，找到問題的核心並對問題域進行分解。它強調的是一種解題的思路，但這個解不是惟一的。

　　典型的例子是設計模式，設計模式確實給了咱們以很大的啓發，經過它，咱們可以瞭解到優秀的代碼是如何用於解決實際問題的。可是是否是你必須在軟件中照搬設計模式呢？若是你這麼作，那麼你對設計模式的理解仍然不夠。我曾和在建築行業的朋友聊起Christopher Alexander的建築的永恆之道。他很興奮的告訴我，那確實是一本很好的書，可以引起人很深的思考，可是如今也有另外的一種觀點，認爲美仍然是無形的，應該發自建築師的心裏。對這句話我思考了好久，其實建築是給人使用的，所以最重要的是它能都給人帶來的價值，隱含在其中的那種活生生的氣質，這是建築師文化底蘊的外在表露。因此，Christopher Alexander在那本書中的目的，也是爲了找到一種總結本身觀點的方法，來總結本身對人文的認識。至於如今你們對他的思路提出了質疑，那也是一件好事，這說明你們對建築之道的認識到了新的高度。建築是這樣，軟件中的模式也是同樣的，我也曾熱衷於研究模式的使用，直到某一天我猛然驚醒，與其沉迷於模式的表面形式，爲何不去研究隱藏在它背後的文化底蘊呢？武俠小說中常說無招勝有招，模式的應用也應當到達這個境界，你若是能夠在不經意間應用模式的思想，那又何須拘泥於模式的形式呢？

　　編寫優秀OO代碼雖難，但還有更難的事情，就是讓整個開發團隊都產出優秀的OO代碼。咱們剛纔說了，OO對問題的解不是惟一的，但各個不一樣的優秀解聚集到一塊兒，可能就是一個糟糕的解，這是風格和架構的問題。你如何在團隊中制定制度，營造氛圍，讓優秀OO代碼成爲團隊最終的成果？這些問題，在我看來，要比CMM可貴多，這個問題並非靠花錢就可以解決的。若是可以解決這個問題，這個團隊的創造力必定是驚人的。

4. 面向對象軟件開發過程

　　普通的軟件開發過程和麪向對象開發過程有着很大的不一樣。回想咱們在非面向對象中開發過程當中，最常常採用的任務分配方法就是以軟件模塊爲單位，這樣的好處是分配簡單，不一樣任務之間耦合程度低，容易操做。壞處是幾乎沒法作到重用，也缺少總體性的設計。而面向對象軟件開發則不一樣，它是以類、類集合做爲基本單位的。類之間關係錯綜複雜（雖然咱們提倡低耦合的設計，但類之間的關係仍然是相對複雜的）。這種狀況下程序員之間相互協做的要求就很是之高，這種關係若是處理恰當，則可以徹底體現出面向對象的威力，不然，那將會是一場大災難，面向對象的軟件開發過程要養成一些好的習慣：

4. 1 儘可能簡化和穩定客戶端。

　　我的編程能夠是一種享受，但團隊開發始終是一項嚴謹的職業活動，所以多考慮別人，不要設計複雜的接口，雖然你省事了，但這會給理解和使用你的接口和人形成障礙。

4.2 準備一份簡潔的文檔，並保持更新。

　　隨便一種形式的穩定，能夠是代碼，能夠是UML圖，也能夠是純粹的文字（估計沒幾個程序員喜歡這種形式）。只要它可以傳達你的代碼的目的，那就足夠。記住，更新代碼後，同時更新你的文檔。過時的文檔不只是廢紙這麼簡單，它會給其它人形成麻煩。切記！

4. 3 儘量多的考慮異常和錯誤的狀況。

　　寫出一個功能並無什麼，可是要把這個功能寫的很是的完善那就很難了，由於你須要考慮各類各樣的狀況，正常的、非正常的。因此，寫完一個類的定義應該是，完成編碼和穩定，並經過原定的測試。本文摘自惠集網http://www.huiji123.com