為什麼許多專案的技術方案高、大、上，具體實現卻種種問題，**慘不忍睹？
許多架構師自身並沒有長時間的深入程式設計工作的經歷，在技術上的沉澱不足，導致對於軟體工程的理解、目標沒有清晰的認識。在做架構設計時，非常容易泛泛而談，並且給出的方案，太過高屋建瓴，缺乏對具體實現的理解和把握。許多架構設計方案，僅僅停留在ppt上，具體的落實完全依靠一線開發人員。
在技術選型階段，較好的團隊第一件要做的事情，通常並不是侷限在技術本身，而是深入的理解業務，搞清楚自己要做的到底是什麼，並且明確的給出期望的技術指標。
在此基礎之上，團隊會開展多次頭腦風暴，共同**業務流程中可能會涉及的技術細節，以及可選的方案並制定客戶認可的技術指標，這一點相當重要，在專案中不能單純的追求高技術指標，而是權衡時間成本，人力成本，以及專案經費，制定合理的技術指標。
在這一階段，許多架構師在技術的選型上，往往更傾向使用自己並不熟悉的，甚至完全沒有用過的技術，藉此機會提高自己，充實自己的簡歷。他們可能會選擇更新，更激進的方案，不管專案是不是真的需要；也不太懂得權衡技術與成本，不願意選擇看上去好像落後一些但更穩定，更可靠，綜合成本更低的技術，片面追求高大上，到了實施階段，就非常容易出現種種不可控的技術因素影響專案的進度及品質。
這一點幾乎在所有的專案中都存在，架構師在設計好方案或搭建好開發框架之後，團隊的開發工作與進度管控完全由專案經理控制，架構師不參與團隊管理，大部分時間埋頭寫文件或自己研究技術，這種情況的專案，幾乎必然會出現許多技術上的問題並影響專案進度及品質；很多專案的方案非常漂亮，但是具體實現和**編寫卻慘不忍睹，就是架構師失職的重要體現。
架構師除了前期技術選型及框架搭建，最重要的工作，以及架構師這一職位的根本意義，我認為在於對整個團隊的傳、幫、帶。
架構師要能夠放低姿態，對整個團隊進行必要的技術培訓，對**實現的質量擔負第一責任，必要時對開發人員進行手把手的幫扶與指導，關於這一點其實沒有什麼技巧與方法好總結，只能以我自己的經驗來說，過去我帶過乙個全部由工作經驗一年以下的小朋友組成的團隊，雖然他們的經驗和能力有所欠缺，但是好在都很好學，在專案的前兩個月中，我每天要花大量的時間用筆、用紙教他們具體怎麼分析怎麼實現，然後再去review他們的**，剛開始的時候所謂的review，基本是兩個人做在一起，看著我重寫，這種方式他們進步的非常快，慢慢的在review的過程中只需要我少少改一部分內容。不用乙個月，整個團隊的編碼風格、**品質就已經高度一致（注意我說的是高度一致，不是高水平，但這就夠了）。
與上一點所談的問題相輔相成，大多數專案的開發階段專案經理是主要話事人，架構師不參與團隊管理。而理想的情況應該是兩個人協同共管、架構師做為司令員，主管開發品質，技術建設，專案經理做為政委，主管專案方向、進度、人員問題及部門協調、客戶溝通。
專案經理要有一定的包容心，能夠容納乙個架構師與己分權，要給予架構師一定的人事權利，甚至是團隊人員績效考評的第一考評人，沒有任何權利的管理工作是很難落到實處的。
關於這一點，大概需要一點緣分。
為什麼你總成為不了架構師？
為什麼你總成為不了架構師？背景 今天接到乙個哥們兒的 說，很鬱悶，想和我聊聊。我問，有啥鬱悶的事情啊，說來聽聽。他說，最近很鬱悶，我本來今年的計畫是成為乙個架構師，但是，無論如何努力，都不知道為什麼，感覺希望很渺茫.這哥們兒其實是乙個很努力的傢伙，曾經是我team裡技術最好的程式設計師，對乙個技術不...
為什麼你總成為不了架構師？
背景 今天接到乙個哥們兒的 說，很鬱悶，想和我聊聊。我問，有啥鬱悶的事情啊，說來聽聽。他說，最近很鬱悶，我本來今年的計畫是成為乙個架構師，但是，無論如何努力，都不知道為什麼，感覺希望很渺茫.這哥們兒其實是乙個很努力的傢伙，曾經是我team裡技術最好的程式設計師，對乙個技術不鑽明白不罷休的那種程式設計...
為什麼我總成為不了架構師
2013 5 19 12 13 閱讀 12 以下是我這幾年的反覆思考得來的一些謬論。讓大家見笑了。雖然好多摘取別人的成果。但是對於讀者的你們也就微微一笑吧！一 什麼是架構師?其實架構師的概念並不是從程式開發專業一誕生就有的職位概念，架構師 software architect 僅僅是最近幾年提出來的...