架構師應該是一種角色——而不是一個職位

昨天看到一篇關於「架構師」的文章，讀後非常有感觸。我個人比較認同作者的大部分觀點，故決定將原文進行翻譯，和國內的開發者一起分享。

當一個資深的開發者變得更加資深時會發生什麼事情？他們經常會被提拔做去「架構師」。有時一個架構師也不一定非要是開發者，如果他們能看到更大的藍圖。最終，總有一個人掛著「架構師」的頭銜：他對要開發的系統和正在開發的系統做出架構上決策。在一些更大的公司，還有「架構師議會」，每個團隊指定的架構師們聚在一起決定著一些明智的事情。

但我認為專門設立「架構師」的職位是一個糟糕的想法。架構師應該是建築行業的一個職位，這是說的過去的，因為你不能在項目中期改變和調整架構。但是軟體架構是十分靈活的，不應該預先就嚴格地定義好。而且開發工作和架構設計是如此的緊密關聯，所以說某個人決定「什麼要做」和「什麼不要做」是不科學的。這會帶來各種各樣的問題，主要是因為架構師經常無法全面的考慮到具體的實現是怎麼樣。如果一個架構師長時間不寫代碼，他們更加傾向於忽略「實現細節」，轉而僅僅考慮抽象設計。然而，抽象總是伴隨著遺漏，只考慮抽象而不考慮特定的實現這樣的解決方案很少行得通。

我的第一個論點就是：在不知道詳細地編寫所有代碼地情況下，你無法在成為一個優秀的架構師。大多數情況下都不是「簡單地編碼」。如果你已經成為架構師多年，同時也多年沒有寫過代碼了，那幾乎可以肯定你不是一個優秀的架構師。

當然，你可能是一個優秀的架構師。或許在你所在的那個特別的公司里，有人坐在象牙塔中，指揮著碼農去整合這個實現那個，這可能說的過去。但即使是這種情況，也有更好的方法。

架構師應該是一種角色。每個資深的團隊成員都可以也應該扮演架構師的角色，不用每個團隊指定一個人來當。實際上，最好有多個人來扮演架構師。在會議中討論架構設計和討論功能設計類似，如果你是那個要實現所有事情的人，那麼你需要帶著明確的想法去參會。任何的過度設計（大部分架構師經常會犯這個錯誤）需要在你面前證明是合理的——「我是否願意去寫這些模板代碼，或者是否有一種更簡單優雅的實現方式」。

職位可以使「軟體工程師」，但角色可以是「敏捷大師」、」架構師」、」持續集成官」，等等。如果公司需要一個「架構師議會」去決定系統間更宏觀的整合，開發者可以提名某個人去參與這些會議，這個人有可能是對這些系統最了解的人。

我知道現在架構師在想什麼——有一些更加高層次的關注點開發要麼不太能理解要麼不應該為此被打擾。大錯特錯！如果你的開發不理解更高層次的架構規劃，那麼遲早你會遇到問題的。是的，因為他們要讓代碼適應你正在規劃的更大的藍圖，他們需要被打擾。

還有一方面於團隊成員的態度和動態的交流。如果某個不是特別優秀或者受人尊敬的開發被提升為「架構師」，那麼可能破壞團隊的和諧。另一方面，某些人被提升為「架構師」以後可能會過於自信，以至於他們會想當然的去做出設計決定，而不管那些反對他們的好的爭論點。

所以，理想的情況（這是我的第二個論點）是取消架構師的職位。確保你團隊中資深的成員能夠參與架構設計和決策，那樣他們可能會更有幹勁，他們也會對他們開發的成果有一個更加清晰的規劃。最為重要的是，架構決策不能脫離日常的「現實」的開發環境，否則它們會不必要的複雜化。

學習Java的同學注意了！！！

學習過程中遇到什麼問題或者想獲取學習資源的話，歡迎加入Java學習交流群495273252，我們一起學Java！

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！