在現(xiàn)在這個技術(shù)高速發(fā)展的時代，無論你是在校學(xué)生，還是技術(shù)職場中的精英，都會面臨需要持續(xù)提升。但是如果只知道提升技術(shù)能力，忽略了一些技巧和技術(shù)素養(yǎng)的培養(yǎng)和習(xí)慣。你會發(fā)現(xiàn)你再有能力，也變得無用武之地。因為真正的強(qiáng)者是不會只依賴TA的裝備。更多的是技巧，經(jīng)驗，應(yīng)變能力還有思想。

這篇文章會教5大法則助我們成為更出色的開發(fā)者，在眾多開發(fā)者中脫穎而出的訣竅，也會在我們的技術(shù)職業(yè)生涯中給我們很多的幫助。

1. 先思考，后設(shè)計，再下手

先思考，后設(shè)計，再下手

多數(shù)拿到新功能需求，大致有思路就直接下手開始寫代碼，半天下來發(fā)現(xiàn)這個需求或者功能越想越復(fù)雜。前進(jìn)的路開始迷茫，內(nèi)心越來越煩躁（甚至開始埋冤產(chǎn)品，這個需求怎么搞那么復(fù)雜，太坑了！），禿頭的噩夢開始了。(╯?_ ?）╯

其實開始寫代碼之前，思路就沒有整理清楚或者目標(biāo)不明確，想著想著就偏離了初衷。越深入考慮就越復(fù)雜，考慮到解耦代碼，封裝服務(wù)，設(shè)計數(shù)據(jù)庫，擴(kuò)展性，通用型等等這些因素。想想都已經(jīng)邁入了從0到放棄的節(jié)奏了。甚至遇到過“杞人憂天”的程序猿小哥哥，小姐姐。TA們問我說：“如果那一天服務(wù)器在我處理的時候停電了怎么辦呀，如果服務(wù)器爆炸了呢？！”（這種絕對不夸張，還真的有哈）

其實就是因為前期沒有充分的思考和設(shè)計所以才會導(dǎo)致后面的手慌腳亂。

深度思考

投入代碼的海洋之前，我們需要先深度思考這個功能需求，整理清楚它的目的，場景，難點。

1. 明確目的 --- 明確功能需求的目的，了解清楚它是用來做什么，為了達(dá)到什么目的。

好比如現(xiàn)在是要開發(fā)一個文章搜索。一聽到這個，你會想到什么呢？文章標(biāo)題搜索？全文搜索？拆詞搜索？標(biāo)簽化搜索？還能想到更多各式各樣的搜索功能可以在這個功能需求中實現(xiàn)。如果不明確目的是什么，可能一開始就想復(fù)雜了。最終可能只是需要一個簡單的標(biāo)題搜索而已。而我們花了半天在想一大堆的可能性，系統(tǒng)要承載這個功能需要如何設(shè)計。

2. 使用場景 --- 場景因素決定了這個功能的技術(shù)架構(gòu)，也決定它的難度等級。

那場景到底是什么？其實就是這個功能規(guī)模的影響因素，舉個例子：后端來說場景可以是這個文章搜索涉及的數(shù)據(jù)量級，還有使用的用戶量級和并發(fā)量級。這些都是會直接關(guān)系到后端架構(gòu)的設(shè)計，和代碼的編寫策略。那如果是前端呢？前端要考慮的因素有：這個搜索是否有重復(fù)使用性（是否需要封裝成組件），是否需要加強(qiáng)的交互（比如，實時聯(lián)想歷史搜索或者關(guān)鍵詞），是否涉及前端需要數(shù)據(jù)與交互結(jié)合處理數(shù)據(jù)來達(dá)到一些特殊交互。這些都是直接和前端的實現(xiàn)方式息息相關(guān)的。

3. 分析難點 --- 明確目的，鎖定場景后，就可以開始解刨功能需求找到技術(shù)難點。

注意一個誤區(qū)，這個思考過程不是決定技術(shù)架構(gòu)和策略，這里只是單純通過已有的關(guān)聯(lián)性系統(tǒng)功能，技術(shù)能力范圍，數(shù)據(jù)量級，用戶量級，開發(fā)時效等因素排查出這個功能需求開發(fā)的難點。如果在這里就開始考慮到設(shè)計和策略，我們就會過多的花時間在一兩個難點上，甚至過度設(shè)計。我們的重點是分析出某些部分的存在難度，先解刨出來，后面開始架構(gòu)設(shè)計和策略的時候會特別注意到這些難點。

??小結(jié)一下：
在設(shè)計和開發(fā)一個功能需求前，有一個系統(tǒng)化的思考模式可以讓我們快速的明白一個功能需求和整理思路！習(xí)慣先深度思考，可以大大提高自身技術(shù)的成長。慢慢我們會發(fā)現(xiàn)你分析一個功能需求會看的更加透徹，開發(fā)效率也會隨之上升。

設(shè)計與策略

開發(fā)任何一個功能，特別是大型系統(tǒng)，我們都是需要有一個架構(gòu)設(shè)計的過程。系統(tǒng)架構(gòu)設(shè)計會包括：

• 后端 --- 數(shù)據(jù)庫，設(shè)計模式，編寫策略（例如：服務(wù)層封裝）等。

• 前端 --- 組件封裝，底層工具類，代碼接受，模塊化等。

設(shè)計這個功能也是有一套方式方法可以提高這方面的效果和能力。

1. 畫圖 --- 使用UML/思維導(dǎo)圖/邏輯圖等工具整理自己的功能邏輯流程， 這個可以強(qiáng)化功能的背后的思路。通過畫圖可以完整的，可視化的整理了一遍你大腦中的功能邏輯思路。大大強(qiáng)化了這個邏輯在你腦海里的影響。在畫圖的過程中，你還會挖掘出一些細(xì)微的問題和缺陷，通過這個過程，你的邏輯思路會得到優(yōu)化和強(qiáng)化。

2. 探討 --- “集思廣益”，集合大家的力量必定比你一個人想強(qiáng)，所以設(shè)計出你的架構(gòu)和邏輯圖后，可以與你的伙伴一起探討和分享。你會發(fā)想TA們可以看到你看不多的角度和觀點。從而可以更加優(yōu)化你的設(shè)計和邏輯。如果你有看過我寫的《如果高效學(xué)習(xí)編程》，應(yīng)該知道“小黃鴨教學(xué)法”，在你講解你的設(shè)計和邏輯思路的過程，從思想轉(zhuǎn)化為語言的過程，你已經(jīng)在重新整理了一片你的設(shè)計思路和邏輯。你可能會在過程中發(fā)現(xiàn)一些你預(yù)想不到的全新觀點。

3. ETC原則 --- “Easy to change” 易于改編原則來源于一本書叫《程序員修煉之道》，意思就是代碼可以更容易被改遍的才是最好的代碼 --- “Good code is easy to change”。設(shè)計和編程中最重要的一個點就是，保持代碼靈活和易于改編重用的架構(gòu)技術(shù)。（這里我先透露一下，近期我也又在準(zhǔn)備寫一篇專門講解有關(guān)此原則的文章，感興趣的童鞋，敬請期待，可先關(guān)注本博主哦）。在設(shè)計架構(gòu)的時候如果遇到兩個或者多個選擇，那就遵循ETC原則，選擇擴(kuò)展性高，易于改編更好的方案。

??小結(jié)一下：
做好功能需求整理和設(shè)計模式的建立，對于功能需求的了解已經(jīng)可以達(dá)到一定的深度和理解的相對透徹。這個時候就可以開始一頭扎進(jìn)去代碼的海洋了。你會發(fā)現(xiàn)自己的代碼會寫的很順暢，一種乘風(fēng)破浪的感覺，恍惚敲代碼都帶風(fēng)。

2. 把功能需求分解成小任務(wù)

把功能需求分解成小任務(wù)

接到一個功能需求時，眾多開發(fā)者都會覺得，這個需求含有多個功能點，感覺無從入手。還會有一種莫名的復(fù)雜感。這個是因為一個功能需求里面很多時候?qū)﹂_發(fā)來說都是參合了多個小功能。

