这几个月来，自己一直在维护一个“牛”项目，所谓牛项目，就是一个让自己维护了几个月，却无法释怀的项目。
项目是已经做好了的，我们只负责维护。从页面的规模来看，项目不算很大，但据我所知，公司已经在这个项目上花费了N多人力物力，且项目前景不好。
为什么说项目前景不好？
首先，项目本身运用了开发组自己编写的框架。开发者本来想利用自己框架使这个程序运行高效，并且易于维护。事实上，自己维护这个项目得到的心情却是无比的沉重。为什么？因为，这个框架语法怪异、功能不完善，维护起来非常费力。这也提醒了自己：不管什么开源不开源框架，使用前开发者一定要考虑清楚，这个框架是否是已经经过实战检验？倘若是一些半生不熟的东西，还是趁早摒弃为妙，否则后患无穷。
其次，项目结构不合理。项目中的大部分C#代码仅仅起到了一个数据传递的作用。项目俨然成了一种为N层而N层的样子。
再次，项目中的绝大多数业务逻辑被封装在存储过程中。若这些存储过程设计良好，倒也可以接受。可是这些存储过程却偏偏写得乱七八糟，让人难以理出头绪。一个相同或者类似的业务逻辑，你会在不同的存储过程中找到；一个稍微复杂点的业务逻辑会被封装进一个至少有2,3000行的巨大存储过程中。这还不算最坏，最要命的是，存储过程里面到处充斥着if...,else...,还有递归嵌套。看到这些大仙写的存储过程，自己只能用自愧不如来形容！
Ajax形同虚设。点击页面上的一个按钮，程序服务器端立即依据业务逻辑全部重算，完成后，系统框架将整个页面的HTML 字符串一股脑的发到客户端。苍天啊，大地啊，这叫：AJAX吗？
项目中还有一个让人感觉特别奇特的地方。客户反映，系统经常丢失从其他的地方接收来的数据。检查代码后发现，系统将导入的数据和本系统产生的数据混在一起，并且还可以相互修改，甚至覆盖。某位大仙又在导入的地方写了一份相同业务逻辑来检查、过滤这些外来数据。这样一来，想不丢失数据都难呐！
写到这里，自己禁不住感叹：用一种技术去实现一个系统或许不难。难的是如何搞清这种技术的局限性和适用性。不能以为自己手里有锤子，就意味着遇到的所有问题都是钉子。大部分情况下，你还必须要具体问题具体分析，合理使用钳子、扳手、镊子等等其他工具一起协作才行！