Our team just got a new (senior) team member. He's nice and he knows a lot. Our codebase is not the best codebase out there (we know that), and we do mix certain best practices from here and there (clean code, separation of concerns, solid, DI, modularization, etc.)... but we are far from following "by the book" the most popular practices our there. This fact doesn't slow us down and we pretty happy with our current "architecture" (features are pushed fast, bugs are fixed in an isolated way, performance has scaled nicely, etc.), and we are certainly open for suggestions on how to improve our codebase, of course.
Now, our new team member suggests in PRs things like the following:
- "let's rename that class to X so that it includes the suffix Y because of reason Z". This suggestion makes totally sense... but in our codebase our classes have already a certain naming convention that doesn't go the way our new team member thinks is best.
- "following SOLID principles, class X should be splitted in two because of reason Z". Again, the suggestion makes totally sense, but if we follow it, it would make class X a snowflake in our codebase.
The worst thing is that our codebase is not in a bad shape, so his suggestions, while definitely well-intentioned and correct in most software engineering books, lack context and would make our codebase not necessarily better. There is, of course, the possibility to refactor our entire codebase to follow the best practices out there, but we think that will give us little to no benefit (also, it will take time and it will be hard to argument this kind of decision to management because, as I said above, it's "working fine")
You might want to have a meeting with this new person, his senior peers on the team, and a manager who can oversee and referee things. Talk with him about the stuff he wants to change. If everyone agrees that his ideas are good then you should talk about how to incorporate his ideas into the code.
As a senior person he should understand that simply parachuting in new style to existing code can cause problems. On the other hand you should be willing to find places where these improvements can be added appropriately, perhaps in new code or bulk refactoring that would happen anyway. You want him to feel that you are on his side so this new style should be the team's new style, enforced by everyone where appropriate, and not just his thing. If you review a PR for new code, you'll want to make sure it conforms to the new style, and say it like "following our team's style for new code, class X should be split in two because of reason Z" and not "please split class X in two because that's what NewGuy wants, you know how he can be."
If you just say no to his ideas even if you agree they are good then he might become unhappy and, if rejecting his ideas becomes a pattern, might end up leaving.