1. 程式人生 > >軟體架構師應該知道的97件事之概括1-15

軟體架構師應該知道的97件事之概括1-15

架構師是一種神祕的職位,據說每個架構師都有密不可傳的方法,當然我們不信,更多的是隻可意會不可言傳。就是說了我們也不會懂,因為還每到“火候”。所能做的就是,當我們到這種火候的時候我們能想起來曾經有過架構師這麼說過,然後我們就可以更自信的向前大步走....

1、客戶需求重於個人簡歷

要想擁有漂亮的個人簡歷:我們常常向客戶推薦技術、手段,甚至方法論來解決問題,使用時髦的程式設計技巧和流行的正規化,有時候根本不是尋求解決問題的最佳方案。

積累一批滿意的客戶,選擇切合實際的技術解決他們的難題,讓他們樂於推薦你才是最好的履歷。

2、簡化根本複雜性,消除偶發複雜性

根本複雜性指的是與生俱來的、無法避免的困難。比如,協調全國的空中交通就是一個“天生的”複雜問題,必須實時跟蹤每架飛機的位置。

偶發複雜性:是人們解決根本複雜性的過程中衍生的。

架構師的責任在於解決問題的根本複雜性,同時避免引入偶發複雜性。

怎麼做?儘量選擇源自實際專案的框架,警惕那些象牙塔裡面的產品。

3、關鍵問題可能不是出在技術上

簡單的專案也會翻船,而且這不是個別情況。大多數專案是人完成的,人才是專案成敗與否的基礎。

如果團隊裡有人工作方式不正確,拖專案後腿怎麼辦?有一種非常古老但很完善的技術可以幫助你解決問題。它可能是人類歷史上最重要的技術創新,這就是對話。

有幾個簡單的對話技巧可以顯著改善對話效果:

不要把對話當成對抗。

不要帶著情緒與人溝通。

嘗試通過溝通設定共同的目標。

4、以溝通為中心,堅持簡明清晰的表達方式和開明的領導風格

溝通必須簡明清晰,沒有人願意閱讀冗長的架構決策文件,架構師言簡意賅的表達觀點是專案成功的必要條件。

架構師往往忽略了自己也是領導者。作為領導者我們必須獲得同伴的尊敬才能順利開展工作。所有的成員都希望有明確的溝通和開明的領導。只能這樣才能改善溝通效果,建立團結健康的工作環境。

5、架構決定效能

大家似乎理解,事實並未如此,有些架構師認為簡單的更換底層架構就足以解決應用的效能問題,他們很可能輕信了“經測試產品效能超出競爭對手25%”,比如從4ms到3ms,這1ms放在一個性能極低的架構裡幾乎可以忽略不計。

歸根結底,所有產品和架構必須遵循分散式計算和物理學的基本原理:執行應用和產品的計算機效能有限,通過物理連線和邏輯協議實現的通訊必然有延時。因此,應該承認架構才是影響應用效能和可伸縮性的決定因素。效能引數是無法簡單的通過更換軟體,或者“調優”底層軟體架構來改善的,我們必須在架構的設計和重新設計上投入更多的精力。

6、分析客戶需求背後的意義

顧客和終端使用者通常提出的所謂需求,只是他們心目中可行的解決方案,並不是問題唯一的解決途徑,當了解顧客的需求背後的意義,我們可以為顧客解決真正的問題並可能降低難度。

7、起立發言

許多架構師都是從技術崗位上成長起來的,他們擅長和機器打交道,然而架構師更需要與人打交道,無論勸說開發人員接受具體的設計模式,還是向管理層解釋購買中介軟體的利弊,溝通都是達成目標的核心技能。

有經驗的架構師會很重視推銷自己的想法也明白有效溝通的重要性,其中一個簡單又實用的技巧是在2人以上的場合發表意見時請“站起來”,起立發言非常重要尤其是當其他人坐著的時候。

當你站起來的時候無形中新增一種權威和自信,自然就控制住了場面,聽眾不會隨意打斷你的發言,這些都會讓你的發言效果大為改觀,你會發現站立可以更好的用雙手和肢體語言。在10人以上的場合,起立發言方便你與每位聽眾保持視線接觸。眼神交流、肢體語言等表達方式在溝通中的作用不可小覷。起立發言還可以讓你更好的控制語氣、語調、語速和嗓門,讓你的聲音傳的更遠。當你講到重點內容時,注意放慢語速。發聲技巧也能顯著改善溝通效果。

比溝通事半功倍,起立發言是最簡單、有效的方法。

8、故障終究會發生

硬體會出錯,於是我們增加冗餘資源來提升系統的可靠性,同時也增加了至少有一臺裝置出錯的概率。

軟體會出錯,增加額外的監控程式也會出錯。於是我們又為自動化增加監控,結果是更多的軟體,導致更高的故障率。類似的如:三裡島核電站洩漏事故

