在为新系统编写代码时，我不想在设计中引入我可能永远不需要的不必要的复杂性。所以我在这里关注 YAGNI，而是在我认为需要更多灵活性或职责变得更加清晰时进行重构。这让我可以更快地移动。
但是初级开发人员有一个问题，他们不知道何时重构或在哪里构建设计。他们只是在现有设计中塞进更多代码。
那么，解决这个问题的最佳方法是什么？我是否应该更频繁地构建一个更具前瞻性的设计，以便在添加时他们有一个很好的例子可以效仿，即使我们可能永远不需要添加任何东西？还是我应该继续进行更多的代码审查、教育等？或两者？
你们中有人遇到过这类问题吗？你是怎么解决的？
我会推荐代码审查或结对编程。它使您有机会教育您的开发人员并提高整体质量。
也许您首先明确地认识到您的工作的一部分是帮助开发初级开发人员。如果你不是老板，管理层应该签字同意。管理层需要认识到，您的选择是现在开发它们还是以后清理它们，并且您需要管理层的支持来度过这将花费的时间。
代码审查和结对编程是个好主意。它们特别好，因为它们不“只适用于初级人员”——我和我的一位亲密同事都这样做；我们在一起将近 100 岁，拥有 70 多年的编程经验 :-)
但是这里有一个更大的问题：使您最有效的编程方法（YAGNI + 重构）对您的初级合作伙伴无效。 我的经验是，人们需要数年时间才能了解 YAGNI 的好处，所以如果你期望他们只是学习你做事的方式，那么你会让自己失望。
我鼓励你找出一些你认为对你的初级合伙人有用的方法。特定的方法可能无关紧要（异端！）；我在复合/结构化设计、基于对象的设计、代数规范（！）和极限编程方面取得了成功。但
一定要选择一些有名字和一些文献专门用于它的东西，你的后辈可以以学习为荣，这是他们可以在未来的项目中使用的技能。
为了表明它很好吃，你可能需要自己吃狗粮。选择一些你可以忍受并富有成效的东西。
仔细观察你的后辈，并教他们一个决策程序，他们可以用来确定何时应该向你寻求指导。
祝你好运！
他们是初级的，而你是高级的，这是有原因的。
意识到何时需要更改设计的能力就是其中之一。
我会像你一样继续，但鼓励他们在事情变得困难时来找你。然后，如果需要，您可以与他们一起更改设计，这对您来说比重构它更容易，并将帮助您将知识传递给初级开发人员。
一个很好的方式来展示一个设计的构建程度是指定设计在构建时会做什么，然后编写测试来覆盖新功能。当测试通过时，开发就完成了。
您可能会在此过程中意识到您忘记测试某些东西。这很好，并且是有用的反馈，可帮助您下次更好地指定。编写缺少的测试，并且只写足够的代码让它们通过。
然后重构。知道重构时要寻找什么需要一些练习。从...开始
重复这个几十次，它会变得更容易。
另一种看待 YAGNI 的方式是，对代码的任何更改都需要证明是合理的。
要求任何提交需要相关的单元测试（或 BDD 用户故事，选择你的毒药）可能会有所帮助吗？它有助于传达您的意图（您希望人们思考他们为什么要添加此功能）并且您可以免费获得回归测试。
还让新手开始考虑模块化（通常需要使您的代码可测试），如果您以后确实需要重构，这将有很大帮助。
我完全支持代码审查和教学，但我认为面向未来的设计也很重要。也许您可以从设计 API 和使用 API 的初级开发人员的角度来考虑它。这样一来，您就可以完成他们会搞砸的艰苦工作（识别重复的代码并消除它），而他们会做所有不能有效利用您的时间的繁重工作。
当然，这必须与培养初级开发人员技能的需求相平衡。等式的两边都不能忽略。
这可能有助于规划他们将做什么工作，然后验证它以帮助建立他们的判断力，这正是你所要求的，在我看来。配对是一种选择，但如果你不能抽出那么多时间，那么就有一种“检查点”来查看他们的表现并防止他们走上错误的道路。