Software Architecture

 

I hope that during this course we can learn how to make a good software architecture, because I have read about it in several courses and as the chapter says there is no code without architecture I have done architectures although probably not being as conscious of it as I should have been and I have never known if my architecture is good or bad and how I can improve it. I understand the concepts seen in class, but I have never been told you could have reduced this class into this, or this class does to much. Also, I have never had to do maintenance on a software, so I have never experienced the results of a bad architecture, the closest was when I had to refactor entire classes made by my teammates in videogames. Learning how to better design a software architecture is something I would like to see during the course.

Overall, it was a nice chapter as it allowed me to remember what I saw in other courses in a really short time and I was able to understand some things like the Framework that I had not really understood in my software engineering courses. Although I have to admit that some guidelines are too broad such as the level of detail in the architecture where it says that it should not be too little, but neither it should too much. I understand what it wants to say, but it is not really too helpful. Probably the best advice I read was that a good design was simple and that it means that it can be described in a paragraph and shown in only a diagram, and that the architecture should not try to define how the components work, only what they have to do and how they interact with each other.

Comentarios

Publicar un comentario

Entradas populares de este blog

Is design dead?

  “Any unneeded complexity makes a system harder to change in all directions except the one you anticipate with the complex flexibility you put in”. I believe that quote of the reading is the one that does a better job explaining why you need simplicity in the code and the strong point of programming for the present, not for the future. As indeed making a part of my code easy to modify would need that I make the assumption of what type of change would be needed in the future. I really like his moderate posture or coward as he calls it because in some of the things he mentions regarding design or having absolutely no architecture at all, do sound too extreme especially when in situations where is clear from day one that you do need a database. I particularly like his posture in regards to architecture of doing it, but take it as a sketch not something written in stone as you do not know what possible requirement changes come in a project or what specific issues come during the programmi
Leer más

SOLID

  The SOLID principles are really good advice and were explained in a really simple way during this article. Some of them I had already heard as in the past I have read one of Uncle Bob’s books during the Videogame project course. The Single Responsibility Principle is the only one of the principles that until now I always have in mind while writing classes, although being honest just as the article says it is not always that straightforward what would be considered doing only one thing, so sometimes I may not apply it perfectly. The Open/Closed Principle and the Liskov Substitution Principle those are principles that are new to me and certainly go against some of the things I knew.   Because I had learned to use inheritance in those situations, although reading the article I agree that abusing inheritance may not always be a good idea as it may leave the code in an unpleasant state or generate side effects. The Interface Segregation Principle I never had thought about doing that,
Leer más

Software Craftsmanship

  I have been trying to avoid of thinking of programming as a craftmanship since some years ago because we were kind of thought that it was incorrect. During our software development courses we were taught that treating it as a craftmanship was what caused it. But the way uncle Bob explained it as a craftmanship did resonate with me as indeed you do feel proud of your code when it works, and when you manage to program an elegant solution or a clean code it does feel better. Also, everyone has their own way of programming for example when in a group project I see a variable with an unholy name such as ‘iiiiiiiiiii’ I immediately ask Óscar if he did it, and with people you have programmed multiple times you get a feeling of how they code. Maybe it is not a wrong way to see code after all if you can follow the software craftmanship manifesto, which indeed as they say it is not nearly as popular as the agile manifesto. The points in them do sound like really good programming practices to
Leer más