閱讀文件夾：

• 1.背景
• 2.項目管理，質量、度量、進度
• 3.軟件開發是一種設計活動而不是建築活動
• 4.高速開發（簡單的系統結構與復雜的業務模型）
• 5.技術人員的業務理解與產品經理的業務理解的終於業務模型
  • 5.1.產品的業務理解（業務流程、數據流程及場景）
  • 5.2.技術人員的業務理解（領域模型、設計模型、抽象建模）
• 6.技術債務（腐爛的遺留代碼）
• 7.軟件項目管理與軟件project的鴻溝（項目管理得有語境上下文）
  • 7.1.軟件項目管理事實上應該多去重視一些技術層面的管理
  • 7.2.軟件project才是指導軟件開發的科學方法論
  • 7.3.代碼質量、可持續叠代、高速開發（須要軟件方法論的支撐才幹做好軟件項目管理）
• 8.敏捷、極限編程。精益思想
  • 8.1.重軟件項目管理不等於重軟件項目質量（否則瀑布模型就不會失敗）
  • 8.2.Scrum不等於敏捷開發僅僅能算是敏捷過程（此時僅僅是重視過程而不是終於的軟件質量）
    • 8.3.結合XP終於落實到軟件質量上（比方結對編程、互相code review、高速重構）
• 9.償還技術債務的成本（拖得越久成本越大，並且是指數級的）
  • 9.1.技術債務與高速開發
  • 9.2.技術債務的償還方式是有技術門檻的
  • 9.3.償還技術債務僅僅是其一。關鍵是怎樣避免技術債務（又一次開發不等於不會有新的技術債務）
• 10.軟件過程瓶頸
  • 10.1.代碼終於會成為你的最大的開發瓶頸（並且是無法解決的瓶頸）
• 11.不合格的技術人員對公司的副作用是非常大的（要做一名合格的技術人員）
  • 11.1.技術人員應該重視編程而不是各種高大上的技術名詞和互聯網浮躁的心態
• 12.總結

1.背景

近期對軟件開發有了一個新的認識，這個認識源自連續看了兩本Craig larman大師的書籍《UML與模式應用》、《精益與敏捷開發大型應用實戰》和公司眼下的項目情況這兩件事情一起碰撞導致的感悟。

先說下前者，為什麽會想到看Craig larman大師的書籍。事實上我收藏的書籍已經上千本，在各個電商平臺上都有帳號。目的僅僅有一個就是收藏好的書籍。

家裏也堆了非常多，沒事瀏覽新書是我如今最大的樂趣。我相信有這樣的感覺和愛好的不止我一個人，家裏堆上幾十本書的在IT行業算是非常正常的。

書多了有時候不知道要看些什麽也非常正常。我的原則就是隨時調整，看眼下所面臨的困惑。依據我以往的經驗總結。在實際問題面前尋找答案最easy讓你有新的感悟和提升。

我相信書中自有黃金屋、書中自有顏如玉，要在對的時間看對的書，說白了就是在有困惑的時候就去尋找給你答案的這方面書籍。為什麽要看Craig larman大師的書。是由於近期的工作內容有非常多自己搞不懂的地方，希望能通過大師的指點有所感悟。果然受益匪淺。

再說下後者。近期一直在和這幾個事情打交道：遺留代碼、技術債務、項目管理、項目質量、開發進度、高速開發、重構、單元測試、敏捷開發、Scrum、XP，你可能會有點疑惑，有些東西是反復的，比方項目管理中包括了項目質量、開發進度，再比方敏捷開發與Scrum和XP。似乎我在把一個大的概念拆解成多個小反復的概念。我之所以這麽做，是由於我想強調這些概念的差別和真正的相互作用，從軟件工匠的藝術角度出發來真正的看待這些概念。比方說，項目質量與代碼有關系嗎，開發進度與遺留代碼有關系嗎，項目管理與技術債務有關系嗎等等，這些問題的本質是全然不同的，作為技術人員尤其是應用開發的技術人員一定要強調概念。一定要明確不同的概念的本質含義，假設你不強調概念我想你的代碼是寫不好的。對業務的理解也不會深刻。

