原標(biāo)題：架構(gòu)師不寫代碼，能行嗎？

從什么時(shí)候起，技術(shù)角色的提升就意味著脫離技術(shù)與交付？CTO 不寫代碼已經(jīng)引起諸多爭(zhēng)議了，架構(gòu)師也不寫代碼，能行嗎？

就目前看來這似乎沒什么問題。畢竟，寫代碼是開發(fā)人員的工作。架構(gòu)師就應(yīng)該在更重要的任務(wù)上忙碌。

但是，讓架構(gòu)師遠(yuǎn)離寫代碼會(huì)限制開發(fā)團(tuán)隊(duì)的潛力。當(dāng)需求和業(yè)務(wù)需要發(fā)生變化時(shí)，也可能導(dǎo)致架構(gòu)混亂。

所以對(duì)于業(yè)界的誤解，今天我想要為架構(gòu)師正名，接下來，就讓我們來看看為什么讓你的軟件架構(gòu)師參與寫代碼的工作是一件好事。不過，在此之前，我們首先來看看架構(gòu)師的日常工作。

對(duì)于架構(gòu)師是否需要編寫代碼一直有肯定或否定兩種觀點(diǎn)，其實(shí)這兩種觀點(diǎn)都有失偏頗。首先，我們看看支持架構(gòu)師編寫代碼的理由：

1.能避免實(shí)現(xiàn)細(xì)節(jié)的失敗。很多軟件架構(gòu)師由于思想和抽象思想本身的局限，比如抽象本身實(shí)際是對(duì)細(xì)節(jié)的無知和忽視，導(dǎo)致太多項(xiàng)目失敗在性能等細(xì)節(jié)，還有API的精致設(shè)計(jì)以及組件的相互交互。

當(dāng)然這些實(shí)現(xiàn)細(xì)節(jié)由代碼架構(gòu)師來編寫也不一定能避免，或者認(rèn)為只有代碼架構(gòu)師才能避免的觀點(diǎn)也是片面的。

2.責(zé)任，代碼架構(gòu)師能夠?qū)ψ约旱捻?xiàng)目負(fù)責(zé)任，但是負(fù)責(zé)任也不一定必須親自編碼，一個(gè)好的架構(gòu)師需要緊密與遞交團(tuán)隊(duì)結(jié)合在一起。

3.反饋，代碼開發(fā)是一個(gè)迭代過程，架構(gòu)師應(yīng)該隨同產(chǎn)品開發(fā)一直跟進(jìn)，當(dāng)然跟進(jìn)開發(fā)過程不代表親自參與編碼，不寫代碼也不意味著會(huì)缺乏反饋。

4.尊重，為了項(xiàng)目能夠成功，架構(gòu)師應(yīng)該被尊重，架構(gòu)師能夠?qū)懘a與每天寫代碼是兩回事，讓架構(gòu)師每天沉浸在代碼細(xì)節(jié)編寫中，反而是一種不尊重。

其他兩個(gè)支持架構(gòu)師必須編碼的理由是：開發(fā)人員相比代碼架構(gòu)師實(shí)現(xiàn)項(xiàng)目系統(tǒng)的細(xì)節(jié)可能要困難；其次，沒有架構(gòu)意識(shí)的開發(fā)人員會(huì)將更多問題帶入代碼。這兩個(gè)問題其實(shí)正是訓(xùn)練開發(fā)人員的機(jī)會(huì)，通過架構(gòu)師的引導(dǎo)能夠培養(yǎng)更多高級(jí)軟件工程師。

其實(shí)，架構(gòu)師編寫代碼也有很多缺點(diǎn)：

1.只見樹木不見森林，一個(gè)架構(gòu)師忙于編寫調(diào)試代碼會(huì)導(dǎo)致他沒有時(shí)間或精力及時(shí)發(fā)現(xiàn)開發(fā)演進(jìn)中的架構(gòu)致命問題。

2.對(duì)于一個(gè)好的架構(gòu)師，與其將時(shí)間花在編碼上，好像是發(fā)揮其價(jià)值，其實(shí)更大的價(jià)值是進(jìn)行代碼審查以及與項(xiàng)目有關(guān)的知識(shí)技術(shù)分享上。

