Code Review

Source: https://about.gitlab.com/topics/version-control/what-is-code-review/

This article is titled “What is a code review?” As clearly stated by the title, the article explains the processes of code reviewing. “A code review is a peer review of code that helps developers ensure or improve the code quality before they merge and ship it.” Code reviews help in the identification of bugs, increase the overall quality of code, and enhance understanding of the source code. Code review, as suggested in the name, happens after a software developer has finished coding. Code needs to be checked before it is merged into an upstream branch for bugs or conflicts. A code reviewer “can be from any team or group as long as they’re a domain expert. If the lines of code cover more than one domain, two experts should review the code.” Adhering to a solid code review process allows for continuous improvement of code and aims to ensure that faulty code isn’t being implemented for customers/users to see and use. This process isn’t just important for the code itself, but also for all of the team members of a software development project. Whilst reviewing the code, meaningful knowledge of the source code is shared between team members to ensure that it is being implemented properly. The main benefits of the code review process are: the sharing of knowledge, discovering bugs earlier, maintaining compliance, enhancing security, increasing collaboration, and improving code quality. Code reviews allow for maintaining compliance because different developers have different backgrounds and thus different personal processes when they are developing. Code reviews allow these people to get together and maintain a standard coding style. Security is enhanced because “security team members can review code for vulnerabilities and alert developers to the threat. Code reviews are a great complement to automated scans and tests that detect security vulnerabilities.” There are many benefits to code review, but there are some disadvantages, including: longer time to ship, focuses being pulled from other tasks, and large reviews mean longer review times. These can be described as necessary evils due to the sheer amount of positives that code reviews offer in software development.

I chose this article because it was published by GitLab, a software that we are heavily using in class for version control, and I thought that it would be interesting to read this specific topic from the syllabus. Version control softwares such as GitLab allow code reviews to happen, so diving deeper into the topic in an article published by this popular software company was tempting. Before reading this article I understood that code reviews were important to pinpoint any bugs or difficulties before merging code into the upstream, but I never really thought about the implications of security or different development styles. I’ll definitely keep this information in mind during future code reviews on the job to remind myself that bugs aren’t the only important thing during a code review.

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

Why Git

Why is it always git

Photo by RealToughCandy.com on Pexels.com

The version control system that every programmer uses. Even in my computer science class, we had lectures dedicated to Git, the commands in Git, how Git is used, what Git is used for, and just so much Git. The funny thing, is there are other version control systems such as Mercurial, but they aren’t ever brought up they are there but feel overshadowed by git. So the question I am asking now is why Git. So I did some investigating.

The question: what does Git do that is so special compared to other version control systems? Now version control systems can do all sorts of things such as allowing developers to see what has been changed, enable collaborative work, and branch and merge changes to a repo. If multiple can do this, then what does git do differently? An article from Geeks For Geeks lists several. Git can be worked on offline and is resilient because multiple developers can have copies of the repo, and any local repo can be used to restore a project. It also comes with conflict resolution that’s allows one to handle merge conflicts by providing tools to solve those problems. So what about the other systems. Well, GFG got that covered. Here are some comparisons.

Subversion

Compared to Git, the architecture is centralized, one single central repo

Fewer branching and merging options

Better performance

Mercurial

Smaller community compared to Git

Not as much flexibility as Git

Perforce

Can handle very large code base

Not as flexible as Git in terms of merging

Git is Open Source and Free, while Perforce isn’t

That is a decent amount of reasons to use Git over other VCS. I think the community part is important for such a popular system, because if you aren’t too familiar with the commands that come with Git, then you have a lot of people that can help. There are a lot of forums and articles about Git tools out there if you ever need it.

I also feel that the collaborative aspect of Git is, very helpful. A lot of projects have a lot of people working on them, so having something like Git that can handle it and make the task easier is great. Also, the fact that it is accessible helps with that too.

Git being so popular makes a lot of sense now, accessibility, community, and collaboration are what a lot of developers require, and I have to say Git provides that well.

GeeksforGeeks. (2024, September 19). Git vs. other version control systems: Why Git stands out? https://www.geeksforgeeks.org/git-vs-other-version-control-systems-why-git-stands-out/

From the blog Debug Duck by debugducker and used with permission of the author. All other rights reserved by the author.

YAGNI

Source: https://www.geeksforgeeks.org/what-is-yagni-principle-you-arent-gonna-need-it/

