幾乎在所有的軟件項目| 產品中，軟件架構師永遠都是冤大頭。
至少在我所經歷過，參與過或是聽說過的所有產品里，似乎沒有任何一個軟件架構是不被吐槽黑出翔的。現在想想，就在幾個月前我自己也在吐槽某產品的架構爛透了。 天知道哪根筋錯位居然因此挖了個坑自己跳了進去決定自己來做這個項目的架構，於是有了各種讓人哭笑不得的故事。
大概，“爛透了”本身就是國內任何一個軟件架構的宿命所在。只是曾幾何時像鴨子一樣伸長脖子看砍頭的我如今自己來到了這個斷頭台上，周圍的人們一如曾經的我，恨不得上來自己一刀把斷頭台上的人砍了，好搶在所有人前面吃到那個帶血的饅頭。
******以下純屬虛構，請勿對號入座***************
---------------------------------------- 邪惡的分割線 --------------------------------------------
故事一
“小A， 某某功能你幫忙實現以下吧，繼承一下xxxx接口，到調一下xx類的xxx方法...blabla（比較簡單的功能實現）..順便熟悉一下現在的架構。”
若干天后， pm召集項目組開會了解進度。
小A：“xxx目前架構下實現不了，架構耦合度太高了。”
架構師:“哪部分由困難？哪里不好弄？”
小A：“xxx類和xx類里面好多鎖， 完全不知道這些鎖是干嘛的 ，很容易死鎖，沒法維護的(ps:這兩個類和他要實現的功能毫無關系，只是簡單的線程池調度實現，共享資源有加鎖 )”
架構師:“暈，你看那倆類的具體實現干嘛，要用他們的時候只要調 xx方法就行了，你完全不需要關心實現，何況你壓根不該用那個， xxx.dll在干些什么你知道嗎?”
小A：“不知道，系統復雜而且混亂，我壓根看不懂。。”
......
接下來基本就是這樣的邏輯:
if( Relation(PM, Architect) > Relation(PM, A) && (count++) < PM.TrustRate)
PM.say(“回去再看看是不是你自己沒看明白”);
else
咔嚓，人血饅頭做成。
程序員的邏輯1： 如果某功能我做不出來，那一定是架構耦合度太高了。至於耦合度是啥意思，pm不知道， 因此他自然也不可能知道其實我也不大明白，管它呢，那么難做，耦合度肯定高。
程序員的邏輯2： 如果某模塊式干嘛的我沒看懂（那一大篇英文文檔有病才會去看），那一定是系統復雜性太高了。不然怎么可能連我都看不懂呢？
我i想說: 尼瑪，連哪個dll干嘛的都沒搞明白你就說耦合度高？？？？讓做個用戶權限驗證的邏輯跑去multithreading.dll 里面找完了抱怨有鎖，你寫不好多線程不意味着所有多線程都是會死鎖沒法維護的！
------------------------------------ 又是邪惡的分割線 ----------------------------------------
故事二：
某系統已經維護了2年有余，當時操刀設計的兩個人和本人私交不錯，據我所知兩人技術水平了得，至少比我強一個檔次。可惜兩人雙雙已經離職，因為公司薪資競爭力每況日下，導致這兩年招聘要求一降再降，一些優雅的老系統維護漸漸就成了問題。
某天和PM閑聊，談到上述系統。
PM:“(blabla一堆閑聊前文)， 所以軟件架構很重要， 像我們當時那個X系統，當年xx做的，問題很大，現在沒人看的懂，又要重新做過。。”
我:“有文檔留下來啊，怎么會沒人看得懂”
PM:“原來的系統設計太差了，沒法用, blablabla”
我也就沒再說什么。pm不是做技術的，系統設計太好或者太差當然不是他自己看出來的。至於是誰告訴他系統設計太差，要說現在團隊里會有人比當時的設計者技術強， 我絕對不信。 同樣是做技術的，隨便聊兩句就能大致知道對方幾斤幾兩，然而PM可能知道嗎？他當然更傾向於相信在職員工而不是已經離職的人。
結論：如果你不幸做了某系統架構設計然后離職走人，上帝知道你會不會哪天打噴嚏到窒息最后一命嗚呼。
----------------------------------最后一根邪惡的分割線 --------------------------------------
某天有人抱怨系統有一個模塊設計不好。那是事實，那個模塊可謂是當前系統最失敗的設計之一 （PS:厄，確實是我設計的，略爛..）。
於是某天開會：
我:"X模塊設計不大好，現在考慮把它重構下"
某資深程序員:"的確阿，你看XX和XX有耦合，xxxx不符合xxx最佳實踐。。blabla（以下省略1000字長篇大論）"
我(心里說"似乎可造之材，搞不定可以培養下看看"):"那你看看試試把它重構了唄"
資深程序員:(略慌張的) “那 ....那..我最近時間精力有限。。。blabla..”
最后的結論： 作為資深程序員，最優雅的方式就是盡可能地指出不好的地方，但絕對不要實際參與改進。 兵無常勢水無常形，在不確定是否會贏的情況下，絕對不要拔劍。
結論的結論：
在溝通能力變得越來越重要，大家都追求德智體全面發展，加上做技術長遠看沒前途的大背景下，
在越來越多的程序員“溝通能力” 遠比技術能力強悍的時代中，
作為向產品負責的PM,如果很不幸你不是技術出身，軟件架構就會徹底成為<羅生門>，每個人都說着不同的故事，誰也不知道誰說的才是真相。
而剩下的，只有交情，信任等等，這時候，請雙手合十祈禱專精技術的員工，在建立交情和信任方面要比其他人來的更強。