既然必然會出錯就需要事先設計好防範故障的模型,以應對威脅系統安全的意外情況。

9、我們常常忽略自己在談判

我們都面臨過削減預算的要求,如果資金運轉促襟見肘,技術方案只能委屈求全。

比如如下情景:

“我們真的需要這東西嗎?”專案投資人發難道。

儘管真的需要,我們通常也不能這麼回答,因為此時我們是在談判,此時我們需要認清自己的角色,不能把自己當成工程師,而且投資人明白他在和你談判,我們應該這樣回答"真的需要嗎"這類問題:

“單臺伺服器每天至少崩潰3次,沒有第二臺我們甚至無法跟董事會演示,事實上我們需要4臺伺服器,構成2組,這樣在需要時斷開一組而不必被迫關閉系統。即使有一臺出現意外,也不影響系統正常執行”

10、量化需求

速度快不能算作需求,響應靈敏和可擴充套件也不能算需求,因為我們無法客觀地判斷是否滿足了這樣的條件。

正確的描述需求應該像這樣:“必須在1500ms內響應使用者的輸入。在正常負載下,平均響應時間控制在750ms-1250ms之間。由於使用者無法識別500ms以內的響應,所以我們沒必要將響應時間降到這個範圍一下。”

11、一行程式碼比500行架構說明更有價值

架構說明書(specifications)很重要,因為它描述了構建系統的模式,但是靜下心來全面徹底地理解架構——即從巨集觀上把握元件之間的互動,又著眼於元件內部的程式碼細節——也很重要。

架構師往往容易被抽象的架構所吸引,沉迷於設計過程。事實上僅有架構說明書是遠遠不夠的。軟體專案的最終目標是建立生產體系,架構師必須時刻關注這個目標,牢記設計只是達到目標的手段,而不是目標。

如果親自開發,應該珍視自己花在寫程式碼上的時間,千萬別聽信這會分散架構師精力的說法。這樣既能拓展你的巨集觀視野,也能豐富你的微觀世界。

12、放之四海皆準的解決方案

架構師應該堅持培養和訓練“情景意識”——因為我們遇到的問題千差萬別,不存在放之四海皆準的解決方案。

“情景模式”:調查有經驗的架構師處理複雜問題的方式。有經驗的架構師和設計師的答案如出一轍:只須使用常識....【一個】比“常識”更貼切的說法是“情景意識”——在給定情景下對合理性的把握。架構師通過學習和實踐,不斷積累的案例和經驗,建立足夠的情景意識。他們通常需要十年的磨練,才能解決系統層次的問題。

13、提前關注效能問題

商業使用者的需求主要表現衛隊功能的要求。系統的非功能特性則由架構師負責,包括:效能表現、靈活性、持續正常工作時間、技術支援資源等。但是對非功能特性的初始測試往往被拖到開發週期的最後階段,有時還由開發團隊來操刀,這樣的錯誤屢見不鮮。

在專案週期的最後階段才關注效能問題,會導致我們錯失大量歷史資訊,這些資訊包含效能變化的細節。如果效能是架構設計的重要指標,就應該儘早展開效能測試。在採用敏捷方法開發的專案中,如果有2周為一個迭代週期,我認為效能測試的開始時間最遲不能晚於第三次迭代。

堅持技術測試是需要耐心和毅力的,無論是搭建合適的測試環境,採集適當的資料集,還是編寫必要的測試用例,都需要投入大量的時間。

14、架構設計要平衡兼顧多方需求

平衡兼顧各方的要求和專案的技術需求

CEO需要控制成本

運營部門要求軟體易於管理

二次開發人員要求軟體程式碼容易學習方便維護

業務部門:旅行合同義務、創造收益、樹立客戶口碑、控制成本,創造有價值的技術資產

技術部門:確保軟體的功能

15、草率提交任務是不負責任的行為

傍晚時候,團隊正在完成本次迭代的收尾工作,一切按部就班、有條不紊。只有約翰趕著赴約有些急躁,他倉促寫完自己的程式碼,編譯、檢入,然後匆匆離開。幾分鐘後紅燈亮起(許多采用敏捷開發方法的軟體公司(例如ThouthtWorks)在每個團隊成員的桌上放置一盞3色燈,用來表示當前的整合狀態,黃色正在整合,綠色整合成功,紅色整合失敗),構建失敗。約翰沒來得及執行自動測試就草率地提交了任務,連累大家無法繼續工作。正常的工作秩序全被打亂了。

這個時候架構師就該發揮作用了,營造一種團隊文化,以維護流程通暢為重,以浪費他人時間為恥。要做到這一點,務必在系統內實現完善的自動測試功能,糾正開發人員的行為。

沉下心來改變系統的生產效率,縮短流程避免各行其是,才能縮短開發時間。總之一定要杜絕一切草率提交任務的念頭。