java开发一年多少钱_一个JAVA开发一年的总结

看到别人写出的bug，自己也很大可能会犯同样的错误。

从bug中学习，每一个bug都会对自己有警示的作用，或许你的定时任务有问题，那么完全可以想想，如果上线了出问题怎么办，是否有补偿机制，如果要补偿如何处理。并找到根源，然后思考这个根源会影响到哪些功能。

绝对不要放过一个细微的问题，之前在使用dubbo的时候发现实体类中如果有Date类型的属性为空会导致整个类为null，同事们采取的做法是用别的类型替代，但是仔细钻研一番，看了源码之后发现这是dubbo2.5.3使用hessian序列化时候的一个自带的bug，并且定位到了源码中的某一行。如果不能发现并很好的避免，如果以后出问题了会非常棘手。可以这么说，项目中的问题，没有小问题，任何一个问题都可能毁了一切。

程序员要做的事情应该比产品提供的需求更多，包括后台的管理，一些意外情况的处理，甚至之前说到的定时任务的补偿，都可以形成管理模块进行开发。

问题的最小场景的还原，当面对一个问题的时候，应该能够迅速的缩小问题的范围，然后定位到问题结症所在，再予以解决，这是一个经验的问题，还是需要直觉和积累，而直觉来源于经验。

开发的过程中要考虑越来越多的事情，性能，稳定，异常，安全，复用性，兼容性等等，做到了这些，代码将会慢慢变成一件艺术品。

项目的安全性，包括常见的SQL注入，XSS，CSRF，DDOS，cookie劫持等等的比较容易防御但是却能造成很大危害的漏洞，应该设计时候就予以考虑，而不是开发完了再去补。

功能的整体性，如果有一个较大的系统需要开发，那么最好能先让开发人员了解整体，最最好的情况当然是整个需求一起给出，这样方便开发人员从整体上设计，如果一个庞大的体系今天一个需求明天一个需求，而且这些需求彼此关联，后期的开发将会举步维艰。

架构的遵循，传统的J2EE层次，现在使用到的包括Controller，Facade，Service，Dao层级。前端则是HTML和JS的配合，模板框架配合渲染HTML。那么当使用的时候Controller应该重点负责对应起URL，进行权限的校验，session的检查等等并调用具体的facade层次，facade更多的是业务上的逻辑，比如转账那么service应该有两个接口，一个加钱一个减钱，facade去调用这两个接口，而不是service直接一个接口完成了加钱减钱，facade进行了垂直的调用，并且如果要求密码的话，我更倾向于密码校验在facade(那么对应的service也要有校验接口)，而在serivce 就不必校验密码，毕竟service提供了加钱减钱的服务，而facade才是真正的业务。在我看来这样的设计才能让service的复用性更高，各层级层次清晰分明。对团队的配合至关重要。

细节上注重，比如mybatis中$和#的区别，整体上关注，比如hibernate和mybatis的优缺点，redis和其他缓存的对比等等。

注释非常重要，尤其接口的注释，应该说明这个接口的功能，传入参数的类型及含义，返回值的类型及含义，如果是数字类型那么-101234各代表了什么。对于别人的代码的修改也应写好注释，修改的起始位置，结束位置，修改人，修改时间，为什么修改等等。否则以后别人问你为什么改可能自己都记不住。

日志的记录，在重要的业务流程或者容易出现异常的地方加入较多的日志，平常的代码也要加入日志便于上线之后出了问题查找问题原因所在。

不是特别忙碌的情况下可以多接触新的技术或者语言，一门新的语言可能让你大开眼界原来还有这样的语法，接触的越多，思路会越广，也会越聪明。程序员不能停止学习。