在開發(fā)中，編碼我們有分層架構(gòu)、設(shè)計(jì)模式做為套路來(lái)高效開發(fā)，但你也知道編碼不是開發(fā)的全部，一個(gè)完全的開發(fā)流程用面向?qū)ο笏枷雭?lái)概括，它分為OOA(面向?qū)ο蠓治?、OOD(面向?qū)ο笤O(shè)計(jì))、OOP(面向?qū)ο缶幊?。一個(gè)好的代碼結(jié)構(gòu)是需要需求分析，架構(gòu)設(shè)計(jì)做為輔助的，Stay嘗試向你描述一個(gè)理想高效的工作流程，有了這個(gè)套路，不僅能讓你縮短編碼時(shí)間，還能得到團(tuán)隊(duì)的認(rèn)可。

關(guān)于高效開發(fā)，大多數(shù)人的***反應(yīng)就是成熟的分層架構(gòu)、設(shè)計(jì)模式以及第三方lib。這些給了我們?cè)O(shè)計(jì)準(zhǔn)則還有便利的工具更快的去做需求實(shí)現(xiàn)。

高效開發(fā)還有另外一層含義，關(guān)于一個(gè)團(tuán)隊(duì)他要如何去提升團(tuán)隊(duì)的整體開發(fā)效率、縮短開發(fā)周期，能夠一步一步去更快速的產(chǎn)品迭代，在這個(gè)過(guò)程中你要做好需求分析，架構(gòu)上的設(shè)計(jì)。

今天的主題是撇開技術(shù)和大家聊聊高效開發(fā)的一些套路與實(shí)踐。

如何提升個(gè)人開發(fā)效率

如何來(lái)提升開發(fā)效率?我們先來(lái)粗暴的對(duì)比一下，同樣一個(gè)需求，不同的角色會(huì)如何來(lái)著手實(shí)現(xiàn)，然后我們?cè)賮?lái)看差距在哪里?

這個(gè)圖我想大家應(yīng)該都能看懂。

一個(gè)需求如何被處理，從初級(jí)開發(fā)工程師到中級(jí)再到高級(jí)、架構(gòu)師他們處理的方式流程是不一樣的。

例如你是一個(gè)新人，剛到了一家公司，被委派了一個(gè)任務(wù)，可能直接就去搜索了。因?yàn)榉峙浣o你的任務(wù)是拆分出來(lái)一個(gè)比較具體、比較小的功能，所以不需要去做什么架構(gòu)上的分析，只需要去做具體的實(shí)現(xiàn)。對(duì)于一個(gè)實(shí)現(xiàn)者而言，他只需要去搜索或者去找以前自己寫過(guò)代碼，最笨的方式才是自己去手寫。不過(guò)呢，不是所有實(shí)現(xiàn)都是可以面向Google編程的，單純的復(fù)制粘貼會(huì)讓你的代碼增加隱患，而你也知道，這是相當(dāng)危險(xiǎn)的，而且也不會(huì)有技術(shù)沉淀。

當(dāng)你工作一兩年，對(duì)一些工作流程比較熟悉后，再拿到一個(gè)任務(wù)就會(huì)想應(yīng)該如何去解決這個(gè)問(wèn)題，當(dāng)然這個(gè)時(shí)候你的任務(wù)也從小功能變成了一個(gè)模塊。這個(gè)業(yè)務(wù)是什么樣子的，應(yīng)該如何去做分析，拆分成一個(gè)個(gè)小功能，然后有針對(duì)性的去搜索，雖然搜來(lái)的不能完全滿足你的需求，但你只是要個(gè)解題思路，借鑒下稍微做下適配就可以實(shí)現(xiàn)啦。

而對(duì)于高級(jí)開發(fā)工程師或架構(gòu)師來(lái)說(shuō)，拿到的任務(wù)就是一個(gè)比較龐大的、成體系的一個(gè)模塊或者一個(gè)系統(tǒng)。所以要考慮的事情要比初級(jí)或中級(jí)要多的多，這時(shí)候就得做需求分析，架構(gòu)上的設(shè)計(jì)，并且在設(shè)計(jì)的時(shí)候，還得去考慮應(yīng)該如何解耦，如何分離高層抽象和低層實(shí)現(xiàn)，因?yàn)榫唧w的實(shí)現(xiàn)是要拆分出來(lái)交給team中其他人去做的。

