資深架構師的經驗分享——軟件項目開發和決策

這篇文章是關於什麼的

參與項目決策的人必須意識到他們的決定對項目的成功和成本以及時間和金錢的影響。

對於我20多年的軟件開發經驗和10多年的諮詢工做，我做爲架構師或開發人員參與了許多項目 - 其中大多數成功，有些失敗，但每一個項目（不管成功與否）都涉及好的和很差的決策由各類人制做。

本文的目的是經過提倡根據個人經驗作出的決定以及避免錯誤的決策來爲項目成功奠基基礎。

總的來講，我擁有C ++，Java，C＃和JavaScript的經驗，但在過去的10年中，我一直主要致力於C＃桌面應用程序。儘管如此，這裏提出的許多想法都具備通常性。當我討論一個C＃桌面應用程序時，我明確地陳述它。

軟件開發始終存在一個「政治組件」 - 本文不涉及這一點。本文的目的是提供建議，以最大限度地提升客戶滿意度，同時最大限度地減小支出。

項目開發主要指南

在這裏，我介紹了軟件開發的兩個主要準則，這將在文章中進一步詳細描述。

1. 在軟件開發主題上有不少書籍，文章和更多的廣告垃圾。用一粒鹽吧！若是你讀的東西與常識衝突 - 選擇常識。

2. 在公司，項目或我的層面，需求的傳播（特別是API需求）應該從使用它的人（客戶）流向構建它的人，而不是相反。經過客戶端，我也指同一項目中使用其餘人構建的軟件的開發人員。這個很是重要的規則經常被忽視，不利於項目的成功。

在項目的開始

在一個項目的開始階段就要作出一些重要的決定。理論上，在項目開始時作出的錯誤決策能夠稍後糾正。然而，錯誤的決定浪費的金錢或時間越多，後來糾正的可能性越小，由於糾正它們會引起能力問題。

選擇一種語言

對於一門語言，我強烈建議不要使用C ++（除非你正在構建一些很是高性能的算法，由於它的編譯時間很慢，所以一秒鐘的分裂相當重要）。每一個軟件開發（若是正確完成）都涉及不少原型設計，並從新啓動應用程序或爲應用程序運行測試。代碼更改後的每次新運行都涉及編譯。C ++模板的構建方式是在編譯時必須生成代碼，這樣C ++一般編譯起來很是慢。編譯速度緩慢將致使原型設計速度緩慢，開發速度相應緩慢。沒有模板，C ++沒有現代強類型語言那麼強大。

並且，Java和C＃擁有許多內置於該語言的標準庫，而C ++則依賴於第三方庫。

最佳團隊規模

在個人經驗中，較小的團隊能夠更快地生成更好的軟 例如，對於桌面三層項目，我會推薦一個3人團隊 - 每一個層級一我的+一個建築師+ 1-3個裁人。

我最成功的項目正是由3-7名成員組成的團隊。我參與過的最不成功的項目之一是擁有20多名成員的團隊，幾年內沒法實現幾個月內小型項目將實現的目標。

Scrum或不Scrum

毫無疑問 - 對Scrum來講！敏捷/ Scrum可能並不完美，但它比替代品更好。然而，Scrum的某些方面並不有效（我認爲它們不該該成爲過程的一部分，儘管大多數敏捷教科書都會提到它們）。如下是scrum的正面和負面特徵列表。個人建議是：避免使用負面特徵。

Scrum的積極

1. 一般，在項目開始時，客戶自己可能不清楚他們須要什麼。它須要不少迭代（包括客戶和開發人員的錯誤）讓客戶弄清楚須要構建什麼，以及開發人員如何構建它。Scrum的迭代方法最適合這種範式。

2. 在scrum之下，開發人員能夠估計本身須要多長時間才能實現某個功能 - 他們一般能夠作得比管理人員好得多。

3. 每日更新對經理和開發人員都有益。雙方均可以更好地瞭解項目的位置。此外，對於開發者來講，這是一個與他人分享他們一直在努力工做的機會，以便了解他人正在作什麼，而且通常來講，在編程時能夠鍛鍊大腦的非編程部分部分休息一下。

4. Scrum會議結束後，包括演示和計劃在內，也會因平常會議的緣由而受益，但規模較大。

Scrum的負面影響

1. 一些Scrum版本倡導只跟蹤整個團隊的表現 - 不考慮我的開發者的貢獻。雖然團隊績效很是重要，但認識我的努力仍然很重要。

