新的项目已经执行到开发设计阶段了，此项目包含之前多个单独子系统，他们将整合为一个统一系统平台，项目包含了数据库的集成、界面的集成，
今天和新项目的架构人员沟通了一些项目架构的一些细节，对他的有些看法我还是持质疑态度，比如下面的几个做法。
＃1、因为多个子系统都有相同的数据表，数据库（SQL Server ）整合时，这些相同的表是否需要整合。
最初他的想法是将相同的表整合为一张表，加字段表示某条数据属于哪个子系统模块。但是最后有人提出：在一张表里会不会出现用户在使用多个子系统处理同一表数据时，造成数据操作访问出现表的锁死；某个子系统产生错误数据时，会影响其它子系统。
我觉得上面的两点，在开发时应该都是可以避免的，但是最后定的是：各子系统重复的表还单独保留。
这里反映的一个问题就是，在项目开发时，如果遇到了技术难点，一般开发人员或开发负责人都不想去画点时间研究新问题，他们都会把新的设计往老的架构上去靠拢，这样降低了技术难点，只是需要花些力气，比如相同代码逻辑要写好多遍。
这样开发人员一直都在用老的知识，造成的结果就是，做了好几年开发，技术水平还是很一般，因为一直在copy老的东西。
＃2、相同信息、不同类型数据插入数据库表通过序列号区分，比如我有一个学生表，程序里面写死序列号1到10000为初中生，10001到20000为高中生。
这种方法很奇葩，既然需要分信息的类型，为什么不在信息表中添加一个”类型“的字段，他的解释时，不加字段可以不动原来的表结构，少改一些代码。
这里反映的一类问题都是，项目的技术负责人一般都优先考虑了怎么做更省事，而不是怎么做扩展性、条理性更强。
比如很多东西都在代码中写成了硬逻辑，不利于之后的扩展和改造。
我觉得很多项目之所以改造困难，bug重重，都是应为前期程序架构人员图省事，埋下的坑。
