程式員從心理上講都是喜愛自己的代碼的，
正確的軟體開發應該是懶惰式開發，也被稱作忍耐式開發；這種開發方式的表現是，在真正動手寫代碼前，程式員要花大量的時間通盤考慮所有可能的解決方案和途徑，
這可以看作是延緩寫代碼，在沒有完全理解問題前絕不動手寫代碼，
先把問題理解清楚，確保將要寫的代碼能真正的解決問題，這將會避免之后寫出大量無用的代碼，
這里說的先把問題弄清楚，表現有：
真正的理解需求，讓產品部門(業務分析部門)弄清楚他們真正需求的是什么，
這些部門通常不給足夠的時間來整理需求，
他們經常不是請教問題領域專家，而是順從領導的意見，
他們通常無法提供前后一致或完整的需求意見，
清楚跟團隊中的其它程式員或其他團隊中的程式員需要那些互動，如何互動，這包括：1）使用白板交流；2）畫流程圖(UML或Visio)，
你需要花大量的時間調研，來確保需求符合實情，來做作業讓你和同事的交流有共同的語言語意，然而，程式員都喜歡立刻沖上去編程，喜歡在電腦前不停的敲代碼，
在真正的軟體開發中，只有5%的開發時間是有效率的，如果你發現一個程式員用100%的時間都在盯著螢屏，那么，你看到的這個程式員是最糟糕的程式員，
爛程式員不喜歡去修改已經寫成的爛代碼，相比起優化自己的代碼，他們更愿意簡單的增加更多的代碼，以此來彌補之前的缺陷，更糟糕的是，他們喜歡把責任歸咎于他人，
最終，一堆不好用的代碼上在來另外一堆不好用的代碼，整個系統變得到處是bug，極不穩定，
優秀的程式員經常也會寫出爛代碼，但他們能看到那些代碼需要優化，哪些需要重寫，優秀的程式員和不優秀的程式員的區別就在于對有問題的代碼的態度，優秀的程式員的做法是：
如果代碼整體上好的，那就重構代碼，
如果代碼整體上有問題，那就重寫代碼，
當代碼中有需要優化或需要重寫的地方時，時間拖的越久，你就越難回頭解決這些問題，因為對這些代碼依賴的程式會越來越多，越來越深，當你優化這些代碼時，相關的依賴也需要進行相關修改，
當積累的問題越來越多時，輕松的優化/重新這些代碼已經變得不可能，而使用繼續增加代碼的方式來彌補之前代碼問題，會讓系統變得越來越不穩定，
如果腦子里沒想清楚，那就懶一些，把寫代碼的時間往后推，
另外如果你想更好的提升你的編程能力，學好C語言C++編程！彎道超車，快人一步！筆者這里或許可以幫到你~
分享（原始碼、專案實戰視頻、專案筆記，基礎入門教程）
歡迎轉行和學習編程的伙伴，利用更多的資料學習成長比自己琢磨更快哦！
免費學習書籍：
免費學習資料：
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/262827.html
標籤：其他