关于Java 项目的思考总结

Java 项目思考总结

前言

今天是2017年3月25日，笔者已经毕业半年，工作经验一年。
正好有心思写这个总结。

持续开发

对于Java项目，我所接触的一般就是JavaWeb项目和 Java Jar后台进程项目。
一个项目要想健康持续开发和维护，那么就要尽早设计好，编码按照规范，切忌不要偷懒图便利，先完成功能再后续优化这种思想要尽量避免。

当你做这个项目完成的时候，会切换到别的项目开发，当这个项目有新的开发需求的时候，再回头看自己的代码，可能有两种感受：
1.

我擦，这个居然是我写的代码，这么烂，这咋改，不敢动啊。

2.

我擦，这个居然是我写的代码，居然这么清爽，不忍心写乱了。

所以，为了以后的持续开发和维护一开始就认真写好，即便是要交给下一个人，代码质量还不会腐坏。

以后等于永不

Later is never.

软件开发有这么一句话，留着以后做，等于永远不会做。所以要做就趁早。要做就给后面做好铺垫。

编码

模型Model

对于Java使用的比较多的是Spring框架，配合Mybatis。我见过一些代码，为了简便，直接使用List<HashMap< String, Object>>
作为Mapper接口的返回。
这样写是毫无问题的，刚毕业的时候看到项目(十年前的代码都有的那种)里面都是这样写。
但是这种写法尽可能要避免。
MVC中的Model干嘛用的，就是对数据建模用的，现在有Mybatis生成器，直接生成Model，用getXXX()的方式取值，比用 Integer.parseInt(result.get("Str"))类似这种优雅多了，还会转来转去，为何不直接在MapperXML里面手写一个ResultMap直接映射到你的Model里面呢？取值的时候要写Key的名字，写错或者为Null，类型转换来转换去，多累。

上下文Context

对于业务总有一个粒度，或者说某种维度。比如以城市为维度。那么在业务代码里面，要经常使用要这个维度变量。然后几乎每个方法里面都会待着这个变量，(...Integer cityId)。这种变量少还行，但是加上方法本身的变量列表，就超过3，4个了。。有点长，不优雅。

为何不定义一个Context。这个可以是个简单的POJO，把你常用的变量放在里面，在业务起始的地方初始化，然后进入各种流程，都可以使用这里的变量，全局共享。没什么安全性需要考虑的，自己的代码自己负责。
我一般定义一个BusinessEnv的类，存放当前的业务环境数据。比如cityId，cityName，No，Number一类的东西。比放在Map里面优雅。
这样写还有一个好处，就是改动比较集中，可以放心设置，不会有某些地方写死了，不容易传错变量。

编码风格Style

笔者回顾之前写的代码，就像写流水账一样，像瀑布流，一个方法几百行，想到哪里处理到哪里。看了一本书，之后惊叹编码风格的重要性。

写代码就像写文章那样，一个一个的自然段那样，行文流畅，结构清晰，那才是好代码。自己改也方便，也方便交给别人，很灵活，可插拔。

编码的过程中，不是一次就能写出这样完美的代码，那么在推进的过程中，你可以慢慢优化，慢慢就成型了。界限，梗概，脉络都会清晰起来。

这时候，可以做一步小重构了，把代码重排一下，就像写文章的排版一样。
如下图所示：这是一个主程序，优化之后的代码，不敢说这个多好，但是结构还是比较清晰的。先拿到维度的配置，然后构建Context，然后初始化一些东西，然后prepare some data，接下来sendGoods，最后更新什么东西，然后backScan干点事情，最后clear Context内容，清除数据，释放内存，以帮助GC回收垃圾。

一开始是一大片很长的，此项目虽小，写一个文件里是可以的。但是一个方法巨长。然后就是每一个步骤的业务，像是Pipeline一样，也可以说是单一责任，一个业务模块处理一件事情。每个模块又可以拆分更细的模块，由浅入深，保证每一块都是先梗概，后细节。

像这样，这个方法里，一行处理一个事情。

待续….