最近在维护一个项目，接手之前好多运营同学说：“这个可是个牛B的项目，已经运行10来年了，基本满足了我们的运营需求，但是随着业务的调整，运营力度的加大，未来这个项目将会更加重要，所以需要继续维护新功能。”
其实听到这里心里已经忐忑了，一个项目运行了这么久，必定贴了太多烂代码的补丁，适配了许多非人类的需求了，真的会是好项目吗？但是想想运行了这么多年，应该不会差到哪里吧，不然怎么会跑的这么好，相必之前的架构师一定是个大牛，既来之，上吧。
三天后......
目前是维护这个项目的第四天，今天只新增了一个js控制远程接口数据的下拉框的需求。但是已经有点招架不住了，“好戏”带我娓娓道来。
但是也是见识到了这个项目的“牛B”之处。
js，Js，JS！！！
javascript是个好东西，在我每次开始做一个新的web项目的时候，我都最喜欢写js代码，认为它是我的好朋友，我们愉快的将一个产品思维中的无形之物焕然世间之上。
javascript是一个坏东西，当它出现在一个维护N久的项目中，被太多的“调教师”调整之后，我完全被js困在它的牢笼之中，难以摆脱。
因为项目诞生了近10年，可以想见他从最开始的javascript作为胶水语言偶尔出现在asp混编之中；
当web2.0之后JavaScript第一次开始在web前端比重加大，也引入了ajax的使用，开始慢慢重要。
08,09年随着jquery等js库和js-ui的出现，开始在项目中出现各种js库文件；
慢慢随着前端比重越来越重，js mvc,mvvm等框架的出现，不同编程方式的引领潮流，于是项目中出现了各种对于js面向对象的封装和改良，各种class，module，es5，require等等，每次调试总有种穿越百货商场的感觉。
于是为了达到控制dom元素和样式的方式只能在后面不停的增加js代码判断dom状态，修改css样式。
解决方案：
所以以后新项目中，强烈建议引入前端开发框架，不管是knockout,angular,backbone起码整个js代码结构有迹可循，不会像无头苍蝇到处乱撞浪费时间，js代码需要有组织有纪律，这些框架会很好的帮助我们。
多源数据源
第二个问题是太多的数据源头，从之前的单机应用中，数据直接来自于后端，通过循环拼接html元素显示在前端。
而后开始接入其他系统的数据和服务，于是出现了webservice，restful-api，jsonp等。
在加上某些特殊配置的js文件作为数据源。
现在的系统中已经很难找到统一的数据管理源头，需要再不停的判断，不停的截流，再作补贴与修改。
解决方案：
一定要做前后端分离，或者进行统一数据源的管理，服务端可以单独建立一个层进行服务端及外部api的统一封装，前端界面需要建立对应的js工程文件进行数据源的管理，道理就是统一且唯一。
硬编码，白名单
修改了几天，经常有不同的运营同学提交bug，说同样是运营账号为什么会显示不同的界面，结果查看一下是因为系统里面出现了硬编码账号控制，可恶的是硬编码账号会出现在xml配置文件中，服务端代码中，数据库中，js文件中。
一个个改过来都是新需求，结果被运营定位成bug心里甚是难受，bug和需求能是一样的吗？bug对于程序员是多大的伤害啊。
解决方案：
建立白名单，最初开发同学不要相信运营或者产品同学的“肯定”，“确定”的话语，比如“放心，肯定不会改了”，结果换了一个产品照样改，为了不吭自己人，兄弟建立白名单吧。
一定要有产品介入
这个项目的特点是直接运营同学和开发同学对接，运营同学的需求和疑问会直接交给开发同学，最后的问题就是运营根本不知道这个项目和数据在哪里产生，将要去哪里结束的。
举个例子，运营希望在所有的页面都有发红包的功能，开发跟他确认了半天，确定吗？他们会一样吗？数据会正确吗？这样真的好吗？
“确定，确定”
结果后来说，这个页面好像得控制一下账号，但是不是权限；每个页面发送红包的金额应该可以控制的，其实好多活动在这个页面是不需要发红包的。
其实他都不知道在创建红包的时候做配置就可以控制在不同界面上的展示了，但是他看不到整个系统数据的流转。
这个时候就体现了产品同学的作用，他会将运营或者无技术思维能力用户的需求进行加工和确认，对多个需求点进行规划和总结，同时有效调整整个数据业务流程让多方需求都能有效在系统中流转起来。
但是没有产品的结果就是沟通太费劲，开发同学又当客服，又当产品，又当顾问，时间就这样非常不宝贵的浪费了。
每当这个时候突然意识到产品同学的作用了，原来大家是相爱想杀啊。
当没有专门懂业务的产品，有多需求有说不明白的运营提需求，有为了省事轻易相信需求的开发，有没有通过工程及框架限制代码风格而是幼稚的相信开发人员的架构师和技术经理共同造成了这个“牛B”的项目一步步越来越烂。
