好的，我已经遇到过很多次了，但是在这种情况下，情况有些过分夸大了。
客户说： “嘿，您能给我们这个小模块来完成这个小任务吗？”
我： “没问题”。
因此，基于预算和约束等因素，我跳过了一些架构设计工作，并一头扎进去，不费吹灰之力。
然后，他们要求另一个模块。还有一个。和一些增强。多年来，这一切都非常缓慢地提醒您。在不知不觉中，您就拥有了这个可怕的架构可怕的应用程序。
当您被要求做一些小事情时，您会怎么做？您不知道它是否会继续增长...客户是否会继续要求添加（它们也不这样做）。
您不能对它进行过度的架构，因为它毕竟只是一个小应用程序，如果您说（因为我知道所有声音），它们就会移到其他地方“以防万一，让我们将此事物设计为顶层在线安全性和关注点分离。实际上，让我们使用一个依赖项注入工具，它将使这件事真是太棒了……等等。”
他们会说“是的”，然后去找别人。
预算，时间和感知与架构应用程序本身一样重要。
应该如何处理？
我猜这个问题真的可以归结为：“如果您没有所有看起来像是小型应用程序的最终结果的所有信息，那么如何避免（或减轻）早期的架构和设计决策将是完全可以的？以后没用？
Answers:
我遇到了很多这样的问题，而我通常所做的正是您所做的，立即潜入并完成它。
当他们回来获得更多收益时，这意味着他们的商业模式正在发挥作用，并且他们应该愿意多投资一点。那是我坐下来的时候（通常根据复杂程度选择第三个模块），然后告诉他们坏消息。
我将把所有东西放在桌子上，提议重做包括最新模块在内的全部内容，并告诉他要花多少钱。他们通常在开始时会有一些震撼，但如果您有良好的工作关系并且您的工作正常，那应该不是一个大问题。
确保他们理解三件事：
如果他们真的不想打扰完整的重写，您仍然可以使用第3个模块。这可能会花费您几个小时，您需要为此付费。提醒他们，他们真的应该考虑在将来进行重写，因为等待时间越长，花费的成本就越高。
确实要花更多的钱让别人去做。新员工必须重新设计所有内容，而对他们的需求和怪癖的了解却很少，这意味着要花费更多的重写时间，并冒着自己做不到工作的风险。
您不打算快速赚钱。这个东西确实需要重新设计。
顺便说一句，如果您的帐单习惯现在大约一半，完成后一半，则可以考虑为他们提供延长的付款条件。现在将其更改为一半，然后将余额分配给您进行处理。如果他们有预算问题，那可能会减轻压力。
只需为他提供一个小应用程序并为此付费即可。
根据我的经验，万一客户需要更多的时间，那么一开始就要花更多的时间在实际所需的时间之外。但是您必须权衡efford在执行此操作（您是否为此得到报酬）与所有这些附加更改真正发生的可能性之间的权衡。一年后可能会完全替换整个应用程序。
通过在初始架构上投入时间，您可能会觉得自己对自己有所帮助。但实际上，您只是通过使其他模块对他而言便宜而赢得了客户的青睐。
只需为每个成功的模块向您的客户收取更多费用，然后逐步重构初始项目，但始终只是为了满足客户需求。
以前的答案很好，而且，老实说，我可能会做些什么。就是说，对于这种方法，我有点不安，因为您基于对客户的需求（以及找到工作的愿望）的假设来做出正确属于客户的决策
我忍不住应该做的就是对客户诚实，让他们选择：1.我现在可以（相对）便宜地做到这一点。它将很棒-会起作用-但将来的增强功能将花费更多一点费用2.我可以在它上面花更多的时间，这将花费更多的时间，但不会给用户带来任何实际的好处，但从长远来看，如果您需要添加新功能，则可以为您省钱。
理想情况下，您可以为他们提供一些时间/成本方面的数字-否则对话可能会过于学术化-但我很高兴得出这些数字也可以有所作为。至少，按照先前的项目来进行讨论可以使客户的生活更轻松（并且让客户的生活更轻松应该是当务之急：-)）
别人就建立良好的工作关系发表了意见-但是您可以诚实地开始这一过程。如果客户是您甚至无法与之对话的那种人，那么现在可能是时候问问自己您需要多少工作了……
我会将这些“迭代”视为一个单独的项目。完成每个小模块或附加操作后，您应该关闭这些项目。然后，当他们想要其他东西时，请草拟文书工作。随着时间的流逝，该软件变得更加昂贵……这意味着您要为每个小型项目收取更多费用。
这是一种查看方式，而不是... LONGGGGGG项目。
您如何避免（或减轻）早期做出的建筑和设计决策，而这在以后是完全不适当的？
你不能。程序员不是通灵的。尽管我们可以预测简单的事情或看到UI的改进，但是我们无法真正编写超出客户端以后可能不想要的代码（您看到那里的精神错乱了吗？）。
您的问题提到它具有业务流程，但是我不确定它们是否是好的流程。这里有一些提示：
杂草丛生的产品
它发生在我们所有人身上。从头开始重建通常是一个糟糕的主意，尤其是考虑到将来会再次进行。
取而代之的是，我将与用户要求的更改签约。为每个功能添加额外的时间，使用原始时间来处理该功能，并花费额外的时间来改进整个体系结构，一次只进行一次小改进。我们的目标不是在一个合同中完全“修复”体系结构，而是随着时间的流逝慢慢地对其进行芯片化。
逐步改进代码迭代，将重点放在真正重要的部分上。