《软件方法》读后感-三年前端开发的思考，如何有效地阅读需求？
时间：2023-11-20 14:37:00
DDD领域驱动设计批评文集>>
自测题集强化软件方法>>
软件方法各章合集>>
本文转载：https://juejin.cn/post/7051749719214653471
[外链图片转存失败，源站可能有防盗链机制，建议保存图片并直接上传(img-kLM8zfzV-1655335044660)(https://mmbiz.qpic.cn/sz_mmbiz/GmehiaiamM62ooaVkTgicmrYgnIC0rdFniaeDxCbMd9xVlPmBFO5gRQUEKQv8fSPRtTKrNyicWWIbMSxu2l8X9UibQPQ/640?wx_fmt=other)]
本文是基于lucio最近对软件方法的研究进行了整理lucio我们不会理解学习后的一些思考，比如UML等待实际操作的内容，只要分享一些，我以前说过不了解读完后，大受震撼”的观点。
你开发的时候有什么烦恼？
在诸如CSDN在掘金的技术论坛上，有各种与软件开发相关的教程，我们可以在编码过程中找到几乎所有可能出现的问题。
这些对我们刚刚接触到软件开发，有很大的帮助，我们个人编程技术的增长，也是随着一个接一个技术文章阅读，一步步成长。
[外链图片转存失败，源站可能有防盗链机制，建议保存图片并直接上传(img-6gBvdgHT-1655335044663)(https://mmbiz.qpic.cn/sz_mmbiz/GmehiaiamM62ooaVkTgicmrYgnIC0rdFniae5icDnsdW5lp8fk2FNVEXx1tG3fwZOH1TcpAfonrmznUhb7MsrhCBKog/640?wx_fmt=other)]
但随着工作时间的增加，lucio慢慢发现，让lucio烦恼，每天占用大量的工作时间，不是无法解决的技术问题——最后，技术问题总能找到解决方案，而是需求难以理解、无休止地实现细节确认和沟通、急促的排期和改不完的bug。
若需要，让lucio半夜三点辗转反侧睡不着，绝对不是因为不知道如何实现某个技术点。更常见的原因是表到了，不能完成工作；担心产品在线，突然发现bug；找到一个需求迭代，因为旧代码留下的坑，你必须更复杂地挖另一个坑。
编程技术水平，我们学得快或慢，只要愿意学习就会提高。但这些都困扰着我们，除了编程技术，如何解决？
一些开发人员可能会认为这是解决不了的问题，由于问题的原因不在自己身上，产品经理的需求不明确，产品经理总是改变业务实现，项目经理安排的时间表不合理。
确实，缺乏知识经验产品团队，和不流畅的沟通，很容易带来糟糕的开发体验，但是我们技术人员认真剖析自己想一想，我们自己就没有问题么？
假如还是觉得没有，或者问题不大，那我们就好好想想这些问题：
-
什么样的需求是好需求什么样的需求是坏需求”？
-
业务流程又变更为什么你以前没想到它会改变？
-
看完需求文档，你真的理解需要吗？为什么会有这样的需求，实现需求，对谁最好？
仔细想想，我们是否发现很多时候，我们对需求的判断是我们自己的主观的想法，或者基于以往经验的判断，没有真正的标准和依据。这似乎不太清楚…，以前不是这样做的…产品经理显然很难说服这种说法。
有时我们不能改变上游发展的工作规范，但至少在发展环节，我们可以做好需求分析和需求分析，我们可以软件设计更合理，可以避免小变化带来大规模修改，甚至可以反推产品，补充需求中不完善的路径，提前确认可能的变化点。
结论
很多时候，我们的烦恼来自于前期需求分析不足。
需求分析确实需要一些时间，但可以肯定的是，但收入可以证明花时间是值得的。随着项目规模的增加，这种收入将越来越明显。
如果你想知道如何进行需求分析，不妨继续阅读，一步一步地理解什么是软件开发？需求分析是什么？
软件开发在做什么？
长期以来，我们优化编程的主要目的是节省编码的工作量，让软件提供更好的服务。
但根据《软件方法:业务建模与需求》一书的观点，我们开发软件是为了销售和提高需求质量提升销售额；编码设计就是成本。我们优化编码，节省编码工作量降低成本。
经营公式利润 = 收入 - 成本。
软件开发的公式是：利润 = 需求 - 设计。
结论
我们软件开发的最终目的是提高利润，无论是节省工作量还是改善用户体验。这种利润可能不直接反映在我们的开发人员身上，但也以其他红利的形式反馈给我们。
谁在为软件买单？
我们开发了一个为谁服务的软件？
这是一个很容易给出错误答案的问题。让我们举几个例子：
问：微信支付，这是几乎每个人都会使用的产品，微信支付是为谁服务的？
A:用户，使用移动支付购买用户。
我相信这是许多读者的回答。不幸的是，这个答案是错误的。
仔细想想，微信支付不向使用移动支付的用户收取费用，用户不会为更快的支付支付微信。例如，如果他们每年支付100元的会员费，他们可以使用微信支付。我相信很多人会选择不使用它。
真实为微信支付接入微信支付访问微信支付的商户，他们向微信支付手续费。微信支付给他们带来的是提高收费效率，减少错误，让用户无现金进入商家消费。事实上，改善移动支付用户体验的最终目的是让更多的人为了商家的利益使用微信支付。
[外链图片转存失败，源站可能有防盗链机制，建议保存图片并直接上传(img-L7FM5p81-1655335044667)(https://mmbiz.qpic.cn/sz_mmbiz/GmehiaiamM62ooaVkTgicmrYgnIC0rdFniaeluJYiaHldicnAhURnqjKlvGgKyAEKdqkyqDFMxPrfYJyDZIzJnMKdM3A/640?wx_fmt=other)]
类似的例子，一个武侠风的RPG游戏，不是大多数零氪玩家，而是那些真正为游戏充值的人。零氪玩家更像是游戏开发者提供的氪金玩家的玩具。
[外链图片转存失败，源站可能有防盗链机制，建议保存图片并直接上传(img-Lja1Ru2P-1655335044668)(https://mmbiz.qpic.cn/sz_mmbiz/GmehiaiamM62ooaVkTgicmrYgnIC0rdFniaebnqJgvPicXl8HMttL0Bd3ZWt5UGFYk3XCSMVpCuyztiaPKJJv1V5p0Qg/640?wx_fmt=other)]
类似的例子，支付宝过年集五福，服务的不是每天扫描代码的用户，而是五福卡背面的商家和品牌。支付宝的产品不在乎用户最终分配了多少红包。他们需要关注的是品牌广告和商家发行的优惠券给商家带来了多少转换和利润。
[外链图片转存失败，源站可能有防盗链机制，建议保存图片并直接上传(img-njcYVdEW-1655335044670)(https://mmbiz.qpic.cn/sz_mmbiz/GmehiaiamM62ooaVkTgicmrYgnIC0rdFniaeNx5YETDPyCm7OEEibAPqIFWRXKxKKbk5CRdRQqqXdKLib3LGrIUFicXTA/640?wx_fmt=other)]
真正理解软件目标人群，在需求分析中，更好地理解产品提出的许多互动。比如用户收五福的时候，有一个痛点，就是每张优惠券都需要从福卡翻过来才能收到。为什么不收到福卡就直接收到卡包？因为集福卡不是为了方便用户。它的真正目的是让支付宝的商家和品牌有更多的曝光和验证。这一步的繁琐操作是让用户看看他们得到了什么优惠券，并考虑是否使用这张优惠券一秒钟。
结论
在需求分析中，我们经常犯的一个错误是忽视思考目标群体的需求，我们能为目标群体提供什么样的服务？服务。多思考一下这个问题，我们也就能进一步理解产品经理提出需求的意图，理解意图后，在程序设计阶段，我们就可以设计更合理的架构，为可能出现的需求变更预留好接口。
其实很多的需求变更，都是可以预见的，是“假的需求变更”。理解需求的意图，能提高我们预见变更的能力。
改bug，实际上改的是什么？
软件出现的bug，一般是什么问题导致的呢？我们经常会在复盘的时候，给bug基于原因做分类，比如前端逻辑错误、后台逻辑错误、需求理解错误等等。
随着开发经验的增加，单纯因为编程设计导致的bug，会越来越少，随着和产品团队的磨合，我们遗漏需求功能点、文档理解错误的情况也会减少。
但是bug依旧存在，而且越来越多的bug，其出现的原因变得“不好解释”，比如下面这个故事。
程序员小张完成了一个抽奖的功能，产品小红体验功能：运气好，抽中了，显示“恭喜获得”；运气不好，没抽中，显示“很遗憾，你运气不好”。貌似一切都没什么问题，于是小张和小红开开心心得把功能上了线。
但是没过多久，线上出问题了，许多用户抽了奖，却什么都没显示。小张连夜排查问题，终于发现了，用户抽中了礼包，但是礼包早被消耗完了，于是用户什么也没有看到，于是小张连夜给抽奖代码加上了判断，告知用户“礼包发完，下次再来吧”。
问题复盘的时候，小张需要选择bug原因，虽然觉得有点懵，但确实是改了几行代码问题才解决的，于是，小张恹恹的选了“程序逻辑错误”作为bug原因。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vRzltNhi-1655335044672)(https://mmbiz.qpic.cn/sz_mmbiz/GmehiaiamM62ooaVkTgicmrYgnIC0rdFniaeEH0dXu8flCEzwdpf1pianbY8481dSGxNd2Uicg3yaQ3x05aQWklcFNEg/640?wx_fmt=other)]
QAQ摸摸小张的头，问题出现了确实有点问题，但至少不能因此就说小张的编程能力不行，就上面的问题来分析，“程序逻辑错误”并不是最本质的原因，我们透过现象看本质，导致问题最本质的原因，是“需求逻辑的错误”，当然这也不能说小张完全没有问题，小张的问题在于没有进行需求分析，没有及时发现功能点缺少的扩展路径。
结论
实际上，我们改的很多bug，本质上都是需求逻辑错误，出现问题的原因是我们没有对需求进行分析。
基本路径，是用户与软件交互最顺利，最终能达到目的的路径。
比如用户用银行卡到自助取款机取钱，其基本路径是：用户插卡->输入密码->输入金额->取款机吐出现金。
扩展路径，是基本路径外，其他发生意外的路径。
比如还是用户用银行卡到自助取款机取钱，存在的扩展路径有：
用户插卡->输入密码->密码错误；
用户插卡->输入密码->输入金额->用户余额不足；
用户插卡->输入密码->输入金额->取款机没现金了；
···等等。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SP5EhCE0-1655335044674)(https://mmbiz.qpic.cn/sz_mmbiz/GmehiaiamM62ooaVkTgicmrYgnIC0rdFniae42DJWsEZfwGoA6mIb67POpdEhibFbmOkbRNmPNuqrzKer1CN1bk8rsA/640?wx_fmt=other)]
产品提需求或者开发人员分析需求的时候，最容易犯的一个错误，就是只关注了基本路径，而忽略了可能存在的扩展路径。
开发需要进行需求分析，而且不只是浏览需求文档，更重要的是，发现可能存在的扩展路径，及时反馈给产品并一起补齐扩展路径，需求分析做好了，bug自然就少了。
学会辨别什么是“好的需求”？
很多时候，我们判断需求写的好不好，都是凭借过往的经验，或者看需求文档里面字多不多、流程图画的多不多，交互图清不清楚。这虽然也有点道理，但是不完全是对的。
你奋笔疾书一个月抄了整本新华字典，不能就直接把曹县的文科状元颁给你吧。
那什么是“好的需求”，具体的判断可以读读《软件方法：业务建模和需求》一书，总结下来，需要有下面这些元素：
-
明确需求服务的目标组织（理解为谁服务，进一步理解需求）
-
明确需求带来了什么样的改进（开发通过这个点理解需求的意义，理解意义是为了更好的程序设计）
-
明确软件的执行者是谁（不一定是目标组织，比如高铁购票app的执行者是买票的用户，但是目标组织是高铁集团）
-
明确的系统用例（从业务序列图识别出来，表示需求中，软件提供给执行者的功能，比如抽奖活动，其系统用例有：用户->抽奖，用户->查看抽到的奖励，等等。这些常常是在需求中写出来详细流程了，但却缺少了提炼出一个功能点的地方）
-
对每个系统用户（功能点），有明确的用例规约，包括以下内容：
-
前置条件和后置条件（在什么情况下触发，最后达到什么目的）
-
涉众（什么人会参与到这个用例）
-
基本路径（最顺利的交互路径）
-
扩展路径（处理意外的路径，是最容易忽略的地方！）
-
补充约束（用户输入信息的验证条件，软件可以运行的平台，质量要求等等）
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8fpaL1Ju-1655335044676)(https://mmbiz.qpic.cn/sz_mmbiz/GmehiaiamM62ooaVkTgicmrYgnIC0rdFniaeGGF4Hc9qjLNMYOSI3Dh9wibCL4ibo25ev6fmzqlBK8J9gGQ3QXHm8cRQ/640?wx_fmt=other)]
这些元素具体的组织格式，在需求中用什么形式给到这些信息，还需要进一步细化。
结论
但我觉得，不管是产品编写需求，还是开发人员分析需求，以这些元素作为check list，都能有一些意外收获。
其实需求文档的理解成本高、需求分析效果不好，最主要的原因还是在于缺少规范，如果提需求和分析需求，都有一个严格的流程和规范，禁止天马行空，自由发挥，那需求逻辑错误和沟通成本应该会减少很多。
当然，规范的制定和执行也是需要成本的，这块的推进，只能说道阻且长。
但是作为开发人员，我们可以先尝试一下，在需求分析阶段，用规范的建模来理解需求，从而服务于我们的程序设计。
UML：基于基本共识进行沟通
UML图，开发人员都会用，但是在什么时候用呢？
相信很多人和以前的我一样，只有到了需要向别人展示自己的业务实现方案的时候，才会去画各种UML，比如答辩或者项目成果展示的时候。
但这其实违背了UML图设计的初衷，UML图原本的目的是为了辅助程序设计的，而不是先有代码，再来画图。
这种“先代码，后画图”的工作方式，其实就是抛弃了“需求分析”这一环节，这样的工作方式，很容易导致整体设计的不合理，后续功能难以扩展。
UML图使用的另一种误区是，画了一个序列图，却需要展示者先来“讲一讲”，观众才能理解。
UML图是对业务实现的完整描述，是基于软件开发者的一些基本共识产生的。好的UML图，不需要实现者的讲解，也能准确描述具体的业务实现。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-C9UZrzg9-1655335044681)(https://mmbiz.qpic.cn/sz_mmbiz/GmehiaiamM62ooaVkTgicmrYgnIC0rdFniaeGoU4EpOibbX5kXR0EnJHRlFm5FQZByIWrqm5dNVfFWgc9XTo9LOG3fA/640?wx_fmt=other)]
结论
UML图是辅助程序设计，实现需求的时候，不要跳过建模阶段，直接开始编码。
UML图的这些基本共识，是开发人员节省沟通成本的关键，所以，画图的时候，还是要严格遵循规范。
软件在解决什么问题？
软件的目标是业务现状的改进，这种改进，按《软件方法：业务建模和需求》书中的说法，可以分为三种模式。
-
模式一：物流变成信息流
-
模式二：改善信息流转
-
模式三：封装领域逻辑（用软件系统代替人脑）
物流变成信息流，是现在大多数互联网公司在做的事情，比如移动支付，把现金的交易，变成电子货币的交易。
改善信息流转，比如多个系统协作完成的工作，变成只需要一个系统来完成，比如现在很多政务门户app。
目前大多数软件，都是基于模式一、模式二做的改进。
结论
其实除了互联网产业，其他产业的改进，很多也是遵循着三个模式的。
当我们面对一个流程或者项目，找不到可以优化的点的时候，可以循着这三个模式，寻找可优化的点。
阿布思考法
通过需求分析，掌握了需求的来龙去脉后，在设计阶段，我们怎么更好地去设计需求的实现呢？
代码设计涉及到很多具体的知识和经验，这里是讲不明白的，lucio依旧还是只分析一些从书中学到的，对lucio有帮助的方法。
《软件方法：业务建模和需求》一书，提到了一个叫“阿布思考法”，就是遇到一个问题是，先假设自己拥有充足的资源，我会怎么实现这个需求？然后在回到现实中，用自己有限的资源，去山寨这个理想的方案。
这个思考法，可以帮助我们突破自身环境的限制，找到真正合理的解决方案。
我们应该都有过这样的经历，规划需求实现的时候，要考虑很多的东西：时间够不够、投入的人力值不值得、已有的组件是怎么样的、能做到什么程度……考虑的东西太多，我们就不得不对实现方案作出妥协，拿出一个勉强可以实现需求的方案。
但是这样的方案，往往是不好扩展和维护的，下次思考方案的时候，不如试试“阿布思考法”，抛开限制，思考一个经得起时间考验的方案。
知识的诅咒
知识的诅咒（Curse of knowledge）是一种认知偏差，指人在与他人交流的时候，下意识地假设对方拥有理解所需要的背景知识。
这也是开发人员和产品沟通的时候，经常犯的错误，我们不能假设产品同学或甲方了解我们代码实现的全部细节，就像我们不能直接拿着UML图和非开发人员讨论方案。
我了解的，别人不一定了解，这很正常，正确的沟通方式是，面对不同的人，采用对方可以理解的沟通方式去沟通需求，代码实现上的限制和难点也要尽量转换为更通俗的方式来解释。
参考资料
《软件方法：业务建模和需求》潘加宇
本文的大多数观点，是基于这本书的思考，这本书对分析需求和工作方式有很大的指导作用，但是也存在一些缺点，比如一些专业名词，和大家共识里面的名词不太统一，但是多读几遍，还是不影响理解的。
《UML和模式应用》拉曼
《编程原则：来自代码大师Max Kanat-Alexander的建议》马克斯·卡纳特-亚历山大
更多实际操作和代码实现的知识，推荐阅读这两本书。