這個時候最好的解決辦法就是盡量的分解需求為多個小任務(wù)。在《如果高效學(xué)習(xí)編程》中也有提到一個觀點 --- “化繁為簡，小步快跑”，把復(fù)雜的功能拆分成多個小的點，也能讓自己會迅速的開展工作。同時也會更有沖勁，每個任務(wù)如果太過復(fù)雜，實現(xiàn)時間太過長，會慢慢覺得枯燥無味，效率就會大大下降。

如何分解需求？

我團(tuán)隊的很多小伙伴一開始自己拆解功能需求的時候，經(jīng)常會問我，“不知道需求怎么拆解，感覺拆的太細(xì)又不實際，但是如果不拆細(xì)，又覺得沒有拆的必要“。這里我來給大家一些方法來拆解功能需求：

• 按流程 --- 每個功能需求都有一定有一個或多個的業(yè)務(wù)流，邏輯流，數(shù)據(jù)流?？梢允褂眠@個流程分解。

• 業(yè)務(wù)流 --- 可以按照業(yè)務(wù)的流程拆可，比如注冊賬號，短信通知，推薦聯(lián)系人。這個系統(tǒng)的注冊到通知到推薦聯(lián)系人。其實都是注冊流程中的，但是我們可以按照流程拆開3個獨立任務(wù)進(jìn)行開發(fā)。

