前言
到今天为止，正好是工作一年了。
一年里有过折磨痛苦，有过成就感，一年后很欣慰能看到自己是有所收获的。
记录如下，如有不当，还望指点。
技术
看到别人写出的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各代表了什么。对于别人的代码的修改也应写好注释，修改的起始位置，结束位置，修改人，修改时间，为什么修改等等。否则以后别人问你为什么改可能自己都记不住。
日志的记录，在重要的业务流程或者容易出现异常的地方加入较多的日志，平常的代码也要加入日志便于上线之后出了问题查找问题原因所在。
不是特别忙碌的情况下可以多接触新的技术或者语言，一门新的语言可能让你大开眼界原来还有这样的语法，接触的越多，思路会越广，也会越聪明。程序员不能停止学习。
习惯
任何一个人都有值得学习的地方，或许他性格沉稳，或许他乐于钻研，或许他感兴趣于新兴技术。
保持清醒的头脑，忙碌也要适当，快速的反应和清晰的思路才是最佳的状态，而不是浑浑噩噩的瘫在电脑前做着一些搬砖的工作。
对于已经成型的功能点，如果进行了改进或者安全性的加强，应该在改进的同时整理优化点或者修改点，提交测试的时候一并通知测试人员，这样能让力量用在刀刃上，测试测的准，也省时间。
多多思考如何提高工作效率，这种思考有两种，第一种，如何提高自身效率，包括代码习惯，IDE的使用，小技巧的积累，甚至作息时间上的调整等等。第二种就是如何提高所在团队的效率了，所处的团队高效，活跃，那么自身也会受益颇多。所以可以开发小的工具供大家使用，比如当大家一起去完成一些技术含量比较低的工作的时候，开发了一个小工具来减少一些无脑的工作。比如当大家每天启动项目的时候要启动那么多微服务，可以和管理者沟通是否搭建一个公用的微服务减少大家启动的时间以及PC内存的占用，比如当大家痛苦于登记JIRA上的bug修改记录的时候，是不是可以考虑开发一个小工具造福全人类呢~
跟住趋势，承受向好方向发展时候的痛苦，比如最近在从eclipse逐步过渡到使用IDEA，快捷键什么的基本不一样了，用着有点不习惯，但是能感觉到如果熟练了效率肯定会高很多（逼格也高）。
不断的出现技术上的问题是一件好事情，说明整个项目是在向前走的。随着项目组项目业务的越来越复杂，架构上的问题也逐渐暴露，所以问题的存在也在推动着不断地进行优化。
沟通
如果有新的同事或者刚刚加入项目组的同事，更倾向于首先让其了解整个项目的整体作用，然后讲到他即将接触到的相对独立的模块的功能，然后再细致的讲解业务上的流程，数据的流转，以及一些特殊的情况。先了解最主线的任务，然后再讲解各种不正常的情况。从大的概念上了解，然后再比较全面的了解一个小功能，再辐射到更大的模块，这也是我自己学习和渗透项目的一个思路。
自己做出了一件很棒的事情完全可以拿去和别人炫耀，比如你用了一个很好的设计模式，比如你优化了一个功能让他快了10倍，比如你开发了一个很棒的工具。或许你的炫耀可以让别人知道你这么做的优点，然后向你学习，也或许别人听了之后给你了一个更棒的建议。成就感是最好的动力，每个人都希望被肯定。
清晰的说明，耐心的讲解，必要的配合一些画图，会让沟通事半功倍，如今的开发节奏谁都不能独自开发一个很棒的应用，沟通和表达在团队中绝对是非常重要的能力。
项目相关
开发的时间不应舍弃设计，单元测试，模块测试，全面的自测，以及联调的阶段，如果时间安排上忽视了这些，那么必然要在后来的修改bug时间，或者处理紧急问题的时间上找回来，而且一定会亏损更多的时间。
公司在将项目转化为产品的过程中，随着产品包含的范围不断的扩大，业务的不断整合，开发人员渐渐的不能从全局的角度来审视整个产品，而现有架构的特点对于业务的理解要求还是比较高的。所以全局上了解了业务，才能写出高质量，复用性高，可靠性高的代码，这对程序员来说是一个挑战。
需求边界的划分清晰也是非常重要的一件事情，当然了，这不是一个普通的程序员能够掌握的事情，但是如果需求边界不清晰，需求不断的变更或者增加，对整个项目组来说都是一件非常耗神耗力的事情。
项目组人员越来越多的时候，各个开发人员之间技术的差异，或者因为业务上的不清晰导致的代码质量的问题比较严重，毕竟项目的水平取决于最差的一块。
周边
问题多的时候尽量保持平稳的心情，毕竟急躁不能带来任何正面的效果，其实这个也是需要磨练的，光是说肯定没用的，经历了很多折磨的事情才能淡定的面对一些很蛋疼的情况。
理解同事，无论是产品还是测试，虽然没有感同身受但是也应该尽量的站在别人的角度思考，自己做成什么样子能对大家都好，提高大家的工作效率。
注意身体健康，身体是革命的本钱啊~所以基本隔一天去公司的健身房锻炼一次，保证一个好的体魄，旺盛的精力才能更好的生活和工作。
兴趣爱好也很重要，如果每天的生活就是起床，敲代码，睡觉，再起床的话，真的只是活着而不是生活了，平时喜欢弹弹乌克丽丽唱唱歌，拍拍照片旅旅游，和同学同事开黑LOL，要懂得休息和放松~
最后
表达能力真的非常非常重要，清晰，扼要。
要有责任心。
重视细节。
尽量给团队加buff。
自身能力横向的扩展，知识面的拓宽。
自身能力纵向的深入，对已知技术的深入理解。
你不该只是活着，要去生活。
