做架構設計幾年了，發現這幾年來，做最多的不是去研究學習怎樣做，而是去說服人家用這個架構。其實，有時候很討厭聽到下面這句話：

為什麼我們要這樣做？

說真的，這個問題我聽了很多次，通常會發生在以下幾種狀況的時候

• 老闆說要做架構設計：
  有些主管，因為時程趕或者是因為什麼不知名的原因，認為有架構就是好事，所以希望能夠在自己的專案或系統中導入架構，除了或許會有莫名的虛榮心以外，當然真的相信架構設計能帶來一些好處的也不在少數。但是通常上行不下效～
• 自己一頭熱：
  做設計的人，往往有時候看到一些技術文章，或者是使用一些 open source 的時候，發現別人這樣用相當好，所以自己一頭熱的想使用它，沒有詳細的去瞭解它的來龍去脈，以及當時這樣用的前因後果，這種狀況在初學者身上尤其明顯，我當年就常常這樣
• 有人系統做爛了，需要收尾： 救火隊的工程師，大概最有感覺，因為前人種的樹根基不穩，或者是遇到臭氣燻天的程式碼，發現原本的寫作方式已經無法在下去了，期望用新的方式來達到目的，順便重新整理一下程式碼
• 時程來不及：
  往往專案趕、人力少的時候，希望用一些方式來達到專案時程。架構設計有時候也會是其中的一個選項，因為好的架構其實是可以專注的在 Business Logic 上面，而不是不斷的重複 Copy-Paste ~
  遇到這種問題的時候，如果不是說別人是因為虛心求教來問的問題，我自己心裡面，常常都會有一個字先冒出來：『靠』，心情不好的時候就是另外一個 f word～

所以往往做架構設計這種事情，花最多時間的不是在設計，而是在說服別人要去用。包含為什麼要這樣用，以及要怎樣去用它

可惜常常事不盡人意，我遇過做架構還會把系統搞爛的可能性，也有七八成～

1. 你不夠力或者主事者不夠力的時候
2. 你沒辦法後續繼續主導的時候
3. 大家只想把一套設計用到爛的時候
4. 你人緣不好的時候
5. 你的想法，沒辦法落實的時候

在《人月神話》這本書有一句蠻經典的話就是：『沒有銀彈』，所有的架構設計，都會因為時間、人員能力、專案狀況而因地制宜，不可能用一套打死所有的狀況。就像是 GoF 設計模式 中的 工廠模式，往往根據不同的狀況，會有不同的實作方式，如採用 Reflection, IoC 等都是很好的實作，而工廠模式並不會告訴你，你應該要怎樣去實作，而是告訴你，你可能的概念方向是什麼。

做到後期，往往發現做架構其實就是在做人，你有好的思考能力、設計能力，但是如果你不能說服人家心甘情願的來使用，那就跟 0 元的股票是一樣的，擦屁股都嫌硬～

願不願意使用絕對是重點。如果飽了，或者是食慾不振的時候，不管多美味的食物，都不太能挑起食慾。同理，架構設計用或不用，絕對是初期一定要討論的關鍵點，有人願意用，並且會照著你的方式用，這個架構才是有用的牛刀
如果你不是主導者，或者你沒有有力的主導者幫你忙，不做有時候比硬要做來的好。你要知道，生命會自己找到出路的～～～沒有你，生活一樣悲慘要過

你做出來的架構，後續要交給其他人去使用，但是你無法抽出時間或你無法參與調整的時候，往往到最後，你會發現人的創意是無限的，事情往往都會超出你的意料之外

通常，會想要用架構設計的人少之又少，如果能夠不學新東西就可以把事情做完，這樣的人不在少數，所以，學一套作法，已經會讓很多人為之卻步了，所以如果能夠用一套作法打死所有的系統，那是最好。這種架構，你最好不要署名，不然你會發現，越到後期，你背後的怨氣會越來越重，因為架構已經是一輛重的拖不動的牛車了

不要沒學會爬就想要飛，市面上能找到架構設計的書百百種，但是不會有人告訴你你的專案或系統應該要用哪種架構，但是不要天真的以為把很知名的設計模式用上去就對了，如果你不是很有經驗或者是你真的理解了那些設計模式背後的意義，你還是乖乖用 Copy-Paste 好了，畢竟做對才是最重要的

對專案參與者的個性跟能力要熟悉。如果你不知道你的同事，到底是不是能接受這樣的作法，那真的你要花費相當多的精神去瞭解以及預防萬一，避免後期會發生你沒辦法收尾的狀況

做人真的比做架構重要。你如果是個討人厭的傢伙，不管你的能力再好，架構再漂亮，都不會有人願意去用的～

最近因為換了新東家，對公司生態人員都還不甚熟悉，在默契還不足的情況下，常常會發生我要花比較長的時間去說服別人使用一些他們以前沒用過的東西，所以最近的感觸特別多～

找了找最近的文章，發現去年才發過類似的文章：愈來愈不喜歡講架構了，因為講的人痛苦，聽的人也痛苦，我想我現在的心情，大概有經過沈澱，已經慢慢的可以收斂了