吃一堑长一智，做为程序员的咱们记住这几点

正文

一、多沟通，先理解需求，再动手写代码。

墨菲定律真的很适用需求沟通，你不理解的需求作出来每每都是错的！这样只会浪费时间，浪费精力。

2.写代码前先要理好思路，接着再写代码也不迟

拿到需求，按照要实现的功能，先分析去实现的思路。 在分析实现思路的时候，能够一边分析，一边用中文把它写下来。或者你在工具里直接写成注释，那接下来的工做就是一个个翻译的过程，很容易实现了。能够避免少走不少弯路。

三、业务高于技术

从绝对的价值来讲，技术比业务重要的多，可是，从企业的角度来讲，技术是为公司商业作服务。因此对企业来讲，业务远比技术重要。

四、必定要写注释

不少人不肯意写注释，其实写注释主要目的是为了提升程序的可读性，好的程序应首先易于阅读，其次才是效率高低的问题。注释少了,别说别人看,时间长了本身都看不懂本身的代码！

五、频繁改需求

偶尔改需求是很正常的事情，由于需求根据商业需求不断调整的，改需求是再正常不过的事。若是频繁地改需求。那你可能就要抱怨了！可是要学会理解，毕竟拿工资干活也是很正常的事情！

六、需求文档必定要写！

若是没有写需求文档会致使这个需求只有公司的某我的知道，而其余人若是想要参与到这项工做中就须要问他，若是大部分需求仍是经过口头沟通，不写文档作记录，后续就容易扯皮！因此写好了需求文档，谁均可以看，谁也别问谁，谁也别影响谁。需求文档是属于流程规范化的一个部分，这是专业性的表现。

七、认为有错的地方必定要及时改

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

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

可能最近在网上学了新技术，若是没有百分百把握，最好仍是不建议使用.引入新技术虽然是好事，也是一个组织寻求专业性进步的必经之路。可是，你回想一下你工做中用到过的新技术，有没有被“坑”过？我估计每一个人都被“坑”过吧！

九、尽量本身解决问题

任何一个企业的老板都但愿本身的员工可以自主独立的解决遇到的问题，而不是一遇到问题，就要向老板、同事索要解决问题的方法。若是真的遇到本身解决不了的问题了那就要及时向领导、同事求助，以避免出现更大的问题。

十、本身先测几遍

写了代码不测试就能用的，除非你是大神！否则通常都有残留 的BUG在里面！因此本身仍是要测过以后在扔给测试人员去测，要保证质量！同时也不要浪费别人的时间。

关于我

更多Android高级面试合集放在github上面了
须要的小伙伴能够点击关于我 联系我获取**

很是但愿和你们一块儿交流 , 共同进步

目前是一名程序员，不只分享 Android开发相关知识，同时还分享技术人成长历程，包括我的总结，职场经验，面试经验等，但愿能让你少走一点弯路。