抽象需求之分析及探求实现可循之法

引子

近日崇左方就路侧运营以来反复出现的问题进行了汇总并抛过来。这意味着，伴随着问题/需求，路侧即将产生一些新得开发和改动工作。

不安和抵触

坦白讲，对于开发人员而言，面对问题和需求，我们或疑惑，或惶恐多少是有些不安和抵触情绪的。于我司实情，我们首先可排除一种可能，就是：开发人员缺乏责任心、懒惰。除开这种不分青红皂白一棍子打死的极端，探本究源，这种不安的情绪，还是来自于不确定。一方面，来自于问题的阐述。如问题抛出方，是否自己经过了审慎思考和论证，提出了合理的问题，可明白知道自己在讲什么？如果是UE（用户体验）类问题，那这些是否有反馈依据，是否有收集足够得民意或调研结果？之后，在需求转述传达环节，又是否将需求清楚表达、传递给前端市场人员？市场人员是否又准确传递给开发人员？另一方面，开发人员自身面对既存问题，和新得需求，是否有把握实现？

什么需求是合理得？

面对需求得轰炸，我们很容易受情绪牵引，容易陷入不自觉的妄断：这个需求提得不合理！那个需求实现不了！

那么请静下来，问寻一下自己，是认真否思考过这些：什么需求得提出是合理的？什么需求是可承接能实现的？有什么客观上可依据的判定标准吗？还是仅凭自己的好恶，或者由于自己没把握、现有的架构改动起来难度太大等，主观臆测、抗拒从而断定其不合理，不能实现？

如果妄断先入为主，一定会阻碍我们用客观的视角对需求真正涵义的进一步深挖和明确，不能如实观照。从而由于浅表得理解，草草应付实现了事，导致了后续再有新需求迭代时困难进一步加重。

一个例子

例如，对于这样一种场景，即系统内车主已通过微信自主缴费等手段触发了离场（即逻辑上、软件层面已经实际出场），而物理上由于车主接打电话、熄火等诸多原因暂未将车开出车位，恰逢此时高位视频等设备由于随机干扰又推入了一条入场记录，导致系统重新产生计费订单，引起客诉。由此，运营方提出需求，能否在系统内设置一个缓冲时窗，避免此类情况发生？面对这样一种场景，其需求是合理的吗？能实现吗？我们的人员在层层自然语言的转述问题时，是否准确清晰？开发人员是否理解了需求的核心含义？

当这样一个需求夹杂其他琐碎得去求一股脑撞过来时，如果我们被情绪蒙蔽，很容易烦躁得认为：物理上车子什么时候离场我哪知道？！高位视频不准总是”谎报军情“，我怎么知道要不要采纳处理？！新得计费订单计就计呗，反正车主已在系统里提交出场，上一个订单已经结束了！……

显然，这不是解决问题正确、应有得态度，无论是谁，无论何事，搪塞、自欺欺人于解决问题本身都无所助益。其实，稍微冷静下来客观分析，上述问题即可等价表述为：某车牌在进入某场站某车位时，其进场有效得前提之一是该车在设置得缓冲时窗内不能有同场同车位的出场行为记录。换言之，当这些条件同时成立时，进场视为无效。于是，软件实施自然就是在前置的入场判定相关逻辑里，加一道上述条件得检核逻辑即可完成该需求的实现。这样，就规避了已完成出场订单得车主由于物理延缓出场再次触发入场而产生得二次计费。当然，由于人性得复杂使得实际情况更为复杂。有些车主可能想利用这样得漏洞，故意提前缴费结束订单，而实际继续停车不想出场，以逃脱减免费用。那既然作为”有人值守+高位视频“得综合方案而言，可通过辅以管理手段来解决，如人工巡检离场车辆确认来敦促违规车主离场，停车公告牌上、小票上明确告知离场限定时间否则追加计费等。程序方面，也可设置异步任务，检测某车位出场后在缓冲时窗过后是否还有同一车辆在该车位上，发出告警或通知或自动生成新订单等。

总之，办法总比问题多。因为问题和办法是一对孪生兄弟，是事物得一体两面，问题本身就是答案。

厘清需求之特性

新旧之分

我们常言，“又有新需求啦”，那么需求新旧有别否？如有，又何谓新旧？

