碰到史上最烂JAVA项目

这还算奇葩？见多不怪了。

太多这样的项目了，特别是在小公司。在保证效益的前提下，老板才不关心你用什么技术，怎么实现呢！

如果刚进公司遇见这样的代码，pm或你直属上司还说不错，建议你直接走人，待下去没前途。。

这个没见过 我就见过5K行的类

哥们 抛硬币吧
在抛硬币的瞬间你就会知道你自己期望的答案了。

是的，规矩是人定的，乐意干就不干

    一般这种公司，管理层甚至是项目经理都是比较软弱，建议自己多吭书本，外面去找点项目练练手，来年跳吧。一个技术管理者，不懂代码规范，写出来的代码不知道性能有多烂，一定要等到客户电话才会投入力量去解决，那么结果就是无数地加班和代码重构。你会越写越操蛋

干掉他，你来！

减持就是胜利

一看就是没见过市面的吧。

几千行的存储过程。八千行的javascript我都维护过。而且我还重构了那个八千行的javascript。存储过程我是实在动不了……

当代码写到了一定程度，就会有这样的能力也就会碰到这样的任务。能够在规范的代码约束，优良的框架下写代码是一件幸福的事情。但是，这样也容易造成懒惰。架构设计得好的系统往往锻炼不了什么人的。每天只是在造一个齿轮而已。

当猎头找你，要你去接受年薪很高的职位的时候，你就会发现，这样的岗位上的工作基本都是这种让人看了就让人绝望的代码。但是你想想：如果是规范的简单的代码，那岂不是才毕业大学生都可以维护了。何必来找你？这样的工作才是真正锻炼人的，应该好好珍惜。

代码的混乱一方面是因为历史原因，另外一方面是因为业务本来就复杂。我见过一个系统关联的进程有上百个。有java的，有vb的，有C#，还有shell脚本和C，然后通过Socket、webservice、http、数据库通讯和同步。写java写着写着就变成了写perl，然后变成写c，接下来还要改存储过程，然后还要写点vb，最后还给界面上一个silverlight。

搞技术总是想设计一个万能的语言，一个统一优美的框架，设计出一个优美的系统。但是业务本身就不是优美的，本身就不是简单的。能够读懂别人的代码，并且能够从中学习到业务知识，甚至能够就现有的代码提出新需求的概要和详细设计，才是做业务真正需要的能力。这个时候才会突然想到UML里面的几种图还是真都有点作用，自己没事就在本子上画画吧。