近期我將自己的技術生涯的目標定為“軟件工匠”，事實上說實話我不在乎title，我僅僅在乎自己的工作內容是什麽。軟件工匠是沒有邊界的，僅僅要和軟件開發有關系的內容都是屬於工匠須要去專研的領域。假設工匠離開工具就喪失了工匠的真正價值所在。所以說千萬別放棄寫代碼。無論你是一名架構師還是一名開發經理，代碼永遠是產品的終於設計。一旦你離他而去就離產品的質量越來越遠，後面我也會講下為什麽代碼如此重要。

2.項目管理。質量、度量、進度

這節的標題是不受歡迎的，大家知道為什麽嗎。技術人員是能明確的，有過長達5-10年的開發出生的管理者也是能明確的。唯一不明確的就是沒有太多開發經驗的管理者，或者那些不喜歡開發的管理者，那些逃避開發的管理者。由於他們離真正的產品實現太遙遠，他們離軟件開發領域真正的問題太遙遠。管理一旦忽視代碼質量問題就會慢慢找上你，你的項目往後的質量越無法控制，度量、開發進度都會遇到瓶頸。

說個當下的現象，我從事一線開發也有好幾年了，陸陸續續看到非常多人轉作管理，可是你會發現做管理的人一般都是技術水平一般的人，或者對技術沒有太多追求的人，更誇張的是在有些小公司的管理者可能就沒寫過代碼。

為什麽會出現這樣的現象，事實上主要原因有兩個，首要的就是個人的職業規劃，在就是公司的價值導向。先說價值導向，往往寫代碼的人的價值沒有項目管理的價值大，這在一些中小公司還是非常普遍的，真正的科技型公司這類問題差點兒沒有。而職業規劃是全然能夠接受的，畢竟每一個人的興趣和追求不同，這無可厚非，應該尊重每一個人的選擇。

可是這裏的問題是。一旦沒有太多技術底蘊的技術人員坐上項目管理者的職位後會對技術的理解360度大轉彎。這事實上是不正確的，項目的成敗不可忽視技術。

不繼續討論這個話題了，這不是本篇文章的重點。人各有誌，選擇是正常的。可是要明確的是選擇的本質不是價值導向。而是興趣導向。這才不會讓你忽視另外一個角度，由於一個軟件產品的終於成功是要靠項目管理和軟件project相共同的努力，缺一不可。

這裏想聊聊項目管理的三個重要的方面，質量、度量、進度。首先我不是一個專業的項目管理者，可是我是一名專業的軟件project師，我不知道項目管理的詳細內容有哪些，可是我知道項目管理的終於目標是和軟件project的目標是一致的，都是為了項目高質量的完畢。

項目的成敗光靠項目管理是解決不了的，假設能夠就不會出現《軟件project》、《設計原本》了。

保證軟件項目的真正成功是須要軟件project的支撐才行，而管理更加是對開發的組織、協調、溝通上的，這是兩個層面兩個角度互相作用的。項目管理中不會有設計、抽象、可維護性等這些內容。

這裏尤其想討論的就是軟件項目的質量，如今看來衡量軟件項目的質量忽視了代碼的質量，客戶驗收、功能完畢、穩定上線，沒耽誤進度，這就是完畢了一個項目，我們忽視了一個就是代碼的質量，為什麽要關心代碼的質量。

度量，度量是對開發周期內全部發生的事情進行數據可視化，BUG數、公布回退數、代碼行數（比較特殊）、需求變更數等等，還有些我不是太清楚的度量數據，總之應該會有非常多。度量的目的是為了什麽，是為了可以在這些數據出來後改善項目的各方面質量，控制各個不穩定的方面。

開發進度，“質量”一段中我最後拋出了一個問題“為什麽要關心代碼的質量”，由於他直接決定了你的項目進度，當你的代碼質量越來越差的時候你就失去了對項目進度的控制。你再多的度量指標都是無意義的，就算你能夠統計出BUG數上升了，可是你也控制不了BUG數下降。由於你已經偏離正常航線太遠，就算你能夠控制需求變更的速度和次數，可是你無法控制適應變更的代碼的速度和次數。

變更是無法避免的。你的代碼無法面對這些復雜的變化，由於你的代碼不是設計出來的而是堆出來的。最後你的項目質量也無法非常好的保證。

