在開發中，編碼我們有分層架構、設計模式做為套路來高效開發，但你也知道編碼不是開發的全部，一個完全的開發流程用面向對象思想來概括，它分為OOA(面向對象分析)、OOD(面向對象設計)、OOP(面向對象編程)。一個好的代碼結構是需要需求分析，架構設計做為輔助的，Stay嘗試向你描述一個理想高效的工作流程，有了這個套路，不僅能讓你縮短編碼時間，還能得到團隊的認可。

關于高效開發，大多數人的***反應就是成熟的分層架構、設計模式以及第三方lib。這些給了我們設計準則還有便利的工具更快的去做需求實現。

高效開發還有另外一層含義，關于一個團隊他要如何去提升團隊的整體開發效率、縮短開發周期，能夠一步一步去更快速的產品迭代，在這個過程中你要做好需求分析，架構上的設計。

今天的主題是撇開技術和大家聊聊高效開發的一些套路與實踐。

如何提升個人開發效率

如何來提升開發效率?我們先來粗暴的對比一下，同樣一個需求，不同的角色會如何來著手實現，然后我們再來看差距在哪里?

這個圖我想大家應該都能看懂。

一個需求如何被處理，從初級開發工程師到中級再到高級、架構師他們處理的方式流程是不一樣的。

例如你是一個新人，剛到了一家公司，被委派了一個任務，可能直接就去搜索了。因為分配給你的任務是拆分出來一個比較具體、比較小的功能，所以不需要去做什么架構上的分析，只需要去做具體的實現。對于一個實現者而言，他只需要去搜索或者去找以前自己寫過代碼，最笨的方式才是自己去手寫。不過呢，不是所有實現都是可以面向Google編程的，單純的復制粘貼會讓你的代碼增加隱患，而你也知道，這是相當危險的，而且也不會有技術沉淀。

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

而對于高級開發工程師或架構師來說，拿到的任務就是一個比較龐大的、成體系的一個模塊或者一個系統。所以要考慮的事情要比初級或中級要多的多，這時候就得做需求分析，架構上的設計，并且在設計的時候，還得去考慮應該如何解耦，如何分離高層抽象和低層實現，因為具體的實現是要拆分出來交給team中其他人去做的。

不同的角色面對同一個任務時，他們的關注點是不一樣的，也就使得工作方式不那么一樣。

初級和高級的差距在哪里?

既然我們已經清楚了一個需求不同的人來實現它是不一樣的，那么不一樣到底在哪里，我們要挖掘那個具體的因素，這樣才能知道應該如何做調整。

現在我們的問題就是找出初級與高級的差距到底在哪里，少了哪些環節?

Stay先把視角拉高一點，我們來看看面向對象(Object-Oriented)，你可以把OO分為，OOA、OOD、OOP，也就是面向對象的分析(Analysis)，面向對象的設計(Design)，以及面向對象編程(Programming)

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

高級開發工程師他會有一個具體的步驟：

• 通過OOA來分析業務流程輸出模型
• 基于模型再做面向對象的設計OOD，借助UML來描述整體的一個業務需求的流程
• 以OOD歸納的用例圖、時序圖、類圖做為藍圖來指導OOP
• 設計高層抽象，以偽代碼的方式串聯起整個業務流程
• 拆分出一些獨立任務交給其他人實現

在面向對象編程的過程中，還可以套用經典的設計模式、設計原則來提升系統的穩定性，讓代碼變得可測試，可擴展。

對比下初中級呢，他們的關注點更多的放在OOP上，在具體代碼實現上。這樣就不太能全觀整體業務的流轉和邊界，無法預見需求未來可能發生的變化，僅僅做些重復勞動力對提升開發效率是沒有任何幫助的。

跳出低層實現這口井

但是啊，讓初中級去像高級那樣去做OOA、OOD也不現實啊，如果對業務不是很熟悉，一些流程上想得不夠清楚，或者沒有考慮如何去提升用戶體驗，沒有站在產品角度考慮問題，那么設計出來的架構可能會比較死板，同時也漏洞百出。

這是不是很矛盾?沒有經驗沉淀，就無法像高級工程師那樣思考，做不到那樣就只能做低層實現，這樣沉淀的太慢了，就像死循環啊，那么我們該如何break出這個loop呢?

那就先從更好的做OOP開始，其實想把一段代碼寫好，還是有點困難的，關鍵在于你想寫出來的代碼能打多少分，及格分是60分，它剛好處于可以跑的狀態，偶爾會出點小bug;100分就是通過設計模式設計原則寫出的良好代碼，它能很好的去做測試、做擴展，那它的穩定性也很強。

如何才能得高分?有一句古話說的很好，讀書破萬卷，下筆如有神，你做的準備工作越多，底蘊越足，寫代碼就會越順暢。

