Week-15: 12/21/2024

It’s easy to get something functional, but is it good? The book “Clean Code” by Robert C. Martin shows how my past coding techniques were wrong. This book isn’t just about making code work; it’s about crafting code that is understandable, maintainable, and, dare I say, beautiful.

The book highlights the importance of seeing code as a kind of communication rather than simply computer instructions. It’s about creating code that’s simple to understand, alter, and, ultimately, live with. The book provides several definitions of clean code, including the following: elegant, efficient, simple, straightforward, and carefully crafted. It also covers ideas and practices including utilizing meaningful names, constructing concise functions, correct commenting, formatting, error handling, unit testing, and so on. The book depicts the transition from sloppy to tidy code. It also includes a collection of code smells or heuristics that might help you write better code. 

I chose this book because I often find myself spending more time deciphering what code does than actually adding new features. I was looking for guidance on how to avoid creating such a mess and to understand what makes code easy to work with, and the book seemed highly relevant to my goals as a student. I also appreciated the idea that code is read far more often than it is written, so making it easy to read is very important.

This book has opened my eyes, particularly to the importance of code readability. It is not enough to have code that is functional; it must also be understandable to everybody who will work with it. This is particularly crucial in collaborative efforts. The author’s description of “code sense,” a carefully developed feeling of ‘cleanliness,’ struck a chord with me. Knowing that code should be clean isn’t enough; we also need to learn how to make it clean. 

I will be putting the principles of “Clean Code” into practice by always striving to leave the code cleaner than I found it. I also plan to be more diligent in naming variables and functions, keeping functions short and focused, and implementing tests to validate and describe code. This book has taught me that clean code is more than a nice-to-have; it is an important component of becoming a professional software developer. I now recognize that “working” code is only the first step; “good” code needs ongoing attention and effort. I’m excited to implement these concepts into my future projects, not just to improve my grades but also to gain more experience programming software.

Book: Clean Code: A Handbook of Agile Software Craftsmanship by Robert Cecil Martin

From the blog CS@Worcester – computingDiaries by hndaie and used with permission of the author. All other rights reserved by the author.

Week-15: 12/20/2024

This blog post really helped me understand how important design patterns are for making REST APIs that are easy to use and can handle a lot of traffic. The post talked about things like naming resources consistently, breaking up big chunks of data into smaller pieces, and making sure that updates don’t break older versions of the API.

One thing that really stuck with me was how important it is to name your resources consistently. The post emphasized that using standard and intuitive naming conventions makes APIs predictable for other developers. It’s like having a well-organized filing system—if everyone knows where things are supposed to go, it’s much easier to find what you need.

The post also talked about things like versioning and error handling, which are super important for making sure that your API can evolve over time without breaking things for people who are already using it. Versioning ensures backward compatibility as APIs evolve, which means that even if you make changes to your API, older applications that use it will still continue to work. Error handling is all about giving developers useful information when something goes wrong. The post mentioned that providing informative error responses can help guide developers who are using your API. I’m definitely going to be focusing more on these aspects in my future projects.

The reason that I chose this blog post was because it aligns closely with what I learned in the class. Our class discussions often emphasized the best practices for creating maintainable, user-friendly APIs, and this post serves as a practical extension of those theoretical concepts. I wish I had read this article before some of my homework assignments; it would have made it easier for me to understand the assignments. Additionally, its concise, actionable guidance provides a clear framework for applying these principles in real-world scenarios.

Overall, this blog post was a great way to connect the theoretical stuff we’ve been learning in class with how things actually work in the real world. It’s one thing to understand these concepts in theory, but it’s another thing to see how they’re applied in practice. This blog post provides practical insights into designing APIs that are easy to use and can be scaled up as needed. It’s given me a much better understanding of how to create APIs that are not just functional but also developer-friendly and built to last.

Blog link: https://blog.stoplight.io/api-design-patterns-for-rest-web-services

From the blog CS@Worcester – computingDiaries by hndaie and used with permission of the author. All other rights reserved by the author.

Week-13: 12/2/2024

This week in class we worked on merge conflicts and how to resolve them. I had to do an activity that had to do with solving a merge conflict. This experience was not as frustrating as I thought it was going to be. While doing the activity, Professor Wurst highlighted how important it is to understand version control systems like Git and to develop effective strategies for resolving conflicts collaboratively.