不同的角色面對(duì)同一個(gè)任務(wù)時(shí)，他們的關(guān)注點(diǎn)是不一樣的，也就使得工作方式不那么一樣。

初級(jí)和高級(jí)的差距在哪里?

既然我們已經(jīng)清楚了一個(gè)需求不同的人來(lái)實(shí)現(xiàn)它是不一樣的，那么不一樣到底在哪里，我們要挖掘那個(gè)具體的因素，這樣才能知道應(yīng)該如何做調(diào)整。

現(xiàn)在我們的問(wèn)題就是找出初級(jí)與高級(jí)的差距到底在哪里，少了哪些環(huán)節(jié)?

Stay先把視角拉高一點(diǎn)，我們來(lái)看看面向?qū)ο?Object-Oriented)，你可以把OO分為，OOA、OOD、OOP，也就是面向?qū)ο蟮姆治?Analysis)，面向?qū)ο蟮脑O(shè)計(jì)(Design)，以及面向?qū)ο缶幊?Programming)

那初級(jí)與高級(jí)的差距到底在哪里呢?就差在這三部上。

高級(jí)開發(fā)工程師他會(huì)有一個(gè)具體的步驟：

• 通過(guò)OOA來(lái)分析業(yè)務(wù)流程輸出模型
• 基于模型再做面向?qū)ο蟮脑O(shè)計(jì)OOD，借助UML來(lái)描述整體的一個(gè)業(yè)務(wù)需求的流程
• 以O(shè)OD歸納的用例圖、時(shí)序圖、類圖做為藍(lán)圖來(lái)指導(dǎo)OOP
• 設(shè)計(jì)高層抽象，以偽代碼的方式串聯(lián)起整個(gè)業(yè)務(wù)流程
• 拆分出一些獨(dú)立任務(wù)交給其他人實(shí)現(xiàn)

在面向?qū)ο缶幊痰倪^(guò)程中，還可以套用經(jīng)典的設(shè)計(jì)模式、設(shè)計(jì)原則來(lái)提升系統(tǒng)的穩(wěn)定性，讓代碼變得可測(cè)試，可擴(kuò)展。

對(duì)比下初中級(jí)呢，他們的關(guān)注點(diǎn)更多的放在OOP上，在具體代碼實(shí)現(xiàn)上。這樣就不太能全觀整體業(yè)務(wù)的流轉(zhuǎn)和邊界，無(wú)法預(yù)見(jiàn)需求未來(lái)可能發(fā)生的變化，僅僅做些重復(fù)勞動(dòng)力對(duì)提升開發(fā)效率是沒(méi)有任何幫助的。

跳出低層實(shí)現(xiàn)這口井

但是啊，讓初中級(jí)去像高級(jí)那樣去做OOA、OOD也不現(xiàn)實(shí)啊，如果對(duì)業(yè)務(wù)不是很熟悉，一些流程上想得不夠清楚，或者沒(méi)有考慮如何去提升用戶體驗(yàn)，沒(méi)有站在產(chǎn)品角度考慮問(wèn)題，那么設(shè)計(jì)出來(lái)的架構(gòu)可能會(huì)比較死板，同時(shí)也漏洞百出。

這是不是很矛盾?沒(méi)有經(jīng)驗(yàn)沉淀，就無(wú)法像高級(jí)工程師那樣思考，做不到那樣就只能做低層實(shí)現(xiàn)，這樣沉淀的太慢了，就像死循環(huán)啊，那么我們?cè)撊绾蝏reak出這個(gè)loop呢?

那就先從更好的做OOP開始，其實(shí)想把一段代碼寫好，還是有點(diǎn)困難的，關(guān)鍵在于你想寫出來(lái)的代碼能打多少分，及格分是60分，它剛好處于可以跑的狀態(tài)，偶爾會(huì)出點(diǎn)小bug;100分就是通過(guò)設(shè)計(jì)模式設(shè)計(jì)原則寫出的良好代碼，它能很好的去做測(cè)試、做擴(kuò)展，那它的穩(wěn)定性也很強(qiáng)。

如何才能得高分?有一句古話說(shuō)的很好，讀書破萬(wàn)卷，下筆如有神，你做的準(zhǔn)備工作越多，底蘊(yùn)越足，寫代碼就會(huì)越順暢。