何谓新需求？

窃以为这是难以界定的问题，甚至是个伪命题。因为论及该问题，需要阐明角度/立场/出发点。

从缘起法来看？诸行无常，一切需求都是新得
从业务领域系统内看？那么超脱领域系统之外的需求，都是新需求
领域系统内不存在的功能看？那么未做过、未实现的功能要求都是新需求
不同于先验既存的？那还要看这个“同一性”如何定义……

何谓迭代改进型需求（旧）需求？

或许这个同新需求的界定一样是个伪命题。如果上述新需求从某个角度可区分，那或言除新需求外得一切需求都可归于迭代型需求。

抽象的边界之分

软体可解决，通过改善软件逻辑的设计，可以实现解决该需求
超出软件逻辑可解决边界，必须通过改善人为管理方式来实现的需求

从缘起法看需求的提出

诸事无常。《金刚经》云：“一切有为法，如梦幻泡影，如露亦如电，应作如是观”。我们所言需求，体现在软体的功能上，是由一系列我们称之为“实体”的集合构成的。这些实体之间产生时序上的交互行为（通信），我们称之为业务活动。然而，实体真的存在吗？实体，非实体，是名实体。从缘起法的角度看，实体是不存在的。因为世间不存在孤立封闭的、恒常不变的东西，一切互为因缘，互相联系，互相成就，哪有实体？若实体存在，也必然会像康德所言“物自体不可知”，和我们无关，因为它处在一个封闭域中，不可观测的。所谓不可观测，是说观测也需触缘，所观测的一定是能观测可观测，有触缘的，既有触缘则非孤立，因为观测者被纳入进去组成新得系统，实体便便随着观测者得造作产生相对运动便不再孤立，这与我们理念中的那个实体矛盾，遑论触缘导致实体状态会变？

然而，我们的认识能力就是这样奇怪。认识，非认识，是名认识。我们本质上是割裂的看待、认知事物的。因此产生了“相”，进而执于相，假定它是一孤立的整体，在一定时间上存续具有稳定性，然后我们通过知性范畴这种先天认识法律，通过类比、归纳形成概念（名言）。也就是说，正因为”凡所有相，皆为虚妄“，认识本是无位置和次序的（性空），我们才有选择位次的可能，也因众缘和合（缘起）产生了具体位次。缘起和性空不矛盾，说的是一回事，一体两面。

我们技术上所谓的”对象“以及其”生命周期“，不过是众缘的”成、住、坏、灭“的粗观而已。就拿”停车场“这个所谓得实体来讲，如果哪天政府一道勒令，禁止任何人员/机构以任何名义圈占任何公共资源进行谋利活动，抑或若干年后科技发展到人人可脚踏风火轮，人人可腾驾筋斗云，那么”停车场“还存在吗？况其路外、路内之属性安在？”车位“、”车辆“、”费率“等实体，亦复如是。

此时，关于需求究竟为何，因何如是提出，还是问题吗？吃茶去！（参）

从业务领域看需求

领域，非领域，是名领域。世间万法都是互相联系的，何况所谓的“三百六十行”行业之分，乃至据其细分衍生所谓得”业务领域“之别？惟显其陋矣！

然而，我们众生精力有限，于这世间做活计，得生存，得活着，故执计于这些。对于我们做停车业务人来说，现实生活中，我们执业于我们所认定得这些实体场站、车子、车位、智能设备、费用、车主、收费员等，现实业务表现为这些实体得交互活动（造行造业）；对于软体而言呢？就是对这些实体和其交互活动进行抽象表达，由此产生软件中得实体域，这些实体域相互通信交互，又相当于和合而生新得实体——”记录类实体“；再对这些记录类实体进行聚合呢？就是我们所做的聚合统计结果。这些统计结果通过UI展示给领导、给相关用户使用，他们得脑子一咣当，水啦，面啦，浆糊啦，就又产生出了新得业务需求……你看，业因和果报都在，法尔如是。

那所谓得”业务需求“，是谁得需求？是众生得。就是众生在其能观所观得众实体中所扮演得不同角色，基于各自的位次（立场），有了各自得分别和好恶，将其所欲，和盘托出尔。

