1. 規劃

新手程式設計師往往剛拿到需求就會開始coding，實際上這樣並不高效。當拿到需求的時候，一定要以上帝視角考慮程式的整體結構，整個系統要分成哪幾個層次，有哪些模組，每個模組的功能的實現，模組之間如何銜接，甚至需要哪些函式的變數，這些都要儘量在coding之前想好。就像上帝為眾神分配任務一樣，上層分配規劃完成後再逐個施工，這樣方能事半功倍。

2. 借鑑和修改程式碼

事必躬親，用到的東西都自己寫，這樣真的就是敬業嗎？實際上，直接去借鑑相應的程式碼是一個非常高效的手段。現在網路上可以找到很多經典的程式碼，只需要稍微修改就可以拿過來用，而且經典的程式碼由於經過很多人最佳化，可靠性會比自己寫的更高。正所謂：高階程式設計師＝普通程式設計師+Google。

3. 認真註釋

當你在寫某個程式的時候，可能自己記得很清楚，這一段是什麼機制如何實現，但是寫的程式越來越多，會導致你想不起來當初為什麼這樣寫，改動和交接也十分麻煩。而對程式碼進行註釋就可以有效避免這種情況。註釋不僅可以讓人讀懂程式碼，甚至能讓讀程式碼的人獲取更多資訊，不信你看：

（這就是公司得罪程式設計師的下場哼）

4. 形成自己的變數命名規則

定義變數在寫程式中非常常見，一個程式可能用到成千上萬的變數，這些變數之間又有著錯綜複雜的聯絡。很明顯狗剩、鐵蛋、二妮、i、j這些名字是遠遠不夠的，不論是內部變數還是全域性變數，都要形成自己的一種命名規則，能夠一眼看明白變數的意思。

另外，還要儘量減少重名變數和容易混淆的變數名，如果變數定義出現問題，會容易讓人產生疑惑。所以只有養成良好的變數命名習慣，才能有效避免這類問題。

5. 認真對待編譯中的warning

新手程式設計師往往重視error忽視warning，覺得warning不影響編譯執行。當你的程式規模到了一定程度，這些warning可能就會讓你的程式出現匪夷所思的問題，到時候哭都找不到地方。所以一定不要忽略warning，對於每個warning一定要思考為什麼會出現，如何才能消滅，然後修改程式幹掉這個warning。

6. 看文件、部落格要多版本對照

看文件和部落格要注意多版本對照，很多對你有價值的資訊可能就藏在一篇初看覺得很難理解的文件中。

你：這文件並無卵用o(╯□╰)o。

文件：哼活該你學不到o(╯□╰)o

所以你要多看一些文件相互印證，然後去猜作者的用意。

7. Regexper等正則表示式視覺化工具

如果資料分析妹紙來找你幫忙寫正則表示式，可以用這個把正則表示式的編寫視覺化……不僅是為了機率極小的“打動芳心”效果，更重要的是降低溝通成本，節約雙方時間，這將在時間緊迫的時候為程式設計師帶來極大便利。

8. 寫無副作用的函式

把檔案讀寫和業務邏輯分開，保證業務邏輯相關的函式輸入什麼，就能得到什麼。如果得到的東西有錯誤，那麼就可以反求諸己，從輸入內容找到問題。

9. 利用程式碼自動生成工具

比如java有maven外掛mybatis-generator-maven-plugin……就可以直接自動生成DAO。

1. 入職前瞭解加不加班

2. deadline是老手的，而不是你的

老闆：“你是新來的小王吧，這裡有一個重要的任務……時間緊任務重……”這種時候，如果你忙不過來就早請示晚彙報——這個時候還會有人記得你是新手程式猿。畢竟以後就變成這樣，老闆：“你是剛來的老王吧，這裡有一個重要的任務……時間緊任務重……”

3. 教會產品經理使用搜索引擎

產品經理：你是新來的小王吧，老李讓我來問問你這個功能能不能做blabla……反正你是新手，也解釋不清楚，這個時候最好總結一下他的關鍵詞然後讓他百度。如果這是一位勤奮好學的產品經理，以後就會省掉很多麻煩。

4. 當一個企業說自己開源的東西有多好的時候……

要麼這個東西所應對的業務對你所在的小公司來說根本遙不可及，要麼就是進階版還要繼續花錢。

5. 技不如人Do not panic

技不如人Do not panic，是因為：恐慌不能解決任何問題。在承認自己和大神存在差距的同時，盡力去努力縮短它們就好，不要有太多負擔。

