Don't just add a comment like “see commits” or “see code”. Review the commit early, commit often section. Your commits should be granular enough to easily describe in a sentence or two. If not, you're waiting too long to commit.
Summary
Working with revision control is a fundamental part of working with source code. In fact, it's become social media with sites like GitHub, Bitbucket, and Visual Studio Team Services. It's important to have a good understanding of the version control system that your team uses, both conceptually and syntactically. Understand the concepts, understand how to use it correctly, and understand how to get the most out of it.
Version control is used for specific reasons, and those reasons can facilitate other tasks that software development teams need to perform, such as working in parallel, merging concurrent work, code reviews, etc. Make sure that you're not making your revision control tool work against you by making an effort to do those other tasks in the most acceptable way recognized.
Next up, let’s expand these patterns and think about patterns and practices from an architectural perspective.
79
© Peter Ritchie 2016
P. Ritchie, Practical Microsoft Visual Studio 2015, DOI 10.1007/978-1-4842-2313-0_4
Design and Architecture:
Patterns and Practices
Two things are clear about software. One is that the term architecture is often misunderstood, and the second is that every software system has an architecture. Many authors have written tomes of books on architecture, including what it means, how to do it, who should do it, when you should do it. This chapter really just scratches the surface of architecture and distills it down to what it is, what it tries to address, and some of its attributes. The chapter presents some patterns and practices when it comes to architecture.
Architecture
Every system has an architecture. A system has elements, there are relationships among the elements (structure), and there are principles that constrain the system's design and evolution. Some architectures can be simple because they reuse common architectures, designs, or language and thus require less description. Other systems are more complex as they may use a less common language to describe a new architecture or design. Whether a system is simple or complex, it has an architecture.
Historically, software architecture has been somewhat neglected. The formal description of the architecture is sometimes ignored, despite architecture being a property of every system. In situations like this, the architecture is assumed, leading the inability to follow any principles or constraints. This lack of communication of the high-level design often leads to a poorly designed system and the decisions about system constraints are not taken into consideration for lower-level design decisions.
Let’s look at an example of where the architecture may be ignored. When someone creates a Windows application in Visual Studio they choose a template. Sometimes they might add class libraries to contain some of the code, but for all intents and purposes it is just a Windows application project (be it WinForms, WPF, Console, etc.). There is still an architecture to that application that should constrain all future design decisions.
In a Windows application, typically, all the logic resides in the application; there are no external services that perform logic, which limits the scalability of the system to vertically scalable. If the application is GUI- based, there is a limited ability to interact with the system and the ability of the system to interact with the external system. The system must run on a Windows computer and probably requires specific versions of Windows. There are sorts of other implicit decisions that have been pre-made when choosing a Visual Studio project template, decisions that define the elements of the system, their relationships, and constraints of future design decisions.
Not all templates are limited to the implied architecture. You can make additional architectural decisions and still use an application template in Visual Studio. For example, you may choose to create a WPF application but have it communicate with a REST service to perform certain logic or to access certain data. That is a decision that results in a different architecture. You may choose a formal description of that architecture. The description often comes in the form of architecture diagrams. We will get into more detail about architecture diagrams in Chapter 5 .
80
In any system, it is important to describe the architecture. In systems that use a common architecture (or someone else's decisions) it is less important. However, in systems where there are significant decisions made about the focus of the system outwardly, it is vital to describe that architecture. The architecture is how the system constrains to those decisions; if it does not constrain to those decisions then the result is a different architecture. That different architecture may still be valid, it is just not the one that was decided upon. How well a design abides by those constraints defines how well the system meets the needs it was supposed to solve.
To a certain extent, architecture is about the high-level what s and how the system outwardly communicates.
Design
There are still design decisions that need to be made about any system, despite there being an architecture, either implied or explicit. Those decisions are equally important in a system and are ultimately constrained by the architecture of the system, whether it is implied or explicit.
Design embodies the internals, or is inwardly focused. It focuses on the algorithms, the internal data structures, etc. The design must take into account the architectural decisions and constraints of the system in order to correctly implement the system.
The design is concerned how about the how s and inwardly-focused concepts: the algorithms, data structures, etc.