5大法則助你 成爲更出色的開發者

在如今這個技術高速發展的時代，不管你是在校學生，仍是技術職場中的精英，都會面臨須要持續提高。可是若是隻知道提高技術能力，忽略了一些技巧和技術素養的培養和習慣。你會發現你再有能力，也變得無用武之地。由於真正的強者是不會只依賴TA的裝備。更多的是技巧，經驗，應變能力還有思想。

這篇文章會教5大法則助咱們成爲更出色的開發者，在衆多開發者中脫穎而出的訣竅，也會在咱們的技術職業生涯中給咱們不少的幫助。

1. 先思考，後設計，再下手

多數拿到新功能需求，大體有思路就直接下手開始寫代碼，半天下來發現這個需求或者功能越想越複雜。前進的路開始迷茫，心裏愈來愈煩躁（甚至開始埋冤產品，這個需求怎麼搞那麼複雜，太坑了！），禿頭的噩夢開始了。(╯ಠ_ ಠ）╯

其實開始寫代碼以前，思路就沒有整理清楚或者目標不明確，想着想着就偏離了初衷。越深刻考慮就越複雜，考慮到解耦代碼，封裝服務，設計數據庫，擴展性，通用型等等這些因素。想一想都已經邁入了從0到放棄的節奏了。甚至遇到過「杞人憂天」的程序猿小哥哥，小姐姐。TA們問我說：「若是那一天服務器在我處理的時候停電了怎麼辦呀，若是服務器爆炸了呢？！」（這種絕對不誇張，還真的有哈）

其實就是由於前期沒有充分的思考和設計因此纔會致使後面的手慌腳亂。

深度思考

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

1. 明確目的 --- 明確功能需求的目的，瞭解清楚它是用來作什麼，爲了達到什麼目的。

比如如如今是要開發一個文章搜索。一聽到這個，你會想到什麼呢？文章標題搜索？全文搜索？拆詞搜索？標籤化搜索？還能想到更多各式各樣的搜索功能能夠在這個功能需求中實現。若是不明確目的是什麼，可能一開始就想複雜了。最終可能只是須要一個簡單的標題搜索而已。而咱們花了半天在想一大堆的可能性，系統要承載這個功能須要如何設計。

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

那場景究竟是什麼？其實就是這個功能規模的影響因素，舉個例子：後端來講場景能夠是這個文章搜索涉及的數據量級，還有使用的用戶量級和併發量級。這些都是會直接關係到後端架構的設計，和代碼的編寫策略。那若是是前端呢？前端要考慮的因素有：這個搜索是否有重複使用性（是否須要封裝成組件），是否須要增強的交互（好比，實時聯想歷史搜索或者關鍵詞），是否涉及前端須要數據與交互結合處理數據來達到一些特殊交互。這些都是直接和前端的實現方式息息相關的。

3. 分析難點 --- 明確目的，鎖定場景後，就能夠開始解刨功能需求找到技術難點。

注意一個誤區，這個思考過程不是決定技術架構和策略，這裏只是單純經過已有的關聯性系統功能，技術能力範圍，數據量級，用戶量級，開發時效等因素排查出這個功能需求開發的難點。若是在這裏就開始考慮到設計和策略，咱們就會過多的花時間在一兩個難點上，甚至過分設計。咱們的重點是分析出某些部分的存在難度，先解刨出來，後面開始架構設計和策略的時候會特別注意到這些難點。

🌟小結一下： **在設計和開發一個功能需求前，有一個系統化的思考模式可讓咱們快速的明白一個功能需求和整理思路！**習慣先深度思考，能夠大大提升自身技術的成長。慢慢咱們會發現你分析一個功能需求會看的更加透徹，開發效率也會隨之上升。

設計與策略

開發任何一個功能，特別是大型系統，咱們都是須要有一個架構設計的過程。系統架構設計會包括：

• 後端 --- 數據庫，設計模式，編寫策略（例如：服務層封裝）等。

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

設計這個功能也是有一套方式方法能夠提升這方面的效果和能力。

1. 畫圖 --- 使用UML/思惟導圖/邏輯圖等工具整理本身的功能邏輯流程， 這個能夠強化功能的背後的思路。經過畫圖能夠完整的，可視化的整理了一遍你大腦中的功能邏輯思路。大大強化了這個邏輯在你腦海裏的影響。在畫圖的過程當中，你還會挖掘出一些細微的問題和缺陷，經過這個過程，你的邏輯思路會獲得優化和強化。

2. 探討 --- 「集思廣益」，集合你們的力量一定比你一我的想強，因此設計出你的架構和邏輯圖後，能夠與你的夥伴一塊兒探討和分享。你會發想TA們能夠看到你看很少的角度和觀點。從而能夠更加優化你的設計和邏輯。若是你有看過我寫的《若是高效學習編程》，應該知道「小黃鴨教學法」，在你講解你的設計和邏輯思路的過程，從思想轉化爲語言的過程，你已經在從新整理了一片你的設計思路和邏輯。你可能會在過程當中發現一些你預想不到的全新觀點。

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

🌟小結一下： 作好功能需求整理和設計模式的創建，對於功能需求的瞭解已經能夠達到必定的深度和理解的相對透徹。這個時候就能夠開始一頭扎進去代碼的海洋了。你會發現本身的代碼會寫的很順暢，一種乘風破浪的感受，恍惚敲代碼都帶風。

2. 把功能需求分解成小任務

接到一個功能需求時，衆多開發者都會以爲，這個需求含有多個功能點，感受無從入手。還會有一種莫名的複雜感。這個是由於一個功能需求裏面不少時候對開發來講都是參合了多個小功能。

這個時候最好的解決辦法就是儘可能的分解需求爲多個小任務。在《若是高效學習編程》中也有提到一個觀點 --- 「化繁爲簡，小步快跑」，把複雜的功能拆分紅多個小的點，也能讓本身會迅速的開展工做。同時也會更有衝勁，每一個任務若是太過複雜，實現時間太過長，會慢慢以爲枯燥無味，效率就會大大降低。

如何分解需求？

我團隊的不少小夥伴一開始本身拆解功能需求的時候，常常會問我，「不知道需求怎麼拆解，感受拆的太細又不實際，可是若是不拆細，又以爲沒有拆的必要「。這裏我來給你們一些方法來拆解功能需求：

• 按流程 --- 每一個功能需求都有必定有一個或多個的業務流，邏輯流，數據流。可使用這個流程分解。

• 業務流 --- 能夠按照業務的流程拆可，好比註冊帳號，短信通知，推薦聯繫人。這個系統的註冊到通知到推薦聯繫人。其實都是註冊流程中的，可是咱們能夠按照流程拆開3個獨立任務進行開發。

• 邏輯流 --- 按照不一樣的業務邏輯拆分你的任務，使用相同註冊帳號的例子，能夠拆分爲：檢測用戶名重複，添加用戶的邏輯，推送短信邏輯，創建短信發送服務等等。

• 數據流 --- 也能夠理解爲按照查詢數據的邏輯來分割你的功能需求。好比創建帳戶體系倉庫，創建短信發送記錄查詢倉庫等等。

• 按功能模塊/體系 --- 若是你接到的是一個大的功能需求，這個功能可能就含有多個功能模塊在其中。好比咱們要作一個財務模塊，咱們能夠首先根據功能模塊或者體系拆分：對帳體系，提現體系，資金流水，銀行帳戶管理，資金管理等等。

🌟小結一下： 當咱們接到的功能需求較大的時候，咱們必定要把需求「化繁爲簡，小步快跑」的方式進行分解。這個會大大有利於咱們提升效率。畢竟在技術開發中長跑是會精疲力盡的，小步快跑才能讓咱們高效使用腦力。分解需求還能讓咱們注意到更細微的功能點，那樣咱們不會在複雜的功能需求中遺漏一下微小的功能點。

3. 結隊開發，代碼評審

在開發的過程當中，開發者們每每會沈醉於本身的完美代碼之中。我一開始也是如此，本身寫了一個服務，不管是命名，寫法，封裝，邏輯設計，架構設計等等，我都以爲是完美無暇了，甚至以爲都被本身的代碼美到了。可是越是這個時候，咱們就越是沒法發現美中不足。咱們要接受一個現實就是沒有最好，只有更好。

首先要明白，自身的問題大部分人大機率都會是看不清本身的。心裏的想法是：本身一直都是這麼作的，因此不會以爲本身是有能夠改善的點，也會總覺得本身是對的。因此咱們須要人來提點和指出咱們的不足和缺點。人生若是有一面好的鏡子是能夠照出本身的不足，推進本身改變，成長，提高。否則人會深醉在本身的迷惑中沒法找到自身的缺點，最終就是走入沒法突破的瓶頸。

在開發中也是，找一個或多個開發小夥伴審查本身的代碼。由於每一個開發者都擁有不一樣的經驗。一個優秀的團隊，每個成員都有自身特別專研的領域和技術能力。或多或少都是一種互補的狀態下組成的團隊。因此互相審查代碼能夠達到互相學習，互相吸取彼此的特長和優勢，然而達到最大化的互補，共同寫出最好的代碼。

1. 結隊開發 --- 其實結對開發，就是每次開發一個功能，你會分配一個夥伴，或者創建一個小組。待開發的過程當中，能夠彼此討論架構和設計方案，實現方案等等，互補也互相學習利於成長，「兩人搭配幹活不累」。結隊開發也能有效避免不少功能中的細微細節被忽略，仍是那句話「兩個腦殼一定比一個腦殼強」！

2. 坦誠的審查 --- 在開發完一個功能後，找到你的隊員互相閱讀而且審查彼此的代碼，從而互相提出寶貴的意見。 可是其實不少時候，由於彼此是同事也是開發小組中的戰友，在「審查」對方的優秀「做品」的時候給最真實的反饋意見，每每咱們和對方內心會以爲這是一種「批判」，一種「批評」。然而由於這種顧慮和心態，讓咱們在審查的過程當中有一種莫名的壓力和負擔。因此給出的意見不能一針見血。「真實坦誠的話大多數人都不愛聽，讚美的謊話都很中聽」，也能夠說是「忠言逆耳」。可是每每就是最真實的反饋意見是對彼此最有價值。也是這樣才能在技術的道路上，讓本身看到與明白自身的不足而且更好的去改進，從而在這條道路上彼此都能愈加的走的更快更遠。因此若是都想讓本身和隊員有快速成長，那就更須要咱們對彼此的知識成果予以尊重，予以坦誠相待的態度，給予隊員代碼中不足之處的反饋，也謙虛誠懇的接受別人的意見。這是代碼審查重中之重！

在個人團隊中提出使用結隊開發，代碼審查制的時候，我收到不少反饋：「咱們原本就是敏捷迭代開發，時間很緊湊，不夠時間去審查」，「每一個人的技術能力良莠不齊，有些人沒法讀懂彼此的代碼」，「功能裏面摻合着業務和功能需求的業務流程，對方沒有作個人功能業務，看不懂呀」等等等等。一開始你們敢於提出了不少問題。

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

• 時間問題 --- 敏捷迭代中，都是小步快跑，迭代週期根據項目而定，可是大體都是1-4周的範圍以內。時間確實是比較緊迫的。可是互相審查代碼這個好處實在是不少，因此就算要在敏捷迭代中耗費一點時間也是很是值得的。

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

• 能力參差不棄 --- 這個是審查中的問題，也是爲何更須要審查的緣由。不觸動互相審查，在團隊中給彼此意見讓團隊的整體能力拉平，能力中的參差不棄的問題就永沒法解決。

• 方案： 首先開個羣，或者開個會議，互相提出本身的優缺點，還有提出本身今年想提高的方面。找到團隊成員各自的強項其實問題就好解決了。把強項和有這方面想提高的人結隊開發，這樣就能夠發揮有強項人的能力，同時幫助了有這塊短板的戰友。並且，別人的強項也多是你的短板，不多有開發者是方方面面都很強的。別人身上確定有你能夠學到的東西。因此彼此都有良好的學習文化和心態。

• 業務不熟悉 --- 其實代碼審覈不是去測試對方的功能和業務，咱們是寫代碼的開發者，不是測試工程師。代碼審查的主要目的是爲了，提升研發質量，把控代碼規範，提升編寫能力，提升技術知識。

• 方案： 因此咱們讓開發者互相審查的是，代碼質量，實現方式，架構設計，代碼規範，編寫策略等方面，這種是不須要知道業務的，若是這些有涉及業務的須要才那麼實現的，能夠詢問對方計算難點在哪裏：是查詢？數據的處理？審查的重點放在技術本事不是業務代碼的層面上。

🌟小結一下：

• 開發者基本上都是抱團工做的，這種環境下都是很適合互補互相學習的環境。若是想彼此有快速的成長，那就須要咱們互相去給彼此提出坦誠又寶貴的意見，從中吸收彼此的優勢和強項。這樣每一個人在這個團隊中都會獲得高速的提高。
• 若是你所在的公司領導沒有推行這種模式，能夠提議一下，若是由於公司的狀況不合適，能夠本身組隊互相分享代碼探討，這樣仍是能達到互相學習和提高的！

4. 在安靜的環境中開發

開發者在平常工做中，都是要高度集中，腦力全開的狀態下工做的。因此環境形成的干擾對開發者而言是很影響效率的。一個難題，一段代碼的思路，都是須要高度集中，在大腦中1000QPS的輸出速度來思考問題和邏輯。因此若是在過程當中被聲音，交談，或者其它環境的干擾，就會被打斷思路，而後陷入一個不停的思路重組的過程，大量的時間都被消耗掉了。

當年我剛剛當上了研發主管，開發於管理並行。發現本身天天都處於高併發狀態，同時幾件事情在處理，溝通，回答問題，協調工做，分析需求，與產品經理互懟，功能設計，功能規劃，任務分解，而後就是研發。這一堆的事情都是平常必需要作的事情。我發如今研發的過程當中，總會有那麼一兩我的來打斷個人思路，當我大腦在全速前進的時候，忽然在高速公路上出現了一個「程咬金」。解決了TA的疑問以後，從新投入研發，須要花至少10分鐘從新整理思路和投入狀態，大腦回歸原來的速度。可是萬萬沒想到，第二我的又來了。當時的我就感嘆了一句，「作一個小小開發真的是太幸福了」。

其實不僅是技術管理崗會遇到這種問題，作一個研發組的開發者也會遇到，會有產品經理，測試，其餘同事來請教你，給你指bug等等的事情須要和你溝通。因此這種干擾是沒法在崗位或者職責上避免的。

那咱們怎麼才能作一個靜靜的小開發呀？(ლ `Д ́ )ლ，我來告訴你一些小祕訣吧：

1. 番茄工做法 --- 給本身定好20-60分鐘的高度集中的工做時間，這個時間內誰都不要過來打擾你，若是這個時間段有人來找你，你問一句「很差意思，我如今有點忙，事情緊急嗎？不緊急我過xx分鐘過來找你「。若是對方的事情是不緊急的，你就能夠繼續投入開發。到了一個25分鐘階段結束的時候，你再起來跟對方溝通。時間是很寶貴的，爲了可讓你們高效溝通，也高效率開展研發工做。咱們要高效運用時間。

2. 帶上耳機 --- 若是音樂會打擾你思路的話，就開一點輕音樂，或者一些大天然環境的聲音。這樣能夠幫助你高度集中，不讓本身聽到一些能打擾你的聲音。這種也是有效的管理好本身的耳門，讓本身高度集中在研發中。我通常不會告訴別人，別人看到你帶着耳機，高度集中的樣子，莫名的會給到TA人心理壓力和心理負擔，會想這一刻過去找你，會不會打擾到你的。

3. 免打擾模式 --- 在你高度集中的時候，開啓手機的免打擾模式，關閉你電腦裏面一些與你如今工做無關的應用和網頁。只要不是工做的羣均可以開啓消息免打擾。在你番茄工做法的休息時間段，再去看一看消息，加加水，走動一下放鬆一下。（可是記得必定要控制本身的休息時間，休息過長會致使徹底脫離工做狀態，要從新進入狀態耗費的時間就會變長）

🌟小結一下： 技術研發是一個須要高度集中的腦力活，大腦的QPS須要保持在較高的速度和狀態才能達到高效。因此要學會自控，更要把控好本身所在的環境與人。時間是寶貴的，只有珍惜時間纔會在最短期內達到最大量度的產出。若是你能作到，你會發現你加班會變少，工做效率會提升。

5. 不要只追求速度

開發者的研發速度快當然是好，可是隻最求速度，就會下降質量，到頭來咱們會發現總的完成速度可能更長。爲何？ 速度和質量是相輔相成的。速度過快，就會下降質量，質量下降了，後面你會累積不少技術債，你的功能就會出現不少BUG，還有可能出現性能，寫法，規範問題。後面還須要花大量的時間給本身擦屁股，甚至還須要你的戰友爲咱們擦屁股。因此呢？快不必定真的快，「正所謂急功近利，最後可能拔苗助長」。

因此在開發的過程當中，必定要先養成重視本身的代碼質量的習慣，包括：

1. 規範 --- 良好的規範會高度提高可讀性，後面回來修改，修復，擴展都會更加容易

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

3. 合理解耦/封裝 --- 封裝和解耦代碼是一個優秀的開發者必備的技能和習慣，這個能夠有效分組分塊分邏輯來管理本身的方法和邏輯，也是高度提高「易改編性，易於後面維護和擴展。

4. 重視備註 --- 在一些複雜業務邏輯中，必定要重點給本身寫下詳細的備註，沒有備註就等同於別人在看一本英文書，看的一臉懵逼。可是也要記得不要過分備註，每一行代碼都寫幾個字備註一下。這種就會反而下降代碼的可讀性，分邏輯塊，分模塊，分組備註相關內容。主要仍是清晰明瞭纔是重點。

🌟小總結一下： 當你養成了好的編寫代碼的習慣，有了高質量的代碼產出，你會發現你已經成爲一個高手，「快，恨，準」。要知道，若是你一開始只最求速度，你最後的技術債會嚴重拖累你的。最後時間都花在插屁股上了。拔苗助長！

---

總結

看完這邊文章咱們發現作爲一個開發者，不僅是須要提高本身的技術能力，技術素養也是重中之重。只有技術能力，在職場中會有不少壓力，職場中是不會給咱們全世界的時間來開發，也不會給咱們一個溫馨的環境讓咱們集中。因此做爲一個更出色的程序員，咱們身上必須擁有更多的防身技能，才能在咱們面對各式各樣的狀況和問題出現時，咱們能處於泰然，遊刃有餘。每每也是這些能耐才能讓咱們與衆多的開發者有明顯的區別。

但願這5大法則能夠助你在技術行業裏成爲更出色的開發者，在衆多的開發者中脫穎而出，升級加薪，走上技術和人生的巔峯。