我正在寻找一种有效的方法来向现有团队成员介绍OOP概念，但这并不是侮辱。我的队友对OO语言并不陌生。我们从事C ++ / C＃已有很长时间了，因此对技术本身很熟悉。
但是，我环顾四周，并且没有付出很大的努力（主要是以代码审查的形式），似乎我们正在生成的是恰巧在类内部的C代码。仅举几例，几乎没有使用单一责任原则，抽象或试图最小化耦合的尝试。我见过没有构造函数的类，但每次实例化时将memset设置为0。
但是每次我提起OOP时，每个人都会点头并让他们看起来好像完全知道我在说什么。知道这些概念是件好事，但在交付实际工作时，我们（比其他人更多）似乎很难应用它们。
代码审查非常有帮助，但是代码审查的问题在于它们仅在事实发生之后发生，因此对于某些人来说，我们似乎最终重写了刚刚编写的代码（它大部分是重构的，但仍然要花费很多时间）。另外，代码审查仅提供反馈给单个工程师，而不是整个团队。
我正在做一个演示文稿（或一系列）的想法，然后尝试再次提出OOP以及一些本来可以编写得更好并且可以重构的现有代码示例。我可以使用一些没有人拥有的非常老的项目，因此至少那部分不应该是一个敏感的问题。但是，这行得通吗？正如我所说的，大多数人已经做过C ++很久了，所以我的猜测是：a）他们会坐在那里思考为什么我要告诉他们他们已经知道的东西； b）他们实际上可能会将它当作侮辱，因为我告诉他们他们不知道如何做他们已经从事多年甚至数十年的工作。
是否有另一种方法可以比代码审查更广泛地吸引读者，但同时又不会像惩罚性演讲那样？
我不是一个刚大学毕业的孩子，他对理想的代码设计有着乌托邦式的理想，我不希望任何人都能做到。我之所以写这本书，是因为我只是对一个实际上在纸上有不错的高级设计的人进行了评论。但是，如果您描绘类：A-> B-> C-> D，则在代码B，C和D中都实现几乎相同的公共接口，并且B / C具有一个内联函数，因此最高级的A类绝对在做所有工作（包括内存管理，字符串解析，设置协商...）主要以4种mongo方法进行，并且出于所有目的和目的，几乎都直接调用了D。
更新：我是一名技术负责人（担任该职位六个月），并得到了小组经理的全力支持。我们正在开发非常成熟的产品，并且维护成本绝对是众所周知的。