This article is titled “What is YAGNI principle (You Aren’t Gonna Need IT)?” YAGNI is “a principle in software development that suggests developers should only implement features that are necessary for the current requirements and not add any additional functionality that might be needed in the future.” The reasoning for this is that if you add features that might potentially be needed in the future, there will be risk for more bugs, increased complexity, and increased times of development, thus leading to increased cost. The YAGNI principle is similar to the KISS principle (Keep It Simple, Stupid), which also advocates for simplicity, it encourages developers to avoid complexity when it isn’t necessary. Developers should follow the YAGNI principle if they wish to keep the following costs in mind: the cost of building, delay, carry, and repair. The cost of building refers to the total cost of efforts and resources implemented in the project. Building things that aren’t needed leads to increased costs overall. Cost of delay refers to missed opportunities, if you spend time on unnecessary features, the development of more important ones will inevitably be delayed. Cost of carry refers to the difficulties of having unnecessary complex features. These complexities make it difficult to work on other parts of a software project, require more time, lead to an increased cost, and overall cause harder times moving forward. Lastly, the cost of repair, or technical debt, refers to the costs associated with bugs or mistakes that occur during the development process. YAGNI is important to ensure that the development process is focused, efficient, and cost-effective. YAGNI can be implemented into your code by prioritizing communication between team members. Ensuring that necessary requirements are met, a simple plan is made, ignoring ideas that don’t meet goals or deadlines, and keeping good records of project progress will allow your team to follow the YAGNI principle. YAGNI allows for simplicity, faster development, flexibility, reduced risk, and cost savings by complementing other development principles while prioritizing unnecessary implementations.

I chose this article because I appreciate how geeksforgeeks simplifies topics within the software development community. I don’t recall this principle being explicitly mentioned in class, but we have definitely alluded to it and I thought it’d be beneficial to read about it more, considering that it is in the syllabus. It was interesting to learn that the YAGNI principle complements other software development principles, such as the KISS principle, and compiles them into a unique principle that prioritizes simplicity over complexity and more features. It embodies the idea of “less is more.” This is a great set of guidelines I’ll be sure to follow in industry because it promotes that sometimes less work isn’t a bad thing. Instead of creating a multitude of features, ensuring that the ones that are critical, and required sooner, are being developed, will still get the job done.

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

Understanding The Waterfall Methodology

At the start of the semester, we talked about Software Methodologies, and one of the topics we covered was the Waterfall Methodology. The article I chose focuses on the Waterfall Methodology, which emphasizes completing and approving each phase before moving to the next. This approach helps reduce errors, making the process more time-efficient and improving project documentation.

The Software Development Life Cycle (SDLC) is divided into six phases: requirement analysis, software design, planning, software development, deployment, and testing. When the Waterfall Model is applied to the SDLC, it adds structure by defining the time and duration for each phase. This helps developers and teams better understand how long the process will take and what to expect at each step.

The article also explains when the Waterfall Model is the best choice for a project. Since every methodology is different, this model works well for projects with clear concepts, less complexity, a solid and unchanging plan, and minimal room for errors (no repeated phases). It’s commonly used in industries like healthcare and banking. The article also discusses the advantages and disadvantages of the Waterfall Methodology.

One advantage I really like is that each phase is completed one at a time, providing a clear and straightforward plan for programmers to follow. However, a disadvantage I find inefficient is that progress can be slow, which might make it harder to estimate when the project will be completed.

The article outlines the distinct phases of the Waterfall Model:

  • Requirement Analysis: Gathering and documenting what the software needs to achieve.
  • System Design: Translating requirements into system specifications, including hardware and architecture considerations.
  • Implementation: Developing individual units or components based on the design.
  • Testing: Integrating and rigorously testing components to find and fix issues.
  • Deployment: Releasing the completed software to clients or the market.
  • Maintenance: Providing ongoing support, including patches, bug fixes, and updates.

I chose this article because it provides a clear and concise explanation of the Waterfall Model. I also wanted to learn more about this methodology and how it differs from others. Waterfall is one of the more popular choices among engineers and developers, and now I understand why. Its structured approach makes it appealing for certain types of projects, even though it may not always be the fastest.

Looking ahead, I want to apply what I’ve learned about the Waterfall Methodology to my future career as a software engineer and projects like my Software Capstone class next semester. Understanding how to plan and organize phases systematically will be important for delivering a successful project. I also want to explore other software methodologies to understand their strengths and weaknesses. Knowing when and what type of project each methodology works best for will help me decide how to approach different challenges in my career.

Source:
What Is The Waterfall Model?

Citation:
Team, Codecademy. “What Is the Waterfall Model for Software Development?” Codecademy Blog, 7 June 2024, http://www.codecademy.com/resources/blog/what-is-the-waterfall-model/. 