• 邏輯流 --- 按照不同的業(yè)務(wù)邏輯拆分你的任務(wù)，使用相同注冊賬號的例子，可以拆分為：檢測用戶名重復(fù)，添加用戶的邏輯，推送短信邏輯，建立短信發(fā)送服務(wù)等等。

• 數(shù)據(jù)流 --- 也可以理解為按照查詢數(shù)據(jù)的邏輯來分割你的功能需求。比如建立賬戶體系倉庫，建立短信發(fā)送記錄查詢倉庫等等。

• 按功能模塊/體系 --- 如果你接到的是一個大的功能需求，這個功能可能就含有多個功能模塊在其中。比如我們要做一個財務(wù)模塊，我們可以首先根據(jù)功能模塊或者體系拆分：對賬體系，提現(xiàn)體系，資金流水，銀行賬戶管理，資金管理等等。

??小結(jié)一下：
當(dāng)我們接到的功能需求較大的時候，我們一定要把需求“化繁為簡，小步快跑”的方式進(jìn)行分解。這個會大大有利于我們提高效率。畢竟在技術(shù)開發(fā)中長跑是會精疲力盡的，小步快跑才能讓我們高效使用腦力。分解需求還能讓我們注意到更細(xì)微的功能點，那樣我們不會在復(fù)雜的功能需求中遺漏一下微小的功能點。

3. 結(jié)隊開發(fā)，代碼評審

結(jié)伴開發(fā)，代碼評審

在開發(fā)的過程中，開發(fā)者們往往會沈醉于自己的完美代碼之中。我一開始也是如此，自己寫了一個服務(wù)，無論是命名，寫法，封裝，邏輯設(shè)計，架構(gòu)設(shè)計等等，我都覺得是完美無暇了，甚至覺得都被自己的代碼美到了。但是越是這個時候，我們就越是無法發(fā)現(xiàn)美中不足。我們要接受一個現(xiàn)實就是沒有最好，只有更好。

首先要明白，自身的問題大部分人大概率都會是看不清自己的。內(nèi)心的想法是：自己一直都是這么做的，所以不會覺得自己是有可以改善的點，也會總以為自己是對的。所以我們需要人來提點和指出我們的不足和缺點。人生如果有一面好的鏡子是可以照出自己的不足，推動自己改變，成長，提升。不然人會深醉在自己的迷惑中無法找到自身的缺點，最終就是走入無法突破的瓶頸。

在開發(fā)中也是，找一個或多個開發(fā)小伙伴審查自己的代碼。因為每個開發(fā)者都擁有不同的經(jīng)驗。一個優(yōu)秀的團(tuán)隊，每一個成員都有自身特別專研的領(lǐng)域和技術(shù)能力。或多或少都是一種互補的狀態(tài)下組成的團(tuán)隊。所以互相審查代碼可以達(dá)到互相學(xué)習(xí)，互相吸收彼此的特長和優(yōu)點，然而達(dá)到最大化的互補，共同寫出最好的代碼。

