影响项目代码可读性的反面教材

最近换了家公司，公司名声在外，当初能进去还有点受宠若惊，直到接手了个项目后..。在简单查看代码之后，才发现自己就是个可怜的娃。首先就发现代码风格不统一，经过询问，才知道这个写的跟玄幻推理小说一样的代码已经运行了七年，传到我这已第八代掌门了，听到这，我和我的小伙伴们都惊呆了，顿时起了杀生的念头。
冷静后，为了不让自己也做出危害人间的事，就写这文章提醒一下自己，同时发发牢骚。
咱不知道啥是应该做的，那就列出不应该做的。

1、不遵守命名规范
    这个应该属于初级错误。在接手的项目中处处可见，小写开头的类，大写开头的变量、方法，把人看的一愣一愣的。

2、忽视方法的功能内聚性
    在阅读项目代码时，时常能看到一些欠缺内聚性的方法。一个关于业务逻辑的方法中竟然写入了各种合法性检查、数据库查询、赋值等代码，而各项功能之间又存在着各种千丝万缕。这种写法增加了耦合，让代码的维护与变更变的十分困难。

3、滥用成员变量和系统属性
    比起局部变量，成员变量的确是很方便，哪里都能调用，但别忘了，它也哪里都能赋值。比如，当在个方法中调用了一个成员变量，方法中又调用了其他方法，这时这个成员变量的值，就有很大的可能会被调用方法给修改了。这样造成了这个成员变量“多个入口又多个出口”的情况，变量的变化就无法直观的监测。

系统属性是整个项目都能使用，通过System.setProperty方法设置，通过System.getProperty方法获取。虽然只能定义一次，但在不同的地方定义，这样造成了阅读代码时比较麻烦，需要查找到在哪定义，才能知道被赋了什么值。建议在同一的地方进行定义。

4、带有误导性的方法
    例子一：void getXXXX() 。在这个项目中这类方法通常会与成员变量配合使用。类似这样的方法名总让人不爽，名字叫获取，实际却是自己找。
    例子二：根据参数数量的不一样，CreateLib类有两个构造方法，但两个构造方法却new了不同的成员变量和完成了不同的业务逻辑。

5、未能按功能分层
    辅助功能、业务逻辑、数据访问的代码要么被写到同一个包的多个类中，要么被写到了一个类中。

6、庞大对象作为参数或返回值
    项目中，一个带有操作数据功能的POJO类被作为一个方法的返回值。虽然传递是地址，但一个带有多余功能的对象被传出去，会给增加业务的复杂性和危险性。比如这个带有数据操作功能的POJO类，在作为返回值返回到某个方法时，很难保证这个POJO类不会再次操作数据。

还有，不要将一些重要的类作为参数传递。比如：在此项目中经常可看到将静态Connection实例作为参数在众方法中传递。
    

7、类之间的互相引用
      给个例子
       class Product{
            private ProductDao dao = new ProductDao;
            ...
            void update(){
                dao.update(this);
            }

            String getUpdateSql(){
                return "update product set...";
            }
            ...
        }

        class ProductDao{
            private Product p = null;
            ...
            public update(Product product){
                p = product;
                ...
                st.executeQuery(p.getUpdateSql());
            }
            ...
        }

    这样写造成了循环引用，除了不好阅读之外，也容易让ProductDao类无法被回收。

8、缺少适当的注释
    当看完整个项目的主流程后，竟然发现一句注释都没有。额滴神啊～！

9、缺少必要的文档
    由于涉及到数据库操作，在再次询问后，才知道这部玄幻推理小说就连数据字典都没有，更别说业务描述部分的文档。

总结

    以上问题都归结于公司对自己产品的松撒管理和对文档的不重视所导致。因为一个新成员的进入，他进入100%的工作状态是需要时间的，但以上问题会延长他进入状态的时间，增加他了解项目的成本，在某种形式上也会对公司造成损失。

最后借用某经典电影的台词发发牢骚：“顶你个肺啊～！”