I am at my company for half a year now and think that I have gotten a fair idea of their codebase. Initially I didn't dare to form strong opinions, but now I start to feel that the code could benefit from a more structure and more software engineering.
My coworkers do a great job of adding new features, creating a cool product and so on. I just feel that there is no second refactoring and cleaning step, just the initial “making it work”. Given that we in the team are all scientists, and it is a growing company with a relatively new and rapidly evolving product, I can see that a flexible prototyping mindset was appropriate. At the university I have seen many projects start and eventually collapse into themselves as the grad student effectively was the project owner, they spend the time during their thesis on “making it work” and cut more and more corners until graduation. The next student would look at their code and usually throw it away. I don't want to see the company plateau in speed, so I believe that continuous refactoring needs to be part of the process.
I've just read “Clean Code” (R.C. Martin), and had years ago read “Code Complete” and “Rapid Development” (S. McConnell). In a small side project I have recently performed refactoring via abstraction. I added dependency inversion on an external library and then exchanged that for a different one. It didn't took long and the result feels amazing. Also I have tried to refactor everything I can and I could directly sense the increase in speed going forward. When I cook, I try to clean as I go to have countertops usable.
Some of my team members have a different perception on this, just like I did years ago. A decade ago I would laugh about Java, how people specified interface IWidget
, class Widget
and abstract class AbstractWidgetFactory
and class FrobnicatingWidgetFactory
when they could just have a class FrobnicatedWidget
to start with. I thought that having less lines of code would be more readable in every case. But over the time I have changed a bit, I feel that if there are class TextLogger
and class BinaryLogger
there may is an unwritten structure with an interface Logger
wanting to be made explicit. So in our code (which is Python and C++), I see abstractions and patterns which are implicitly present. And I would like to make them explicit.
The co-workers find that adding any encapsulation or standard design patterns to the code explicitly makes it more complicated. Adding another virtual class as the parent supposedly only adds a new class, even though the current classes already have an (implicit) interface. And I want to modularize classes further, they say that increasing the number of classes only increases the complexity. I say that a single class that does too many things is more complicated than the same logic in multiple decoupled classes. But I don't seem to get them to see the things like I do.
I am a scientist programmer myself. I have spent years writing code that works and just left it like that. Only over years of being annoyed with not understanding my own code I came to read about actual software engineering. I still don't dare to fully call myself “software engineer”, but I aspire to get there. And from the books I read I have the impression that I am on the right track. But of course I could be wrong.
I would really just force everyone to read “Clean Code” and to start think exactly like I do and do as I think would be correct. But of course it doesn't work like that. And it doesn't make sense either; my judgement isn't perfect, my experience limited and so on. Rather, I would like to have a professional discussion but would need to have more convincing arguments for the people who feel that refactoring would slow us down and would make the code more complex.
So my questions are:
- Am I generally on the right track with my perception of conception and mid-term maintenance costs?
- How can I get buy-in for and cleaner coding from coworkers who have a different perception of software development and mostly focus on getting things working?