随笔--四个月培训小结

  大学四年了，高中毕业后就再没写过文章了，写起来真是生疏了，大家见谅，本文纯属记录生活，留着给自己和一些感兴趣或还未大学毕业的人看看，或许会有些收获。

  转眼，来苏州高博培训Android已经快四个月了，项目就快完工了，第一完成这么大的项目，说实话，还是比较高兴的，虽然还有些bug，虽然在代码的结构，类及变量的命名，代码的可移植性等上还是不满意，虽然可能没有其他项目小组的项目功能齐全，没有其他游戏等项目那样吸引人，但这毕竟是我们小组的汗水结晶，更是倾注了我为时半个多月的努力。仅仅半个多月，估计就已经写了近万行代码（虽然有很多重复代码），总体上，心里还是颇感充实的。

  下面说说感想吧，分技术上和非技术上的。

  技术上：

  1.类，类变量，方法名，包名，布局文件名等的命名。虽然上课时都一再强调，类首字母大写，变量首字母小写，采用驼峰式写法，文件名见名知意，比如是活动就写成xxActivity，是Bean对象就写成xxBean，是Servlet，就写成xxServlet，但由于执行时并不是一个人执行，所以有的人遵守了而有些人没有，所以应该需要一套命名准则来限制，总之，这是非常基础的，而回头看我们的项目，真正达到要求的只有60~70%吧，这个感觉不是很满意，项目组里应该沟通好的。

  2.活用类的封装。自己写代码时就感觉自己好多时候就是在复制粘贴，因为好多地方的代码都很类似，所以代码写到一半时才想到要将重复部分的代码封装成一个类中的方法，举个简单的例子，Android中最简单的Toast显示消息就可以封装成一个静态的show方法传入两个参数（Context，Text），而这些也是在我写代码的过程中才体会出的，并第一次感受到方法的封装与代码的重用是多么方便的事情。但也是由于半途醒悟，所以代码中好多重复的代码也没有时间去重新编写了，这是我感到遗憾的第二点。

  3.提高代码的可移植性。以前一直觉得代码的可移植性不是什么重要问题，亲自编写了半个月代码，感觉可移植性还是很重要的。个人认为代码的可移植性高就是当代码的环境改变时，仅需要对代码微小的修改即可。举个我项目中的例子，本组的项目需访问采用asynchttp方法访问服务器端，而当服务器ip发生变化时，Android客户端就需要修改它访问的ip地址。而我在编写代码时，在每一个Activity中都定义了url，并赋值为http：//x.x.x.x/web端项目名/xxServlet，因此，当ip修改时需要修改每个Activity中的url。而个人认为最合理的方法是将url放在一个用于存放全局变量的类中，如App.class,让它继承Application，然后所有Activity都调用统一的变量，当服务器ip修改时，只需改App中的url即可。这是我的项目中第三个问题所在

  4毕竟还没毕业，这个问题本人还总结不出是属于哪一部分。还是举本项目的例子，本项目的web端Servlet有接近20个，的确，这样子使得每个Servlet的功能都很明确，如客户端修改密码，修改绑定手机号，修改昵称放在了三个Servlet，因此在web端就需要在DAO添加三个方法，在DAO实现类实现，然后在Servlet实现调用。而实际上这三个属性均放在数据库的User表中，因此他们访问数据库的操作极为类似，因此可以合并成一个Servlet并使用参数type来区分是访问哪一个字段，这样客户端只要写一个url，服务器端也只要写一个Servlet，DAO和DAO实现类也只要编写和实现一个方法，感觉简便了不少。

  5数据库的设计要合理，数据库的设计合理，可以为程序员减少很大的代码量。本人数据库学的不是很好，项目初期设计数据库时就稀里糊涂的，导致项目后期访问数据时，在某一张表不存在某字段A，而又想根据该表中的字段同时访问该表的其他字段以及字段A，这时只能采用多表查询或是进行两次查询。在不影响第三范式的情况下，个人认为还是在该表中添加字段A比较简单。

  6注释明确，清晰。我也是到项目后期才发现这一点的。注释，不仅是给学习代码的人看的，更多的是给维护的人看，而且，通过注释也可以整理思路，方便代码编写者的编写，所谓磨刀不误砍柴工。尤其要注释的部分是参数较多的方法，步骤较多容易混乱的部分以及代码开头的作者创建时间以及文件描述。后期我在单元测试时登陆注册以及个人信息修改模块都测试了没有问题，但在集成测试是发现登陆后修改信息是成功的，而在注册后修改信息却是失败的，于是就要看这三个模块，尤其是登陆和注册。而此时，我自己写的代码也并不是一下子就看懂的，还花了不少时间，更别说是给其他人看或给维护的人看了，如果当时有注释，就完全不一样了。这也算是事后诸葛亮吧。

  非技术上

  1如果时间充裕，遇到问题尽量自己百度。项目初期，问题很多，老是报错。一报错就找老师，老师一来，结果每次都是很简单的问题（极少部分情况除外），即使老是不能立马解决，老师也是自己百度后告诉我的，因此我们应该培养自己看日志，自己百度的习惯，太依赖老师不是个好习惯，毕竟工作后同事可没有帮我们解决问题的义务。帮你解决是感情好，不帮你也纯属正常，人家也有人家的事情嘛。

  2适度工作 劳逸结合。在苏州，一般是早上八点半到教室，晚上九点半离教室，周五周六没有晚自习，周三下午有2小时自由活动时间，中午有1小时左右午睡时间。看起来似乎比高中要轻松不少，其实不然，从早到晚，所有的工作都是编代码，查bug，当人们不停地在做同一件事时往往更容易疲劳。当然，乐在其中的除外。记得项目初期，由于本组包括我在内有两个人请假，回来之后就一直在赶进度，没日没夜的写代码，结果第二天起来往往晕乎乎的。那几天经常会出现这样的情况：早上写代码时，尤其是快到11点时，写着写着，就不知道代码写到哪边了，报错时，也也经常找不到是在哪里自己打印了log，然后午休过后，发现编码效率明显高了一个档次。现在终于明白为何在软件工程课上，老师会说软件完成进度往往不是靠加班就能拉上去的，适度的加班或许有一定效果，过度的加班往往会降低效率。就像弹簧一样，你拉它的力度越大，它反弹回去的速度越快，但拉他力度已经超出弹性形变的力度，弹簧就不具有弹性或弹性很小了。

  3选择哪个培训机构。这是个非常敏感的问题，在这里我不发表个人对任何培训机构的看法。在之前选择培训机构时，这个问题也困扰了我很久，然后来了之后，就发现我多虑了。并不是说某某培训机构有多好，也不是说某某培训机构是垃圾，而是培训的关键在自己。现在网络这么发达，网络上的资源用之不竭，只要稍微找一找就能发现很好的资源，如果你有强大的自制能力，你完全可以选择不必培训，自己自学，但是一般人（比如我自己）都是下定决心后，不到2个星期就放弃了，如此周而复始，浪费时间而已。因此，我们不必纠结这个次要问题，而是问自己：自己究竟想不想学。

  4做好笔记。在这里，我不推荐记纸质笔记，因为之前在大学也学过Android，也学过Java，笔记也记了厚厚两本，可是有什么用呢，除了当时期末考试时复习看了一下，然后就一直躺那了。记成博客形式有以下几点好处1，自己有问题是随时翻到自己的博客，看看当时是怎么写的，而纸质笔记并不可能随时在身边2，写成博客既可以帮助别人学习，也可以让别人发现自己笔记中的漏洞，利于自己的成长（写技术blog最好写自己有把握的，或自己测试过的，不要误人子弟）3，在面试时，考官问你有没有技术博客时，也不至于哑口无言了。

  5心态要好。我不知道真正公司里有没有吃干饭的，但肯定会有工作量不均衡的情况。比如我们小组就有人纯属打酱油，从头到尾一句代码都不写。当然，公司即使有这样的情况，也不可能这么严重吧。对于这种现象我刚开始也不是处理的很好，就一直在心里抱怨，虽然嘴里不说，但脸上的表情估计就是所说的“就像谁欠了他钱似的”，结果整个人心情都不好，编代码也心不在焉，效率下降。后来，渐渐意识到不妙，赶紧调整心态。遇到这样的情况，可以这样想1要懂得“吃亏”，我想，没有哪个优秀的程序员是没有庞大代码量做基础的，既然要做程序员，代码是第一位的，首先得有大量的编码经验，因此就把自己多做的当成一种经验的积累吧，程序员一开始都是从积累经验做起的。2没事少抱怨，抱怨也不会有什么结果。有句话好像是这么说的“笑着过是一天,哭着过也是一天，为什么我们就是不能笑着过每一天呢”。3心情是会传染的，自己没有一个好心情，往往为使得项目小组的氛围受影响。在此，要特别感谢我们组的组长，感觉他在小组中最大作用是调整项目成员的心态。这一点是我自叹不如的。

  以上纯属个人看法，欢迎大家与我讨论，也欢迎大家批评指正。