以上就是小慕為新手程式設計師整理的小技巧，當然適用與否還是要看大家自己的決定和判斷~雖然程式設計師在網上一直被調侃，但是其中很多人是懷抱著喜愛的態度在“高階黑”，小慕就已經在以往回答的評論中看到好多妹子喜歡程式設計師了呢！所以，如果你已經進入了這個行業，不妨好好利用這些小技巧，提升自己的工作能力，還是那句話，麵包和老婆都會有的~

其實在我看來，程式設計真的沒有什麼，最重要的就是兩點:思想和仔細。

要有程式設計的思想，也就是程式設計中使用的架構，模式等。

仔細就是要邏輯嚴謹，思考周全。

做到這兩點，你就會成為一個合格的程式設計師。

再來列一列一些可能不知道的小技巧吧！

1、學會使用 Google 搜尋。怎麼使用谷歌，別問我，自己想辦法，畢竟敏感資訊。

2、學會使用 stackoverflow 。可以很好的解決你的疑難雜症。

3、正確使用 GitHub。GitHub 上的優秀開源專案不僅可以避免你重複造輪子，也可以讓你學習原始碼，讓你知道高手的程式碼是怎麼樣的，價值很大，你收穫很多。

說實話，以上三個東西你利用好了，絕對成長很快。用過的程式設計師都說好。再接著說說程式設計中學習和總結的小技巧。

4、學會寫部落格，總結問題。寫寫自己的解決思路，挺好的一種提高總結問題的能力的方法。

6、遇到問題，一定要學會 debug 。debug 找出問題，解決問題是和合格程式設計師拉開距離的重要方式。

以上六點你要都能做好，你就很優秀了。重點來了，尤其是新手程式設計師，請重點看下面這篇文章，可以讓你豁然開朗。

https://mp.weixin.qq.com/s/8hiwbDTigsk0GZ31JZRynQ

讀完之後，你會感受良多的。

1. 對stackovewflow可以基本解決你一半的問題

2. 對google程式設計能解決另外30%的問題

3. 一個好的產品經理比高工資更重要

4. 現在的問題可能幾個月之後就有解決方案了，科技進步的很快

5. rm -rf /這種別人告訴你的命令先谷歌下

6. 頸椎好好保護

如果只是週而復始地寫程式碼，想必程式設計的工作會讓很多程式設計師發狂。如何在看似枯燥的工作尋找樂趣，我認為對工作的激情和興奮感、始終學習的態度，還有掌握一些實用高效的程式設計技巧，對於提升工作樂趣和效率大有裨益。今天我就跟大家分享一下25個實用程式設計小技巧，希望可以給大家的工作和學習帶來更多的思考。

1. 不要毫無計劃地寫程式碼，思考、調研、計劃、編碼、測試、修改，一個都不能少；

2. 不要寫程式碼前過度計劃，在一頭鑽進程式碼前做點計劃是好事，但是即便是好事，也可能物極必反。

3. 請勿低估程式碼質量的重要性，如果你只能夠關注你所寫的程式碼的一個方面，那麼肯定是可讀性。

4. 使用實現功能的最簡單方案，作為專業的程式設計師，你的職責不是找出問題的一個解決方案，而是找出問題的最簡單的解決方案；

5. 適時放棄，當你開始懷疑一個解決方案的時候，你就應該考慮拋棄它，並且重新思考這個問題。不管你已經在這個解決方案中投入了多少精力。像 GIT 這樣的版本控制系統能夠幫助你分開管理和嘗試多種不同的解決方案，把它利用起來吧；

6. 擅用 Google，除非你正在使用一種極其前沿的技術，否則當你遇到一個問題時，很可能別人早就遇到過同樣的問題了，並且也找到了解決方案了。給自己省點時間，先 Google 一下；

7. 做好封裝，基本的想法就是你想你的程式碼高內聚和低耦合，意思是說保持相關的程式碼在一起（在一個類中），降低不同類之間的相互依賴；

8. 做好規劃，寫好需求再寫程式碼，儘可能編寫目前正在實現的方案所需的最少量程式碼；

9. 要懂演算法，使用合適的資料結構；

10. 不要寫重複性程式碼，要用好配置檔案，不要使用沒必要的條件語句和臨時變數；

11. 做好程式碼註釋，但是不要給傻子都知道的程式碼寫註釋；

12. 一定要寫好測試，如果可能的話，甚至在開始寫程式碼實現需求之前，你就應該開始預估和設計需要測試校驗的情況了。測試驅動開發 （Testing-driven development, TDD）不是什麼花俏的炒作，它是會實實在在會對你思考功能特性、尋找更好的設計方案產生積極影響的。