2. 在Scrum結束時召開了會議，人們捶胸說出了什麼問題 - 越多越好。我歷來沒有看到從他們身上出現任何好東西。發生問題時，應由開發人員解決。更嚴重的問題應該升級到建築師/經理，有時候應該改變項目程序。

對等編程

除非是短時間的，而且由兩個願意合做夥伴徹底自願地分享知識，不然永遠不會看到任何好的同伴節目。

我練習很是積極，快速，以結果爲導向的編程 - 觀看別人的節目讓我想睡覺。我認識的每一個人都被迫作同儕編程，分享我對它的見解。

選擇軟件包和第三方組件

你應該很是當心選擇3 次黨庫-你應該懷疑華而不實的演示和廣告。選擇一個3 次方包（不管是開源仍是須要付出的東西），只有當如下條件之一是true：

1. 這是一個衆所周知的產品 - 如MS Visual Studio，Oracle DB，MS SQL Server，Telerik或DevExpress控件 - 擁有數千種證詞

2. 您的開發人員將直接使用該軟件，並在合理的時間內對該軟件進行試驗，至少兩週，而且使用起來很是溫馨。

請記住，您爲軟件包支付的金額越多 - 以後將更換或更換副本越困難，由於您花錢的人會但願確保這筆錢不會被浪費。

請記住，偉大的公司仍然能夠有糟糕的產品。我多年前就有一個團隊對Oracle的Stellent軟件產生了負面影響 - 他們花費了大約25萬美圓！對於甲骨文而言，他們當時剛剛購買了Stellent，所以它徹底是在Oracle以外開發的。

此外，還記得那花了一個月研究3 個在一開始方組件能夠從字面上拯救你年後。

第三方組成部分的一些具體建議

本部分針對MS桌面系統。

UI控件的包

對於WPF前端，我推薦如下軟件包：

1. Telerik - 用WPF概念構建而成，易於修改和學習。

2. DevExpress - 不須要 WPF（在我看來），因此定製起來不那麼容易，但仍然靈活並且速度很快。它具備Telerik沒有的一些控件，包括容許用戶在運行時組裝WPF視圖和地理地圖控件的設計器控件。

我對Xceed瞭解很少，但從我聽到的狀況來看，它的使用也至關不錯。

我會警告反對Syncfusion - 至少幾年前，它創建與WPF意識形態相反。

我會推薦反對Infragistics - 它具備最開箱即用的功能，但根據個人經驗，這很難定製，而在WPF中，定製是遊戲的名稱！

全部上述WPF軟件包在製圖時都會遇到性能問題。我與之合做的WPF Chart軟件包，我強烈建議使用SciChart。

不管您選擇何種軟件包 - 選擇包含下載源代碼權限的許可證。每當我使用Telerik或DevExpress時，我都必須研究他們的代碼，以便可以產生個人客戶所指望的效果。

IoC容器

大多數體面的規模項目都應該包含控制的倒置，以便爲項目構建擴展點或便於交換實際測試實現的實現（例如，當涉及到對後端測試前端功能時）。

大多數狀況下，我使用的MEF2有點複雜，但老是適合項目的目的。

我聽到不少Ninject的正面評論（儘管我本身從未使用過）。

我正在開發Roxy IoC容器。它仍在進行中，特別是在IoC方面，因此我如今不能推薦它。但願我能在幾周內推薦它。

測試框架

無論怎樣，Xunit是我所知道的最好的測試框架，我極力推薦它。這是免費的。它容許使用各類基於屬性的輸入來運行相同的測試。在其餘框架中，您必須爲每一個輸入組合編寫單獨的代碼。

中間層

在MS宇宙中，我會建議使用MVC控制器或WebApi或WCF構建自定義中間層。我也喜歡在中間層使用ADO Entity Framework。

WCF比ASP中間層解決方案更復雜，更強大。一般，ASP中間層對於此目的來講已經足夠了，但對於更復雜的需求，好比使用TCP鏈接而不是HTTP，WCF很棒。

後端

對於體面大小的項目，我建議使用Oracle或MS SQL Server。根據個人經驗，最多不使用SQL數據庫做爲緩存機制與SQL數據庫一塊兒使用，或者用於某些特殊操做，例如全局搜索。

項目工具

我使用了許多工具，下面是我推薦的工具：

對於源代碼控制，我推薦Git和Subversion; 都工做得很好，都是免費的 - 個人首選是Git。

