企业是否允许有多个管理员?
如果出现多个管理员,是否允许管理员登录?
某程序设计:如果企业有多个管理员,则管理员在登录时就会报错。
这么设计是否合理?肯定不同的人,各有各的看法。
从程序设计角度来分析,【企业设置管理员】和【企业成员登录】是两个完全不同的抽象概念,应设计为两相模块,应该互不影响。
如果强行产生关系,就会使程序变的复杂,在修改程序时,很容易引起bug。尤其是当模块较多时,模块间的相互依赖我们称之为耦合,耦合越多,越容易出问题。
我们在做程序设计时,应该尽量解耦,而不是增加耦合。
写此文章是源于我遇到一个真实案例:
即由于修改其他模块的逻辑导致企业出现了多个管理员,结果所有的管理员都不能登录了(当然实际还有其他的影响,只说登录是方便缕清逻辑)。我提出:
- 首先,企业不允许存在多个管理员,这个设计我赞成,没有问题,其他模块的bug应该修复。然后修复一下数据即可。
- 其次,我建议登录应该解耦,不应该受企业是否有多管理员的影响。避免以后线上真的出现这样的数据而引发故障。
对于第一点,大家没有异议。
对于第二点,总结下来的观点如下:
- 大部分的人认为没有必要,说只要做到了第一点,就不会出现这样的数据。如果出现了这样的数据,也是数据问题,应该通过修正数据解决。
- 还有一部分人认为是历史设计问题,但是鉴于出现问题的概率比较低,没有必要改了。
- 修改也需要成本,需要回归测试,可能会因为修改而引入新的问题。没必要在当前版本解决,可以放到以后解决。
- 修改会导致逻辑变的更复杂。
我认同2,如果代码逻辑控制的好,出现脏数据的概率很低。如果运气好,或许线上永远不会出问题。但我不认同1,3,4。我的论点是:
- 针对1,能通过程序解决的问题,尽量不要通过修数据解决。
- 针对3,我同意修改确实需要成本,我也同意延期解决。但是我觉得以这个做为【不在当前本解决】的理由不合适。因为现在bug已经出现,本身就要对程序做修改,然后做回归测试,此时不改,更待何时?规划到以后的迭代,然后再做一遍回归测试?哪个更节省成本,这个账怎么就算不清呢?(当然如果领导愿意,我也无话可说)其实这根本就不是领导算不清账号的问题,而是按照公司目前的惯性,一般延期放到以后解决的问题,基本上就永远不会再解决了。典型的政绩导向,问题交给下一任,至于下一任怎么解决,我才不关心。我又不会为公司服务一辈子。在目前减员增效的大背景下,说不家那一个就把我干掉了,我干吗为这样一个概率极低的问题这么上心?
- 针对4,修改是解耦,预期是逻辑变得更简单,而不是更复杂。另外,在没有看过代码前不能下定论,至少要经过梳理对比才能下结论,拍脑袋认为修改会导致逻辑变复杂不合适。另外,bug已经出现了,我们又如何知道修bug的改动会不会让逻辑变更复杂呢?我们从来不会质疑修复bug所带来的复杂度提升,怎么用到修改设计上,就会更愿意质疑呢?(当然这种质疑是有道理的,因为设计本身就意味逻辑变更,所以我们会更关注设计上的逻辑变更,但是其他情况所带来的变更就应该被忽略吗?)
最后我想说,设计问题才是最大的问题。线上故障之所以多,就是因为我们在做设计的时候不愿意费脑子思考,什么都不如简单粗暴的修数据来的爽快。
各位同学,你们的看法是?欢迎评论留言。