设计不合理才是最大的问题

企业是否允许有多个管理员？

如果出现多个管理员，是否允许管理员登录？

某程序设计：如果企业有多个管理员，则管理员在登录时就会报错。

这么设计是否合理？肯定不同的人，各有各的看法。

从程序设计角度来分析，【企业设置管理员】和【企业成员登录】是两个完全不同的抽象概念，应设计为两相模块，应该互不影响。

如果强行产生关系，就会使程序变的复杂，在修改程序时，很容易引起bug。尤其是当模块较多时，模块间的相互依赖我们称之为耦合，耦合越多，越容易出问题。

我们在做程序设计时，应该尽量解耦，而不是增加耦合。

写此文章是源于我遇到一个真实案例：

即由于修改其他模块的逻辑导致企业出现了多个管理员，结果所有的管理员都不能登录了（当然实际还有其他的影响，只说登录是方便缕清逻辑）。我提出：

1. 首先，企业不允许存在多个管理员，这个设计我赞成，没有问题，其他模块的bug应该修复。然后修复一下数据即可。
2. 其次，我建议登录应该解耦，不应该受企业是否有多管理员的影响。避免以后线上真的出现这样的数据而引发故障。

对于第一点，大家没有异议。

对于第二点，总结下来的观点如下：

1. 大部分的人认为没有必要，说只要做到了第一点，就不会出现这样的数据。如果出现了这样的数据，也是数据问题，应该通过修正数据解决。
2. 还有一部分人认为是历史设计问题，但是鉴于出现问题的概率比较低，没有必要改了。
3. 修改也需要成本，需要回归测试，可能会因为修改而引入新的问题。没必要在当前版本解决，可以放到以后解决。
4. 修改会导致逻辑变的更复杂。

我认同2，如果代码逻辑控制的好，出现脏数据的概率很低。如果运气好，或许线上永远不会出问题。但我不认同1，3，4。我的论点是：

1. 针对1，能通过程序解决的问题，尽量不要通过修数据解决。
2. 针对3，我同意修改确实需要成本，我也同意延期解决。但是我觉得以这个做为【不在当前本解决】的理由不合适。因为现在bug已经出现，本身就要对程序做修改，然后做回归测试，此时不改，更待何时？规划到以后的迭代，然后再做一遍回归测试？哪个更节省成本，这个账怎么就算不清呢？（当然如果领导愿意，我也无话可说）其实这根本就不是领导算不清账号的问题，而是按照公司目前的惯性，一般延期放到以后解决的问题，基本上就永远不会再解决了。典型的政绩导向，问题交给下一任，至于下一任怎么解决，我才不关心。我又不会为公司服务一辈子。在目前减员增效的大背景下，说不家那一个就把我干掉了，我干吗为这样一个概率极低的问题这么上心？
3. 针对4，修改是解耦，预期是逻辑变得更简单，而不是更复杂。另外，在没有看过代码前不能下定论，至少要经过梳理对比才能下结论，拍脑袋认为修改会导致逻辑变复杂不合适。另外，bug已经出现了，我们又如何知道修bug的改动会不会让逻辑变更复杂呢？我们从来不会质疑修复bug所带来的复杂度提升，怎么用到修改设计上，就会更愿意质疑呢？（当然这种质疑是有道理的，因为设计本身就意味逻辑变更，所以我们会更关注设计上的逻辑变更，但是其他情况所带来的变更就应该被忽略吗？）

最后我想说，设计问题才是最大的问题。线上故障之所以多，就是因为我们在做设计的时候不愿意费脑子思考，什么都不如简单粗暴的修数据来的爽快。

各位同学，你们的看法是？欢迎评论留言。