做爲需求/錯誤跟蹤系統，我推薦Atlassian Jira或Rally。二者都是高度可配置，通過充分測試的解決方案。

爲了構建，發佈和持續集成，我推薦Atlassian Bamboo。

請注意，當用戶數少於10時，Atlassian軟件很是便宜。對於這樣的團隊，每一個產品的平均費率爲每個月10美圓。

進步vs保守派

團隊中總有人渴望並願意學習新軟件和新軟件包（我就是其中之一），以及那些想要堅持熟悉的老軟件和舊軟件包的人。

如下是這些方法合理的一些例子。

進步是正確的

1. 好久之前，因爲縮短了編譯時間和原生包，從C ++切換到Java極大地提升了項目的生產力。

2. 切換到WPF和C＃絕對是一個偉大的決定 - WPF是最好的基於Windows的桌面開發包，而C＃如今比Java更強大，而且不斷改進。

3. 人們採用反應式擴展的速度很慢，但它絕對是一個很好的軟件包，能夠用來構建過去很是複雜的事情。

4. Roslyn是一款出色的C＃編譯器，我相信它最終將令人們可以實現本身的語言特性，同時提供完整的IDE支持。

當保守派是對的

在過去的10年中，微軟發佈了許多失敗的軟件包。（這教會我當心）。

1. 我對Silverlight仍然很是痛苦。我認爲這是一個偉大的web開發包。我敢打賭Silverlight（儘管我明白它是微軟的一種慈善行爲，由於它破壞了本身的平臺），我輸了。

2. Windows RT，曾經被MS積極推廣的多個Windows Phone平臺失敗。（我已經更聰明瞭，從一開始我就感受不太好）

關於預測包裹什麼時候失敗或成功的一些想法

恐怕以100％肯定性來預測幾乎是不可能的。

WPF是一個很好的包，我從第一眼就愛上了它的概念（以前我有過不少相似的想法）。

Silverlight也是由MS徹底維護的一個很好的軟件包，當MS決定他們再也不須要時，它基本上已經死亡。

Windows RT是一個翻版，我以爲它從一開始就會成爲一個翻版，由於他們偏離了.NET並試圖進入本地。

我猜的經驗法則是：

1. 當MS發佈一款優秀的產品並在其背後放置一些肌肉時 - 產品就會蓬勃發展。

2. 當MS發佈一款優秀的產品並停產時 - 產品就會死亡。

3. 即便MS肌肉也沒法挽救糟糕的產品。

我想在本小節中對有關新的MS軟件包的一些預測加以限制。

基於我掌握的有限信息，我相信Xamarin擁有光榮的將來 - 它有望成爲智能手機和平板電腦編程的主要手段之一。

恐怕UWP不會飛，由於它只適用於Windows 10和Windows 10產品。您將沒法在Windows 8或Windows 7上運行它，更不用說Linux或Mac。爲何使用它，若是它只是WPF和WPF在任何Windows平臺上運行的蒼白陰影？

我之前錯了，我可能又錯了 - 時間會顯示。

在項目開始前或開始時進行原型設計

儘管Agile具備迭代性，事實上客戶可能只是對最終產品應該在一開始就應該有一個模糊的概念，但項目設計師在開始時至少想出了一個小原型是一個好習慣項目。

這樣的原型應該結合一些UI，中間層和數據庫功能以及基本的測試項目。應用程序的全部部分應該可操做並相互通訊，而且應該運行測試。

根據個人經驗，我建議在原型上花費2周到1個月的時間。只有在建築師要求的狀況下，建築師才能在別人的幫助下親自完成。

該項目的其他部分將涉及擴大原始原型。

除了做爲參考的初始參考點以外，這樣的原型還可讓管理人員和團隊確信他們作出的決定以及他們使用的第三方組件將實際達到最終目標。

3層架構

這是標準的3層體系結構模式：

在圖中 - 雙面黑色箭頭表示從UI客戶端到中間層以及從中間層到數據庫的請求 - 響應鏈接。

單側紅色箭頭表示從實時饋送到中間層和客戶（訂閱它）的「熱」（實時）鏈接。此外，它還顯示一旦收到實時數據，它可能會記錄到數據庫中（從中間層到數據庫的紅色箭頭）。

中間層能夠有高速緩存，單個客戶端高速緩存能夠提升速度。一般，您緩存您知道在特定時間段內不會更改的數據。當時間間隔過去後，您將數據強制從緩存中移出或標記爲「過期」，以便在下一次請求後刷新數據。