3.上下文切換是非常昂貴的，架構(gòu)師一邊負(fù)責(zé)架構(gòu)設(shè)計(jì)的邏輯一致性，一邊如果還要跟著項(xiàng)目編碼幾天，這兩種上下文切換其實(shí)代價(jià)是昂貴的，比如某個(gè)人需要更改底層API代碼，將之前隱藏的細(xì)節(jié)暴露給外部調(diào)用者，架構(gòu)師會(huì)建議其在原來的API代碼上再封裝一層等等，這些都是為了維護(hù)系統(tǒng)的可維護(hù)性和演進(jìn)發(fā)展的邏輯一致性，不至于代碼系統(tǒng)隨著時(shí)間推移變得混亂和不可維護(hù)。也就是說，架構(gòu)師主要職責(zé)是對(duì)系統(tǒng)的架構(gòu)負(fù)責(zé)，架構(gòu)必須是可維護(hù)的，必須是可擴(kuò)展的，長(zhǎng)年累月地能保證做到這兩點(diǎn)是非常不容易的，其中大量工作是與莽撞開發(fā)人員交涉。所以，架構(gòu)師身兼數(shù)職導(dǎo)致上下文場(chǎng)景不同切換，幾項(xiàng)工作可能都做不好。

讓架構(gòu)師親自動(dòng)手編碼是一個(gè)短期思維，并不具有擴(kuò)展性，只有知識(shí)分享才能在長(zhǎng)期開發(fā)周期中具有可伸縮擴(kuò)展性。架構(gòu)師有時(shí)動(dòng)手解決了一些架構(gòu)問題，他必須向其他人講解分析問題，以及自己的解決方案的理由，這些都是知識(shí)經(jīng)驗(yàn)分享，這種文化會(huì)在開發(fā)人員之間傳播。一個(gè)好的架構(gòu)師會(huì)很快編碼解決問題，但是如果不將其知識(shí)分享，就只是技巧技能的炫耀而已，而且會(huì)導(dǎo)致開發(fā)人員想：你能你就干，進(jìn)而以后架構(gòu)師越來越多地親自動(dòng)手編碼；如果他花更多時(shí)間講解培訓(xùn)相關(guān)知識(shí)，幫助其他人更深入理解這項(xiàng)任務(wù)，那么以后越來越多這樣的任務(wù)就可以直接交給開發(fā)人員完成。

所以，很少或沒有編碼的架構(gòu)師就被強(qiáng)迫積極分享他們的經(jīng)驗(yàn)知識(shí)，從而能讓項(xiàng)目減少對(duì)架構(gòu)師的依賴，當(dāng)然，不少架構(gòu)師為了保護(hù)自己的工作總是通過塔布禁忌規(guī)定只有少數(shù)人才知道如何做這件事。

當(dāng)然，有一些支持架構(gòu)師不編碼的理由也是值得商榷的，比如：

1.架構(gòu)師不應(yīng)該關(guān)心實(shí)現(xiàn)細(xì)節(jié)。其實(shí)架構(gòu)師有責(zé)任提出最佳實(shí)踐等細(xì)節(jié)，包括開源組件推薦等等，提供實(shí)現(xiàn)細(xì)節(jié)方案比較和知識(shí)分享。

2.架構(gòu)師只要在這個(gè)項(xiàng)目寫一次代碼，然后就可以到其他項(xiàng)目了，這種觀點(diǎn)也會(huì)給項(xiàng)目帶來災(zāi)難，因?yàn)轫?xiàng)目質(zhì)量(維護(hù)性與擴(kuò)展性)就難以保證了。

3.架構(gòu)師是高級(jí)職務(wù)，可以陪伴客戶打高爾夫談業(yè)務(wù)需求，而開發(fā)人員都不知道怎么打高爾夫。這個(gè)觀點(diǎn)在中國(guó)還是有點(diǎn)效果的。

最后總結(jié)：知識(shí)共享型的架構(gòu)師不是不編碼，而是不會(huì)編制太多代碼，通常職責(zé)如下：

1.代碼審查code review ，引導(dǎo)如何編碼更好

2.結(jié)對(duì)編程。

3.考慮架構(gòu)的改變，如果API經(jīng)常被改變，或經(jīng)常向別人解釋這段代碼是如何工作的，這些就有必要對(duì)代碼架構(gòu)進(jìn)行變動(dòng)，讓其變得更易懂或更易于修改。

4.針對(duì)不斷涌現(xiàn)問題，經(jīng)常和隊(duì)員討論可能的解決方案。

來源網(wǎng)絡(luò)，侵權(quán)刪除返回搜狐，查看更多

責(zé)任編輯：

總結(jié)

以上是生活随笔為你收集整理的解决方案架构师我需要懂代码吗_架构师不写代码，能行吗？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。