YAGNI 和初级开发人员
当为新系统编写代码时，我不想在设计中引入不必要的复杂性，而我可能永远不需要这种复杂性。 因此，我在这里关注 YAGNI，并且随着我认为需要更大的灵活性或随着职责变得更加明确而进行重构。 这让我可以移动得更快。
但初级开发人员存在一个问题，因为他们不知道何时重构或在何处构建设计。 他们只是将更多的代码塞进现有的设计中。
那么，解决这个问题的最佳方法是什么？ 我是否应该更频繁地构建一个更面向未来的设计，以便在添加时他们有一个很好的例子可以遵循，即使我们可能永远不需要添加任何东西？ 或者我应该继续进行更多的代码审查、教育等？ 或两者？
你们中有人遇到过此类问题吗？ 你是怎么解决的？
When writing code for a new system I don't want to introduce unnecessary complexity in the design that I might never have any need for. So I'm following YAGNI here, and rather refactoring as I see the need for more flexibility or as responsibilities becomes more clear. This allows me to move faster.
But there is a problem here with junior devs, in that they will not recognize when to refactor or where build out the design. They just stuff more code into the existing design.
So, what are the best ways to tackle this? Should I more often build a more future-proof design so when adding to it they have a good example to follow, even if we might never have to add anything? Or should I just go ahead with more code reviews, education, etc? Or both?
Have any of you had any experience with this type of problem? How did you solve it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我会推荐代码审查或结对编程。 它让您有机会教育其他开发人员并提高整体质量。
I would recommend code reviews or pair programming. It gives you the chance to educate your fellow developers and increase the overall quality.
也许您首先明确认识到您工作的一部分是帮助培养初级开发人员。 如果你不是老板，管理层应该签字同意。 管理层需要认识到，你的选择是现在开发它们，还是稍后清理它们，并且你需要管理层在这段时间的支持。
代码审查和结对编程都是好主意。 它们特别好，因为它们不“只适合初级人员”——我和我的一位亲密同事都这样做； 我们加在一起已经快 100 岁了，拥有超过 70 年的编程经验 :-)
但这里有一个更大的问题：使你最有效的编程方法（YAGNI + 重构）对你的初级者来说并不有效 我的经验是，人们需要多年的时间才能了解 YAGNI 的好处，因此，如果您期望他们只是了解您的做事方式，那么您就会感到失望。
我鼓励您确定一些您认为对初级合作伙伴有用的方法。 特定的方法可能并不重要（异端邪说！）； 我在复合/结构化设计、基于对象的设计、代数规范（！）和极限编程方面取得了成功。 但是
一定要选择有名字的东西和一些专门的文献，你的后辈可以为学习而感到自豪，这是他们可以带到未来项目中的技能。
为了证明它好吃，你可能需要自己吃狗粮。 选择一些你能忍受并能提高工作效率的东西。
仔细观察你的后辈，教他们一个决策程序，他们可以用它来确定何时应该向你寻求指导。
祝你好运！
Perhaps you begin by recognizing explicitly that part of your job is to help develop the junior devs. If you're not the boss, management should sign off on this. Management needs to recognize that your choices are to develop them now or clean up after them later, and you need management's backing for the time this will take.
Code reviews and pair programming are fine ideas. They are especially good because they are not "just for junior people"–I do both with one of my close colleagues; together we are nearly 100 years old and have more than 70 years of programming experience :-)
But there's a larger problem here: the programming methodology that enables you to be most effective (YAGNI + refactor) is not effective for your junior partners. My experience is that it takes people years to learn the benefits of YAGNI, so if you expect them just to learn your way of doing things, you are setting yourself up for disappointment.
I would encourage you to identify some methodology that you think is going to be useful with your junior partners. The particular methodology probably doesn't matter (heresy!); I've had success with composite/structured design, object-based design, algebraic specification (!), and extreme programming. But
Do pick something that has a name and some literature devoted to it, that your juniors can take pride in learning, and that is a skill they can carry to future projects.
In order to show that it is tasty, you may need to eat the dog food yourself. Pick something you can live with and be productive in.
Observe your juniors carefully and teach them a decision procedure they can use to identify when they should ask you for guidance.
Good luck!
他们是初级而你是高级是有原因的。
意识到何时需要改变设计的能力就是其中之一。
我会继续像你一样，但鼓励他们在事情变得困难时来找你。 然后，如果需要，您可以与他们一起更改设计，这对您来说比重构更容易，并将帮助您将知识传递给初级开发人员。
There is a reason they are junior and you are senior.
The ability to realise when a change in design is needed is one of them.
I would carry on as you are but encourage them to come to you when things are getting difficult. You can then work with them to alter the design if needed, this will be easier for you than refactoring it and will help you pass on knowledge to your junior developers.
展示设计构建程度的一个很好的方法是指定设计构建后将做什么，然后编写测试来覆盖新功能。 当测试通过时，开发就完成了。
在此过程中您可能会意识到您忘记测试某些内容。 这很好，并且是有用的反馈，可以帮助您下次更好地指定。 编写缺少的测试，并编写足够的代码来使它们通过。
然后重构。 知道重构时要寻找什么需要一些练习。 首先
重复这个动作几十次，事情就会变得更容易。
A very good way to show how far to build out a design is to be specify about what the design will do when built out, then write tests to cover the new functionality. When the tests pass, development is done.
You might realize along the way that you forgot to test for something. That's fine, and is useful feedback to help you specify better next time. Write the missing test(s), and only enough code to make them pass.
Then refactor. Knowing what to look for when refactoring takes a bit of practice. Start with
Repeat this a few dozen times, and it'll get easier.
看待 YAGNI 的另一种方式是，对代码的任何更改都需要证明其合理性。
要求任何提交都需要关联的单元测试（或 BDD 用户故事，选择你的毒药）可能会有所帮助吗？ 它有助于传达您的意图（您希望人们思考为什么要添加此功能）并且您可以免费获得回归测试。
还可以让菜鸟开始考虑模块化（通常需要使您的代码可测试），并且如果您以后确实需要重构，这将有很大帮助。
Another way of looking at YAGNI is that any changes to code need to be justified.
Might it be helpful to require any commit needs an associated unit test (or BDD user story, choose your poison)? It helps to communicate your intent (you want people to think about why they are adding this feature) and you get regression tests for free.
Also gets the noobs to start thinking about modularity (usually needed to make your code testable) and will help a lot if you do need to refactor later on.
我完全支持代码审查和教学，但我认为面向未来的设计也很重要。 也许您可以从设计 API 和使用 API 的初级开发人员的角度来考虑。 这样，您就可以完成他们会搞砸的艰苦工作（识别重复的代码并消除它），而他们则完成所有不能有效利用您时间的繁重工作。
当然，这必须与培养初级开发人员技能的需要相平衡。 等式的两边都不可忽视。
I'm all for code reviews and teaching, but I think futureproof design is also important. Maybe you could think of it in terms of you designing an API and the junior developers using the API. In this way you are the one who does the hard work that they would screw up (identifying duplicated code and eliminating it) while they do all the grunt work that isn't a productive use of your time.
Of course this has to be balanced with a need to develop your junior developers skills. Neither side of the equation can be neglected.
这可能有助于规划出他们将要做的工作，然后对其进行验证，以帮助建立他们的判断力，在我看来，这正是您所要求的。 结对是一种选择，但如果你抽不出那么多时间，那么可以设置一种“检查点”来查看他们的表现并防止他们走上错误的道路。
It may help to map out what work they will do and then verify it to help build their sense of judgement which is really what you are asking, to my mind. Pairing is one option but if you can't spare that much time then having a sort of "check point" to see how they are doing and preventing them from going down the wrong path.