首先***個是你要考慮的是，這個產品提出的需求有沒有得到你的認可，你覺得什么的方式來實現會使得效益***化。你可以給產品提些建議或者改進，因為你想做一個產品把它做好，你必須要參與進去，即使你做的是比較小的需求，功能，模塊。

當你看到感興趣或者有挑戰的任務，得自己去爭取這一塊的整體的設計和實現，不要被動的去接受一個任務。因為接收來的任務都是別人咀嚼好的，給你定好了條條框框，你只用往里面填實現就可以的，那些都是沒有技術含量的。

同時也不要急著去表達這個做不了，那個做不了，安卓做這個很難實現的等等。不要去逃避責任，至少要先做一些真實的調研和嘗試，或者選取一些可變通的、折中的解決方案，給對方做選擇題，而不是直接拒絕。

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

Stay在做代碼實現的時候，比較偏向于先實現業務，再去考慮UI上的實現。因為用戶體驗是一個沒完沒了的事，你可以把它設計得很好花哨也可以把它設計得很簡單，這鍋得產品經理去背。而對于業務來說，改動就不會那么頻繁了，業務梳理清楚了，還愁不能響應UI的action嘛，并且還有另外一個好處就是業務是testable的，不需要View層也可以測試。假如你上手就畫UI，十有八九你就把UI和業務耦合在一起，連剝離復用都很難做到，更別提寫測試用例啦。

寫代碼不可能一天寫滿八小時，也不可能說一天就能把整體的業務全部寫完。如何可持續地做開發，最最重要的是，得有一個藍圖、一個清晰的高層抽象結構，有了高層定義再一個一個往里面填具體實現就可以了。(可以參考下毛胚房裝修的全過程)

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

重新理解開發流程

剛才Stay給大家描述的是一種抽象的實施方式。接下來給大家做個示范：

高效開發Stay覺得應該分為，OOA、OOD、OOP，跟我們剛才講的那個是一樣的。先得有需求分析，再做流程設計，***才是代碼實現。

本想寫個完整的案例，奈何精力有限，后續有時間再補上：)

開發環節中的角色扮演

從OOA、OOD再到高層抽象架構和低層實現，不同角色的職責是不一樣的。請看圖說話：

很多工作兩三年的同學都會焦慮， ‘焦慮的是技術不能走的長久，30歲以后就走管理吧’ 。有這樣的焦慮不是什么錯，錯的可能是你對管理沒有一個非常明確的概念。你知道如何做一個合格的管理嗎?他的職責是什么?他比起其他角色，突出在哪些能力?

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

剛才Stay一直在強調OOA、OOD、OOP，是因為站在一個管理的層面，想要產品穩步迭代，需要讓每個環節變得可控。

• 想象下，如果需求分析不對，大量的業務代碼要重寫，這是潛在風險。
• 想象下，如果業務設計不夠明確，沒有提前定好規則與約束，大量的代碼都會是一次性的，也就導致了冗余和低效，這是技術債務，遲早要還的。
• 想象下，如果代碼不夠解耦，未來修改會導致牽一發而動全身，使得重構困難，又無法滿足產品快速迭代。

正因為要避免這些不可控的因素，才會有了職責的細分。有了項目經理、售前、架構師、技術負責人、開發人員。當然在小公司，職責沒那么清晰，可能一個技術負責人就cover所有職責了，如果你做為開發人員經常加班，進度緩慢，可以反思下，你的leader是在哪些環節做的不夠好而導致低效，你能否分擔一些。

從職業發展的角度來說，大家都是自下而上從d1、d2、d3這樣的小角色慢慢往上走的，除了技術需要不斷深入，未來轉管理還需要有抽象思維、業務能力、溝通協作，這些并不比寫代碼簡單多少。

也不要覺得目前自己只是一個小角色，只能替大佬擦擦鞋。不要這么想，每個人都應該更好的表達自己，更好的去體現自己在一個團隊的價值。如果你做不到這點的話，你就很有可能被替換掉。所以多做一些事情，不要怕犯錯，多去和其他部門溝通交流，要把自己耦合到每一個部門中去。重構最怕強耦合，想要開掉你，團隊還要有一個陣痛期呢，對不?

來個收尾

雖然通篇沒講技術，但不代表我覺得技術沒用哈，支撐產品的是技術，推動產品的也有技術的功勞，只是覺得這個角度很有趣，大家可以再深思下，為什么要有面向對象語言?是業務推動了技術，還是技術革新了業務?

單純的講方法論就和雞湯一樣，喝了都說好，第二天就忘記了。這不是方法論的鍋，更多的還是自己無法結合整理出適合自己的方法論，同時也是因為眼界不夠，過于關注眼前的細節。

那些入行兩年就到處和人說自己迷茫，遇到瓶頸的同學，有沒有想過是自己的眼界不夠呢，是不是把技術開發單純的理解為堆代碼了呢?