周报 5月17日

周报 5月17日
..的张明让我做的功能并不是整个..体系，目前只是做...页面，主要是三个功能，...显示。

..的功能要新增很多类和文件。Service，DAO，SQL.xml这些全都没有，都要我添加。这是个很好的机会，让我从core和impl开始，用良好的设计思想把类设计好，注释都写详细。 因为我在看别的类的时候，经常发现各种设计不合理的地方，有的人写Service接口，一下子就弄出来十多个方法，也不管用不用得到。 有的Service或者DAO里面，有两个不同方法，里面实现的功能却是一样的，甚至连代码都一模一样。我坚持的原则是，我做什么功能，需要用什么方法，我才在Service接口里定义这个方法。保持代码的干净整洁。

有的Service里面判断参数是否合法，Action里面又判断参数是否合法，有的参数两次都判断了，有的只有Service在判断，Action里面不管。一旦修改起来，各种各样的bug就出现了。我现在是把所有判断和业务逻辑都写在Service里。每一步干什么，都注释得清清楚楚，层次非常清晰。 这也和我做的功能本身业务逻辑很清晰有关。我只处理两个表，而有的同事做限时抢购的，有五六个表。

虽说我只有两个表，有些地方的设计已经让我觉得不合理，但表结构又不能随便改，要总体组评审，所以在影响不大的情况下，我还是按照张明建好的表来开发。

给变量起名，在我们项目里，有的人喜欢起obj, data, list这样的名字，除了他当时写的时候知道是什么意思，恐怕再也没有人知道是什么意思，可维护性非常差。可能他那个时候只有一个list，所以就取名list，然后别人又加新的功能，有新的list，别人就在list前面加上别的单词，出现了skuList，votesList之类的。这时候，最开始的那个list就显得很奇怪了。所以我起名的时候，尽量按照具体功能来取名。

StatusConstants里的常量，有些是旧的过时的，或者从来没用到过的。RTX群上就有人在问，某某常量等于几是什么意思，结果出现了几个不同的版本。我定义常量，是严格按照业务给的需求，业务要什么功能，我才定义这个常量，今天业务说某某功能不做了，我马上把相应的常量注释掉，注明原因。 以后和..整合的时候，我也会密切关注，看..代码里定义的常量和我定义的是否一样，看有没有人把我定义过的常量在其他地方又定义了一遍。这些问题，在修改已有功能时，宁愿不去动，以免越改错越多，而在开发新功能时，则要从源头上避免。