首先***個(gè)是你要考慮的是，這個(gè)產(chǎn)品提出的需求有沒(méi)有得到你的認(rèn)可，你覺(jué)得什么的方式來(lái)實(shí)現(xiàn)會(huì)使得效益***化。你可以給產(chǎn)品提些建議或者改進(jìn)，因?yàn)槟阆胱鲆粋€(gè)產(chǎn)品把它做好，你必須要參與進(jìn)去，即使你做的是比較小的需求，功能，模塊。

當(dāng)你看到感興趣或者有挑戰(zhàn)的任務(wù)，得自己去爭(zhēng)取這一塊的整體的設(shè)計(jì)和實(shí)現(xiàn)，不要被動(dòng)的去接受一個(gè)任務(wù)。因?yàn)榻邮諄?lái)的任務(wù)都是別人咀嚼好的，給你定好了條條框框，你只用往里面填實(shí)現(xiàn)就可以的，那些都是沒(méi)有技術(shù)含量的。

同時(shí)也不要急著去表達(dá)這個(gè)做不了，那個(gè)做不了，安卓做這個(gè)很難實(shí)現(xiàn)的等等。不要去逃避責(zé)任，至少要先做一些真實(shí)的調(diào)研和嘗試，或者選取一些可變通的、折中的解決方案，給對(duì)方做選擇題，而不是直接拒絕。

在確定了技術(shù)選型之后，那么接下來(lái)就是哪些人來(lái)領(lǐng)哪些任務(wù)。領(lǐng)任務(wù)的時(shí)候，大家不要總是去領(lǐng)那些自己擅長(zhǎng)的，每個(gè)人都要變得多元化，不僅僅是只會(huì)一門手藝(以后只會(huì)安卓也不行了)擅長(zhǎng)做UI的要去嘗試處理復(fù)雜業(yè)務(wù)、能處理復(fù)雜業(yè)務(wù)的也要想想如何處理一些動(dòng)畫自定義UI。

Stay在做代碼實(shí)現(xiàn)的時(shí)候，比較偏向于先實(shí)現(xiàn)業(yè)務(wù)，再去考慮UI上的實(shí)現(xiàn)。因?yàn)橛脩趔w驗(yàn)是一個(gè)沒(méi)完沒(méi)了的事，你可以把它設(shè)計(jì)得很好花哨也可以把它設(shè)計(jì)得很簡(jiǎn)單，這鍋得產(chǎn)品經(jīng)理去背。而對(duì)于業(yè)務(wù)來(lái)說(shuō)，改動(dòng)就不會(huì)那么頻繁了，業(yè)務(wù)梳理清楚了，還愁不能響應(yīng)UI的action嘛，并且還有另外一個(gè)好處就是業(yè)務(wù)是testable的，不需要View層也可以測(cè)試。假如你上手就畫UI，十有八九你就把UI和業(yè)務(wù)耦合在一起，連剝離復(fù)用都很難做到，更別提寫測(cè)試用例啦。

寫代碼不可能一天寫滿八小時(shí)，也不可能說(shuō)一天就能把整體的業(yè)務(wù)全部寫完。如何可持續(xù)地做開發(fā)，最最重要的是，得有一個(gè)藍(lán)圖、一個(gè)清晰的高層抽象結(jié)構(gòu)，有了高層定義再一個(gè)一個(gè)往里面填具體實(shí)現(xiàn)就可以了。(可以參考下毛胚房裝修的全過(guò)程)

如果實(shí)在是總結(jié)不出適合自己的套路，那就用‘書讀百遍其義自現(xiàn)’這一招好了，但讀是遠(yuǎn)遠(yuǎn)不夠的，還得寫代碼，寫完了還要想如何去改良。

重新理解開發(fā)流程

剛才Stay給大家描述的是一種抽象的實(shí)施方式。接下來(lái)給大家做個(gè)示范：

高效開發(fā)Stay覺(jué)得應(yīng)該分為，OOA、OOD、OOP，跟我們剛才講的那個(gè)是一樣的。先得有需求分析，再做流程設(shè)計(jì)，***才是代碼實(shí)現(xiàn)。

本想寫個(gè)完整的案例，奈何精力有限，后續(xù)有時(shí)間再補(bǔ)上：)

開發(fā)環(huán)節(jié)中的角色扮演

從OOA、OOD再到高層抽象架構(gòu)和低層實(shí)現(xiàn)，不同角色的職責(zé)是不一樣的。請(qǐng)看圖說(shuō)話：