1. 結(jié)隊開發(fā) --- 其實結(jié)對開發(fā)，就是每次開發(fā)一個功能，你會分配一個伙伴，或者建立一個小組。待開發(fā)的過程中，可以彼此討論架構(gòu)和設(shè)計方案，實現(xiàn)方案等等，互補也互相學(xué)習(xí)利于成長，“兩人搭配干活不累”。結(jié)隊開發(fā)也能有效避免很多功能中的細(xì)微細(xì)節(jié)被忽略，還是那句話“兩個腦袋必定比一個腦袋強(qiáng)”！

2. 坦誠的審查 --- 在開發(fā)完一個功能后，找到你的隊員互相閱讀并且審查彼此的代碼，從而互相提出寶貴的意見。 但是其實很多時候，因為彼此是同事也是開發(fā)小組中的戰(zhàn)友，在“審查”對方的優(yōu)秀“作品”的時候給最真實的反饋意見，往往我們和對方心里會覺得這是一種“批判”，一種“批評”。然而因為這種顧慮和心態(tài)，讓我們在審查的過程中有一種莫名的壓力和負(fù)擔(dān)。所以給出的意見不能一針見血。“真實坦誠的話大多數(shù)人都不愛聽，贊美的謊言都很中聽”，也可以說是“忠言逆耳”。但是往往就是最真實的反饋意見是對彼此最有價值。也是這樣才能在技術(shù)的道路上，讓自己看到與明白自身的不足并且更好的去改進(jìn)，從而在這條道路上彼此都能越發(fā)的走的更快更遠(yuǎn)。所以如果都想讓自己和隊員有快速成長，那就更需要我們對彼此的知識成果予以尊重，予以坦誠相待的態(tài)度，給予隊員代碼中不足之處的反饋，也謙虛誠懇的接受別人的意見。這是代碼審查重中之重！

在我的團(tuán)隊中提出使用結(jié)隊開發(fā)，代碼審查制的時候，我收到很多反饋：“我們本來就是敏捷迭代開發(fā)，時間很緊湊，不夠時間去審查”，“每個人的技術(shù)能力參差不齊，有些人無法讀懂彼此的代碼”，“功能里面摻合著業(yè)務(wù)和功能需求的業(yè)務(wù)流程，對方?jīng)]有做我的功能業(yè)務(wù)，看不懂呀”等等等等。一開始大家勇于提出了很多問題。

那我們怎么搞？不用慌讓我們來分析一下，提出解決方案：

• 時間問題 --- 敏捷迭代中，都是小步快跑，迭代周期根據(jù)項目而定，但是大致都是1-4周的范圍之內(nèi)。時間確實是比較緊迫的。但是互相審查代碼這個好處實在是很多，所以就算要在敏捷迭代中耗費一點時間也是非常值得的。

• 方案： 每個人在每天早上就花1小時，審查前一天小伙伴們提交審核的代碼，然后在Gitlab這種代碼管理平臺中直接在代碼中填寫反饋意見。這樣時間是可控的，也不會讓開發(fā)者浪費太多時間在審查中。

• 能力參差不棄 --- 這個是審查中的問題，也是為什么更需要審查的原因。不觸動互相審查，在團(tuán)隊中給彼此意見讓團(tuán)隊的總體能力拉平，能力中的參差不棄的問題就永無法解決。

• 方案： 首先開個群，或者開個會議，互相提出自己的優(yōu)缺點，還有提出自己今年想提升的方面。找到團(tuán)隊成員各自的強(qiáng)項其實問題就好解決了。把強(qiáng)項和有這方面想提升的人結(jié)隊開發(fā)，這樣就可以發(fā)揮有強(qiáng)項人的能力，同時幫助了有這塊短板的戰(zhàn)友。而且，別人的強(qiáng)項也可能是你的短板，很少有開發(fā)者是方方面面都很強(qiáng)的。別人身上肯定有你可以學(xué)到的東西。所以彼此都有良好的學(xué)習(xí)文化和心態(tài)。

• 業(yè)務(wù)不熟悉 --- 其實代碼審核不是去測試對方的功能和業(yè)務(wù)，我們是寫代碼的開發(fā)者，不是測試工程師。代碼審查的主要目的是為了，提高研發(fā)質(zhì)量，把控代碼規(guī)范，提高編寫能力，提高技術(shù)知識。

