吃一塹長一智，做爲程序員的咱們記住這幾點

正文

一、多溝通，先理解需求，再動手寫代碼。

墨菲定律真的很適用需求溝通，你不理解的需求作出來每每都是錯的！這樣只會浪費時間，浪費精力。

2.寫代碼前先要理好思路，接着再寫代碼也不遲

拿到需求，按照要實現的功能，先分析去實現的思路。 在分析實現思路的時候，能夠一邊分析，一邊用中文把它寫下來。或者你在工具裏直接寫成註釋，那接下來的工做就是一個個翻譯的過程，很容易實現了。能夠避免少走不少彎路。

三、業務高於技術

從絕對的價值來講，技術比業務重要的多，可是，從企業的角度來講，技術是爲公司商業作服務。因此對企業來講，業務遠比技術重要。

四、必定要寫註釋

不少人不肯意寫註釋，其實寫註釋主要目的是爲了提升程序的可讀性，好的程序應首先易於閱讀，其次纔是效率高低的問題。註釋少了,別說別人看,時間長了本身都看不懂本身的代碼！

五、頻繁改需求

偶爾改需求是很正常的事情，由於需求根據商業需求不斷調整的，改需求是再正常不過的事。若是頻繁地改需求。那你可能就要抱怨了！可是要學會理解，畢竟拿工資幹活也是很正常的事情！

六、需求文檔必定要寫！

若是沒有寫需求文檔會致使這個需求只有公司的某我的知道，而其餘人若是想要參與到這項工做中就須要問他，若是大部分需求仍是經過口頭溝通，不寫文檔作記錄，後續就容易扯皮！因此寫好了需求文檔，誰均可以看，誰也別問誰，誰也別影響誰。需求文檔是屬於流程規範化的一個部分，這是專業性的表現。

七、認爲有錯的地方必定要及時改

你感受可能會出現Bug的地方，必定會有bug！

八、使用本身有把握的技術

可能最近在網上學了新技術，若是沒有百分百把握，最好仍是不建議使用.引入新技術雖然是好事，也是一個組織尋求專業性進步的必經之路。可是，你回想一下你工做中用到過的新技術，有沒有被「坑」過？我估計每一個人都被「坑」過吧！

九、儘量本身解決問題

任何一個企業的老闆都但願本身的員工可以自主獨立的解決遇到的問題，而不是一遇到問題，就要向老闆、同事索要解決問題的方法。若是真的遇到本身解決不了的問題了那就要及時向領導、同事求助，以避免出現更大的問題。

十、本身先測幾遍

寫了代碼不測試就能用的，除非你是大神！否則通常都有殘留 的BUG在裏面！因此本身仍是要測過以後在扔給測試人員去測，要保證質量！同時也不要浪費別人的時間。

關於我

更多Android高級面試合集放在github上面了
須要的小夥伴能夠點擊關於我 聯繫我獲取**

很是但願和你們一塊兒交流 , 共同進步

目前是一名程序員，不只分享 Android開發相關知識，同時還分享技術人成長曆程，包括我的總結，職場經驗，面試經驗等，但願能讓你少走一點彎路。