From the blog CS@Worcester – CodedBear by donna abayon and used with permission of the author. All other rights reserved by the author.

What is scrum

A development team is a unique environment that requires a unique framework for the developers to follow. In other industries such as construction, you need all of the workers to focus on one goal at a time. You wouldn’t want a team working on the stairs to an attic while another team is still working on the foundation. When constructing a bridge you would have a really tough time working on the middle without having the ends already built. While both software and construction have the goals of building or creating something, its clear they would utilize different frameworks.

That is where development teams have come up with the idea of having a scrum.

A scrum is a way for a team to break down a larger project into manageable goals that can be met within time frames called sprints. The main benefits are increased collaboration, flexibility and the ability to adapt leading to better quality, usable software in shorter time frames. These shorter time frames make it better for users by giving them products they can actually use at a more consistent pace.

There are 3 key roles in a scrum team, the developers, the scrum master and the product owner. The roles each have their own tasks in order to make the system flow.

The roles and tasks are:

Product owner:
-creating and communicating the goals

-creating and ordering backlog items

-making sure the backlog is accessible and understandable

Scrum master:

-serving, coaching and helping the product owner and the development team

-leading training and planning for both the product owner and development team

-removing barriers between stakeholders and the developers
-making sure that all the scrum events are taking place

Developers:

-planning of the sprint

-having a universally understood definition for the word done within the team

-holding each other accountable and staying flexible when needing to adapt

A sprint is where all of the members of a scrum team come together to create a product. A sprint has different stages called events. Each event has an important role for the team to consistently create products, understand their products, and continue to improve as a team. 

The sprint events and their uses are:

The sprint:

-the development process as a whole, containing the other events

-fixed lengths usually a month or less

Sprint planning:

-planning is done by the entire scrum team

-product owner creates and orders the backlog

-scrum master assists in the backlog and help communicate it to the dev team

-the dev team plans out which items of the backlog will be the focus of the sprint

-the main aspects are the sprint goal, backlog, and plan to deliver

Daily scrum:

-a short daily meeting among the development team

-check progress towards the sprint goal and adapt as needed

Sprint review:

-all members of the scrum team review the outcome of the sprint

-all members talk about what went well, what went wrong and how they solved what went wrong

Sprint retrospective:

-the scrum team goes over how they can be more effective in any future sprints

-review any impactful changes that have occurred with previous sprint retrospectives

-work to refine their abilities as a scrum team

From the blog Mikes CS 348 by Michael St. Germain and used with permission of the author. All other rights reserved by the author.

Best Practices for REST API Design.

REST APIs are essential of todays software development, this helps applications to communicate across platforms. I read the blog post Best Practices for REST API Design on the Stack Overflow blog, which provided advice on designing APIs that are efficient, secure, and user-friendly. This post furthered my understanding of “RESTful” principles.

Summary

The blog post outlines several key principles for designing REST APIs effectively. It begins by stressing the importance of a well-defined URL structure that reflects the resource hierarchy and uses nouns instead of verbs. For instance, /users/123/posts is a clear and intuitive way to access a user’s posts.

It also highlights the necessity of using standard HTTP methods (GET, POST, PUT, DELETE) to maintain consistency, along with proper status codes to provide meaningful feedback to clients. The post delves into techniques for handling query parameters, versioning APIs to ensure backward compatibility, and implementing pagination for large datasets. Security and performance are emphasized as critical considerations, with recommendations to use HTTPS and apply caching strategies.

Why I Chose This Resource

As we did POGILs in class, I frequently ask myself scenarios where creating a robust REST API are most essential. This blog post stood out because it bridges theory and practice, directly applicable to homeworks and future projects.

Reflection

The blog post reinforced several concepts I’ve encountered, such as the importance of clear URL structures and consistent use of HTTP methods. However, it also introduced new ideas that I hadn’t fully understood as much, such as the role of API versioning in preventing disruptions for existing users when introducing updates.

One particularly impactful takeaway was the emphasis on client feedback through proper HTTP status codes. In my past in class activities, I’ve realized that it is imporetnat for an API to clearly communicate success or failure states, yet I hadn’t prioritized this aspect. The value of using codes like 201 Created for successful resource creation or 400 Bad Request for errors, enhancing user experience.

Future Work

Going forward, I plan to apply these best practices to my API design tasks. For instance, in my upcoming assignments or personal projects, I will ensure that URL structures are logical and intuitive, aligning them with its resourced relationship. Additionally, I’ll pay closer attention to implementing proper status codes and securing APIs with HTTPS to protect sensitive data, such as ID or SSNs…

