架構師需要編寫程式碼嗎？

banq發表於2016-07-26
架構
本文是從知識分享架構師(Knowledge-Sharing Architect)與程式碼架構師(Coding Architect)相比較角度討論該問題。

對於架構師是否需要編寫程式碼一直有肯定或否定兩種觀點，其實這兩種觀點都有失偏頗。首先，我們看看支援架構師編寫程式碼的理由：
1.能避免實現細節的失敗。很多軟體架構師由於思想和抽象思想本身的侷限，比如抽象本身實際是對細節的無知和忽視，導致太多專案失敗在效能等細節，還有API的精緻設計以及元件的相互互動。

當然這些實現細節由程式碼架構師來編寫也不一定能避免，或者認為只有程式碼架構師才能避免的觀點也是片面的。

2.責任，程式碼架構師能夠對自己的專案負責任，但是負責任也不一定必須親自編碼，一個好的架構師需要緊密與遞交團隊結合在一起。

3.反饋，程式碼開發是一個迭代過程，架構師應該隨同產品開發一直跟進，當然跟進開發過程不代表親自參與編碼，不寫程式碼也不意味著會缺乏反饋。

4.尊重，為了專案能夠成功，架構師應該被尊重，架構師能夠寫程式碼與每天寫程式碼是兩回事，讓架構師每天沉浸在程式碼細節編寫中，反而是一種不尊重。

其他兩個支援架構師必須編碼的理由是：開發人員相比程式碼架構師實現專案系統的細節可能要困難；其次，沒有架構意識的開發人員會將更多問題帶入程式碼。這兩個問題其實正是訓練開發人員的機會，透過架構師的引導能夠培養更多高階軟體工程師。

其實，架構師編寫程式碼也有很多缺點：
1.只見樹木不見森林，一個架構師忙於編寫除錯程式碼會導致他沒有時間或精力及時發現開發演進中的架構致命問題。

2.對於一個好的架構師，與其將時間花在編碼上，好像是發揮其價值，其實更大的價值是進行程式碼審查以及與專案有關的知識技術分享上。

3.上下文切換是非常昂貴的，架構師一邊負責架構設計的邏輯一致性，一邊如果還要跟著專案編碼幾天，這兩種上下文切換其實代價是昂貴的，比如某個人需要更改底層API程式碼，將之前隱藏的細節暴露給外部呼叫者，架構師會建議其在原來的API程式碼上再封裝一層等等，這些都是為了維護系統的可維護性和演進發展的邏輯一致性，不至於程式碼系統隨著時間推移變得混亂和不可維護。也就是說，架構師主要職責是對系統的架構負責，架構必須是可維護的，必須是可擴充套件的，長年累月地能保證做到這兩點是非常不容易的，其中大量工作是與莽撞開發人員交涉。所以，架構師身兼數職導致上下文場景不同切換，幾項工作可能都做不好。


讓架構師親自動手編碼是一個短期思維，並不具有擴充套件性，只有知識分享才能在長期開發週期中具有可伸縮擴充套件性。架構師有時動手解決了一些架構問題，他必須向其他人講解分析問題，以及自己的解決方案的理由，這些都是知識經驗分享，這種文化會在開發人員之間傳播。一個好的架構師會很快編碼解決問題，但是如果不將其知識分享，就只是技巧技能的炫耀而已，而且會導致開發人員想：你能你就幹，進而以後架構師越來越多地親自動手編碼；如果他花更多時間講解培訓相關知識，幫助其他人更深入理解這項任務，那麼以後越來越多這樣的任務就可以直接交給開發人員完成。

所以，很少或沒有編碼的架構師就被強迫積極分享他們的經驗知識，從而能讓專案減少對架構師的依賴，當然，不少架構師為了保護自己的工作總是透過塔布禁忌規定只有少數人才知道如何做這件事。

當然，有一些支援架構師不編碼的理由也是值得商榷的，比如：
1.架構師不應該關心實現細節。其實架構師有責任提出最佳實踐等細節，包括開源元件推薦等等，提供實現細節方案比較和知識分享。

2.架構師只要在這個專案寫一次程式碼，然後就可以到其他專案了，這種觀點也會給專案帶來災難，因為專案質量（維護性與擴充套件性）就難以保證了。

3.架構師是高階職務，可以陪伴客戶打高爾夫談業務需求，而開發人員都不知道怎麼打高爾夫。這個觀點在中國還是有點效果的。

最後總結：知識共享型的架構師不是不編碼，而是不會編制太多程式碼，通常職責如下：
1.程式碼審查code review ，引導如何編碼更好

2.結對程式設計。

3.考慮架構的改變，如果API經常被改變，或經常向別人解釋這段程式碼是如何工作的，這些就有必要對程式碼架構進行變動，讓其變得更易懂或更易於修改。

4.針對不斷湧現問題，經常和隊員討論可能的解決方案。

詳細見原文：

Knowledge-Sharing Architects As An Alternative to

[該貼被banq於2016-07-26 18:06修改過]

相關文章