Software Architecture

 This week, we read a chapter of Pete Goodliffe's Code Craft: The Practice of Writing Excellent Code. The chapter, just like this course, focused only on the importance and different types of architecture. After this reading and after having completed the first Ruby activity, I think I finally have a good idea of what to expect throughout the semester. 

Throughout our degree, we have always been told how important it is to design before we start coding, so that we have a "guide" and to get an idea of the workload or work distribution from the beginning. However, so far, it hasn't been taught to us in this way; we would think about the code, abstract it into a higher level, and define our design based on what we thought would be easier to do. 

However, I now see that the correct way to do it is the other way around. Think of what you want your software to accomplish, figure out its scale and any other relevant details, pick a style that fits your project's needs, and then and only then, start thinking about what you can do code-wise to achieve those goals. 

Having said that, I also understand that it's easier said than done and I understand why it hasn't been taught with too much detail so far. In order to know what style better fits your project, you need to have a good understanding of a broad variety of them, and it becomes easier once you have experience working with the different styles. 

For example, today, I most likely wouldn't be able to pick the optimal style for a certain project, but I trust that people with more, and different, experience than me will be able to come up with a good solution for whatever I'm working on, and I'm sure that one day, I'll be able to do the same.