13. 不要覺得程式碼執行起來就是正確的，有些時候程式碼的 bug 可能並不是顯而易見的；

14. 要能夠質疑既有程式碼，作為一個初學者，總是應該假定那些你讀不懂的、且沒有文件註釋的程式碼很可能就是糟糕的程式碼。質疑之，詢問之，使用 git blame 揪出罪魁禍首！

15. 不要過度迷戀最佳實踐，我覺得“最佳實踐”其實是害人的，它暗示著你不需要深入研究它，這就是有史以來最佳實踐，不用質疑！

16. 不要過度迷戀效能最佳化，如果你在執行程式碼之前就在最佳化它了，那很可能你就是在過早最佳化程式碼了，也很可能你正在費時費力做的最佳化是完全沒必要的。

17. 以使用者體驗為目標，要站在終端使用者的角度看問題。專業的開發者要考慮這個特定功能的使用者需要什麼、怎樣使用，要想方設法使得這個功能容易讓使用者發現和使用，而不是想方設法在應用中用最便捷新增這個功能，毫不考慮這個功能的可發現性和可用性。

18. 為你的開發任務挑選合適的工具，你可以使用最原始的工具建造房子，然後享受甜蜜時光。你也可以花費一些時間和金錢去了解先進的工具、更快地建造更好的房子。工具在不斷地改進中，你要樂意去學習它們、使用它們。

19. 要理解好程式碼問題和資料問題之間的關係，即使是程式中最小的 bug 也會導致它所管理的資料去到一種不可預測的狀態。尤其是當所有資料校驗都完全在這個有 bug 的程式中進行時。

20. 切勿重複造輪子，使用好現有的輪子和各種開源庫，會讓你事半功倍。當然，不要僅僅為了使用一兩個函式就引入一整個程式碼庫，在 JavaScript 中的典型例子就是 lodash 程式碼庫；

22. 用好版本控制工具和系統，新手往往低估了一個好的版本控制系統的威力，我這裡所說的好的版本控制系統其實就是指 Git；

23. 不要過度使用共享狀態，一個新手可能會嘗試使用定時器來解決這個共享變數的競態條件問題，特別是當他們必須處理一個數據鎖的問題時。這是危險的標誌，別這麼做，注意它，在程式碼複審中指出它，永遠也不要接受這樣的程式碼。

24. 正視 Error，Error 是好東西。Error 意味著你在進步，意味著你可以透過簡單的後續修改就獲得更多的進步。專業程式設計師喜愛 Error。新手則痛恨 Error；

25. 學會休息，任何人的大腦都需要休息，身體也需要休息。

首先是編譯器的快捷鍵要熟練掌握，掌握快捷鍵可以加快編碼效率，學會檢視編譯器控制檯的報錯資訊，可將控制檯的報錯資訊或異常資訊複製到瀏覽器裡檢視別人是怎麼解決的，報紅了並不可怕，要相信辦法總比問題多。谷歌跟百度是程式設計師行走江湖的必備技能，一定要學會。

看你是哪種型別的程式開發工程師，首先要熟悉自己工作內容的程式語言的同時，還要對工作中使用到的整合開發環境編輯器（IDE）有所熟悉，所謂的小技巧，可以在程式設計中對開發有助於提供效率，也可以對自己開發所熟悉的語言進行便捷書寫，每種開發語言都可以有特殊簡便的寫法，多熟悉瞭解一下，有助於個人開發之路一路前進。

武俠片看多了吧，哈哈

武俠片裡面某大神把畢生功力一下全部過繼給你，你一下就成了一代大俠。

這怎麼可能？

小技巧沒有，一些學習方法倒是有。

人比其他動物高階的地方在於人能舉一反三，觸類旁通

人也對比較神奇，有趣的東西比較容易集中注意力，能持續學習很長時間。

首先：語法、分支、迴圈、順序等結構

你可以做個簡單的遊戲猜數字、猜拳等

其次：學完io\util\lang包等

你可以做個21點撲克牌等簡單遊戲

然後：你學了socket，多執行緒，swing等更高深一點的知識

你可以做個線上聊天室的功能

再後：你學了jdbc,mysql

你做個XX管理系統，比如一個記賬簿，把你每天花的錢都記錄下來，難嗎？

等你完成這些你完全已經入門了，雖然離入行還有一段距離，整個過程你必定會碰到很多坑，你會經常去百度，會經常問朋友、大牛一些技術難點。

