最近的一些工作,让我突然想起了一个概念:过度设计。之前在看大牛分享的信息时,其实有反复看到关于过度设计的描述,不过给出的例子多数都是围绕着系统架构设计或编码阶段的一些具体实施来阐述“过度”的。

我之前有写过一篇文章,其实就提到了一种过度依赖软件的情况。虽然与今天要讲的内容并不相同,但却都与“过度”二字有关联。

最近我们团队在开发一个较为复杂的需求,这应算是这个项目目前为止复杂度数一数二的一个模块了。简单描述,该模块提供了公司职员工作安排功能:

  1. 部门经理对员工未来周进行排班计划时,要尽可能满足该部门的工作时数限制(避免不合理的加班)
  2. 该排班计划有灵活的多级审批流程,系统要识别出排班变更前后导致的差异并交给审批人批复
  3. 公司要可以统计出该部门某一周的排班变更频率,不同时段的排班变的性质不同
  4. 员工是跨部门的共享资源,多个部门排班对同一员工不能造成时间重叠
  5. 不同部门对员工的标准工作时数要求是存在差异的(例如A部门可能要求员工一周不能超过40小数,而B部门要求员工不能连续工作超过5天)
  6. …..

你可能不信,如果我这样罗列下去,大概能有将近50条各种各样的规则,可能更让你不可思议的是,这些规则在某些极端情况下还存在语义上的冲突(欢迎来到真实世界)。正是这些冲突,导致了软件的使用者和开发者之间的距离,或者说对相同系统的不同理解,不同视角。

起初,我一直认为,大道至简,但现在认为,存在即合理。这应该是一种思想上的提升吧,毕竟你并非活在“任何逻辑必须合理且高效”的现实世界~~好啦,让我们继续话题。

我花了一些时间静下来思考,该模块目前为止的状况,都是哪些因素引起的。这么多规则,哪些是客户本质的需求,哪些是由本质需求推理出来的间接规则,哪些是由于软件设计的局限性产生的,哪些是由所选择的具体技术栈引起的
总结后发现,直接来自客户的本质需求只占总量的30% - 40%,而现有具体技术导致的大概占10%,剩下50%就都是在项目需求分析时细化推理出来的了。考虑到与客户沟通存在的理解偏差,加上开发人员的经验和能力,我认为这剩余50%的规则很值得寻味。

我拿其中的一类问题来给大家看一下:

  1. 如果部门的工作时数规则变更了,历史数据怎么处理?
  2. 如果某个员工在不同部门出现排班,部门的限制又不相同,审批时该如何处理此员工?
  3. 有的限制是以天为单位,有的是周,有的是连续性,那跨天排班,跨周连续性排班怎么计算?

这些问题,在没有系统的时候,存在么?或者说,存在的那么明显么?换个角度思考,这些问题都一样的重要么?如果处理不当,整个系统会变得毫无意义么?如果我们的客户不是完美主义者,他接受一定程度的瑕疵,作为设计者,我们又该如何权衡?
我相信,尽最大可能的了解客户所在领域的背景知识此时就显得极为重要,以此来度量出不同类型数据的价值,此外结合自身对软件人机交互的理解,“曲线救国”。

而,如果,追求极致的逻辑性,很可能使项目陷入停滞,而且设计出的方案一定是十分复杂的,实现起来,维护起来都是很困难的。最要命的是,如果没有对软件交互花足够的心思(一般程序员都会忽略),最终结果一定是惨烈的。花了那么多时间和精力,得到否定的结果,不仅影响团队的整体士气,客户也会对你失去信心。

如果我们换个做法,不要过度放大一些问题,不要为破坏了某个规则而感到过度不安(主要是强迫症),及时且尽早的将一些冲突问题与客户讨论,观察分析他们对待此类问题的反映,以此来自我消化同类问题(如果所有问题都与客户讨论,不仅时间成本很大,也很可能遭到客户的反感)。

最终你会在合理的时间交出一份90分的考卷,剩下的那10分你有足够的时间在未来搞定(也可能交给别人了)。