• 方案： 所以我們讓開發(fā)者互相審查的是，代碼質(zhì)量，實現(xiàn)方式，架構(gòu)設(shè)計，代碼規(guī)范，編寫策略等方面，這種是不需要知道業(yè)務(wù)的，如果這些有涉及業(yè)務(wù)的需要才那么實現(xiàn)的，可以詢問對方計算難點在哪里：是查詢？數(shù)據(jù)的處理？審查的重點放在技術(shù)本事不是業(yè)務(wù)代碼的層面上。

??小結(jié)一下：

• 開發(fā)者基本上都是抱團(tuán)工作的，這種環(huán)境下都是很適合互補互相學(xué)習(xí)的環(huán)境。如果想彼此有快速的成長，那就需要我們互相去給彼此提出坦誠又寶貴的意見，從中吸取彼此的優(yōu)點和強(qiáng)項。這樣每個人在這個團(tuán)隊中都會得到高速的提升。
• 如果你所在的公司領(lǐng)導(dǎo)沒有推行這種模式，可以提議一下，如果因為公司的情況不合適，可以自己組隊互相分享代碼探討，這樣還是能達(dá)到互相學(xué)習(xí)和提升的！

4. 在安靜的環(huán)境中開發(fā)

在安靜的環(huán)境中開發(fā)g

開發(fā)者在日常工作中，都是要高度集中，腦力全開的狀態(tài)下工作的。所以環(huán)境造成的干擾對開發(fā)者而言是很影響效率的。一個難題，一段代碼的思路，都是需要高度集中，在大腦中1000QPS的輸出速度來思考問題和邏輯。所以如果在過程中被聲音，交談，或者其它環(huán)境的干擾，就會被打斷思路，然后陷入一個不停的思路重組的過程，大量的時間都被消耗掉了。

當(dāng)年我剛剛當(dāng)上了研發(fā)主管，開發(fā)于管理并行。發(fā)現(xiàn)自己每天都處于高并發(fā)狀態(tài)，同時幾件事情在處理，溝通，回答問題，協(xié)調(diào)工作，分析需求，與產(chǎn)品經(jīng)理互懟，功能設(shè)計，功能規(guī)劃，任務(wù)分解，然后就是研發(fā)。這一堆的事情都是日常必須要做的事情。我發(fā)現(xiàn)在研發(fā)的過程中，總會有那么一兩個人來打斷我的思路，當(dāng)我大腦在全速前進(jìn)的時候，突然在高速公路上出現(xiàn)了一個“程咬金”。解決了TA的疑問之后，重新投入研發(fā)，需要花至少10分鐘重新整理思路和投入狀態(tài)，大腦回歸原來的速度。但是萬萬沒想到，第二個人又來了。當(dāng)時的我就感嘆了一句，“做一個小小開發(fā)真的是太幸福了”。

其實不只是技術(shù)管理崗會遇到這種問題，做一個研發(fā)組的開發(fā)者也會遇到，會有產(chǎn)品經(jīng)理，測試，其他同事來請教你，給你指bug等等的事情需要和你溝通。所以這種干擾是無法在崗位或者職責(zé)上避免的。