那麼恭喜，在這個摸索過程中你已經掌握了學習的方法，整個過程你也看到是圍繞些小遊戲、或者和你生活息息相關的小案例進行的，你學習起來也不會枯燥

恰恰在這不斷的練習中，你能學習得更好。

至於你說的小技巧，我真沒有，你必須自己刻苦努力，真正的喜歡上寫程式碼，如果是別人逼迫你你肯定學得不很好（但有人逼迫你也好，現在網際網路誘惑太多，人很容易分心，如果有個你尊敬，愛戴的人一直敦促你，你肯定也不會厭煩）。

至於後面學到的各種框架的知識你完全可以和前面學基礎一樣，並沒有什麼神奇的地方，堅持，努力就是最好的小技巧。

關注是為了再一次的交流，戳一戳右上角的關注吧！

1.重構是程式設計師的主力技能。

2.工作日誌能提升腦容量。

3.先用profiler調查，才有臉談最佳化。

4.註釋貴精不貴多。杜絕大姨媽般的“例注”。漫山遍野的碎碎念註釋，實際就是背景噪音。

5.普通程式設計師+google=超級程式設計師。

6.單元測試總是合算的。

7.不要先寫框架再寫實現。最好反過來，從原型中提煉框架。

8.程式碼結構清晰，其它問題都不算事兒。

9.好的專案作風硬派，一鍵測試，一鍵釋出，一鍵部署; 爛的專案生性猥瑣，口口相傳，不立文字，神神秘秘。

10.編碼不要畏懼變化，要擁抱變化。

11.常充電。程式設計師只有一種死法：土死的。

12. 程式設計之事，隔離是方向，起名是關鍵，測試是主角，除錯是補充，版本控制是後悔藥。

13. 一行程式碼一個兵。形成建制才能有戰鬥力。單位規模不宜過大，千人班，萬人排易成萬人坑。

14. 重構/最佳化/修復Bug，同時只能作一件。

15. 簡單模組注意封裝，複雜模組注意分層。

16. 人腦效能有限，整潔勝於雜亂。讀不懂的程式碼，嘗試整理下格式; 不好用的介面，嘗試重新封裝下。

17. 迭代速度決定工作強度。想多快好省，就從簡化開發流程，加快迭代速度開始。

18. 忘掉最佳化寫程式碼。過早最佳化等同惡意破壞；忘掉程式碼作最佳化。最佳化要基於效能測試，而不是糾結於字裡行間。

19. 最好的工具是紙筆;其次好的是markdown。

20. leader問任務時間，若答不上來，可能是任務拆分還不夠細。

21. 寧可多算一週，不可少估一天。過於“樂觀”容易讓boss受驚嚇。

22. 最有用的語言是English。其次的可能是Python。

23. 百聞不如一見。畫出結果，一目瞭然。除錯耗時將大大縮短。

24. 資源、程式碼應一道受版本管理。資源匹配錯誤遠比程式碼匹配錯誤更難排查。

25. 不要基於想象開發， 要基於原型開發。原型的價值是快速驗證想法，幫大家節省時間。

26. 序列化首選明文文字 。諸如二進位制、混淆、加密、壓縮等等有需要時再加。

27. 編譯器永遠比你懂微觀最佳化。只能向它不擅長的方向努力。

28. 不要定過大、過遠、過細的計劃。即使定了也沒有用。

29. 至少半數時間將花在整合上。時間，時間，時間總是不夠。

30. 與主流意見/方法/風格/習慣相悖時，先檢討自己最可靠。

31. 出現bug主動查，不管是不是你的。這能讓你業務能力猛漲、個人形象飆升; 如果你的bug被別人揪出來.....呵呵，那你會很被動～≧﹏≦

32. 不知怎麼選技術書時就挑薄的。起碼不會太貴，且你能看完。

33. git是最棒的。簡單，可靠，免費。

34. 僅對“可預測的非理性”拋斷言。

35. Log要寫時間與分類。並且要能重定向輸出。

36. 註釋是稍差的文件。更好的是清晰的命名。讓程式碼講自己的故事。

37. 造輪子是很好的鍛鍊方法。前提是你見過別的輪子。

38. code review最好以小組/結對的形式。對業務有一定了解，建議會更有價值（但不絕對）。而且不會成為負擔。管理員個人review則很容易成team的瓶頸。

39. 提問前先做調研。問不到點上既被鄙視，又浪費自己的時間。

40. 永遠別小看程式媛(╯3╰)