周报5月31日

周报
5月31日
我终于搞清楚了我做的功能是在主干上，如果早知道这一点，一开始就没有理由在分支上进行开发。好在，我一直坚持把功能点都封装在相应的类和方法里，包括在写Javascript的时候，凡是能封装到方法里的，我都封装成方法。而且凡是我写的代码，往往会有注释，在相应代码前面和后面会有一整行//注释，写明这几行代码对应哪个功能点。方法前面都会有@author 支浩宇 的字样，一看就知道是我写的。由于我坚持了这一良好习惯，在分支上删除这些功能的时候，哪些地方要删，非常清晰，不会出错。在主干上加上这些功能，也是直接把已经封装好的方法，整个直接复制过去，复制过去直接就能用，100%兼容。这检验了我写的代码的可移植性非常好。

我把我写的功能都移植到主干上后，发现主干上的人（XX项目组的人），对Service的理解跟我完全不一样。我是把页面上的参数全部传到ServiceImpl里，在ServiceImpl里对参数进行处理、判断。例如用户点了“回复”按钮，要判断他是否....，没....过的不能回复。像这种需求，XX项目组的人会在Action里面判断，他会把除了DAO.insert之外的所有语句都写在Action类里，在Service类里只写两个语句，DAO.insert()和logger.debug()。 我感觉这个做法是挺搞笑的，既然这样还要Service干什么，直接调用DAO不就好了。不过，他这个做法最终的效果也一样，我自己心里明白有的人喜欢这样写，能读懂他的代码就行了。

现在我做的功能js文件越来越大，我表示很担忧。我对使用Javascript是比较反感的，把代码都暴露给用户，不符合一般写程序的原则。我尽量不在js文件里暴露任何业务逻辑的信息。我都是用一个jQuery.ajax，把参数传给服务端。所有呈现给用户的文字提示信息，都写在服务端，不让用户看见。例如，回复内容不能为某某某，这样的判断我是不会暴露在js代码中的，不让用户知道回复内容不能为某某某。而且，凡是在客户端判断过的东西，我在服务端Service里面还要判断一次，因为我觉得在客户端浏览器上可以做各种手脚，我信不过。我总是假设用户浏览器是比较慢的，XX的服务器是非常快的，而且一天闲着没事干，所以我倾向于让用户的浏览器尽量少执行东西，尽量把工作都交给XX的服务器。