On this week’s blog hunt, I came across a helpful blog post by Sid Puri titled “Git Merge Conflicts,” which provided a clear explanation of what merge conflicts are, why they occur, and how to resolve them using Git tools. It broke down the process into manageable steps and even offered advice on how to prevent these conflicts from happening in the first place.

One of the key takeaways for me was understanding the root cause of merge conflicts: multiple developers making changes to the same file at the same time. Because Git can’t automatically figure out which changes to keep, it flags these conflicts and requires manual intervention. The post explained how to use Git’s notification system to identify conflicts and then how to manually merge code using conflict markers – those weird symbols like <<<<<<<, =======, and >>>>>>> that used to make my head spin.

The post also emphasized the importance of communication in preventing merge conflicts. This really resonated with me because our team conflict stemmed from two of us accidentally modifying the same section of code. If we had just communicated about our tasks beforehand, we could have avoided the whole issue. Moving forward, I’m definitely going to advocate for more frequent team check-ins and a more organized approach to task allocation.

What I really appreciated about the blog post was its practical approach to conflict resolution. It explained how to use built-in Git tools like git status and git diff to navigate conflicts with confidence. Mastering these tools will definitely save me time and frustration in future projects. Plus, learning how to handle and resolve conflicts collaboratively is a transferable skill that will be valuable in any team setting, not just software development.

Overall, this blog post was a great resource that directly complemented our coursework on team-based software development. It reinforced the idea that understanding and resolving merge conflicts isn’t just a technical skill; it’s an essential component of effective teamwork in software engineering. I feel much more prepared to tackle these challenges in the future and to contribute more effectively to my team projects.

Blog link: https://medium.com/version-control-system/git-merge-conflicts-4a18073dcc96

From the blog CS@Worcester – computingDiaries by hndaie and used with permission of the author. All other rights reserved by the author.

Week-13: 12/2/2024

Understanding software architectural patterns is critical in the software development industry for creating strong, scalable, and maintainable products.

A recent Turing blog post, “Software Architecture Patterns and Types,” has been useful in solidifying my understanding of this important concept. This article provided a comprehensive overview of various patterns, including monolithic, microservices, event-driven, layered, and serverless architectures. The article clearly gives explanations of each pattern’s design principles, advantages, and limitations.

For instance, while monolithic architectures offer simplicity, they often struggle with scalability. On the other hand, microservices excel in scalability and allow for independent deployment but can introduce complexity in maintenance and debugging. The article also explores emerging trends like serverless architecture, emphasizing their importance in modern cloud-based systems.

The practical examples and concise explanations in the article made it extremely relevant to what I learned in my classes, particularly my software construction, design, & architecture class. The discussion on system scalability and maintainability directly aligns with the topics we’re covering.

One of the most valuable takeaways for me was the emphasis on aligning architectural decisions with business objectives. The article effectively illustrates that a microservices architecture, while attractive for its scalability, might be overkill for a small-scale project. This resonated strongly with my recent experience in a group project where we debated between microservices and a layered design. Reflecting on the deployment and dependency management challenges we faced, the article validated our decision to opt for a simpler layered design as a better fit for our project’s scope.

Furthermore, the article’s discussion of serverless architecture was truly eye-opening. I had previously held a somewhat simplistic view of serverless as a universal scaling solution. However, the article shed light on its potential drawbacks, such as vendor lock-in and latency issues. This more nuanced perspective will undoubtedly inform my approach to future projects, encouraging me to critically evaluate new trends before jumping on the bandwagon.

Moving forward, I intend to apply this knowledge by diligently assessing the specific needs and constraints of each project before selecting an architectural pattern. For instance, when tackling a high-traffic e-commerce site, I would now consider employing an event-driven architecture to effectively handle asynchronous data flow. Alternatively, for smaller projects, I would advocate for a monolithic or layered approach to minimize overhead.

By understanding the trade-offs inherent in different architectural patterns, I feel better prepared to design and build software systems that are not only functional but also scalable, maintainable, and aligned with business goals.

Blog link: https://www.turing.com/blog/software-architecture-patterns-types

From the blog CS@Worcester – computingDiaries by hndaie and used with permission of the author. All other rights reserved by the author.

Week 12 – 11/30/2024

Agile Versus Waterfall: Picking the Right Tool for the Job

