Over the last few years, we have been slowly making the switch over to progressively better written code, a few baby steps at a time. We are finally starting to make the switch over to something that at least resembles SOLID, but we’re not quite there yet. Since making the switch, one of the biggest complaints from developers is that they can’t stand peer reviewing and traversing dozens and dozens of files where previously every task only required the developer touching 5-10 files.
Prior to starting to make the switch, our architecture was organized pretty much like the following (granted, with one or two orders of magnitude more files):
Solution - Business -- AccountLogic -- DocumentLogic -- UsersLogic - Entities (Database entities) - Models (Domain Models) - Repositories -- AccountRepo -- DocumentRepo -- UserRepo - ViewModels -- AccountViewModel -- DocumentViewModel -- UserViewModel - UI
File wise, everything was incredibly linear and compact. There was obviously a lot of code-duplication, tight-coupling, and headaches, however, everyone could traverse it and figure it out. Complete novices, people who had never so much as opened Visual Studio, could figure it out in just a few weeks. The lack of overall file complexity makes it relatively straightforward for novice developers and new hires to start contributing without too much ramp up time as well. But this is pretty much where any benefits of the code style go out the window.
I wholeheartedly endorse every attempt we make to better our codebase, but it is very common to get some push-back from the rest of the team on massive paradigm shifts like this. A couple of the biggest sticking points currently are:
- Unit Tests
- Class Count
- Peer Review Complexity
Unit tests have been an incredibly hard sell to the team as they all believe they’re a waste of time and that they’re able to handle-test their code much quicker as a whole than each piece individually. Using unit tests as an endorsement for SOLID has mostly been futile and has mostly become a joke at this point.
Class count is probably the single biggest hurdle to overcome. Tasks that used to take 5-10 files can now take 70-100! While each of these files serve a distinct purpose, the sheer volume of files can be overwhelming. The response from the team has mostly been groans and head scratching. Previously a task may have required one or two repositories, a model or two, a logic layer, and a controller method.
Now, to build a simple file saving application you have a class to check if the file already exists, a class to write the metadata, a class to abstract away
DateTime.Now so you can inject times for unit testing, interfaces for every file containing logic, files to contain unit tests for each class out there, and one or more files to add everything to your DI container.
For small to medium size applications, SOLID is a super easy sell. Everyone sees the benefit and ease of maintainability. However, they’re just not seeing a good value proposition for SOLID on very large scale applications. So I’m trying to find ways to improve organization and management to get us past the growing pains.