將大塊代碼拆分成函數(shù)。

下班的時候還有問題沒解決，請關(guān)上電腦，明天再看。

YAGNI 原則（你不會需要它）：只寫別人要求你寫的功能。不要預(yù)測未來，只需要盡可能快地完成開發(fā)。只編碼解決當(dāng)前問題最必要的部分。

你不需要什么都懂，也不需要了解所有框架。最棒的事情莫過于打好基礎(chǔ)。在開始使用一個框架前先深入了解這門語言，學(xué)習(xí)基礎(chǔ)的事項（如 SOLID 原則），或者如何寫出干凈的代碼。

KISS 原則：KISS（保持簡單和愚蠢）原則表明，大多數(shù)系統(tǒng)保持簡潔而非復(fù)雜化，就可以運行得很好。盡管這很符合邏輯，但有時候卻很難做到。

不要想太多。

如果你和一個問題或 bug 斗爭了太長時間，先離開一會兒，等下再回來。通常，在離開辦公室去往衛(wèi)生間的路上，解決方案就會出現(xiàn)在腦海里。當(dāng)你對客戶或同事生氣時，也建議你暫時離開去走走，如果你還想保住工作的話……

學(xué)習(xí)寫有用的測試，學(xué)著用 TDD（測試驅(qū)動開發(fā)）。TDD 是一種軟件開發(fā)流程，它是對如下簡短開發(fā)周期的重復(fù)：寫測試；運行所有測試，查看新的測試是否運行；寫代碼；運行測試；重構(gòu)代碼；重復(fù)。

先解決問題再寫代碼。不要在一籌莫展的時候開始編程。

不要記代碼，而是理解邏輯。

如果你復(fù)制粘貼 Stack Overflow 中的解決方案，請確保自己首先理解它。學(xué)習(xí)用恰當(dāng)?shù)姆绞绞褂?Stack Overflow。

想學(xué)習(xí)，先實踐。創(chuàng)建示例，并使其運行，因為只通過閱讀來學(xué)習(xí)遠(yuǎn)遠(yuǎn)不夠。

研究他人的代碼，也時不時讓別人研究你的代碼。結(jié)對編程并進行代碼 review 是不錯的想法。

不要重復(fù)造輪子。

代碼是最好的文檔。

了解如何搜索。你需要有經(jīng)驗，大量閱讀，了解需要找什么。

你寫的代碼以后會由自己或別人進行維護，因此寫的時候想著讀者，不要把自己當(dāng)做最聰明的人。寫代碼要像寫故事一樣。

用谷歌解決錯誤的最佳方式是復(fù)制粘貼。

不要放棄，問題總能得到解決的。糟糕的時刻總會過去。

好好休息。解決問題的最佳方式是先讓大腦得到充分休息。

學(xué)習(xí)使用軟件設(shè)計模式。設(shè)計模式是軟件設(shè)計常見問題的解決方案。每個模式就像一個藍(lán)圖，你可以依據(jù)它進行自定義，進而解決自己代碼中的常見設(shè)計問題（記住，不要重復(fù)造輪子）。

盡可能地使用集成工具和自動化方式。

練習(xí)編碼套路（code kata）：編碼套路是一種編程練習(xí)，可以幫助程序員通過重復(fù)實踐來提升技能。示例參見：https://codingdojo.org/kata/

編程并達(dá)到接口水平，而不是實現(xiàn)水準(zhǔn)。依賴注入是必要的，參見 SOLID 原則。

重構(gòu)——測試 - 重構(gòu)。重構(gòu)即對現(xiàn)有代碼進行重建、改動，在不改變其內(nèi)部行為的前提下提升內(nèi)部結(jié)構(gòu)。

必要的時候?qū)で髱椭?#xff0c;不要浪費時間。

多實踐，熟能生巧。

盡管有時候注釋可以幫到你，但不要在這上面花費太多注意力。注釋可能是過時的。

了解自己的開發(fā)環(huán)境，并建設(shè)足夠強大的開發(fā)環(huán)境，如 IntelliJ。

重用組件。

在開發(fā) web 應(yīng)用時，思考移動端及其相關(guān)的電量和帶寬限制。

不要過早地優(yōu)化或重構(gòu)代碼。盡快做出最小可行性產(chǎn)品比較重要。

不要為了節(jié)約幾分鐘，而選擇低效的捷徑。每次寫代碼，都要竭盡全力。

遵循文檔標(biāo)準(zhǔn)。

用戶不是技術(shù)人才。開發(fā) UI 時時刻想著這一點。

經(jīng)常使用 GitHub 或 bitbucket 等源代碼控制系統(tǒng)，并頻繁進行小的提交更新操作。

使用 log 要比代碼 debug 更好。將所有關(guān)鍵部分記錄下來。

寫代碼時要保持連貫性。如果你使用一種風(fēng)格，請一以貫之。如果你和多人合作的話，請和整個團隊使用同樣的風(fēng)格。

不要停止學(xué)習(xí)，不止是學(xué)新語言或新框架，還要關(guān)注軟件開發(fā)基礎(chǔ)知識。

最后，保持耐心，保持熱愛。