（圖1：項目管理與軟件project的結合才是完整的軟件開發）

近期在看Michael C. Feathers 大師的《改動代碼的藝術》一書，感觸頗多。裏面講到了我們面對遺留代碼的時候，為了添加一個新的功能要付出多少時間和精力。出現明顯的BUG機率有多高，出現隱藏的BUG機率有多高。遺留代碼直接決定了上述三個項目管理的方面。Michael C. Feathers 大師強調了非常多關於我上面講到的項目管理和代碼質量之間的關系，這本書非常值得看。

事實上真正推動軟件開發不斷發展的是軟件project、開發方法論，項目管理僅僅是輔助於軟件project在時間和空間上有效實施。

這裏還要差別下就是項目管理和團隊管理的差別，這兩個東西是不一樣的。項目管理基本上不須要軟件project的支持，可是團隊管理在某些方面是須要軟件project的支持才幹做的更好。

3.軟件開發是一種設計活動而不是建築活動

在《精益與敏捷開發大型應用實踐》一書中是這樣描寫敘述軟件設計和架構的：

1：“軟件架構借鑒了建築的架構，但結果證實這是個不太恰當的類比，並且給軟件開發帶來了有趣的副作用。

建築是硬的。由於在這個領域，設計僅僅在施工前進行一次。然後該建築或者設計就差點兒是永久不變的了。

註意建築師和施工工人是不同的。可是軟件不是一座建築。軟件是軟的，並且編程也不是施工的過程，“軟件架構”僅僅只是是一大堆比喻列表中能夠選擇的一個不太完美類比而已”。

2：“......唯一確實看起來滿足project設計條件的軟件文檔是源碼“。

3："我意識到圖表和文檔並非真正的設計，而源碼才是真正的設計。再次重申“......唯一確實看起來滿足project設計條件的軟件文檔是源碼“。

這幾句話足以證明軟件開發是一個很復雜的過程。是思維密集型腦力活動，並且體如今每個編碼過程中。

在許多項目管理中都覺得軟件開發是一個很easy的活動，主要架構設計好編碼是比較簡單的，難道真的是這樣嗎。我們再看看書中怎麽說的：

1：”源碼是真正的藍圖“。

2：”真正的架構在哪裏，不管好壞、有意或偶然的？是在架構團隊維護的文檔中？還是在上萬個文件裏？顯然是後者。源碼是真正的設計。並且它的總和反映了真實的大型設計或架構。架構就是架構。不是某人的意願“。

如今非常多開發人員另一個明顯的技術理解錯誤就是”寫代碼“是比較簡單的活動。

復雜的是軟件架構。僅僅要架構設計好後寫代碼應該是程序猿的事兒。這裏明顯有一個錯誤的價值觀，覺得寫代碼的人都是便宜的，不具有不論什麽的設計和創造新。

這事實上是一個非常不專業的看法。真以為一個簡單的PPT、WORD文檔中的架構圖就表示架構了。

事實上這個想法是非常幼稚和膚淺的。用Craig larman大師的話講，在整個軟件生命周期的活動中，復雜的是編寫代碼。而代碼才是架構。所以說架構的就是代碼。

你原本理解的架構才是真正難的地方事實上也就是代碼才是真正難的地方，不可浮於表面，這樣才幹更加的接地氣才幹真正的有價值。

架構師應該深入到一線參與一些開發，這時會發現非常多問題，然後將問題帶到架構的位置，用架構的視角設計方案。在親自把這個方法帶到一線落實下去，這才是架構落地一個技術方案的正確方法。

軟件開發是一項設計活動而不是建築活動。軟件是會不斷變化的，而建築一旦敲定是不會改變的。

4.高速開發（簡單的系統結構與復雜的業務模型）

這節我想聊聊高速開發。在圈子裏面對高速開發的理解大部分都是和高速開發框架相應起來。認為應該有一個框架來支持高速開發。僅僅要有了一個框架就能夠進行高速開發。這種看法或想法事實上是錯誤的，對高速開發的理解太狹隘。

《設計原本》作者。計算機科學巨匠Frederick P. Brooks說過，對於軟件開發來說沒有銀彈存在。沒有所謂的可以用簡單發方法來開發復雜的系統。越復雜的系統開發起來不會簡單的，開發一個滿足100個人使用的系統和開發一個滿足1000個人使用的系統在復雜性上已經全然不同了。

