现在项目组的一个同事,和我一起做 OA 系统。
1.权限模块,他设计的表里有两张角色表。我问他为啥有两张角色表?他说一张用来分配权限,一张用来做业务。我说用一张角色表就搞得定了,而且系统里搞两套角色不仅不好维护,也不容易理解,一套角色就完全可行,并且给他讲了半个小时如何做,结果他就是弄不明白,坚持搞两套。
2.不仅角色搞两套,用户和角色的关系也并没有设计单独的一张表来存,而是把角色 ID 绑定在用户表里的。也是就用户表里有一个字段存的角色 ID 。这样一个能有一个角色了,丧失了灵活性和可扩充性。我让他单独建张角色用户表,他表示理解不了,还是按照他的那个思路整。
3.他设计的每张表里都会有很多莫名奇妙冗余的字段,我问他那些字段用来干什么?他给我的解释是说不定以后会用到,先留着。我晕!难道以后有新需求就不能在往表里添加字段了么?还有他的每张表都喜欢加一些状态字段,里面全部存的是'01',’ A01 ‘这种值。然后代码里全是硬编码,根据这些编码处理业务逻辑。我问他设计那么多状态有必要么,他给我的回答还是说不定有用。我刚进入项目组写代码时,对那些硬编码实在是忍受不能,只能手动清理出来,用公共的常量字符串来代替。因为他整的全是字符串,我想整成枚举都不行,只能用一个超大的公共静态类来存那些硬编码。
4.我进项目组之前,他写的模块前段页面上的数据是拼成字符串,然后用 ajax 传到端代码里面。后台代码是用的 Request.From['username']这种方式获取页面的请求数据。根本就不知道什么是模型绑定,跟别说前端的表单提交了。拼的字符串里面,字段之间用的#cell#隔开,行之间用的#row#字符串隔开。传到后台后再用字符串的分割函数分解成数组,然后按数组顺序一个一个的往实体类型里面拷贝。我说你这样拼还不如在页面上直接拼成 SQL ,传到后台执行 SQL 就行了,费那么大劲干啥呢?他很惊讶的反问我,不那样整那你说咋整呢?
……
总的说来,他没有基本的数据库设计常识,基础知识也低得令人发指,但偏偏有着惊人的执拗,很简单的问题我都得费好大劲给他解释,然而并没有什么乱用,他找不出我给他讲的方法的不合理,但他还是固执的坚持他自己的理解和设计。现在我只有按照他设计的那些蠢得想哭的方法写代码。要是你碰到这种同事怎么办?