最近，這個話題在群里接連爆發，這次是由於群里一個朋友所在公司的架構師只給他了個PPT，他期望架構師能給一個DEMO，然后問大家PPT能不能算DEMO引起的，且不說能不能算，不過如果能用PPT表達清楚，我倒是覺得也沒什么。
爭論的核心自然是架構師要不要寫代碼，我倒是覺得這事和架構師本身沒什么關系，多數是看公司規定，總之圍繞着這個問題產生了很多爭論以及延展：
1.架構師需不需要會寫代碼：
認為必須會寫代碼的自然舉了很多見過的架構師寫DEMO之類的案例；認為不需要的基本是說架構師是搞架構的不一定需要會寫代碼，只要一個能實現業務的模型就可以了。
首先，這得排除業務架構，咱只說技術架構，然后是偽代碼算不算代碼。。。？，我是站在架構師不一定要會寫實現的代碼這一邊上的，因為他有時候只需要關心能否實現，怎么能更好的實現，而具體到怎么用某種語言實現倒並不那么重要了，當然，寫DEMO最好，因為程序員接受的快，理解上的壓力也是壓力。
2.架構師要不要懂技術：
這個我覺得實在沒啥好爭論的，架構師最終是要制定一個技術架構來實現業務的，只懂業務的哪種叫領域專家或者信息專家，做的應該是業務顧問之類的職位；至於有些朋友說的，某些官僚機構的架構師只需要會忽悠就可以了之類的事。。。，似乎有些微妙的不太好反駁。。。
3.架構師要不要關心具體技術：
怎么說呢，比如我們公司有個職位叫首席科學家，咱對這個職位不太了解，這類高大上的職位是不是架構師。。。；至於負責落地的。。。要選型總需要懂吧，不懂該怎么選呢？
4.如果選用了某種技術，架構師是不是一定要用過：
我是站在不是的一邊的，之前聽過一個微軟的架構師說，微軟認為一個架構師至少要十年工作經驗，這里就是工作經驗的作用了，憑經驗去分析這項技術合適不合適，說明理由就足夠了。
5.架構師是不是只要憑想象就夠了：
如果真有這樣憑想象就能解決問題的，那一定是非常大的牛，一般架構設計是要說明用什么不用什么，為什么用這個而不用那個，道理是要說清楚的，只給出個怎么做，這種其實就不是完整的架構設計。
6.架構師要不要會忽悠：
必須會啊，你沒有感染力，表達不清楚你的設計，人家就是想用也得用明白啊，而且程序員多數都是比較倔的，你不給他說服了，他才不會相信你的設計呢，不過會忽悠也是要有東西可忽悠的，什么都沒有純靠忽悠的，不能否定說一定沒有，但那肯定不是真正意義上的架構師。
其他還有些諸如項目經理要不要懂技術的爭論就不說了。
說一個大師級人物經歷過的真實項目，當然或許會有片面的地方，但我覺得很有代表性：（摘至 《DDD》）
我曾經在一個項目中負責協調不同的應用程序開發團隊，幫助開發可以驅動程序設計的領域模型。當管理層不允許寫代碼或與程序員討論細節問題。
開始還算順利，我們建立了個不錯的核心模型。但該模型卻沒排上用場，原因有兩個：
一，模型的一些意圖沒有向開發人員說清楚。模型整體效果受細節影響很大，這些細節並不總能在UML圖或討論中遇到。如果我能直接與開發人員一同工作，提供一些參考代碼和近距離技術支持，那么他們也許能理解模型中的抽象概念並開發。
二，模型與程序實現及技術互相影響，而我無法直接獲得這種反饋。例如，程序實現過程中發現模型的某部分在我們的技術平台上工作效率極低，但是經過幾個月我才一點一點獲得了關於這個問題的全部信息。也許較少的改動就能解決，但幾個月過去了，該不該已經不重要了。因為程序員自行編寫了可以運行的軟件---完全脫離了模型的設計。他們再也不願意冒險任由呆在象牙塔里的架構師擺布了。
大師的案例結束。
從案例中，能很清楚的看出來架構師寫不寫DEMO的好處，不過這里還是要分清楚，偽代碼算不算代碼，當然，即使是算代碼，案例中也沒有說一定要寫，有能解決問題的近距離技術支持就好了，只給個設計就再也不管實際是一種不負責任的行為，而且與案例類似的情況非常普遍，我自己也遇到過幾次這種情況。
設計無處不在，而且開發人員可能意識不到某些細節的改變會造成對模型的改變，我覺得因為需求的不穩定沒有什么需要架構師設計的架構能一次成型沒有理解壓力並且完全不需要調整，架構師寫不寫代碼不重要，重要的是能不能及時對架構的實現做支撐，幫助程序員理解和實現軟件。