量變引起質變，當業務量、訪問量、數據量等等這些軟件指標超出一定的範圍之後就和最初的設計全然不同，設計思路也全然不同。

回到當下。

我如今常常面臨這種一個問題，我如今所從事的業務是比較復雜的，對系統的設計要求非常高。假設用量來比喻的化。事實上我如今所面對的業務量是比較大的，業務量中的業務復雜性的量事實上相比於訪問量、數據量等方面的量在設計方法要難的非常多。通常做設計的架構師都僅僅會考慮並發量、訪問量而忽視業務量。比方業務的多變性、業務的擴展性，業務本身的復雜性，這尤其考研設計能力。考驗抽象能力。

這跟你用什麽編程語言用什麽數據庫是沒太大關系的。你腦袋裏運用的是OO、實體關系。這些與詳細技術框架沒關系的設計思維。

業務量對於編寫代碼要求要高非常多。同比於其它幾個量來說非常難落地。訪問量、並發量能夠通過基礎架構的調整優化升級來解決，而業務量的問題域是業務邏輯。是領域模型。當前所面對的業務域，不論什麽一個細小的業務都須要在代碼中體現。

近期陸續在做一些系統重構的工作。就在前兩天我重構了一段代碼。不是基礎性的代碼，是業務邏輯代碼。大概情況是這種。

在系統中有一個重要的領域概念“重量”，這個重量的概念存在非常多個業務量的質變可能性。就是說它本身不是簡單不變的，隨時存在著變化，當我們品類擴充的時候就立刻會變化。

重量的定義是這種：重量=單件重×數量。看上去好像非常easy的樣子，事實上不是，這裏的單件重是會變化的。有些時候是保留3位小數有些時候是保留6位小數。並且這個重量的業務邏輯是在N多個地方都須要用到的。查看代碼下來大概有幾十個地方都在反復著編寫“重量“的業務邏輯。

後來我在同事的協助下重構了這塊業務模型，為什麽我這裏不用業務邏輯來形容我的重構工作，是由於我考慮業務的時候不會是過程式的，假設用”業務邏輯“來思考業務就會給人造成一個錯覺就是”過程式“的代碼結構。

所以我考慮不論什麽業務都是”模型驅動開發“方法，業務要抽象為模型才幹重用、擴展、抗變化性。

這事實上是OOA/D的精髓。業務邏輯僅僅是在模型中的一小塊一小塊的詳細動作。它是在模型的範圍內使用的，而不能一上來就是業務邏輯，業務邏輯太細小不便於抽象化。

（圖2：重量、單件重模型）

我用上面的這個模型對重量業務模型進行了重構。

將原本非常重要的業務概念重量、單件重、不同類型的單件重，進行了概念顯示化，保證這些重要的領域模型不被過程式的代碼淹沒。

且用兩個工廠封裝了創建重量和單件重的業務邏輯。這樣做之後我們的模型就具有抗變化性，以後要是對Weight有不論什麽的創建邏輯的變動我們就能夠在WeightFactory中處理，假設有新的品類擴充進來後須要對單件重相關的處理我們僅僅須要擴展下ItemCategory和PieceWeightFactory兩個模型。

假設你須要做為全然配置化，這個時候模型就更有價值。

比方，我們能夠將IitemCategory拿出去，通過品類擴展的時候自己主動生成相關的類型，假設你認為這還不夠完美，我們能夠進一步將PieceWeightFactory中有關於“依據ItemCategory創建PieceWeight（Decimal） “。做成”Mapper模型“在進行配置化。

這裏你會發現一個非常奇異的地方就是，一旦模型化後業務的量變引起的質變能夠通過逐步重構模型、提取模型、精華模型來解決。

所以說簡單的系統結構是無法表示復雜的業務模型的，假設能夠的話OO語言就不會發展成今天的這樣子。復雜的業務無法通過簡單的系統結構或者說所謂的簡單的高速開發框架之類的東西能夠解決的。

5.技術人員的業務理解與產品經理的業務理解的終於業務模型