并且更甚，由于众生无明，”贪嗔痴疑慢“五毒俱全，甚是厉害，需求才不断变本加厉哦。

编码实现需求的自由度

对于变本加厉需求，实现得难易程度若何？

根据领域边界，可分为领域内外；根据存续状态，可分未曾实现与既有实现之分。概况而言，无论领域内外，未实现的功能，设计和实现的自由度大些。此时属从0到1，从无到有的阶段，自由度虽大，但由于无位次可依，变相来看就是可选多、选择难，所谓”万事开头难”嘛，这个奠基阶段很重要。

第二种，就处在第二阶段，从1到多，或从有到优，量或质的提升了。此时的需求，是要对既有的功能改进型迭代，设计编写代码的自由度会小些。因为，通常理由如下：

不主张推倒重来，风险过大
要向后兼容
不重复投入成本，不重复劳动

因此，从编码实现自由度角度来看，开发完成新功能不叫能耐。真正难点、关注点还是在于这种如何改善既有实现来迎合新的需求，又能向后兼容。（ps:想象要对一个已竣工得大楼进行硬体、软体得结构改造有多难！）

对于既有实现如何改进？

重构的时机？

首先，所有实现的改进，我们称之为重构。而重构的时机，我们不主张“临时抱佛脚”，不主张“一次性、大规模的”重构，那样风险太大，代码质量没有保证。一个总的原则应该是：小步子的渐进式动态重构。让重构成为架构演进的常态。让”架构演进“本身去成为、去定义架构。

重构的内在逻辑是什么，即重构何以可能？

这里所说的重构，关注点不在于细碎的如变量名、注释的改善优化（当然也包括这些），而是侧重于结构上大的实现变动、代码重组等。

我认为其所以能，原因如下：

接口/协议的稳定性
该需求的阐明，仍处在领域边界内，即实体定义和实体交互的边界内。

接口的重要性，对于搞技术的人不言而喻。它的稳定性，是能更换实现，能打桩测试，能使用各种模式变换组织代码得以可能的前提。

而对于领域模型的边界，这个问题的理解程度可能就因人而异了。以最简单的“学生选课”业务系统来说，定义的实体有“学生”、“课程”，其业务是“选课”，使得学生和课程实体发生关联。那么假如现在新增一个需求：请显示出，该学生所在的班主任（或请显示被选课程的任课老师）。请问这个算新需求还是算迭代需求？在既有系统内，能实现么？答：能也不能。显然，不能是因为没有老师这个实体嘛；能是因为引入定义这个实体，并让其和学生或课程发生关联，就可以实现了嘛。至于要不要开始落实实现（你这情况得加钱^_），就是另一回事了。

这样，引言所提问题：什么需求能接/实现，什么需求不能接/实现？有数了吧。

既有抽象良好得情况下

如果既有设计架构良好，高内聚，低耦合，正交表现良好且功能独立，那么恭喜你，对于这样得架构扩展新需求，只需要遵循OCP原则，扩展新增功能实现就好了。那功能不独立呢？也没关系，复用调用嘛。有现成能直接调用得接口最好，不能直接调用得，间接委托调用，对其进行代理、适配、装饰、门面等模式包装下。

那如果，既有抽象不好，计将安出？本着小规模渐进重构得原则，利用设计模式施行局部重构，造新得、好用得轮子，当然这一过程还是要注意审慎对待接口依赖关系，注意高扇入/扇出问题。那再次之，就是以下几种恶劣情况了，就不妨大手术大换血，重新实现了：

业务活动流架构死板，无法灵活适应流程上得变化
技术性能差，如调度架构不合理
可扩展性差，如业务无关得技术平台搭建得不好
代码组织混乱，分层不清晰，模块混乱等

结论

信心。通过以上论述，无论市场还是开发人员，我们可以坚定信心得一点是：只要软件需求还在领域模型得交互边界内，一定能改善设计和实现。
超出领域外得需求，需要建立、引入新得实体域模型
静态实体域，决定了需求可扩展得边界
动态得实体交互，即业务发生得过程影响了实体得状态

策略

没有得模型，建立、引入之
有域模型无交互，让其发生交互联系，增加业务
交互/关联发生变化，那么跟随其变化，并将实现做活，使之策略化，动态化