在現在這個技術高速發展的時代，無論你是在校學生，還是技術職場中的精英，都會面臨需要持續提升。但是如果只知道提升技術能力，忽略了一些技巧和技術素養的培養和習慣。你會發現你再有能力，也變得無用武之地。因爲真正的強者是不會只依賴TA的裝備。更多的是技巧，經驗，應變能力還有思想。
這篇文章會教5大法則助我們成爲更出色的開發者，在衆多開發者中脫穎而出的訣竅，也會在我們的技術職業生涯中給我們很多的幫助。
1. 先思考，後設計，再下手
多數拿到新功能需求，大致有思路就直接下手開始寫代碼，半天下來發現這個需求或者功能越想越複雜。前進的路開始迷茫，內心越來越煩躁（甚至開始埋冤產品，這個需求怎麼搞那麼複雜，太坑了！），禿頭的噩夢開始了。(╯ಠ_ ಠ）╯
其實開始寫代碼之前，思路就沒有整理清楚或者目標不明確，想着想着就偏離了初衷。越深入考慮就越複雜，考慮到解耦代碼，封裝服務，設計數據庫，擴展性，通用型等等這些因素。想想都已經邁入了從0到放棄的節奏了。甚至遇到過“杞人憂天”的程序猿小哥哥，小姐姐。TA們問我說：“如果那一天服務器在我處理的時候停電了怎麼辦呀，如果服務器爆炸了呢？！”（這種絕對不誇張，還真的有哈）
其實就是因爲前期沒有充分的思考和設計所以纔會導致後面的手慌腳亂。
深度思考
投入代碼的海洋之前，我們需要先深度思考這個功能需求，整理清楚它的目的，場景，難點。
-
明確目的 —
明確功能需求的目的，瞭解清楚它是用來做什麼，爲了達到什麼目的。
好比如現在是要開發一個文章搜索。一聽到這個，你會想到什麼呢？文章標題搜索？全文搜索？拆詞搜索？標籤化搜索？還能想到更多各式各樣的搜索功能可以在這個功能需求中實現。如果不明確目的是什麼，可能一開始就想複雜了。最終可能只是需要一個簡單的標題搜索而已。而我們花了半天在想一大堆的可能性，系統要承載這個功能需要如何設計。 -
使用場景 —
場景因素決定了這個功能的技術架構，也決定它的難度等級。
那場景到底是什麼？其實就是這個功能規模的影響因素，舉個例子：後端來說場景可以是這個文章搜索涉及的數據量級，還有使用的用戶量級和併發量級。這些都是會直接關係到後端架構的設計，和代碼的編寫策略。那如果是前端呢？前端要考慮的因素有：這個搜索是否有重複使用性（是否需要封裝成組件），是否需要加強的交互（比如，實時聯想歷史搜索或者關鍵詞），是否涉及前端需要數據與交互結合處理數據來達到一些特殊交互。這些都是直接和前端的實現方式息息相關的。 -
分析難點 —
明確目的，鎖定場景後，就可以開始解刨功能需求找到技術難點。
注意一個誤區，這個思考過程不是決定技術架構和策略，這裏只是單純通過已有的關聯性系統功能，技術能力範圍，數據量級，用戶量級，開發時效等因素排查出這個功能需求開發的難點。如果在這裏就開始考慮到設計和策略，我們就會過多的花時間在一兩個難點上，甚至過度設計。我們的重點是分析出某些部分的存在難度，先解刨出來，後面開始架構設計和策略的時候會特別注意到這些難點。
🌟小結一下：
在設計和開發一個功能需求前，有一個系統化的思考模式可以讓我們快速的明白一個功能需求和整理思路！習慣先深度思考，可以大大提高自身技術的成長。慢慢我們會發現你分析一個功能需求會看的更加透徹，開發效率也會隨之上升。
設計與策略
開發任何一個功能，特別是大型系統，我們都是需要有一個架構設計的過程。系統架構設計會包括：
- 後端 — 數據庫，設計模式，編寫策略（例如：服務層封裝）等。
- 前端 — 組件封裝，底層工具類，代碼接受，模塊化等。
設計這個功能也是有一套方式方法可以提高這方面的效果和能力。
-
畫圖 — 使用UML/思維導圖/邏輯圖等工具整理自己的功能邏輯流程， 這個可以強化功能的背後的思路。通過畫圖可以完整的，可視化的整理了一遍你大腦中的功能邏輯思路。大大強化了這個邏輯在你腦海裏的影響。在畫圖的過程中，你還會挖掘出一些細微的問題和缺陷，通過這個過程，你的邏輯思路會得到優化和強化。
-
探討 — “集思廣益”，集合大家的力量必定比你一個人想強，所以設計出你的架構和邏輯圖後，可以與你的夥伴一起探討和分享。你會發想TA們可以看到你看不多的角度和觀點。從而可以更加優化你的設計和邏輯。如果你有看過我寫的《如果高效學習編程》，應該知道“小黃鴨教學法”，在你講解你的設計和邏輯思路的過程，從思想轉化爲語言的過程，你已經在重新整理了一片你的設計思路和邏輯。你可能會在過程中發現一些你預想不到的全新觀點。
-
ETC原則 — “Easy to change” 易於改編原則來源於一本書叫《程序員修煉之道》，意思就是代碼可以更容易被改遍的纔是最好的代碼 — “Good code is easy to change”。設計和編程中最重要的一個點就是，保持代碼靈活和易於改編重用的架構技術。（這裏我先透露一下，近期我也又在準備寫一篇專門講解有關此原則的文章，感興趣的童鞋，敬請期待，可先關注本博主哦）。在設計架構的時候如果遇到兩個或者多個選擇，那就遵循ETC原則，選擇擴展性高，易於改編更好的方案。
🌟小結一下：
做好功能需求整理和設計模式的建立，對於功能需求的瞭解已經可以達到一定的深度和理解的相對透徹。這個時候就可以開始一頭扎進去代碼的海洋了。你會發現自己的代碼會寫的很順暢，一種乘風破浪的感覺，恍惚敲代碼都帶風。
2. 把功能需求分解成小任務
接到一個功能需求時，衆多開發者都會覺得，這個需求含有多個功能點，感覺無從入手。還會有一種莫名的複雜感。這個是因爲一個功能需求裏面很多時候對開發來說都是參合了多個小功能。
這個時候最好的解決辦法就是儘量的分解需求爲多個小任務。在《如果高效學習編程》中也有提到一個觀點 — “化繁爲簡，小步快跑”，把複雜的功能拆分成多個小的點，也能讓自己會迅速的開展工作。同時也會更有衝勁，每個任務如果太過複雜，實現時間太過長，會慢慢覺得枯燥無味，效率就會大大下降。
如何分解需求？
我團隊的很多小夥伴一開始自己拆解功能需求的時候，經常會問我，“不知道需求怎麼拆解，感覺拆的太細又不實際，但是如果不拆細，又覺得沒有拆的必要“。這裏我來給大家一些方法來拆解功能需求：
- 按流程 — 每個功能需求都有一定有一個或多個的
業務流，邏輯流，數據流。可以使用這個流程分解。- 業務流 — 可以按照業務的流程拆可，比如註冊賬號，短信通知，推薦聯繫人。這個系統的註冊到通知到推薦聯繫人。其實都是註冊流程中的，但是我們可以按照流程拆開3個獨立任務進行開發。
- 邏輯流 — 按照不同的業務邏輯拆分你的任務，使用相同註冊賬號的例子，可以拆分爲：檢測用戶名重複，添加用戶的邏輯，推送短信邏輯，建立短信發送服務等等。
- 數據流 — 也可以理解爲按照查詢數據的邏輯來分割你的功能需求。比如建立賬戶體系倉庫，建立短信發送記錄查詢倉庫等等。
- 按功能模塊/體系 — 如果你接到的是一個大的功能需求，這個功能可能就含有多個功能模塊在其中。比如我們要做一個財務模塊，我們可以首先根據功能模塊或者體系拆分：對賬體系，提現體系，資金流水，銀行賬戶管理，資金管理等等。
🌟小結一下：
當我們接到的功能需求較大的時候，我們一定要把需求“化繁爲簡，小步快跑”的方式進行分解。這個會大大有利於我們提高效率。畢竟在技術開發中長跑是會精疲力盡的，小步快跑才能讓我們高效使用腦力。分解需求還能讓我們注意到更細微的功能點，那樣我們不會在複雜的功能需求中遺漏一下微小的功能點。
3. 結隊開發，代碼評審
在開發的過程中，開發者們往往會沈醉於自己的完美代碼之中。我一開始也是如此，自己寫了一個服務，無論是命名，寫法，封裝，邏輯設計，架構設計等等，我都覺得是完美無暇了，甚至覺得都被自己的代碼美到了。但是越是這個時候，我們就越是無法發現美中不足。我們要接受一個現實就是沒有最好，只有更好。
首先要明白，自身的問題大部分人大概率都會是看不清自己的。內心的想法是：自己一直都是這麼做的，所以不會覺得自己是有可以改善的點，也會總以爲自己是對的。所以我們需要人來提點和指出我們的不足和缺點。人生如果有一面好的鏡子是可以照出自己的不足，推動自己改變，成長，提升。不然人會深醉在自己的迷惑中無法找到自身的缺點，最終就是走入無法突破的瓶頸。
在開發中也是，找一個或多個開發小夥伴審查自己的代碼。因爲每個開發者都擁有不同的經驗。一個優秀的團隊，每一個成員都有自身特別專研的領域和技術能力。或多或少都是一種互補的狀態下組成的團隊。所以互相審查代碼可以達到互相學習，互相吸收彼此的特長和優點，然而達到最大化的互補，共同寫出最好的代碼。
-
結隊開發 — 其實結對開發，就是每次開發一個功能，你會分配一個夥伴，或者建立一個小組。待開發的過程中，可以彼此討論架構和設計方案，實現方案等等，互補也互相學習利於成長，“兩人搭配幹活不累”。結隊開發也能有效避免很多功能中的細微細節被忽略，還是那句話“兩個腦袋必定比一個腦袋強”！
-
坦誠的審查 — 在開發完一個功能後，找到你的隊員互相閱讀並且審查彼此的代碼，從而互相提出寶貴的意見。 但是其實很多時候，因爲彼此是同事也是開發小組中的戰友，在“審查”對方的優秀“作品”的時候給最真實的反饋意見，往往我們和對方心裏會覺得這是一種“批判”，一種“批評”。然而因爲這種顧慮和心態，讓我們在審查的過程中有一種莫名的壓力和負擔。所以給出的意見不能一針見血。“真實坦誠的話大多數人都不愛聽，讚美的謊言都很中聽”，也可以說是“忠言逆耳”。但是往往就是最真實的反饋意見是對彼此最有價值。也是這樣才能在技術的道路上，讓自己看到與明白自身的不足並且更好的去改進，從而在這條道路上彼此都能越發的走的更快更遠。所以如果都想讓自己和隊員有快速成長，那就更需要我們對彼此的知識成果予以尊重，予以坦誠相待的態度，給予隊員代碼中不足之處的反饋，也謙虛誠懇的接受別人的意見。這是代碼審查重中之重！
在我的團隊中提出使用結隊開發，代碼審查制的時候，我收到很多反饋：“我們本來就是敏捷迭代開發，時間很緊湊，不夠時間去審查”，“每個人的技術能力參差不齊，有些人無法讀懂彼此的代碼”，“功能裏面摻合着業務和功能需求的業務流程，對方沒有做我的功能業務，看不懂呀”等等等等。一開始大家勇於提出了很多問題。
那我們怎麼搞？不用慌讓我們來分析一下，提出解決方案：
- 時間問題 — 敏捷迭代中，都是小步快跑，迭代週期根據項目而定，但是大致都是1-4周的範圍之內。時間確實是比較緊迫的。但是互相審查代碼這個好處實在是很多，所以就算要在敏捷迭代中耗費一點時間也是非常值得的。
方案：每個人在每天早上就花1小時，審查前一天小夥伴們提交審覈的代碼，然後在Gitlab這種代碼管理平臺中直接在代碼中填寫反饋意見。這樣時間是可控的，也不會讓開發者浪費太多時間在審查中。
- 能力參差不棄 — 這個是審查中的問題，也是爲什麼更需要審查的原因。不觸動互相審查，在團隊中給彼此意見讓團隊的總體能力拉平，能力中的參差不棄的問題就永無法解決。
方案：首先開個羣，或者開個會議，互相提出自己的優缺點，還有提出自己今年想提升的方面。找到團隊成員各自的強項其實問題就好解決了。把強項和有這方面想提升的人結隊開發，這樣就可以發揮有強項人的能力，同時幫助了有這塊短板的戰友。而且，別人的強項也可能是你的短板，很少有開發者是方方面面都很強的。別人身上肯定有你可以學到的東西。所以彼此都有良好的學習文化和心態。
- 業務不熟悉 — 其實代碼審覈不是去測試對方的功能和業務，我們是寫代碼的開發者，不是測試工程師。代碼審查的主要目的是爲了，提高研發質量，把控代碼規範，提高編寫能力，提高技術知識。
方案：所以我們讓開發者互相審查的是，代碼質量，實現方式，架構設計，代碼規範，編寫策略等方面，這種是不需要知道業務的，如果這些有涉及業務的需要才那麼實現的，可以詢問對方計算難點在哪裏：是查詢？數據的處理？審查的重點放在技術本事不是業務代碼的層面上。
🌟小結一下：
開發者基本上都是抱團工作的，這種環境下都是很適合互補互相學習的環境。如果想彼此有快速的成長，那就需要我們互相去給彼此提出坦誠又寶貴的意見，從中吸取彼此的優點和強項。這樣每個人在這個團隊中都會得到高速的提升。
如果你所在的公司領導沒有推行這種模式，可以提議一下，如果因爲公司的情況不合適，可以自己組隊互相分享代碼探討，這樣還是能達到互相學習和提升的！
4. 在安靜的環境中開發
開發者在日常工作中，都是要高度集中，腦力全開的狀態下工作的。所以環境造成的干擾對開發者而言是很影響效率的。一個難題，一段代碼的思路，都是需要高度集中，在大腦中1000QPS的輸出速度來思考問題和邏輯。所以如果在過程中被聲音，交談，或者其它環境的干擾，就會被打斷思路，然後陷入一個不停的思路重組的過程，大量的時間都被消耗掉了。
當年我剛剛當上了研發主管，開發於管理並行。發現自己每天都處於高併發狀態，同時幾件事情在處理，溝通，回答問題，協調工作，分析需求，與產品經理互懟，功能設計，功能規劃，任務分解，然後就是研發。這一堆的事情都是日常必須要做的事情。我發現在研發的過程中，總會有那麼一兩個人來打斷我的思路，當我大腦在全速前進的時候，突然在高速公路上出現了一個“程咬金”。解決了TA的疑問之後，重新投入研發，需要花至少10分鐘重新整理思路和投入狀態，大腦回歸原來的速度。但是萬萬沒想到，第二個人又來了。當時的我就感嘆了一句，“做一個小小開發真的是太幸福了”。
其實不只是技術管理崗會遇到這種問題，做一個研發組的開發者也會遇到，會有產品經理，測試，其他同事來請教你，給你指bug等等的事情需要和你溝通。所以這種干擾是無法在崗位或者職責上避免的。
那我們怎麼才能做一個靜靜的小開發呀？(ლ `Д ́ )ლ，我來告訴你一些小祕訣吧：
-
番茄工作法 — 給自己定好20-60分鐘的高度集中的工作時間，這個時間內誰都不要過來打擾你，如果這個時間段有人來找你，你問一句“不好意思，我現在有點忙，事情緊急嗎？不緊急我過xx分鐘過來找你“。如果對方的事情是不緊急的，你就可以繼續投入開發。到了一個25分鐘階段結束的時候，你再起來跟對方溝通。時間是很寶貴的，爲了可以讓大家高效溝通，也高效率開展研發工作。我們要高效運用時間。
-
帶上耳機 — 如果音樂會打擾你思路的話，就開一點輕音樂，或者一些大自然環境的聲音。這樣可以幫助你高度集中，不讓自己聽到一些能打擾你的聲音。這種也是有效的管理好自己的耳門，讓自己高度集中在研發中。我一般不會告訴別人，別人看到你帶着耳機，高度集中的樣子，莫名的會給到TA人心理壓力和心理負擔，會想這一刻過去找你，會不會打擾到你的。
-
免打擾模式 — 在你高度集中的時候，開啓手機的免打擾模式，關閉你電腦裏面一些與你現在工作無關的應用和網頁。只要不是工作的羣都可以開啓消息免打擾。在你番茄工作法的休息時間段，再去看一看消息，加加水，走動一下放鬆一下。（但是記得一定要控制自己的休息時間，休息過長會導致完全脫離工作狀態，要重新進入狀態耗費的時間就會變長）
🌟小結一下：
技術研發是一個需要高度集中的腦力活，大腦的QPS需要保持在較高的速度和狀態才能達到高效。所以要學會自控，更要把控好自己所在的環境與人。時間是寶貴的，只有珍惜時間纔會在最短時間內達到最大量度的產出。如果你能做到，你會發現你加班會變少，工作效率會提高。
5. 不要只追求速度
開發者的研發速度快固然是好，但是隻最求速度，就會降低質量，到頭來我們會發現總的完成速度可能更長。爲什麼？ 速度和質量是相輔相成的。速度過快，就會降低質量，質量降低了，後面你會累積很多技術債，你的功能就會出現很多BUG，還有可能出現性能，寫法，規範問題。後面還需要花大量的時間給自己擦屁股，甚至還需要你的戰友爲我們擦屁股。所以呢？快不一定真的快，“正所謂急功近利，最後可能適得其反”。
所以在開發的過程中，一定要先養成重視自己的代碼質量的習慣，包括：
- 規範 — 良好的規範會高度提升可讀性，後面回來修改，修復，擴展都會更加容易
- 策略 — 一個運用好的編寫策略的代碼會更有“易改編性” （前面說到的ETC原則）
- 合理解耦/封裝 — 封裝和解耦代碼是一個優秀的開發者必備的技能和習慣，這個可以有效分組分塊分邏輯來管理自己的方法和邏輯，也是高度提升“易改編性，易於後面維護和擴展。
- 重視備註 — 在一些複雜業務邏輯中，一定要重點給自己寫下詳細的備註，沒有備註就等同於別人在看一本英文書，看的一臉懵逼。但是也要記得不要過度備註，每一行代碼都寫幾個字備註一下。這種就會反而降低代碼的可讀性，分邏輯塊，分模塊，分組備註相關內容。主要還是清晰明瞭纔是重點。
🌟小總結一下：
當你養成了好的編寫代碼的習慣，有了高質量的代碼產出，你會發現你已經成爲一個高手，“快，恨，準”。要知道，如果你一開始只最求速度，你最後的技術債會嚴重拖累你的。最後時間都花在插屁股上了。適得其反！
總結
看完這邊文章我們發現做爲一個開發者，不只是需要提升自己的技術能力，技術素養也是重中之重。只有技術能力，在職場中會有很多壓力，職場中是不會給我們全世界的時間來開發，也不會給我們一個舒適的環境讓我們集中。所以作爲一個更出色的程序員，我們身上必須擁有更多的防身技能，才能在我們面對各式各樣的情況和問題出現時，我們能處於泰然，遊刃有餘。往往也是這些能耐才能讓我們與衆多的開發者有明顯的區別。
希望這5大法則可以助你在技術行業裏成爲更出色的開發者，在衆多的開發者中脫穎而出，升級加薪，走上技術和人生的巔峯。
推薦閱讀
在本文章裏面有講述到一些我其他文章中的觀點，如果想詳細閱讀，這裏有一些推薦閱讀的文章。
- 《如何高效學習編程》 — 編程確實不是一件容易的事情，除了要有較強的邏輯思維，還需要花大量的時間和集中力來提升或者維持一定的高度。
- 《你真的懂怎麼寫服務層嗎？》 — 其實很多系統架構裏面都有服務層，但是服務對很多開發人員來說都有很多不同的定義和寫法。甚至在我待過的公司裏都有不同的寫法和編寫模式。每個人每個團隊每個項目都有對服務不同的理解。那到底什麼是服務，怎麼理解纔是對的呢？
最後感謝大家的閱讀和支持，你們的點贊和關注都是給予我繼續寫作最大的動力。
讓我們一起終身學習，在代碼的海洋中找到快樂與自我。