非常多時候我們都在強調“多去了解業務、多去熟悉業務”，在業務驅動型公司這是必須的，公司中的不論什麽角色的單位都須要熟悉公司的業務範圍。這沒有問題，我想說的是不同的角色對於業務的理解終於的業務模型是不同的。

無論是在傳統的軟件企業中還是互聯網企業中，我們要用軟件來服務於我們或者客戶，當然這裏所說的是業務系統。業務系統的核心就是業務，系統的精神就是業務模型及模型之間的關系。

這節我想說的是，技術人員去了解業務後和產品經理去了解業務後終於的業務模型是如何的。技術人員與產品經理是不同的角色。具有不同的職業背景，不同的知識結構和專業度。如今存在一個普遍的認識錯誤是，技術人員理解業務後與產品經理理解的業務後的終於的模型是一樣的，是如何的呢。是無法抽象的業務。大概的業務，場景化的業務。無法落地到系統中的業務。此時技術人員並沒實用自己的專業度來對業務進行抽象和建模，並沒有直接帶來真正的價值，而是在交談和理解需求的時候感覺上的價值錯覺。

技術人員不可以業務技術化事實上對於公司所說的“當技術人員理解業務後產生的價值是巨大的”事實上是不準確的。

5.1.產品的業務理解（業務流程、數據流程及場景）

產品對於業務的理解是總體上的。包含業務流程、數據流程，場景，在他們的腦子裏是真實的業務場景，是必需要還原的業務場景，不可以有不論什麽的其它模型在作怪。假設產品用不論什麽的其它知識來抽象和強制理解業務是會出現故障的。

產品對於業務的終於模型是業務流程、數據流程和一個不須要表現的場景。

（圖3：產品的業務理解終於模型—業務流程圖）

因為數據流程圖比較簡單，當前樣例中僅僅會有“訂單”的數據實體，畫出來意義不大，我這裏就僅僅畫一個業務流程圖來表達意思就可以。

在這個程度上是無法直接將流程圖落到系統上的。它距離真正編寫軟件另一段過程要進化，而以下那段過程才是技術人員理解業務後要發揮的價值和作用。

5.2.技術人員的業務理解（領域模型、設計模型、抽象建模）

技術人員的了解業務要有所側重。你理解的業務和產品理解的業務是不一樣的。技術人員須要將業務終於技術化才行。技術人員的終於的業務模型是有正確的模式能夠參考的。就拿“創建訂單”這個流程來說。等待技術人員須要去提取和抽象的東西是比較多的也是比較復雜的，須要結合非常多的知識來進行設計活動。

比方訂單。你須要結合“四色原型”模式來提取“訂單”的模型，包含“訂單的類型“、”訂單的跟蹤“。須要結合設計模式來抽象”創建訂單的邏輯“，依據”不同的訂單類型創建不同的終於訂單“。還須要進行設計模型的抽象。比方創建訂單。各個對象的交互是怎樣的，每一個交互的輸入和輸出是什麽。這些都須要技術人員理解了業務後應該具有的業務模型，假設須要將模型語言化就須要結合使用UML來建模。

假設技術人員理解業務後和產品經理理解業務後的結果是一樣的。那技術人員要去理解有什麽價值。技術人員理解業務後要系統化的將各個業務模型落地到詳細的領域內或者說某個子系統子服務中，然後各個系統和服務是怎樣交互的，邏輯的歸屬究竟是哪邊的。終於你寫出來的代碼才是滿足業務的代碼模型，才是有核心競爭力的業務系統有別於無核心競爭力的系統差距。

技術人員了解業務後，針對不同的業務場景開始創建領域模型草圖，依據領域草圖再進行設計模型草圖創建，當然這是一個敏捷的叠代的過程。

（圖4：“創建訂單”相關的領域模型）

有了領域模型之後就須要創建設計模型，也就是各個模型之間的協作關系。還是要強調下，這是一個高速叠代的過程，且無將其看成是瀑布的依賴過程。領域模型的精華也是沒有止境的，當後面進行設計模型的過程時會有對領域模型有補充的靈感，此時不能夠教條。要高速的精華領域模型然後再進行設計模型的過程。

（圖5：“創建訂單”相關的設計模型）

