Since software development is an engineering discipline we often use language to describe our code that first had a meaning in more physical forms of engineering.
We talk about software architecture, frameworks, platforms and things being SOLID.
But why do we use these analogies and what exactly do we mean by code having an architecture and a structure.
Pointing The Way Forward
The first goal of architecture should be to simplify the problem at hand. Often the problem that needs to be solved is too big to be able to comprehend the way forward.
Good architecture turns this one big problem into a series of smaller problems, meaning when we get to writing code it is very clear how each method, class and package moves us forward.
We will very often find that many of these smaller problems have been faced before, we don't need to re-invent the wheel, we apply the same solution as all the previous occasions.
Good architecture can be seen when each sprint planning session is a smooth affair with little debate about what is trying to be achieved or what on earth we need to write.
Good architecture can be seen when all these individual elements start building on top of each other moving us closer to an overall solution.
Intentionally Emergent
Agile teaches us that architecture should be emergent with limited up front documentation and planning.
The reason we say this is so that we speed up the time it takes to produce working software, this doesn't mean we simply expect good architecture to happen, we provide well engineered solutions to the small problems and build in contingency for the inevitable change in requirements.
By following the principles of loose coupling, strong cohesion and inversion of control we produce a modular, layered design that provides the framework for this emergence to take place.
We not only solve the problem at hand we lay the groundwork for solutions to future problems by allowing our architecture to develop without redesign. We aren't clairvoyant the only aspect of the future we can predict is that change is coming so we better be ready.
Ripping it down and starting again isn't engineering, good architecture allows us to not panic when someone asks us to build an extension to the house.
This is in contrast to a unplanned architecture that degrades at every turn and causes the solutions to new problems to become ever harder to achieve, emergent doesn't mean lets just see where we end up, it should mean allowing for renovation.
Proof Not Faith
Good architecture doesn't require you to have faith that it works, it is built to be testable and this testing provides you proof that its working.
The same flexibility that allows an emergent architecture to develop also allows each step along that journey to be undeniably heading in the right direction.
Testability in and of itself is not a property of an architecture its what results from applying SOLID principles, good code is testable code and testable code is good code.
If you ever end up in a position where your architecture is not testable the chances are their are several things its not, such as adaptable or maintainable.
Software engineering shouldn't be a game of Jenga, we shouldn't feel the need to close our eyes when we need to make a change.
Agile is also not an excuse for being sloppy, it isn't about just getting something working its about taking a realistic approach to actually solve the problem not just planning to solve it.
When analysing the problem identify the parts of the solution that are obvious, we need a database or we'll need some kind of API. Put these to one side, we know how to do those, and concentrate on how we can overcome the non-trivial parts of the problem, how can we break this down until we get to a problem we do know how to solve.
Good architecture is a series of really good solutions to a series of really small problems.
No comments:
Post a Comment