吃一堑长一智，作为程序员的我们记住这几点，三级缓存框架问题你都了解了吗

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

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

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

3、业务高于技术

从绝对的价值来说，技术比业务重要的多，但是，从企业的角度来说，技术是为公司商业做服务。所以对企业来说，业务远比技术重要。

4、一定要写注释

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

5、频繁改需求

偶尔改需求是很正常的事情，因为需

《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
浏览器打开：qq.cn.hn/FTe 免费领取

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

6、需求文档一定要写！

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

7、认为有错的地方一定要及时改

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

8、使用自己有把握的技术

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

9、尽可能自己解决问题

任何一个企业的老板都希望自己的员工能够自主独立的解决遇到的问题，而不是一遇到问题，就要向老板、同事索要解决问题的方法。如果真的遇到自己解决不了的问题了那就要及时向领导、同事求助，以免出现更大的问题。

10、自己先测几遍

写了代码不测试就能用的，除非你是大神！不然一般都有残留 的 BUG 在里面！所以自己还是要测过之后在扔给测试人员去测，要保证质量！同时也不要浪费别人的时间。