那我們怎么才能做一個靜靜的小開發(fā)呀？(? `Д ? )?，我來告訴你一些小秘訣吧：

1. 番茄工作法 --- 給自己定好20-60分鐘的高度集中的工作時間，這個時間內(nèi)誰都不要過來打擾你，如果這個時間段有人來找你，你問一句“不好意思，我現(xiàn)在有點忙，事情緊急嗎？不緊急我過xx分鐘過來找你“。如果對方的事情是不緊急的，你就可以繼續(xù)投入開發(fā)。到了一個25分鐘階段結(jié)束的時候，你再起來跟對方溝通。時間是很寶貴的，為了可以讓大家高效溝通，也高效率開展研發(fā)工作。我們要高效運用時間。

2. 帶上耳機(jī) --- 如果音樂會打擾你思路的話，就開一點輕音樂，或者一些大自然環(huán)境的聲音。這樣可以幫助你高度集中，不讓自己聽到一些能打擾你的聲音。這種也是有效的管理好自己的耳門，讓自己高度集中在研發(fā)中。我一般不會告訴別人，別人看到你帶著耳機(jī)，高度集中的樣子，莫名的會給到TA人心理壓力和心理負(fù)擔(dān)，會想這一刻過去找你，會不會打擾到你的。

3. 免打擾模式 --- 在你高度集中的時候，開啟手機(jī)的免打擾模式，關(guān)閉你電腦里面一些與你現(xiàn)在工作無關(guān)的應(yīng)用和網(wǎng)頁。只要不是工作的群都可以開啟消息免打擾。在你番茄工作法的休息時間段，再去看一看消息，加加水，走動一下放松一下。（但是記得一定要控制自己的休息時間，休息過長會導(dǎo)致完全脫離工作狀態(tài)，要重新進(jìn)入狀態(tài)耗費的時間就會變長）

??小結(jié)一下：
技術(shù)研發(fā)是一個需要高度集中的腦力活，大腦的QPS需要保持在較高的速度和狀態(tài)才能達(dá)到高效。所以要學(xué)會自控，更要把控好自己所在的環(huán)境與人。時間是寶貴的，只有珍惜時間才會在最短時間內(nèi)達(dá)到最大量度的產(chǎn)出。如果你能做到，你會發(fā)現(xiàn)你加班會變少，工作效率會提高。

5. 不要只追求速度

不要只追求速度

開發(fā)者的研發(fā)速度快固然是好，但是只最求速度，就會降低質(zhì)量，到頭來我們會發(fā)現(xiàn)總的完成速度可能更長。為什么？ 速度和質(zhì)量是相輔相成的。速度過快，就會降低質(zhì)量，質(zhì)量降低了，后面你會累積很多技術(shù)債，你的功能就會出現(xiàn)很多BUG，還有可能出現(xiàn)性能，寫法，規(guī)范問題。后面還需要花大量的時間給自己擦屁股，甚至還需要你的戰(zhàn)友為我們擦屁股。所以呢？快不一定真的快，“正所謂急功近利，最后可能適得其反”。

所以在開發(fā)的過程中，一定要先養(yǎng)成重視自己的代碼質(zhì)量的習(xí)慣，包括：

1. 規(guī)范 --- 良好的規(guī)范會高度提升可讀性，后面回來修改，修復(fù)，擴(kuò)展都會更加容易

2. 策略 --- 一個運用好的編寫策略的代碼會更有“易改編性” （前面說到的ETC原則）

3. 合理解耦/封裝 --- 封裝和解耦代碼是一個優(yōu)秀的開發(fā)者必備的技能和習(xí)慣，這個可以有效分組分塊分邏輯來管理自己的方法和邏輯，也是高度提升“易改編性，易于后面維護(hù)和擴(kuò)展。

4. 重視備注 --- 在一些復(fù)雜業(yè)務(wù)邏輯中，一定要重點給自己寫下詳細(xì)的備注，沒有備注就等同于別人在看一本英文書，看的一臉懵逼。但是也要記得不要過度備注，每一行代碼都寫幾個字備注一下。這種就會反而降低代碼的可讀性，分邏輯塊，分模塊，分組備注相關(guān)內(nèi)容。主要還是清晰明了才是重點。

??小總結(jié)一下：
當(dāng)你養(yǎng)成了好的編寫代碼的習(xí)慣，有了高質(zhì)量的代碼產(chǎn)出，你會發(fā)現(xiàn)你已經(jīng)成為一個高手，“快，恨，準(zhǔn)”。要知道，如果你一開始只最求速度，你最后的技術(shù)債會嚴(yán)重拖累你的。最后時間都花在插屁股上了。適得其反！

總結(jié)

看完這邊文章我們發(fā)現(xiàn)做為一個開發(fā)者，不只是需要提升自己的技術(shù)能力，技術(shù)素養(yǎng)也是重中之重。只有技術(shù)能力，在職場中會有很多壓力，職場中是不會給我們?nèi)澜绲臅r間來開發(fā)，也不會給我們一個舒適的環(huán)境讓我們集中。所以作為一個更出色的程序員，我們身上必須擁有更多的防身技能，才能在我們面對各式各樣的情況和問題出現(xiàn)時，我們能處于泰然，游刃有余。往往也是這些能耐才能讓我們與眾多的開發(fā)者有明顯的區(qū)別。

希望這5大法則可以助你在技術(shù)行業(yè)里成為更出色的開發(fā)者，在眾多的開發(fā)者中脫穎而出，升級加薪，走上技術(shù)和人生的巔峰。