This resource has also inspired me to explore tools like Postman or Swagger for testing and documenting APIs.

Conclusion

The blog post Best Practices for REST API Design not only refreshed my technical knowledge but also provided ideas for creating APIs that are robust, secure, and user-friendly.

https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/

From the blog CS@Worcester – function & form by Nathan Bui and used with permission of the author. All other rights reserved by the author.

(Week-12) Copyright and Licensing in Software Development

A lot of developers today mistakenly think that publishing code without a license automatically makes it free for public use. However, under copyright law, code without an explicit license is still technically the property of the original owner. That means that any users cannot legally copy, modify, or distribute it without permission. This can lead to legal disputes, misuse of the code, or anything the original owner did not intend. Posting code on GitHub without a license is defaulted to GitHub’s terms, which allows for limited collaboration but restricts use at larger scale.

When it comes to software projects, making sure you have the right license that fits the needs of the project is extremely important to how others interact with your code.  Typically licenses of this nature fall under two categories, a copyleft license or a permissive license.  A copyleft license, such as the GNU General Public License (GPL), ensures that any derivative works must retain the same license.  These licenses promote transparency and guarantee that the software and its derivatives remain open-source. This is for developers who want to foster a community, make improvements from others testing, and prevent proprietary derivatives.  However, some large companies may avoid this technique, as they could be giving a competitive advantage to other competitors interested in their work.  On the other hand, permissive licenses, such as the MIT or Apache 2.0 licenses, allow derivatives to be licensed under proprietary terms. This approach provides as much “freedom” as possible, while making it easier for businesses to use the code without copyright issues. While this can lead to a large increase in usage, it could get out of hand when companies don’t submit their versions of the code.

“How Copyright Works (Part 5): Copyright Licenses in Simple Terms”, is a short video by the Youtube channel What is Law Even.  It is the last installment of a 5-part series that explains the many rigid aspects of copyright law, and how it is used in the context of today.  This installment focuses on the basics of copyright law, and specifically the license aspect of the law.  The narrator explains what a copyright license is, and the possible royalties that may be attached to that respective license.  It is a great straightforward video that is short, but filled with quick bits of knowledge important in the copyright sphere.

In short terms, copyright licensing is extremely important when it comes to software development.  Licenses are a key part of a project’s workflow, and even when they aren’t explicitly stated, there is a good chance there is still one in the background.  Always be weary of the copyright laws as they are only there to protect owners from unlawful practices against their projects.

Link: https://www.youtube.com/watch?v=XjwOTNBRFpE

  • Elliot Benoit

From the blog CS@Worcester – Elliot Benoit's Blog by Elliot Benoit and used with permission of the author. All other rights reserved by the author.

Microsoft’s Git Problem

This week, I came across an article that talks about Microsoft encountering an issue with Git and version control. Microsoft software engineers use Git as their version control system, and they recently discovered a problem with the amount of memory being used in their repository. Their first commit was only 2 GB, then grew to 4. However, it soon was taking up 178 GB of memory. Obviously, this is a bit of an issue. It would be very difficult for a team to make commits with that much storage space in that amount of time. But how does this happen? Well, the article states that the issue stems from name-hash collisions. Basically, Git was finding a bunch of differences with each commit despite there not being many at all. Obviously, this is a huge issue, so steps are already being made to resolve it.

This is an issue that was particularly interesting to me because we are currently learning about Git and how to properly use it in my CS 348 class. Git is an incredibly useful and necessary tool in the computer science world. To see an issue this scale at a company this important grabbed my attention immediately. I was also curious to see how Git was used on large projects at a company like Microsoft.

Seeing that problems like this can occur was for sure interesting. However, what was more interesting to me was that by the time anyone could report on this, changes were already being made. The article does state that this issue would not affect smaller repos, which would be what I am dealing with at the moment. However, it is fascinating to see how on top of everything these developers are in order to assure a smooth running product. It makes me feel better knowing that these issues will be resolved by the time I could ever encounter them. It also motivates me knowing that some day, I will have to be this vigilant in my work to truly be successful. Also, the fact that over 90% of developers use Git for version control was intriguing. I knew it was popular, but I also was aware of other version control systems. This just goes to show how reliable Git is, despite some occasional issues such as this one. I am glad to be learning how to use this system, and I am excited to learn more about it going forward.

https://www.techzine.eu/news/devops/125694/flaw-in-git-bloated-microsoft-repository-by-a-factor-of-35/

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

What is Scrum?