重要說明：根據個人經驗，最好的中間層是沒有任何業務邏輯的層。業務邏輯應該駐留在數據庫和UI中。中間層應該是數據庫基本功能中高度可配置的通用網關，而且不該在每次擴展業務邏輯時都進行修改。我用C＃和Java在個人生活中屢次構建了這樣的中間層。

也許第二個最好的中間層是在添加新的業務邏輯時僅須要較小的和標準化的修改的層。我也曾屢次與這樣的中間層合做過。

運行項目

客戶端 - 服務器API要求傳播原則

多層開發的主要原則是客戶端應該比他實現它的API有更多的發言權（API應該由客戶端驅動）。

正如軟件的客戶（或客戶端代理，如產品經理）對最終產品的外觀應該有更多的說法，UI開發人員也應該對他從中間層使用的API有更大的發言權，後端。

我想清楚2點：

1. 我並非說UI開發人員徹底肯定了API。應該在請求者和實現者之間的討論中明確API - 有些事情可能不可能或很難實現。

2. 服務器的實現仍然取決於服務器開發人員 - 我只談論客戶須要的公共API。

UI開發人員和後端/中間層開發人員之間的關係應該與最終用戶和UI開發人員之間的關係徹底相同。

這個原則一般不被遵循。實際上，人們從後端和中間層開始開發，而後UI必須圍繞全部由此產生的API問題進行論述。

想象一下，UI開發人員會來到最終用戶，並告訴他們，即便他沒有與他們進行任何諮詢，他所建的東西也能知足他們的需求。聽起來至關荒謬，可是UI開發人員不得不常常處理相似的狀況，當後端開發人員告訴他們如今他們擁有他們所須要的全部東西，即便他們沒有與UI開發人員進行任何諮詢。

個人經驗一次又一次地證明了這個原則 - 需求，APIs甚至開發都應該從使用API的部分傳播到實現它的部分。這不只適用於客戶端 - 服務器部門，也適用於您本身編寫重要軟件的狀況。你須要從軟件的目的開始，而後填寫'空格'。不然，若是你從'空白'開始，你可能會發現他們不太適合這個目的。

測試驅動開發的普及是對這種範式的另外一種證明。

建立API

在傳統的'瀑布'哲學中，建築師試圖在項目的一開始就建立不少接口，以便開發人員可以爲他們編程。從個人角度來看，這不是最好的方法 - 它把馬車放在了馬匹的前面。

在開始時應該建立不多的接口，而且架構師應該隨時準備修改它們，若是發現它們不符合目的。

應該在須要時建立接口 - 例如，只要有方法或類須要處理知足某個接口但實現可能會有所不一樣的對象時。不要過於努力地預見，你須要一個接口 - 首先（當只須要一個實現時）編程到一個類，可是當出現這樣的需求時，準備將它改變爲一個接口。

這在我的層面和建築師層面都是如此。敏捷的迭代特性可以適應API修改。

建築師的角色

這將我帶入軟件架構師的角色。

團隊中的一位開發人員能夠承擔建築師的角色（特別是在項目大小合理的狀況下）。

這是軟件架構師應該承擔的任務：

1. 概述發佈過程 - 將產品移至用戶或用戶代理。

2. 隨時關注產品開發進度和產品需求變化。

3. 在開始階段 - 如上所述構建產品的很是稀疏的骨架（原型）（包括初始測試項目）。

4. 解決各類開發人員之間的軟件問題。

5. 找出代碼共同點並將它們分解成可供各類開發人員在各個地方使用的通用API。

最後一點也應該由各個開發人員爲他們本身的代碼實施，或者若是開發人員在多個開發人員領域中看到代碼的共同性，他應該將其引入共同考慮範圍，並讓架構師決定是否須要分解通用性。

通常來講，代碼中的共同點應該不斷重構，不管是由開發人員仍是架構師。

有些人認爲他們須要提早找出並排除全部共同點。這不太可能。沒有人可以作到這一點，就像沒有人可以在項目開始時建立全部界面同樣。沒有理由花大量時間在一開始就考慮我的或架構師層面的共同點。在整個代碼開發過程當中，您將可以找到要重構的代碼。

我對建築師的建議是在整個多層架構中考慮數據形狀。在關係數據庫中 - 數據一般放置在規範化的表格中。也有一些記錄可能經過實時提要進行傳播。該級別沒有層次結構。然而，在UI方面，大多數記錄須要一些層次結構，以用戶想要的形狀顯示給用戶。我打算寫另外一篇專門討論數據形狀和數據形狀轉換的文章。

