似乎隔三差五就能看到一些關於架構師應不應該寫代碼的文章。我是屬於寫代碼派，因為我本身就喜歡寫代碼。但是，當工作職責發生變化之後，如何保持寫代碼和其它工作之間的平衡就成了問題。
從個體效率上來看，我自己親自寫代碼，和很多人相比沒有什麼絕對優勢，甚至有些人碼代碼的速度比我還快一些。
但作為架構師，參與寫代碼還是會有一些不大不小的收益。
一般來說合格的程序員對於明確分配的任務會完成的很好，但是大部分情況下 “架構”
這個詞意味著架構師並不會涉及太多細節，架構圖和代碼實現之間總還是有些距離，你無法保證所有人都會正確的理解你的設計，或者是程序員寫代碼時遇到障礙時會立刻想出足夠優雅的解決方案。
之前寫過一篇關於爛代碼的文章
，大部分爛代碼並不是架構師的設計問題，如果程序員沒能很好的理解設計或者是經驗不足，往往會做出一些非常匪夷所思的東西。比如我見過剛畢業的程序員為了防止模塊耦合而將耦合的代碼又拷貝了一份，或者為了
“優化性能” 而盡量把所有邏輯寫在一個函數裡。
如果不能及時發現並改正這些問題，那麼這些地方就會變成 “正確的錯誤代碼”，或者” 不是我寫的 “代碼，或者” 我靠我也看過那段代碼 “之類足以被掛上恥辱柱的玩意。這種問題算是架構師的責任嗎？作為一個視名聲如命的架構師，我認為是的。
在我看來，寫代碼的架構師更像是在做後勤保障的工作：在代碼中第一時間發現可能存在的問題，向其他人提出警告，或是給予其他人改進的意見，必要的時候或是給其他人演示一下正確的姿勢。
大部分情況下我作為架構師並不需要攬下 “核心模塊” 開發這種工作，畢竟我能調配的時間太零散了，效率難以保證，很多人在專注的情況下比我做的好很多，我只需要保持大局觀需要適度參與就可以了。
總的來說，架構師和程序員在某些方面上有點像產品經理和用戶的關系，大部分程序員並不會主動告訴你他們想要什麼、哪裡需要優化，甚至自己也不知道這些。想要做出好的產品，捷徑之一就是跟用戶做同樣的事情。
文檔來源微信：架構師應不應該寫代碼？
