Disclaimer: I'm a newcomer (this is my third day of work), and most of my teammates are more experienced than me.
When I look at our code, I see some code smells and bad engineering practices, like the following:
- Somewhat inconsistent naming guidelines
- Properties not marked as readonly when possible
- Large classes – I noticed a utility class that consisted of hundreds of extension methods (for many types). It was more than 2500 lines long!
- Large methods – I'm trying to refactor a method which is 150 lines long.
The latter two seem to be a real problem. I want to convince my teammates to use smaller classes and methods. But should I do that? If yes, then how?
My team got a mentor from the main team (we're a satellite team). Should I go to him first?
UPDATE: Since some responses asked about the project, please know that it's a working project. And IMHO, huge classes/methods of that size are always bad.
Anyways, I never want to piss my team off. That's why I asked – Should I do that, and if yes, then how I do that gently?
UPDATE: I decided to do something based on accepted answer: because I'm newcomer, so I see everything in "fresh eyes" I will take note on all code smells that I found (position, why it bad, how can we do it better,…), but at the moment, I just try hard to gather respects from my team: write "better code", know people, know why did we do that… When the time is right, I will try to ask my team about some new code-policies (naming guidelines, smaller classes, smaller methods,…), and if possible, refactor some old code. It should work, IMHO.
Thank you.
Best Answer
You have the benefit of viewing the code with fresh eyes. Take notes to document what you discover of bad practices. Then, as you're getting settled with the team, pull out your notes at an opportune moment, like when it's time for refactoring.