Comment about "Software Architecture: Laying the Foundations of Software Design"

This week I'm going to talk about the foundations of software design which is essential for creating a software architecture. These are my comments after reading the Chapter 14 of the book "Code Craft: The Practice of Writing Excellent Code" by Pete Goodliffe’s.



First of all, after understanding the requirements of scope, time and cost of a project, the software team has to decide the design of the system. The things that have to be decided are, the key software modules and which component talks with one and the other. This will help to identify at a high level how the software has to work and how it can be divided so that every team player can work at the same time. As a programmer, one of the best things that we can receive is a clear explanation of the software design. This allows us to just work in the implementation of it. Sometimes the software can be just pushed to a virtual machine in the cloud but there are some others like an embedded system, on which there are different rules on the design.

Great architecture design can impact in the future whenever a change has to be done. Maybe your boss asked you to add a new module or an error occurred. Whatever it happened, the software architecture will be difference between taking 2 mins to make the change or days, even weeks or months! Also, it is important for everyone in the team to know about the architecture or everyone will start to code the way each one of them "thinks" the program should look like and this at the end can create modules that cannot connect between them and wasted effort.

So in just a few words, software architecture validates that the requirements can be accomplished, it communicates to all parties about the design, and it discriminates the need of a certain component like a database or an API, and its costs. Depending on the system, the software architecture can be no architecture at all (which can doom development before it starts), Layered Architecture (like the OSI Model), Pipe and Filter Architecture (each step/pipe process some information and gives a result which will be processed by another pipe), Client/Server Architecture (a website), Component-Based Architecture (APIs connections), Frameworks (Node, React, Django, etc.).

After reading the chapter, the best recommendation I can give as a software developer is to write a well documented README.md. This document has to have key concepts as what the system is, what is working and what is not (using tools like Travis CI), how it can be deployed and some other key features. You have to think on the next person that will read about the project.

References

G. Pete (2006). Code Craft: The Practice of Writing Excellent Code. No Starch Press, 2006.

Comentarios

Publicar un comentario

Entradas populares de este blog

Metaprogramming (Comment)

The first thing that comes to my mind when reading/hearing the term metaprogramming the word metadata comes to my mind but they don't have the same meaning. Metadata is the data of the data of something, and Metaprogram is not the data of a program, it refers to a program that creates other programs. Imagine a program that creates an app for iOS devices and Android, wait! There is already some options in the internet to do such thing, for example Ionic, but metaprogramming is not that new. There are many other metaprograms like gcc, python interpreter, parse generators like bison, and more. A great example that I read was the one of Erika. She was more outstanding than his programming professor and made a program that generated another one. Although she didn't create something revolutionary, it was so good to explain metaprogramming. As mentioned in the lecture, a quine is a program that prints its own source code, but why would this be helpful for something? Imagine that ...
Leer más

Microservices (Comment)

Using microservices is one of my favorite things on projects, they make it easier to reuse already done software written on any programming language. The only drawback is the complexity of organizing those microservices. Another problem is to define how small your microservice should be. This microservice can scale horizontally by running many instances behind a load-balancer. As Martin Fowler and James Lewis said, a microservice has the next characteristics: Componentization via Services Organized around Business Capabilities Products not Projects Smart endpoints and dumb pipes Decentralized Governance Decentralized Data Management Infrastructure Automation Design for failure Evolutionary Design For me, the best implementation of microservices are APIs and packages that can be called in order to create or transform a piece of information with certain operations/instructions. Now a days we don't create a server entirely, we use a package to create an endpoint that ca...
Leer más

Is Design Dead? - Comment

In every coding project there are people that will write it and some others will design it but without any question, both of them should know that coding isn't trivial, design errors or coding errors will occur and it is essential to have a risk plan in case that something happens. This allows to have a stablished way of dealing with the problems that will appear as the project grows. Depending on the scope of the coding project, if it will be a program that has some components (an API, a database, users, security, etc.), it is important to design it before beginning to code it. This allows to design it to be scalable, secure, maintainable, and error-prove. If the project is just to write a a program that will resemble a calculator, it is just fine to code it as you go. This means that depending on the complexity of the project, it is necessary to define certain documents to establish the foundations that will allow to create bigger projects (more modules, more people assigned t...
Leer más