建站
咨詢
售后
建站咨詢
新聞中心
在開發(fā)中，編碼我們有分層架構(gòu)、設(shè)計模式做為套路來高效開發(fā)，但你也知道編碼不是開發(fā)的全部，一個完全的開發(fā)流程用面向?qū)ο笏枷雭砀爬ǎ譃镺OA(面向?qū)ο蠓治?、OOD(面向?qū)ο笤O(shè)計)、OOP(面向?qū)ο缶幊?。一個好的代碼結(jié)構(gòu)是需要需求分析，架構(gòu)設(shè)計做為輔助的，Stay嘗試向你描述一個理想高效的工作流程，有了這個套路，不僅能讓你縮短編碼時間，還能得到團隊的認可。
公司主營業(yè)務(wù)：成都網(wǎng)站建設(shè)、成都網(wǎng)站設(shè)計、移動網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。成都創(chuàng)新互聯(lián)公司是一支青春激揚、勤奮敬業(yè)、活力青春激揚、勤奮敬業(yè)、活力澎湃、和諧高效的團隊。公司秉承以“開放、自由、嚴謹、自律”為核心的企業(yè)文化，感謝他們對我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團隊有機會用頭腦與智慧不斷的給客戶帶來驚喜。成都創(chuàng)新互聯(lián)公司推出大寧免費做網(wǎng)站回饋大家。
關(guān)于高效開發(fā)，大多數(shù)人的***反應(yīng)就是成熟的分層架構(gòu)、設(shè)計模式以及第三方lib。這些給了我們設(shè)計準則還有便利的工具更快的去做需求實現(xiàn)。
高效開發(fā)還有另外一層含義，關(guān)于一個團隊他要如何去提升團隊的整體開發(fā)效率、縮短開發(fā)周期，能夠一步一步去更快速的產(chǎn)品迭代，在這個過程中你要做好需求分析，架構(gòu)上的設(shè)計。
今天的主題是撇開技術(shù)和大家聊聊高效開發(fā)的一些套路與實踐。
如何提升個人開發(fā)效率
如何來提升開發(fā)效率?我們先來粗暴的對比一下，同樣一個需求，不同的角色會如何來著手實現(xiàn)，然后我們再來看差距在哪里?
這個圖我想大家應(yīng)該都能看懂。
一個需求如何被處理，從初級開發(fā)工程師到中級再到高級、架構(gòu)師他們處理的方式流程是不一樣的。
例如你是一個新人，剛到了一家公司，被委派了一個任務(wù)，可能直接就去搜索了。因為分配給你的任務(wù)是拆分出來一個比較具體、比較小的功能，所以不需要去做什么架構(gòu)上的分析，只需要去做具體的實現(xiàn)。對于一個實現(xiàn)者而言，他只需要去搜索或者去找以前自己寫過代碼，最笨的方式才是自己去手寫。不過呢，不是所有實現(xiàn)都是可以面向Google編程的，單純的復(fù)制粘貼會讓你的代碼增加隱患，而你也知道，這是相當危險的，而且也不會有技術(shù)沉淀。
當你工作一兩年，對一些工作流程比較熟悉后，再拿到一個任務(wù)就會想應(yīng)該如何去解決這個問題，當然這個時候你的任務(wù)也從小功能變成了一個模塊。這個業(yè)務(wù)是什么樣子的，應(yīng)該如何去做分析，拆分成一個個小功能，然后有針對性的去搜索，雖然搜來的不能完全滿足你的需求，但你只是要個解題思路，借鑒下稍微做下適配就可以實現(xiàn)啦。
而對于高級開發(fā)工程師或架構(gòu)師來說，拿到的任務(wù)就是一個比較龐大的、成體系的一個模塊或者一個系統(tǒng)。所以要考慮的事情要比初級或中級要多的多，這時候就得做需求分析，架構(gòu)上的設(shè)計，并且在設(shè)計的時候，還得去考慮應(yīng)該如何解耦，如何分離高層抽象和低層實現(xiàn)，因為具體的實現(xiàn)是要拆分出來交給team中其他人去做的。
不同的角色面對同一個任務(wù)時，他們的關(guān)注點是不一樣的，也就使得工作方式不那么一樣。
初級和高級的差距在哪里?
既然我們已經(jīng)清楚了一個需求不同的人來實現(xiàn)它是不一樣的，那么不一樣到底在哪里，我們要挖掘那個具體的因素，這樣才能知道應(yīng)該如何做調(diào)整。
現(xiàn)在我們的問題就是找出初級與高級的差距到底在哪里，少了哪些環(huán)節(jié)?
Stay先把視角拉高一點，我們來看看面向?qū)ο?Object-Oriented)，你可以把OO分為，OOA、OOD、OOP，也就是面向?qū)ο蟮姆治?Analysis)，面向?qū)ο蟮脑O(shè)計(Design)，以及面向?qū)ο缶幊?Programming)
那初級與高級的差距到底在哪里呢?就差在這三部上。
高級開發(fā)工程師他會有一個具體的步驟：
- 通過OOA來分析業(yè)務(wù)流程輸出模型
- 基于模型再做面向?qū)ο蟮脑O(shè)計OOD，借助UML來描述整體的一個業(yè)務(wù)需求的流程
- 以O(shè)OD歸納的用例圖、時序圖、類圖做為藍圖來指導(dǎo)OOP
- 設(shè)計高層抽象，以偽代碼的方式串聯(lián)起整個業(yè)務(wù)流程
- 拆分出一些獨立任務(wù)交給其他人實現(xiàn)
在面向?qū)ο缶幊痰倪^程中，還可以套用經(jīng)典的設(shè)計模式、設(shè)計原則來提升系統(tǒng)的穩(wěn)定性，讓代碼變得可測試，可擴展。
對比下初中級呢，他們的關(guān)注點更多的放在OOP上，在具體代碼實現(xiàn)上。這樣就不太能全觀整體業(yè)務(wù)的流轉(zhuǎn)和邊界，無法預(yù)見需求未來可能發(fā)生的變化，僅僅做些重復(fù)勞動力對提升開發(fā)效率是沒有任何幫助的。
跳出低層實現(xiàn)這口井
但是啊，讓初中級去像高級那樣去做OOA、OOD也不現(xiàn)實啊，如果對業(yè)務(wù)不是很熟悉，一些流程上想得不夠清楚，或者沒有考慮如何去提升用戶體驗，沒有站在產(chǎn)品角度考慮問題，那么設(shè)計出來的架構(gòu)可能會比較死板，同時也漏洞百出。
這是不是很矛盾?沒有經(jīng)驗沉淀，就無法像高級工程師那樣思考，做不到那樣就只能做低層實現(xiàn)，這樣沉淀的太慢了，就像死循環(huán)啊，那么我們該如何break出這個loop呢?
那就先從更好的做OOP開始，其實想把一段代碼寫好，還是有點困難的，關(guān)鍵在于你想寫出來的代碼能打多少分，及格分是60分，它剛好處于可以跑的狀態(tài)，偶爾會出點小bug;100分就是通過設(shè)計模式設(shè)計原則寫出的良好代碼，它能很好的去做測試、做擴展，那它的穩(wěn)定性也很強。
如何才能得高分?有一句古話說的很好，讀書破萬卷，下筆如有神，你做的準備工作越多，底蘊越足，寫代碼就會越順暢。
首先***個是你要考慮的是，這個產(chǎn)品提出的需求有沒有得到你的認可，你覺得什么的方式來實現(xiàn)會使得效益***化。你可以給產(chǎn)品提些建議或者改進，因為你想做一個產(chǎn)品把它做好，你必須要參與進去，即使你做的是比較小的需求，功能，模塊。
當你看到感興趣或者有挑戰(zhàn)的任務(wù)，得自己去爭取這一塊的整體的設(shè)計和實現(xiàn)，不要被動的去接受一個任務(wù)。因為接收來的任務(wù)都是別人咀嚼好的，給你定好了條條框框，你只用往里面填實現(xiàn)就可以的，那些都是沒有技術(shù)含量的。
同時也不要急著去表達這個做不了，那個做不了，安卓做這個很難實現(xiàn)的等等。不要去逃避責任，至少要先做一些真實的調(diào)研和嘗試，或者選取一些可變通的、折中的解決方案，給對方做選擇題，而不是直接拒絕。
在確定了技術(shù)選型之后，那么接下來就是哪些人來領(lǐng)哪些任務(wù)。領(lǐng)任務(wù)的時候，大家不要總是去領(lǐng)那些自己擅長的，每個人都要變得多元化，不僅僅是只會一門手藝(以后只會安卓也不行了)擅長做UI的要去嘗試處理復(fù)雜業(yè)務(wù)、能處理復(fù)雜業(yè)務(wù)的也要想想如何處理一些動畫自定義UI。
Stay在做代碼實現(xiàn)的時候，比較偏向于先實現(xiàn)業(yè)務(wù)，再去考慮UI上的實現(xiàn)。因為用戶體驗是一個沒完沒了的事，你可以把它設(shè)計得很好花哨也可以把它設(shè)計得很簡單，這鍋得產(chǎn)品經(jīng)理去背。而對于業(yè)務(wù)來說，改動就不會那么頻繁了，業(yè)務(wù)梳理清楚了，還愁不能響應(yīng)UI的action嘛，并且還有另外一個好處就是業(yè)務(wù)是testable的，不需要View層也可以測試。假如你上手就畫UI，十有八九你就把UI和業(yè)務(wù)耦合在一起，連剝離復(fù)用都很難做到，更別提寫測試用例啦。
寫代碼不可能一天寫滿八小時，也不可能說一天就能把整體的業(yè)務(wù)全部寫完。如何可持續(xù)地做開發(fā)，最最重要的是，得有一個藍圖、一個清晰的高層抽象結(jié)構(gòu)，有了高層定義再一個一個往里面填具體實現(xiàn)就可以了。(可以參考下毛胚房裝修的全過程)
如果實在是總結(jié)不出適合自己的套路，那就用‘書讀百遍其義自現(xiàn)’這一招好了，但讀是遠遠不夠的，還得寫代碼，寫完了還要想如何去改良。
重新理解開發(fā)流程
剛才Stay給大家描述的是一種抽象的實施方式。接下來給大家做個示范：
高效開發(fā)Stay覺得應(yīng)該分為，OOA、OOD、OOP，跟我們剛才講的那個是一樣的。先得有需求分析，再做流程設(shè)計，***才是代碼實現(xiàn)。
本想寫個完整的案例，奈何精力有限，后續(xù)有時間再補上：)
開發(fā)環(huán)節(jié)中的角色扮演
從OOA、OOD再到高層抽象架構(gòu)和低層實現(xiàn)，不同角色的職責是不一樣的。請看圖說話：
很多工作兩三年的同學(xué)都會焦慮， ‘焦慮的是技術(shù)不能走的長久，30歲以后就走管理吧’ 。有這樣的焦慮不是什么錯，錯的可能是你對管理沒有一個非常明確的概念。你知道如何做一個合格的管理嗎?他的職責是什么?他比起其他角色，突出在哪些能力?
就這一點，Stay想分享點自己的觀點(僅局限于技術(shù)管理層面)：
剛才Stay一直在強調(diào)OOA、OOD、OOP，是因為站在一個管理的層面，想要產(chǎn)品穩(wěn)步迭代，需要讓每個環(huán)節(jié)變得可控。
- 想象下，如果需求分析不對，大量的業(yè)務(wù)代碼要重寫，這是潛在風(fēng)險。
- 想象下，如果業(yè)務(wù)設(shè)計不夠明確，沒有提前定好規(guī)則與約束，大量的代碼都會是一次性的，也就導(dǎo)致了冗余和低效，這是技術(shù)債務(wù)，遲早要還的。
- 想象下，如果代碼不夠解耦，未來修改會導(dǎo)致牽一發(fā)而動全身，使得重構(gòu)困難，又無法滿足產(chǎn)品快速迭代。
正因為要避免這些不可控的因素，才會有了職責的細分。有了項目經(jīng)理、售前、架構(gòu)師、技術(shù)負責人、開發(fā)人員。當然在小公司，職責沒那么清晰，可能一個技術(shù)負責人就cover所有職責了，如果你做為開發(fā)人員經(jīng)常加班，進度緩慢，可以反思下，你的leader是在哪些環(huán)節(jié)做的不夠好而導(dǎo)致低效，你能否分擔一些。
從職業(yè)發(fā)展的角度來說，大家都是自下而上從d1、d2、d3這樣的小角色慢慢往上走的，除了技術(shù)需要不斷深入，未來轉(zhuǎn)管理還需要有抽象思維、業(yè)務(wù)能力、溝通協(xié)作，這些并不比寫代碼簡單多少。
也不要覺得目前自己只是一個小角色，只能替大佬擦擦鞋。不要這么想，每個人都應(yīng)該更好的表達自己，更好的去體現(xiàn)自己在一個團隊的價值。如果你做不到這點的話，你就很有可能被替換掉。所以多做一些事情，不要怕犯錯，多去和其他部門溝通交流，要把自己耦合到每一個部門中去。重構(gòu)最怕強耦合，想要開掉你，團隊還要有一個陣痛期呢，對不?
來個收尾
雖然通篇沒講技術(shù)，但不代表我覺得技術(shù)沒用哈，支撐產(chǎn)品的是技術(shù)，推動產(chǎn)品的也有技術(shù)的功勞，只是覺得這個角度很有趣，大家可以再深思下，為什么要有面向?qū)ο笳Z言?是業(yè)務(wù)推動了技術(shù)，還是技術(shù)革新了業(yè)務(wù)?
單純的講方法論就和雞湯一樣，喝了都說好，第二天就忘記了。這不是方法論的鍋，更多的還是自己無法結(jié)合整理出適合自己的方法論，同時也是因為眼界不夠，過于關(guān)注眼前的細節(jié)。
那些入行兩年就到處和人說自己迷茫，遇到瓶頸的同學(xué)，有沒有想過是自己的眼界不夠呢，是不是把技術(shù)開發(fā)單純的理解為堆代碼了呢?
文章標題：關(guān)于高效開發(fā)的一些套路與實踐
文章來源：http://www.5511xx.com/article/cohhopo.html
