入职一年多的码农做一个经验总结，也希望对刚入职的码农有个帮助

总结
时间过的还是挺快的，第一次离开陕西是去年3月份，3月2号第一次独自一人来到北京，还好北京还有高中舍友，在他那儿住了两晚上，3月4号当天正式入职现在的公司。在这一年中提高了不少，自己做个总结，是对自己的一次提高，也希望能对初入行的ITers有个帮助，希望大家能在这条路上少走一些弯路。先介绍一下自己吧，我是做java
web开发的，用的技术是SSI（spring、struts2、ibatis）、前台jquery、数据库mysql、oracle。从前台jsp页面到数据库都是我们自己写，没有专门的前台开发人员也没有DBA。在这一年中我很感谢带我成长的导师，他是一位大牛（可惜已经离职了），他教给了我很多，从他身上我也学到了很多。

先从前端说起吧，搞前段，首先都有个强大的调试工具，chrome浏览器挺好用的，调试代码挺方便（据说firefox调试也挺方便的）。安装了chrome浏览器后，右键->审查元素，可以调出浏览器的调试。我常用到的是Elements、Network、Console，Elements主要用户调试HTML页面用的，可以查看一些元素的布局、CSS属性等。我用的最多的是Network，这个功能非常有用，在出了bug排查问题时非常有用。我认为程序可以看作是一个数据流，简单的来说，就是data从前台jsp页面流向后
台，再持久化到数据库。也有个相反的过程，data从数据库到后台再到前台jsp页面的流动过程。定位bug很重要，bug的产生必然是由数据的异常引起的，大家可以跟踪数据的流动来排查bug。首先要确认bug是在这个data流动的哪个环节出了问题，可以进一步缩小bug产生的范围。大家可以看到我点了“查询”按钮以后，发送到服务器的数据：



如此，大家便能知道浏览器发送给服务器的数据是什么，与自己预期的数据是否是一样的，如果不一样，那便是前端的问题，进一步在前端排查，否则则是后端处理数据的过程中引入的bug，可以进一步再排查，是从数据库中读取的数据就有问题，还是处理逻辑有问题。

也可以看到服务器反馈给浏览器的数据：



这样一来，大家就能知道服务器反馈给浏览器的数据，如果与预期的数据不一致，那问题就出在后端，否则就在前端。

接下来就是Console了，控制台可以方便的输出jsp页面的数据，在jsp页面中用console.log("XXXXX");可以很方便的输出调试信息，类似java的System.out.println("XXX");



说完了前端，说一下后端吧，主要说一下编码规范吧。

1、命名很重要：一个错误的命名会很误导人，不良的命名，对于阅读代码的人来说很纠结。一个良好的命名对自己也有很大的帮助。我个人命名的变量都比较长，一般是单词的全称，这样代码读起来易懂，有些缩写你根本不知道它代表的单词是什么，除了像id代表identifier，org代表organization这些大家常见的缩写命名。命名一个方法时候，最好能让大家见名知意，看到名字就能猜出你的功能，而不需要去看方法的注释，甚至是读源码来了解你的功能（最近开始阅读yale大学开源的cas代码，发现人家的注释写的很好，命名很规范，一个class的长度超过了70是好多个单词组合的）。

2、注释很重要：写一个方法时可以先把这个方法的功能、算法原理交代一下，以后自己或者是其他人维护你的代码时候可以很方便，对于易出错的部分加注释提醒。

3、写方法的时候的参数，少用基本类型的组合，而用class类型：比如写一个查找用户的方法queryUser(int age)，最开始的业务需求是根据年龄来查找用户，后来业务规则发生了变化，你可能需要根据年龄和性别来查找用户，于是你又改成了这样queryUser(int
age, int sex)，假设用0代表男，1代表女（其实更好的实现是用枚举来表示男女），说不定你哪天的业务又变化了，需要根据年龄、性别、家庭住址来查询，于是乎你又改成了这样queryUser(int age, int sex, String address)。如果你当时设计的方法是：queryUser(User user)传入的参数是一个User类呢，那该多好啊，你根本不需要改接口。在实际项目开发中改一个接口的成本还是挺大的，实际项目开发中为了达到层次清晰、解耦的目的，后台分了好多层，action、business、dao其中dao还有分了dao接口和实现，一个接口修改得牵动多少地方。而当初设计的接口传递的是User对象，那么你的代码可以简单的增加几行就能达到了目的，而不需要修改那么多的接口，一边修改一边纠结。