創建一個團隊

根據個人經驗，工做場因此外的非工做相關活動是創建人與人之間信任並讓人感受本身是團隊的好方法。如下是一些可行的活動：

1. 清道夫狩獵

2. 去一家餐館或喝一杯

3. 足球比賽

4. 保齡球

人的問題

如下是我在整個項目中觀察到的一些與人相關的問題

1. 良好的領導能力和政治技能不足以執行一個項目。事實上，我看到項目失敗了，由於他們是由具備良好領導才能和政治技能的人領導的，但沒有任何軟件開發意識或有一些軟件開發意識，但不敢用它來反駁上司。

2. 在會議上充滿自信地發言的人不必定知道軟件細節。重要的決定決不該該在一次會議上進行 - 只有在完全的書面討論以後。

當沒有線索的人試圖接管某個領域的編碼或項目領導時，我觀察到了所謂的「庸醫」問題。他們可能具備良好的領導能力和演講技巧，其中一些甚至可能擁有技術技能，但在不一樣的領域。不該容許這些人在他們不知道的領域作出決定。

檢查一我的是不是某個領域的專家的一種方法是讓他創建一個概念驗證原型。若是他不能創建一個小概念證實，他不該該被容許接管這個項目。

我曾與一位表示製做原型的人合做須要太多時間，而且每一個人都只是跟隨他的領導或者整個項目都將崩潰。這種「所有或所有」的方法確定是一種尷尬的跡象 - 應該始終能夠創建一個小概念證實。這我的不得不離開這個項目，沒有他，項目就成功了。

面試候選人

我在職業生涯中進行了許多面試，這裏有幾點我想分享一下：

1. 切中要害 - 若是你想聘請Angular專家，不要問他關於WPF或SQL的許多問題。

2. 例如，測試概念並非細節，例如，測試人們對關係數據庫概念的理解老是很好的，可是（除非你專門僱用SQL專家），你沒必要在MS SQL Server中測試他對臨時表的瞭解。

3. 有時候，記憶力好的人能夠經過心靈學習不少信息，而後用它來進行面試。這就是爲何讓人們真正進入並進行簡單的編碼考試很是重要。這種方式老是能夠看出該人是否擁有知識，或者在幾天以前他就簡單地擠滿了全部東西。

編寫，執行和測試要求

這個要求應該在開發者和訂購需求的人之間進行肯定 - 它多是最終用戶，也多是團隊中的建築師或其餘開發人員。因爲開發人員的屁股已經上線，開發人員應該常常仔細閱讀這個要求，確保在開始工做以前不要留下任何碎片。

要求（或Jiras）一般應該考慮到單一功能。該功能多是用戶功能，或者多是終端用戶永遠不會看到的功能，例如某些重構; 不管哪一種方式，大多數狀況下，一個要求應該有一個功能。

一旦建立了需求，就不該該添加新的功能請求。它應該做爲從請求者到質量保證的路線圖。若是事實證實開發人員實施了這項要求，可是要求是錯誤的或者不完整 - 這是請求者的錯，而且應該打開一個新的Jira來覆蓋剩餘的。可是，若是開發人員沒有知足這個要求 - 這是開發人員的錯，並且須要從新開放並從新分配給同一開發人員完成。

當涉及到UI開發時，也有一些小的，易於實現的需求（我稱之爲'UI煩惱'），儘管它們能夠接觸徹底不一樣的功能，但它們均可以使用到單個Jira。你能夠爲他們打開特殊的'尼特'吉拉，在'單一功能'的條件是沒有必要的。

​針對上面的技術我特地整理了一下，有不少技術不是靠幾句話能講清楚，因此乾脆找朋友錄製了一些視頻，不少問題其實答案很簡單，可是背後的思考和邏輯不簡單，要作到知其然還要知其因此然。若是想學習Java工程化、高性能及分佈式、深刻淺出。微服務、Spring，MyBatis，Netty源碼分析的朋友能夠加個人Java進階羣：744642380，羣裏有阿里大牛直播講解技術，以及Java大型互聯網技術的視頻免費分享給你們。

結論

在本文中，我以建築師和開發人員的長期經驗爲基礎，提出了啓動和執行多層項目的建議。

我相信遵循這些建議能夠大大下降項目成本的時間和金錢，並提升產品的價值。