Skip to main content

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. 

Comments

Post a Comment

Popular posts from this blog

Is Design Dead?

 This week, we had to read Is Design Dead? by Martin Fowler. Just by reading the title, the thought of agile methodologies popped into my head, since they do involve design, just not as much as we're accustomed to. And not too surprisingly, Fowler reached a similar conclusion: design is NOT dead, it has just evolved along with us to keep up with today's standards.  Before, design was used to make sure that you knew everything you needed to get done, and it let you find any flaws in your plan beforehand. It was meant as an all-encapsulating process that all future code will be based on. Today, it has maintained its role as a guide, as to not make the developer feel totally lost, but with today's fast-paced work environment and ever-changing requirements, with the help of methodologies such as Extreme Programming, it has evolved to become more dynamic and easier to change.  For my personal opinion, I've had experiences (both academic and professional) where a bit of desig
Post a Comment
Read more

SOLID

 This week, we read a very straight-forward chapter by Edward Guiness of the book Ace the Programming Interview: 160 Questions and Answers for Success. It very quickly explains the SOLID principles, which are widely-known principles applied to object-oriented programming that have to do with minimizing dependencies between classes. I won't explain what each principle consists of (since it's very easy to find ), but I will share my general thoughts about them.  I still remember when I first started university, my code consisted of one very long python file that you could very easily read from top to bottom; the concept of functions was still foreign to me, and when we started using them, we would split up all of our code into two or three functions and that was that. Since then, we've been introduced to many different ways to make code cleaner and easier to read, and one that's been repeated often is the Single Responsibility Principle, which I agree is very useful in or
Post a Comment
Read more

Why is an architect?

  This week's (very short) article, Who Needs an Architect?, Martin Fowler explains to us the different definitions of architects that exist in the software world. The first and most common definition, which Fowler disagrees with, says that an architect is (s)he who helps identify what the most important parts of a project are, in order to give it structure. However, it is also mentioned that these parts are usually the most important because they are the hardest to change, so an architect's job should also include reducing the amount of these parts. Following the logic, by this definition, an architect's job is to reduce the amount of architecture.  The second proposed definition, which I also think I agree with, is that an architect's role is more like a guide's. His purpose is to help the team become better by using his expertise, and communicating with as much of the team as possible in order to remove their blocks. I think the word architect  still fulfills thi
Post a Comment
Read more