基於領域模型創建設計模型中的對象協作模型，設計模型不僅僅僅僅有協作模型一種還有其它的。協作模型是必須的也是最重要的。有了協作模型之後我們就能夠走查場景是否滿足“創建訂單”的這麽一個業務動作。當八九不離十的時候就能夠進入到編寫代碼階段。進行一個高速的構建代碼模型。由於這個時候還是會有問題出現，僅僅有在代碼模型中沒有問題後才是真的沒有了。

我這裏僅僅是如果一個簡單的業務場景作為演示樣例，目的是為了介紹技術人員差別於產品對於業務理解後的終於模型是不同的。技術人員一定要有完好的能將業務技術化的知識結構。這樣才幹真正的將業務發揮價值。

6.技術債務（腐爛的遺留代碼）

技術債務事實上是無法避免的，各種原因，時間進度、需求變更、市場迫切等。都迫使研發開始堆積技術債務，代碼逐漸開始腐爛，難道我們作為技術人員就僅僅有抱怨和推卸責任嗎。這裏我有一些個人看法。這些個人看法可能跟你的理解不一樣。你可能會說我太理想主義了，可是我想說的是：“作為一個技術人員一定要有情懷，一定要有追求。”用我最尊敬好朋友馮老師的話說：“寫代碼一定要考究“。就算在時間比較緊的時候能夠先寫。可是要記住你的工作並沒有全然完畢。

我是從開發做到架構。經歷過非常多項目磨練。也深知在項目時間比較緊急的時候自己是在一個什麽精神狀態下寫代碼的。自己也幹過到處復制代碼粘貼代碼的時候。加班到12點，眼睛基本上已經非常難看清代碼。寫程序的速度已經趕不上功能交付的速度。我僅僅能說這也沒有辦法，市場決定了項目的進度。

我們能夠吐槽，可是不能抱怨，更不能消極。

事實上現實情況下我們做開發的基本上都是在這個節奏下工作，可是我是怎麽處理這個問題的呢。

首先寫好代碼是個人對技術的一個追求和職業素質的問題，假設你對代碼沒有美感你非常難能編寫出好的代碼，你的代碼也會到處留有壞味道，時間長了就是腐爛的遺留代碼。嚴重的技術債務，研發整天怨聲四起。各種抱怨。吐槽，這樣下去事實上是不好的，團隊裏有追求的技術人員會流失。

實話實說。當自己今天晚上12點寫好了代碼提交了測試，可是我的工作並沒有完畢，我一般會在早上非常早就醒了，我會非常早的來到公司對自己的代碼進行重構和梳理，早上是大腦特別清醒的時候，在這個時候你進行代碼的整理是非常不錯的，並且這個時候公司一般都沒什麽人，特別安靜，當你重構完代碼舒服舒服的再去整理自己每天早上來的其它事務。

你可能會說那是你個人問題，我不一定會在第二天早上能起的那麽早。就算起的來我到了公司也不會對第二天的代碼進行整理，由於那已經上線了已經是完畢的功能，我該繼續下一個需求。

用我的價值觀來看的話，事實上你的工作僅僅完畢了一半，你並沒有保質保量的完畢工作，你的軟件交付質量在產品層面是完畢了，可是你在技術層面是有殘缺的。你給軟件帶來了非常多的技術債務。你給某個對象帶來了腐爛代碼的開始。

這點我如今的公司是很不錯的，公司高層對項目的管理者首要的要求就是必須懂技術。

我一沒事就會和我的好朋友也是好同事馮老師交流技術，互相review代碼，提意見，在互相重構。彼此學習。我們有一個共鳴，就是讓寫代碼有追求的人來把控項目是很不錯的。能夠保質保量的完畢功能，當然不是光說有寫代碼能力就OK的，須要綜合性的。事實上說白了，讓一個精通技術的人在去精通業務做出來的軟件應該是不錯的。

（這裏所說的精通技術是指應用開發方面的精通，不是指技術專家、系統層的技術專家）

作為應用開發者，要時刻記住你所應該具有的專業的職業素質，寫代碼要講究，要記住對你來說代碼意味著什麽。

未完待遇。

。

。

。。。

作者：王清培

出處：http://blog.csdn.net/wangqingpei557

本文版權歸作者和CSDN共同擁有，歡迎轉載。但未經作者允許必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利。

軟件project—思考項目開發那些事（一）