在從事軟件開發的這幾年中，我見過無數程序員寫的代碼，風格迥異，有工作僅兩年就有良好編碼能力的，也有工作七八年代碼寫的一團亂的，當然，我私下里也和這些程序員們溝通過不少，然后發現初學者有很多思想上的誤區。
首先，他們會在網上找很多IDE，然后在各種社區看他們的評價，兩三天換一個，一個好的IDE軟件固然重要，但是IDE不能作為寫好代碼的標準。
其次，初學者更多關注的是代碼的最終結果。比如一段代碼能成功運行了，就認為自己實現了目標，殊不知從代碼運行速度，擴展性等方面，還有很多值得改進的地方，就是因為不注意這些細節，很多程序員到了職業生涯的后期，編碼技術一直未能提升。
壞的編碼習慣影響的不僅僅是項目進度，還會嚴重影響自己的職業生涯，隨著互聯網的不斷發展，很多公司的編碼已經漸漸的向“標準”靠攏，對于程序員的編碼風格和習慣都很看重。
對此，我總結了五種提高代碼質量的方法，希望對初級程序員以及老程序員能改進他們的編碼。
1.將大部分時間花在分析問題上
大多數的程序員在看完需求之后會直接跳入編碼階段。這種情況在初級軟件程序員的身上尤為明顯。初級程序員的性子都非常急躁，想盡快用更多的項目實踐來填充自己的履歷，提高自己的技術，但是這種方法尤不可取，越老道的程序員越會明白一個道理：
一個項目，70％的時間用于分析，30%時間敲代碼。
如果不去分析而直接編碼，首當齊沖的問題就是項目完成后會出現非常多的BUG，為解決這些BUG，你可以能花費很長時間，甚至會將原代碼推翻重新去寫。這樣反而得不償失。
所以每當進行新項目的時候，一定要先分析，提出一個解決方案，梳理成一個流程圖，然后再進行編碼。
2.一個問題，多種方案
“一個問題，多種方案”，是每個程序員最容易忽略的一點，一段代碼一旦完成就過了，不愿花費更多的時間去多找尋幾種解決方案，雖然說這會花費很多時間，但是如果能堅持這個習慣，思維邏輯會有很大增強，同時以后遇到相同的問題，你會找出最佳的解決方案。
這種方法也有助于提高程序員在后期所需要的批判性思維，有了批判性思維，遇到問題之后可以迅速整合出多種方案，根據速度，內存等其他因素選擇出最適合的解決方案。
當然，很多人在剛開始的時候根本想不出多種解決方案，我這里有個方法，可以在開源平臺或者社區搜索。比如StackOverflow和Github
3.多看看別人的代碼
即使在同一個項目組，也很少有程序員會互相看同事的代碼，只完成屬于自己的模塊。同理，初學者也不會去網上看其他人的代碼。
正如我上面所說的，每個程序員都有獨特的編碼風格。閱讀其他人的代碼會給自己帶來很多收益，除此之外，如果進行的是同一個項目，你也能了解到其他模塊的進度，能更加熟悉整個項目
所以在完成工作后，抽出一點時間來看看其他同事提交的代碼，進一步了解自己的項目。
4.培養自己的耐心
很多開發人員不注重細節，對待事情也沒有耐心，比如項目的單元測試，很多人對單元測試不屑一顧，認為單元測試的主要目的是測試代碼的覆蓋率，其實并非如此。
單元測試可以幫助開發者刪除不必要的代碼行，改善代碼和整體項目的性能。
我建議大家可以耐心一點，最好能給每個模塊編寫單元測試用例。試著實現90％以上的代碼覆蓋率，刪除不必要的代碼。
5.時刻更新自己的知識
如果自己不學習新的技術，那么五年之內，你必將遭到淘汰。
這句話并不是危言聳聽，而是時時刻刻正在發生著，就連負責維護開發語言的廠商，每年都在更迭版本，確保語言不會落后，被市場淘汰。
當然，這些語言的技術更新也會給開發者帶來很多便利，比如以下代碼：
// Old ApproachIf (sampleObject != null)
{
If (sampleObject.result != null)
{
string result =sampleObject.result;
}
}
// New approachIf (sampleObject != null)
{
string result = sampleObject?.result;
}
在舊的方法中，首先檢查對象是否為null，然后檢查該對象內部的特定值是否可用。最后才可以將該值分配給變量。
在新方法中，可以直接查詢對象的屬性，如果屬性為null，則返回null值，而不是拋出null引用異常。
這個實例很好的詮釋了新語言的便捷性。
所以我們要經常學習心得知識，關注技術博客，閱讀有關新功能的文檔。在新的項目中嘗試使用。
寫到最后，以上就是改善自己代碼技術的五種方式，希望對大家有所幫助。想學習更多編程技巧， 歡迎持續關注好學編程！
