In this chapter of Code Craft by Pete Goodlife, we are presented with key concepts necessary to define the essence of Software Architecture. Initially, Goodlife makes an analogy with more traditional, building architecture, and how it is needed to design the buildings that will eventually become what you see around you in the street. In software, architecture is seen as the single greatest influence on the design and future growth of a software system. There are multiple architectural views, to document the process, conceptual, implementation, process, and deployment. Again, compared to traditional architecture design, these views are akin to plumbing and electricity diagrams, they are views designed to focus on different perspectives of the software.
So, what is all this for? Basically with software architecture, you can validate it (see if what you're working on is what's needed), communicate (use the design to let your team know what you want) and discriminate (make decisions on what's needed and what can be discarded). Software architecture is also made up of components and connections, in simple terms they are the "things", the objects, the libraries, the databases, and how they'll be linked together.
Architecture is simple, it is meant to be clean, and it is meant to see how components interact as a whole, not how they work individually. It can be arranged in a variety of architecture styles, such as component, pipe and filter, layered, etc. In the end what matters is to keep in mind the importance of a good design, in order to be a good programmer. If you just jump into the code without knowing how things will work further down the line, you will be met with uncertainty and confusion, not only for yourself but especially for your whole team. If you're working alone, then the other person you'll end up screwing over is future you.
Yeah, I can definitely say from prior game development experience, if you don't have a plan, you're stranded. I see it more as a map, you can check it, know where to go, not necessarily what to do, but you know which rooms lead to where, and once you know how everything's connected, you can take action.
So, what is all this for? Basically with software architecture, you can validate it (see if what you're working on is what's needed), communicate (use the design to let your team know what you want) and discriminate (make decisions on what's needed and what can be discarded). Software architecture is also made up of components and connections, in simple terms they are the "things", the objects, the libraries, the databases, and how they'll be linked together.
Architecture is simple, it is meant to be clean, and it is meant to see how components interact as a whole, not how they work individually. It can be arranged in a variety of architecture styles, such as component, pipe and filter, layered, etc. In the end what matters is to keep in mind the importance of a good design, in order to be a good programmer. If you just jump into the code without knowing how things will work further down the line, you will be met with uncertainty and confusion, not only for yourself but especially for your whole team. If you're working alone, then the other person you'll end up screwing over is future you.
Yeah, I can definitely say from prior game development experience, if you don't have a plan, you're stranded. I see it more as a map, you can check it, know where to go, not necessarily what to do, but you know which rooms lead to where, and once you know how everything's connected, you can take action.
Comments
Post a Comment