昨天看到一篇關於「架構師」的文章，讀後非常有感觸。我個人比較認同作者的大部分觀點，故決定將原文進行翻譯，和國內的開發者一起分享。
當乙個資深的開發者變得更加資深時會發生什麼事情？他們經常會被提拔做去「架構師」。有時乙個架構師也不一定非要是開發者，如果他們能看到更大的藍圖。最終，總有乙個人掛著「架構師」的頭銜：他對要開發的系統和正在開發的系統做出架構上決策。在一些更大的公司，還有「架構師議會」，每個團隊指定的架構師們聚在一起決定著一些明智的事情。
但我認為專門設立「架構師」的職位是乙個糟糕的想法。架構師應該是建築行業的乙個職位，這是說的過去的，因為你不能在專案中期改變和調整架構。但是軟體架構是十分靈活的，不應該預先就嚴格地定義好。而且開發工作和架構設計是如此的緊密關聯，所以說某個人決定「什麼要做」和「什麼不要做」是不科學的。這會帶來各種各樣的問題，主要是因為架構師經常無法全面的考慮到具體的實現是怎麼樣。如果乙個架構師長時間不寫**，他們更加傾向於忽略「實現細節」，轉而僅僅考慮抽象設計。然而，抽象總是伴隨著遺漏，只考慮抽象而不考慮特定的實現這樣的解決方案很少行得通。
我的第乙個論點就是：在不知道詳細地編寫所有**地情況下，你無法在成為乙個優秀的架構師。大多數情況下都不是「簡單地編碼」。如果你已經成為架構師多年，同時也多年沒有寫過**了，那幾乎可以肯定你不是乙個優秀的架構師。
當然，你可能是乙個優秀的架構師。或許在你所在的那個特別的公司裡，有人坐在象牙塔中，指揮著碼農去整合這個實現那個，這可能說的過去。但即使是這種情況，也有更好的方法。
架構師應該是一種角色。每個資深的團隊成員都可以也應該扮演架構師的角色，不用每個團隊指定乙個人來當。實際上，最好有多個人來扮演架構師。在會議中討論架構設計和討**能設計類似，如果你是那個要實現所有事情的人，那麼你需要帶著明確的想法去參會。任何的過度設計（大部分架構師經常會犯這個錯誤）需要在你面前證明是合理的——「我是否願意去寫這些模板**，或者是否有一種更簡單優雅的實現方式」。
職位可以使「軟體工程師」，但角色可以是「敏捷大師」、」架構師」、」持續整合官」，等等。如果公司需要乙個「架構師議會」去決定系統間更巨集觀的整合，開發者可以提名某個人去參與這些會議，這個人有可能是對這些系統最了解的人。
我知道現在架構師在想什麼——有一些更加高層次的關注點開發要麼不太能理解要麼不應該為此被打擾。大錯特錯！如果你的開發不理解更高層次的架構規劃，那麼遲早你會遇到問題的。是的，因為他們要讓**適應你正在規劃的更大的藍圖，他們需要被打擾。
還有一方面於團隊成員的態度和動態的交流。如果某個不是特別優秀或者受人尊敬的開發被提公升為「架構師」，那麼可能破壞團隊的和諧。另一方面，某些人被提公升為「架構師」以後可能會過於自信，以至於他們會想當然的去做出設計決定，而不管那些反對他們的好的爭論點。
所以，理想的情況（這是我的第二個論點）是取消架構師的職位。確保你團隊中資深的成員能夠參與架構設計和決策，那樣他們可能會更有幹勁，他們也會對他們開發的成果有乙個更加清晰的規劃。最為重要的是，架構決策不能脫離日常的「現實」的開發環境，否則它們會不必要的複雜化。
出處：
-end-
雲計算是乙個概念而不是一種技術
雲計算做為當今的熱點問題，一直倍受企業界的 的雙重關注，然而什麼是雲計算，一直是困擾著人們的乙個重要問題，這個問題關係到如何才能在雲計算時代真正到來之際 如何才能分到一杯羹，是從中獲利的基礎，是步入其中的前提。雲計算實際上只是乙個概念而不是某種具體的技術，它主要是通過網路實現兩大功能，乙個是遠端計算...
站長，你不是技術員，而應該是乙個銷售員
網際網路的發展造就了站長行業的發展，有人說站長是個苦逼的行業，有人說站長也是一項賺錢的行業。至於誰是誰非不做討論，我們想要知道的是為什麼別人做 可以過得很好，為什麼別人的 可以運營的那麼成功 賺錢 正因為站長行業的發展，建站已經越來越簡單化，任何乙個朋友都可以一鍵式的建站了。而大多數的 並不能盈利，...
如何成為乙個架構師
突然看到這篇文章,值得反省,樂在其中,在接下來的發展中不被淘汰的都來看看，如何成為乙個架構師 先明確這裡所指的php工程師，是指主要以php進行web系統的開發，沒有使用其的語言工作過。工作經驗大概在3 4年，普通的web系統 百萬級訪問，千成級資料以內或業務邏輯不是特別複雜 開發起基本得心應手，沒...