最近段时间每天都会花点时间来园子转转，看过很多博友们写的文章，感觉自己也长见识了不少；由于是第一次写文章，还望博友们多多指教哈。
说说现在的工作吧，现就职于一家国内较知名的外包企业，服务于一家知名的企业，从入职到现在也已经两年多了，而且还是在同一个项目组做着同一个项目（该项目已经做了好几年，需求还在不断的增长，还看不到头）。
进项目组前一年左右的时间，也确实学习到了不少的东西，学习业务、框架、平台以及所撑握的技能、项目经验、设计等都有一定的提高。每个版本的需求量不断增长，而开发周期也在不断的压缩，时间越来越不够用[外包企业，都是计工时的，平时加班不计工时，所以大家都比较排斥加班，可能在外包企业待过的博友有所同感]。现在开发的情况几乎是，需求来了就接住，大概理解下需求就开始动工过了，很多需求还是边开发边与需求人员、业务人员沟通需求，有些需求做着做着发现做不下去或者影响非常之大。几乎是没有设计，拿到需求就开始往里面塞代码，项目几乎全是用笨重的代码堆起来的，大量重复代码、结构混乱，一个方法上百甚至几百行代码，一个类好几千行代码，这种情况随处可见。阅读性、维护性、扩展性极差。非常多的业务全堆积到一个项目上来，各个模块依赖性也非常之高，数据和用户量慢慢的增长，性能也是极大的一个问题。
简单分析了一下有以下几点原因：
1，各开发人员在做开发时，只考虑怎么搞功能给实现，其他很少有所考虑
2，项目组缺少一个比较牛X的人物来进行全局控制
3，需求多，周期短，一个应用负责的任务太多
针对以上的说说个人的想法
首先我们开发人员平时在做开发的时候就得自己多注意，多想想类、方法的职责，文件结构的存放，各种命名的规范等。最近看了一些关于重构方面的，也在尝试着做一些重构，还是有那么一点点的效果。
其次需要一个经验丰富的设计架构师，多进行设计，进行合理的分层，并且带领大家进行技能的提升
需求多，周期短这个问题貌似就无解；可以按照比较大的业务模块将应用分离，一个大应用分离成多个小应用，各个应用之间再进行通信。一个应用负责的事件变少了，相对来说比较独立，结构会比较清晰一些，性能应该也有所提高，也可快速响应需求的变化。
数据库设计，现在也是比较糟的，比如，一个表存储了很多种的业务数据，只要新的业务所要存储的数据与这个表有点像，就往这个表塞，字段不够就往里面添加字段，导致字段非常多，很多字段都是字空的，加某一个字段就是为了应付某种业务数据，而其他的业务数据，又会再加另外一字段。表阅读起来非常困难，而且对性能还有一定的影响。
我认为设计表应该让表结构尽量的简单，表的数量多一个可以接受的（在解决性能问题时，表的垂直分割不就是这样吗），既增加了可读性，又提高了并发。
第一次写，还望广大博友多多指点，既然来了还请留下点足迹吧，踩踩也行；