4、少复制、粘贴代码：同样的代码不要粘来粘去，当时写的时候确实是快了，可是以后需要修改的时候可就慢多了。更可怕的是你要修改多处，结果你只修改了一处，而你自己却以为万事大吉了，说不定哪天就蹦出个bug来。应该把这些公共的代码提取成一个class或者是一个方法。

5、一个方法中不要写太多的代码：一个方法中写好多代码，写的时候确实是很方便，很快，更好的办法是把一个大的方法分解成几个小的方法，然后在主方法中调用其他字方法。如果把所有的逻辑都写在一个方法中，当需求发生变化的时候，再要修改那就慢多了。我自己写代码的时候，刚开始写某个功能的时候很慢，有几种实现很纠结到底用那种实现，思考半天，给个变量起个名儿也得半天，有时候还不知道对应的英文单词，好吧，再打开桌面词典，查查单词。写个方法时也得纠结半天，先想好方法的名字，然后是参数，还有返回值。一小段逻辑的代码可以提取出一个private方法，然后在一个方法中调用好几个私有的小方法。这样读代码的人读起来也轻松，日后需求发生变化了，你的这些个小的逻辑代码块儿只要重新组合下，就又能满足新的功能，可以复用。我自己写一个新功能的时候，第一次写很慢，如果是这个新功能发生了变化，需要修改代码，修改起来非常快，许多代码块儿都是现成的，只需要重新组合一下方法的调用即可。

6、增加一个新的功能模块时最好有个设计文档，先把方方面面都考虑周全了，设计好了再编码实现。如果不这样，最终功能是实现了，如果一开始就有个设计文档，能把方方面面都考虑周全，实现起来就容易多了，实现的代码还能优雅些，边写边修改，最终也能实现，肯定不如一次就考虑周全了实现的好。为了达到最终的目的，可能中间要走些弯路，如果增加的功能多了，每次实现都走一些弯路，系统最终会变的臃肿不堪。如果推倒重来，以前的功夫就都白费了，不光是编码，还有测试部门的测试，有时时间也不允许重构，再说了重构还有风险，这其中的代价还是挺大的。所以新增功能一定要把需求搞清除，有个良好的设计文档，考虑周全了再编码实现。

7、在向SVN提交代码时先做个功能测试，然后没问题了，再做个codereview。

再说说数据库方面的一些内容吧。

1、写好sql语句最好粘在客户端工具中执行以下，看看有没有语法错误。如果在程序跑起来，发现sql语法有错误，修改了sql语句还得重启服务器，挺麻烦的（我们持久化层用的是ibatis，ibatis修改了sqlmap文件后，需要重启服务器）。

2、对一些大表连接操作要注意性能问题：一张表的记录达到几百万条以后再连接另外一张表，性能会很差。假如我们有两张表，一张是用户表user，一张是账户表account，用户表存储的是用户的基本信息，账户表存储的是用户的账户（用户名/密码），假设用户表有100w条记录，账户表也有100w条记录，uniqueid是用户表的主键，是账户表外键。要根据一个用户的uniqueid来查询用户的基本信息和账户信息，sql语句可以这样来写：select
* from user u, account a where u.uniqueid=a.uniqueid and u.uniqueid='XXXX'，那么这条语句在最后的情况下需要检索100w*100w次。结果这么大，效率肯定要差。如果改写成这样select * from user where uniqueid='XXXX'和select * from account where uniqueid='XXX'效果就好多了，这样在user表中最多检索100w次，在account表中最多检索100w次，最终也是100w+100w=200w次而不是100w*100w。看起来是麻烦了，其实结果好多了，这大概就是曲中求直的道理，看似走了弯路，实际上却是最直的，也是最值的一条路。