关于软件项目和规范性的东西

    最近在做一个很是头疼的项目, 项目是其他开发团队写的，由我和我的同事负责项目的收尾的工作.

在接手这个项目的时候，感觉很是无语，本人作为刚刚从学校毕业的学生而言，可以毫不犹豫，毫不客气的说，项目能够写成这样真真正正的是一个奇葩了。原因很简单，这个项目违反了很多项目开发中应该遵守的一些常规性的规范，也正是因为这样导致项目在由其他团队接手的时候，造成了衔接上的困难。

    1. 首先项目中使用了大量的存储过程作为业务逻辑的处理方式，我觉得这绝对是一个苦逼的行为，我们知道存储过程是高度的与数据库相关的，对于系统移植来说是相当的麻烦与繁琐的，所以一般来说系统的可移植性是很低的。另外，项目中不是所有的人都对存储过程十分的熟练，造成的问题是开发的过程中，很小的改动都会付出相当长的时间，当然随着项目的深入这一部分的问题可以忽略，但仍然存在的问题是，当我们改动一个业务的时候同事需要修改代码和过程是一个非常麻烦的事情，无形中增加了负担。无可厚非的一件事是存储过程能带来效率上的提高，所以我们更多的是将该部分的内容放在系统调优的过程里，即使如此，我们依然应该保留普通的代码。一边与对比效果的，这样一旦进行系统移植，我们可以很方便的执行。

    2. 接原来的博文写下第二点。今天修改了一天的页面，原因是为了兼容IE8，原来在IE10下显示还比较好，修改成为IE8兼容模式以后，完全走了行。这里就暴露出了该项目写的第二个不妥之处，原来的项目页面完全是用table进行的布局，修改起来相当的麻烦，而且整改页面就只是一个复杂的bigtable，进行层层的嵌套，导致修改的时候非常的麻烦，一个小小的修改可能要影响整个页面的布局。其实整个页面完全可以分割成几个完全不相干的单个table进行布局，这样在进行布局的修改的时候只对一部分进行修改即可，不至于影响到整个的也面的布局。和分成几个div进行布局是一样的效果。实际上页面就应该采用div+css进行布局，而不是使用table进行也面对框定，这样在修改的时候也方便，也便于进行相应的控制。table的布局在n年前就已经被抛弃了，当然在一些特殊的页面中table的布局结构还是更好的解决方案。希望看到文章的童鞋不要办这样的事了。否则一旦项目页面出现问题可能要付出沉重的代价。