Organizing Software By Coupling

I have just watched Reginald Braithwaite - The Not-So-Big Software Design and it reminded me a lot of some other presentations I watched by Robert Martin on architecture. They both decry the kind of default folder structure you get from your framework. These frameworks usually divide things into groups like controllers, models, and views. The point made by both Braithwaite and Martin (aka Raganwald and Uncle Bob) is that looking at that structure tells you nothing about your application and what it does.

Braithwaite also makes an interesting point about including tests to be closer to the code. Tests are often located in a very different place than the code. He also points out that the architecture should be built regarding the developers as users. It is an interesting way to look at things.

Braithwaite is very good at asking people to think, and his comments have made me think. How we organize our projects should be based on coupling. If I modify a a code object the objects I will most likely also need to modify should be the closest objects in the way the system is organized. Here is a concrete example. In the Angular application I worked on recently we had controllers separated from templates. You had to go a few directories and then down a few to get to the template. In practice, however, whenever you would want to change one you would usually change the other because they were coupled. In the project I work on now there is a tight coupling between view models and templates, but they are very far apart in the code. If we organized our code to better reflect coupling it would help us develop. It would tell us what files we might also want to change. I changed the controller and since the tests and template are right next to it, maybe I should change it to. Another interesting idea in this is the fact that you can datamine your source control repository to find out what files are changed when you change any given file.

Now I don't think that we should use datamining of source control to dictate how we organize our code, but they information can help give you hints about how we use the code. In web development we have tools allowing us to see exactly how users use our product. Every single activity you do in Candy Crush is logged is a Vertica database for analysis. Well, for development we log every single code change we make, but we do no analysis on it.

Anyway, before I digress too much, I think code organization requires thought. And in general the lines you draw between sections of code should be based on the notion of coupling. I believe this fits well with the idea that the organization should inform you about the application. For example, putting everything to do with logging on in the "Logging On" folder helps tell you about the application and it also groups code that it likely to change when you modify the behavior of logging on. This idea necessarily also leads to Braithwaite's idea about making the tests closer to the code they test. If you contain the tests with the code they are testing the value and likelihood they are correctly maintained goes up. You simply need a mechanism to prevent the compilation or inclusion of sections of code.