As a senior in college, I’m starting to think more seriously about what it will actually be like to work on projects in the real world. I recently read a blog post that compared and contrasted Agile and Waterfall project management methodologies, and it really helped me understand the importance of choosing the right approach for different types of projects. This aligns perfectly with what we’ve been discussing in my class about the need for both strategic planning and adaptability.

The blog post “Agile vs. Waterfall: Understanding the Differences” by Mike Sweeney explained that Waterfall is a very linear, sequential approach, where each phase of the project must be completed before moving on to the next. It’s kind of like building a house – you need to lay the foundation before you can put up the walls. This makes Waterfall a good choice for projects where the requirements are well-defined and unlikely to change, like in construction or manufacturing. In these industries, making changes mid-project can be super costly and impractical, so having a clear plan from the outset is essential.

Agile, on the other hand, is all about flexibility and iteration. The project is broken down into short cycles called sprints, and the team continuously reevaluates priorities and adjusts its approach based on feedback and new information. This makes Agile a great fit for projects where the requirements are likely to evolve over time, such as software development. In software development, client needs and market trends can change rapidly, so being able to adapt is crucial.

One of the biggest takeaways for me was the realization that choosing the right methodology is crucial for project success. I used to think that being flexible was always the best approach, but now I understand that structure and predictability can be equally important in certain situations. The key is to carefully assess the project requirements and choose the methodology that best aligns with those needs.

As I prepare to enter the professional workspace, I feel much more confident in my ability to approach projects strategically. Thanks to this blog post, I now have a better understanding of when to use Agile versus Waterfall. For instance, if I’m working on a software project that involves a lot of client interaction, I’d probably lean towards Agile. But if I’m managing a marketing campaign with well-defined objectives, Waterfall might be a more appropriate choice.

The real-world examples provided in the blog post were super helpful in illustrating how these methodologies are applied in different industries. This practical insight will definitely be valuable as I transition from the academic world to the professional world.

Blog link: https://clearcode.cc/blog/agile-vs-waterfall-method/

From the blog CS@Worcester – computingDiaries by hndaie and used with permission of the author. All other rights reserved by the author.

Sunday, September 15, 2024

This week I was introduced to Object-Oriented Design Principles. In this week’s blog, I will be discussing what object-oriented design principles are and how these principles help with creating software so that it is easy to maintain.

The Medium blog post by Ravi Patel “Understanding Object-Oriented Design Principles” offers an overview of major object-oriented design principles and how they help to the creation of successful and maintainable software. Object-Oriented Design (OOD) is a software design methodology that views the program as a collection of interacting objects, each representing an instance of a class. Ravi goes on to discuss the fundamental principles, encapsulation, abstraction, inheritance, and polymorphism.

Encapsulation is the process of grouping data and methods that operate on it into a single unit or class while restricting access to certain of the object’s components. This aids in concealing the internal state and requires all interactions to be conducted through an object’s methods.

Abstraction is the process of simplifying complicated systems by modeling classes based on key traits and behaviors, while obscuring unneeded information. This focuses on an object’s actions rather than its methods.

Inheritance allows a new class to inherit characteristics and methods from an existing class, enabling code reuse and establishing a hierarchical connection between classes.

Polymorphism allows objects to be viewed as instances of their parent class rather than their own. This enables the use of a single interface for a broad range of activities, increasing code flexibility and extensibility.

I chose this blog post because it helped me understand the principles better. After this week’s reading I now understand that object oriented principles is a theory that helps developers in how to think about and build code that is easier to work with, simpler to understand, and requires less maintenance overall. When working on my POGIL activity with my team this week, there was a question that asked us to define the principles without looking them up. We defined the principles as follows:

Abstraction is simplifying code
Encapsulation is adding code to already existing code
Polymorphism is many forms of code/methods
Inheritance are classes and their super classes and constructors

Our definitions were not entirely wrong. We could gather what each principle meant to an extent. I see myself applying these principles in my future projects. It would help create readable code that can also be modified easily as needed. This week’s material made me understand that not all long code is helpful. The simpler the code is the better it is for the next developer to read it. When I usually code, I add a lot of unnecessary code that does not need to be there. I hope to improve my code writing skills as I learn more.

Blog link: https://medium.com/@ravipatel.it/understanding-object-oriented-design-principles-0c1e48207c89  

From the blog CS@Worcester – computingDiaries by hndaie and used with permission of the author. All other rights reserved by the author.