Understanding Scrum: A Framework for Team Success

Scrum, a popular framework for managing complex projects, has transformed the way teams collaborate to deliver value. I explored this in-depth explanation through an article I found on Scrum.org. This provided a clear overview of the principles, offering how Scrum facilitates productivity and adaptability in many different environments.

A Quick Summary

The article breaks down Scrum as a “framework” designed to help teams address complex problems while delivering high-value results. Originating from Agile principles, Scrum relies on time-boxed iterations called Sprints, typically lasting two to four weeks, where teams focus on completing a specific set of tasks. Key roles in Scrum include the Product Owner, who prioritizes work; the Scrum Master, who ensures the process runs smoothly; and the Development Team, which executes the tasks.

Scrum also emphasizes artifacts like the Product Backlog and Sprint Backlog, which guide work priorities and task distribution. Regular ceremonies such as Sprint Planning, Daily Standups, Sprint Reviews, and Retrospectives foster transparency and continuous improvement.

Why I Chose This Resource

We learned this in class and I think it is a good refresher to read. In the world of of software development, I often think of projects where collaboration and adaptability are required. Scrum is a cornerstone of Agile development, making it a vital topic to understand for both academic projects and industry roles. This article stood out for its clarity, structured explanation, and relevance to course concepts, particularly software design and project management.

Reflections

The article reinforced the value of frameworks in managing stressful development cycles. I was interested by the emphasis on teamwork and iterative progress. While individual accountability is important, Scrum places significant focus on collaboration, encouraging team members to engage in problem-solving and decision-making collectively.

A key takeaway for me was the importance of transparency, which Scrum achieves through its artifacts and ceremonies. For example, the Daily Standup ensures that every team member is aligned, minimizing the risk of miscommunication, something I can apply to my group projects in the future.

What I plan to use

In future group projects, I aim to incorporate elements of Scrum, such as structured meetings and task prioritization using a backlog. For example, if I do have a software development project, I plan to propose implementing a Sprint-like system where my team can review progress and adjust objectives weekly. Long term, understanding Scrum positions me better for internships and career roles where Agile methodologies are prevalent.

This article not only described what Scrum is but for me also underscored its practical applications, affirming its relevance to professional sides.

From the blog CS@Worcester – function & form by Nathan Bui and used with permission of the author. All other rights reserved by the author.

REST API Design

Modern web applications are built on top of REST APIs, which provide the essential connection between the client and the server. This week, I discovered a blog called “Best Practices for REST API Design” by John Au-Yeung and Ryan Donovan which outlines important techniques for developing secure, performant, and user-friendly APIs. Because JSON is widely accepted and lightweight, it promotes its use as the standard data format. While HTTP methods like GET, POST, PUT, and DELETE determine the action, logical endpoint architectures that rely on nouns rather than verbs are crucial for clarity. Although it improves readability, resources should be kept simple to prevent complexity.

The blog discusses how to handle problems politely by giving easily comprehensible error messages to facilitate debugging and employing relevant HTTP status codes (e.g., 400 for Bad Request, 404 for Not Found). It also highlights the need of using query parameters for pagination, sorting, and filtering when handling big datasets. For protecting APIs, security measures including role-based access control, SSL/TLS encryption, and the least privilege principle are essential. Although caching is emphasized as a way to improve performance, developers should make sure it doesn’t produce stale data. Lastly, it is advised to version APIs, frequently using prefixes like /v1/, in order to guarantee backward compatibility and permit incremental enhancements.

Since we’ve been learning about REST API design in class, I chose to read a blog about it in order to gain a deeper understanding of best practices. In addition to explaining each essential aspect of REST API design, such as JSON usage, appropriate endpoint naming, error handling, security, caching, and versioning, I selected this blog because it also provides code blocks as examples, which helped readers understand and visualize the concepts more clearly.

What caught my attention the most was the part about using logical nesting for endpoints. It described how APIs are made easier to use and comprehend by grouping relevant endpoints. It also made the point that endpoints shouldn’t replicate the database’s structure. This increases the security of the API by shielding private data from attackers. I became more aware of how endpoint design may affect security and usability after reading this. This demonstrated the significance of properly planning endpoint architectures.

This article impacted my perspective on API design by emphasizing the necessity of striking a balance between usability and simplicity. I want to use these ideas in future projects by making solid security procedures, efficient error handling, and well-defined endpoint structures top priority. By using the strategies covered in this blog, I intend to create APIs that are effective and simple for developers to use, guaranteeing that they can be maintained and offer a satisfying user experience throughout time.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.