很多工作兩三年的同學(xué)都會(huì)焦慮， ‘焦慮的是技術(shù)不能走的長(zhǎng)久，30歲以后就走管理吧’ 。有這樣的焦慮不是什么錯(cuò)，錯(cuò)的可能是你對(duì)管理沒(méi)有一個(gè)非常明確的概念。你知道如何做一個(gè)合格的管理嗎?他的職責(zé)是什么?他比起其他角色，突出在哪些能力?

就這一點(diǎn)，Stay想分享點(diǎn)自己的觀點(diǎn)(僅局限于技術(shù)管理層面)：

剛才Stay一直在強(qiáng)調(diào)OOA、OOD、OOP，是因?yàn)檎驹谝粋€(gè)管理的層面，想要產(chǎn)品穩(wěn)步迭代，需要讓每個(gè)環(huán)節(jié)變得可控。

• 想象下，如果需求分析不對(duì)，大量的業(yè)務(wù)代碼要重寫，這是潛在風(fēng)險(xiǎn)。
• 想象下，如果業(yè)務(wù)設(shè)計(jì)不夠明確，沒(méi)有提前定好規(guī)則與約束，大量的代碼都會(huì)是一次性的，也就導(dǎo)致了冗余和低效，這是技術(shù)債務(wù)，遲早要還的。
• 想象下，如果代碼不夠解耦，未來(lái)修改會(huì)導(dǎo)致?tīng)恳话l(fā)而動(dòng)全身，使得重構(gòu)困難，又無(wú)法滿足產(chǎn)品快速迭代。

正因?yàn)橐苊膺@些不可控的因素，才會(huì)有了職責(zé)的細(xì)分。有了項(xiàng)目經(jīng)理、售前、架構(gòu)師、技術(shù)負(fù)責(zé)人、開發(fā)人員。當(dāng)然在小公司，職責(zé)沒(méi)那么清晰，可能一個(gè)技術(shù)負(fù)責(zé)人就cover所有職責(zé)了，如果你做為開發(fā)人員經(jīng)常加班，進(jìn)度緩慢，可以反思下，你的leader是在哪些環(huán)節(jié)做的不夠好而導(dǎo)致低效，你能否分擔(dān)一些。

從職業(yè)發(fā)展的角度來(lái)說(shuō)，大家都是自下而上從d1、d2、d3這樣的小角色慢慢往上走的，除了技術(shù)需要不斷深入，未來(lái)轉(zhuǎn)管理還需要有抽象思維、業(yè)務(wù)能力、溝通協(xié)作，這些并不比寫代碼簡(jiǎn)單多少。

也不要覺(jué)得目前自己只是一個(gè)小角色，只能替大佬擦擦鞋。不要這么想，每個(gè)人都應(yīng)該更好的表達(dá)自己，更好的去體現(xiàn)自己在一個(gè)團(tuán)隊(duì)的價(jià)值。如果你做不到這點(diǎn)的話，你就很有可能被替換掉。所以多做一些事情，不要怕犯錯(cuò)，多去和其他部門溝通交流，要把自己耦合到每一個(gè)部門中去。重構(gòu)最怕強(qiáng)耦合，想要開掉你，團(tuán)隊(duì)還要有一個(gè)陣痛期呢，對(duì)不?

來(lái)個(gè)收尾

雖然通篇沒(méi)講技術(shù)，但不代表我覺(jué)得技術(shù)沒(méi)用哈，支撐產(chǎn)品的是技術(shù)，推動(dòng)產(chǎn)品的也有技術(shù)的功勞，只是覺(jué)得這個(gè)角度很有趣，大家可以再深思下，為什么要有面向?qū)ο笳Z(yǔ)言?是業(yè)務(wù)推動(dòng)了技術(shù)，還是技術(shù)革新了業(yè)務(wù)?

單純的講方法論就和雞湯一樣，喝了都說(shuō)好，第二天就忘記了。這不是方法論的鍋，更多的還是自己無(wú)法結(jié)合整理出適合自己的方法論，同時(shí)也是因?yàn)檠劢绮粔颍^(guò)于關(guān)注眼前的細(xì)節(jié)。

那些入行兩年就到處和人說(shuō)自己迷茫，遇到瓶頸的同學(xué)，有沒(méi)有想過(guò)是自己的眼界不夠呢，是不是把技術(shù)開發(fā)單純的理解為堆代碼了呢?