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