How do you build a city
One man can’t run a city. Most of the time, though, the city works. Because every city has groups of people who manage different parts, water systems, electricity systems, transportation, law enforcement, etc. Someone is in charge of the big picture, someone else is in charge of the details.
Cities also work because they evolve appropriate levels of abstraction and modules that allow individuals and the parts they manage to function effectively even without understanding the big picture.
Although software teams are often organized in this way, the work they work on often does not have the same focus on faceted segmentation and levels of abstraction. Clean code helps us achieve this at a lower level of abstraction. This chapter deals with keeping things clean at the higher level of abstraction, the system level.
Separate system construction from use
Construction and use are very different processes.
Software systems should separate the initiation process from the runtime logic that follows the initiation process, and there will be entangled dependencies during the construction of application objects during initiation.
Every application should be mindful of the initiation process. That’s the first thing we have to think about. Separating the focus is one of the oldest and most important design techniques in software craftsmanship.
Break down the main
One way to separate construction from use is to move the entire construction process into a module called Main, or main, and design the rest of the system assuming that all objects are correctly constructed and set up. The main function creates the objects the system needs and passes them to the application, which just uses them.
capacity
Cities grew out of towns. At first the roads were narrow and almost untrodden, then gradually widened. Small buildings and empty lots are gradually being replaced by larger ones, and some places are finally standing their skyscrapers.
The growth has not been without pain. How many times have you waded through a road improvement project and asked yourself, why didn’t they just build a wide enough road in the first place? But who can say that building an eight-lane road in a small town is not wasteful?
So getting the system right from the beginning is just a nice expectation. Instead, we should only implement today’s features, implement predictable features, and then refactor and expand. This is the essence of iterative and incremental agile. Test-driven development, refactoring, and the clean code they produce ensure this process at the code level.
But at the system level, you should also plan ahead as much as possible and do a good job of the system architecture. Software systems are analogous to physical systems. Their institutions can grow incrementally, as long as we continue to slice the focus appropriately.
The best system architecture consists of modular areas of concern, each implemented with code objects. Different domains are integrated with the least invasive aspect or aspect like tools. This architecture is test-driven, just like code.
summary
The system should be uncluttered. Intrusive architecture annihilates domain logic and impels agility. When domain logic suffers, quality suffers because defects are easier to hide and user stories harder to implement. When agility is compromised, productivity is also reduced and the benefits of TDD are lost.