这周加了好几天班才勉强做好一个需求，很辛苦，但是却学到了很多东西。
工作习惯：
- 着手实现需求之前并不了解需求的背景也没有读懂需求，导致了中途出现了不少问题需要跟业务的同事沟通然后反复修改需求。导致了需求进度严重落后于预期。
解决方案：
开发之前必须先读懂需求，有问题的地方先总结出来，然后再跟业务同事沟通，讨论。不应也不能直接着手做，遇到问题再沟通。这样不仅降低了自己的工作效率，而且还严重影响了同事的工作。此外，跟业务同事交流业务背景要比自己琢磨或者跟技术同事交流要更有效。视角的不同可以给开发带来新的思路。
- 遇到技术问题的时候，没有及时咨询同事，遇到问题过多死磕，严重降低了工作效率。
解决方案：
遇到技术问题的时候，要先给自己一个时间期限，在时间期限内通过尽可能多的方法寻找解决的方案，并且应该记录好自己寻找答案的思路以及寻找到的结果。如果到达了时间期限就应该马上去咨询同事，并且告之同事自己的思路以及所有找到的相关结果。
这样做的好处是可以
1.显示自己并不是伸手党；
2.同事不需要说一些你已经知道的东西；
3.让同事看到你的思维漏洞，并且帮助你修正思路。
- 没有经常备份代码和log，以及需求中间产生的数据。
解决方案：
作为代码的开发者，除了需要详细地注释代码，也要习惯性地完好保存每个程序迭代版本以及所产生的log。因为如果遇到bug，上一个可运行版本可以马上上线，而log则可以提供解决bug的思路。同理，中间的数据可以帮助完善代码以及修bug。
- 开发不合理。
解决方案：
开发之前应该先找出需要用到的数据，以及每个表的主键。确认数据可用以后再画出实现代码的框架。例如，需要寻找参加了某个活动并且符合资格的客户，就需要从报名系统(A表)先找到报名参加活动的客户，然后以卡号为主键通过交易记录(B表)判断客户是否符合资格。为了提高程序效率，健壮性，可维护性，写出的代码应该是尽可能获得刚好足够的数据，而不是读取一整个数据集。例如，上例中，可以用hash来在B表找报名了的客户。
- 开发不规范。
解决方案：
开发前应该熟读公司的开发规范，里边会有比较详细的开发帮助。但是这次开发的时候没有熟读，遇到了很多问题，并且有的还去问同事，降低了同事的效率。此外，应该按照代码复核的思路来先自己检查代码。
1.检查输出的结果是否为无效字符、null、不合理的结果；
2.对输出的结果进行分析，做频数分布检查结果
3.复查需求文档，检查代码的业务逻辑以及每一个proc sort应否去重；
4.思考代码能否更简洁；
SAS技术：
- 为了程序健壮性，外部输入的数据尽可能先做处理。例如，去重，去除无效数据和空数据，检查字段长度是否合理。
- 可以反复使用的数据应该写成宏。
- 添加时间参数。
- 不能忘记merge的时候
