我在刚开始工作时看到一些代码，其中添加了几个我感到……困惑。在花费了额外长的时间去理解代码实际做了什么之后，我意识到有些初级工程师在使用他们并不真正理解的设计模式，而这对于这个例程没有任何实际价值。删除了所有这些代码，并重新用完全不同的抽象方式重构之后，一切突然变得更容易阅读和扩展了。设计是一项很难掌握的技能，初级开发人员还没有真正掌握这项技能。但作为高级工程师，我们需要教他们，对吧？不过我无法教我修改的代码的作者，因为我觉得那是之前不在公司工作的实习生写的。但你只能做到你所能做的。
源讨论4-chan的Go语言程序员原帖 172 条评论 · 导入时统计这实际上是一种非常糟糕的做法，是一种“过于急切的初级工程师”写软件的方式。你认为它显得过度和令人困惑是完全正确的。这在一开始看起来可能技术复杂，甚至“优雅”（当你第一次写出“有趣”的代码时），但当它被用于需要围绕它和它一起成长的真实软件时，就会变成技术上的噩梦。你实际上更应该担心这种做法带来的可理解性和可调试性。 我花了两年多的时间来修复一些Go语言的软件，（其中一些问题）错误地使用了通道。通道的问题在于你很少真正需要它们，但可以很容易地用它们做很多事情。 我认为判断通道是否正确使用的一个好标准是，如果你对“这是否可以通过直接函数调用实现”这个问题回答“不”…
完整原文把你的经验，加入这段讨论。
还有一个事实是，当你知道你要去哪的时候，写东西会容易得多。当你刚开始的时候，你往往会先做出很多泛泛的条目，以便之后再改进。
完整原文作为一位领导者，我的‘坚定但宽松的观点’是，根本无法在理论环境中有意义地培养这种技能。你最多只能让他们意识到‘过度’和‘适合任务的工具’这样的概念，并不断提醒他们。但没有任何东西能与在现实世界中不得不处理过度设计的混乱代码并因此感到沮丧的经历相提并论。尤其是当你面对的是自己六个月前写的代码时。初级工程师总是会这么做。总是要由资深工程师……让它发生，让初级工程师学到东西，但同时将影响范围控制在可管理的范围内，并在合适的时机，引导初级工程师认识到他们做法的错误。
完整原文> 我意识到有些初级工程师在使用他们并不真正理解的设计模式，而这种模式对这个例程没有任何实际价值。 3.50英镑打赌，这是在Entity Framework的dbContext上实现的通用存储库模式，对吧？ -------- 说到设计模式，我持这样的观点：_设计模式是为弥补编程语言缺失功能而使用的惯用法_，这解释了为什么Java有无数的设计模式，也解释了为什么我们这些厌倦了的人在现代语言中找到了快乐，这些语言采用了更多多范式和函数式编程（Java之后的酷孩子俱乐部：Kotlin、Rust、Swift、TypeScript，（C#能加入吗？））——所以我希望最终会出现一批刚毕业的计算机科学学生进入行业，他们只知道外观/装饰器/适配器是语言设计者为了捉弄用户而做的东西，因为任何合理的编译器都应该能处理接口映射。…
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。