In software, we often hear the phrase git and caught up wondering what it is about. Here is a light description of what git is. Git is a distributed version control system (DVCS) that allows you to track changes in your codebase, collaborate with others, and maintain a complete history of your project. Developed by Linus Torvalds in 2005, Git has since gained widespread adoption due to its speed, flexibility, and robust branching and merging capabilities.

Before we dive into Git commands, it’s crucial to set up Git on your machine: That involves installation and configuration. This is where you Download and install Git from https://git-scm.com. Follow the installation instructions for your operating system and configure it using your name and email address using the following commands, git config –global user.name “Your Name” and git config –global user.email “your@email.com”.

When you move deeper into git commands, this is where it gets interesting playing around with these commands and getting to see what they can do. Some of the git commands include;

1. git init: Initialize a new Git repository in your project directory. This command sets up the necessary Git files and folders.
2. git clone: Copy an existing Git repository from a remote server to your local machine. For example, to clone a repository from GitHub.
3. git add: Stage changes for commit. You can specify individual files or use . to stage all changes in the current directory.
4. git commit: Create a new commit with the staged changes, providing a commit message to describe the changes made.
5. git status: Check the status of your working directory. This command shows untracked files, modified files, and files staged for commit.
6. git pull: Fetch and merge changes from a remote repository into your local branch.
7. git push: Push your local changes to a remote repository. This is essential for collaborating with others.
8. git branch: List all branches in your repository, and see which branch you’re currently on.
9. git checkout: Switch between branches or commits. To create a new branch and switch to it, use: git checkout -b new-branch
10. git merge: Merge changes from one branch into another. For example, to merge the changes from feature-branch into main: git checkout main and then git merge feature-branch
11. git log: View a log of all commits in the repository, including commit messages, authors, and timestamps.

As you go even deeper, you discover more advanced git commands such as ;

1. git stash: Temporarily save changes that are not ready for a commit. You can later apply these changes or clear the stash.
2. git rebase: Combine commits from one branch onto another, resulting in a cleaner commit history.
3. git reset: Unstage changes, move the HEAD to a different commit, or even remove commits from the branch entirely.
4. git cherry-pick: Select specific commits from one branch and apply them to another.

All these commands can also be found in a git installed terminal by typing git help in that event that you don’t have time to look for them on the Internet. In conclusion, Mastering Git and its essential commands is a critical skill for developers. Git enables efficient version control, collaboration, and project management. By understanding these core commands, you’ll be better equipped to navigate your software development projects, whether working solo or as part of a team. So, start using Git in your development workflow, and you’ll find that it’s an invaluable tool that streamlines your work and keeps your codebase organized.

From the blog CS@Worcester – MY_BLOG_ by Serah Matovu and used with permission of the author. All other rights reserved by the author.

In the vast landscape of software development, there’s an underlying principle that seasoned developers know all too well: code should not only work but should also be maintainable, readable, and scalable. To achieve this, we often find ourselves identifying and addressing something known as “code smells” and their close cousins, “design smells.”

Understanding the Essence

Let’s start with the basics. Code smells are those subtle hints in your codebase that something might be off. They’re like those faint odors in your room that you can’t quite pinpoint but know need attention. These “smells” indicate potential issues that can make your code harder to understand, modify, and extend (Fowler, 1999).

On the other hand, design smells are more like the underlying structural issues in your code that lead to code smells. If code smells are the symptoms, design smells are the root causes (Beck et al., 2002). Identifying and addressing design smells is essential for maintaining a clean and healthy codebase.

Common Code Smells

1. Long Methods: Code smells often start with overly long methods or functions. When a function becomes a novel, it’s difficult to follow, debug, or modify. Break down long methods into smaller, focused ones for clarity (Fowler, 1999).
2. Duplicate Code: Repeating the same code in multiple places is a classic smell. It leads to maintenance nightmares since you have to make changes in multiple locations when updates are needed (Fowler, 1999).
3. Large Classes: Just as long methods can be problematic, large classes or modules can become unwieldy. Split them into smaller, more cohesive units (Fowler, 1999).
4. Magic Numbers: Using hard-coded numbers without context is a recipe for confusion. Replace them with named constants or variables (Fowler, 1999).

The Path to Design Smells

Design smells often stem from issues in the overall architecture and structure of your code. Some common design smells include:

1. God Class: When one class knows too much and does too much, it becomes a “God Class.” This violates the Single Responsibility Principle (SRP) and makes the code less modular (Fowler, 1999).
2. Spaghetti Code: Unstructured and tangled code that’s hard to follow is like a bowl of spaghetti. It usually arises from poor planning and lack of separation of concerns (Kerievsky, 2014).
3. Circular Dependencies: When modules or classes depend on each other in a circular manner, it can lead to maintenance challenges and hinder code reusability (Fowler, 1999).

The Importance of Addressing Smells

Ignoring code and design smells is like letting that mysterious odor in your room linger; it won’t get better on its own. Instead, it can worsen over time and create a bigger mess to clean up (Fowler, 1999).

Addressing code smells and design smells early in the development process can save time, reduce bugs, and make your codebase more maintainable. It’s like opening the window to let fresh air in; your code will become more pleasant to work with (Fowler, 1999).

Conclusion

In the world of software development, understanding and recognizing code smells and design smells is essential for writing clean, maintainable, and efficient code (Fowler, 1999). Just as identifying that peculiar odor in your room can lead to a more comfortable living space, addressing these smells in your code can lead to a more productive and enjoyable development experience.

So, as you embark on your coding journey, keep your nose keen, and don’t hesitate to refactor and improve your code whenever you detect those telltale aromas of code and design smells. Your future self—and your fellow developers—will thank you.

References:

1. Fowler, M. (1999). Refactoring: Improving the Design of Existing Code.
2. Beck, K., et al. (2002). Extreme Programming Explained: Embrace Change.
3. Kerievsky, J. (2014). Refactoring to Patterns.

From the blog CS-343 – Hieu Tran Blog by Trung Hiếu and used with permission of the author. All other rights reserved by the author.

The article I chose for this week’s blog post is “Understanding Software Process Models: What They Are and How They Work” from the Institute of Data. I chose this article because it fits well with the software process models section of the course topics in the syllabus and can help solidify an understanding of this topic. I was also surprised to learn that software process models are very dynamic. Before reading the article, I thought they were a rigid but vague system of how to develop any project. The article mentions that each system process model is tailored around the current project being developed. The parts of this article I will be discussing are defining process models, the role of software process models in software development, and the critical components of software models.

The first section of the article I will discuss is defining software process models. The article defines software process models as “…frameworks that define the sequence of activities, tasks, and deliverables required to develop high-quality software.” The article says that software process development models act as a roadmap, providing steps that help guide a software development team and are also a dynamic way of structuring a project development. The article also discusses the role that software process models have in development.

Software process models are essential for development teams to work alongside one another. The article discusses in depth how important software process models are for development. “Process models play a crucial role in ensuring that projects are executed smoothly in software development. They provide all team members with a common language and understanding, promoting effective collaboration and communication.” As stated in the article, software process models allow colleagues to have a common understanding of how and what needs to be implemented and when. This allows for significant clarity and helps discover potential issues early in development. The article also mentions how using system process models can help with costs. “By clearly understanding the activities and tasks involved in each phase of the development process, teams can estimate the time and resources required more accurately. This helps in setting realistic project timelines and budgets.” This is one of the most important benefits of using software process models during development, saving developers time and money and resulting in shorter development cycles. The article also discusses some key components of software process models.

The article mentions some key components of software process models. I will just be going over requirements gathering and analysis for the sake of brevity. “Requirements gathering and analysis is the first phase of the software development process. It involves understanding and translating the client’s needs into clear and concise requirements.” This part sets the groundwork for the project and helps ensure the end product matches the client’s vision. If this part of the software development process is not completed correctly, your end result will likely not be what the client wanted, which means that this first part of the process is one of the most important parts of the entire process.

Article: https://www.institutedata.com/us/blog/understand-software-process-models/

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

Jacob Schmitt’s “Trunk-based vs feature-based development”

Link to article at the end

For this week, I am focusing on Jacob Schmitt’s blog post “Trunk-based vs feature-based development”. This is a short yet efficient article in explaining the differences between the two types of software development processes. Schmitt discusses the alternate use cases of such processes, where and when they might be utilized, who is most likely to use them, and the advantages and disadvantages of them. I chose this blog because as I learn more about forks, feature branches, commits and pull requests, it is important to also understand the overall development processes of companies and why they might use them. The development processes mentioned by the blog intertwine perfectly with git commands and usage.

Trunk-Based Development

According to Schmitt, Trunk-based development allows for developers to push changes straight to the main branch. However, if the new feature will take longer than usual changes, then they can “check out a branch from main, move the changes into it, then merge it back in when the development is complete” (Schmitt). Then, there would be a code review held by other developers to ensure that the new changes do not break the main production branch. Although this development approach is quite popular, it is used more often in the realm of experienced developers rather than newcomers.

Feature-Based Development

As for feature-based development, many developers can work on many different changes or branches at the same time. This is done by each developer creating their own feature branch, and then eventually requesting to merge with the main branch. One of the most important differences between feature and trunk based development is that in feature-based, developers never push straight to the main branch. This approach is much friendlier to beginner developers like myself, as there would be no worry of breaking production with new code since changes are on a different branch.

Advantages & Disadvantages

An advantage that trunk has over feature is that the code changes are more likely to be merged faster. Feature-based development pull requests can add up fast over time, which leads to a longer time between requesting and merging. Despite this, feature-based is much safer for larger development projects and groups, when there are too many feature branches to keep track of at once. As of right now, I prefer feature-based development because I would not be very comfortable working directly with the main branch as a new developer.

Thoughts

Although it might be simple, I found this article to be quite helpful in preparing me for what a future job or internship workflow might look like. When one has little to no experience with development in a professional environment, articles such as this one are very beneficial to learning more about team-based development. It gives a bit more background as to why we do this type of development, rather than just stating that we do it. I hope to use this knowledge in future projects with internships or jobs.

Link to article: Trunk-based vs feature-based development | Jacob Schmitt

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

The article I chose for this week’s blog post is: “YAGNI (You Aren’t Gonna Need It) Principle Helps Devs Stay Efficient”, by Tatum Hunter. The article discusses what YAGNI is, how implementing it is difficult but necessary to implement in development teams, how it can be hard to know when to use YAGNI and how YAGNI can be applied to business as well as using a YAGNI methodology in making contracts. In this blog post I will be focusing on how being able to say no or not yet to a customer or employer is vital to a YAGNI system of software development. I chose this because we learned in class how useful YAGNI is to software development, with how it helps save time and money, as well as help morale and how communicating with customers or employers about what might not be good to implement is important.

YAGNI can be an incredible tool for making sure your team isn’t wasting time and energy on code that will not be used in the final product. This is incredibly useful, because as stated in the article, working on something for months thinking its going to be a great success just for it to be thrown aside can be devastating for team morale. “‘After months of hard work, it [a new component management system] just went by the wayside,’ she told Built In in 2020. ‘It might have been the right business decision at the time, but the team’s morale was really impacted.’” When YAGNI is implemented properly, it should lead to a faster development cycle meaning this project could have been completed before it was put aside. Saving the company money, and the team a lot of heartache.

Learning how to communicate YAGNI with customers and employers is one of the most important parts of implementing YAGNI especially if a requested feature may not be necessary. “‘To do that, we had to say ‘no’ or ‘not yet’ to about 30 features,’ Dingess said. And, true to YAGNI, that was the right call. After the product launched and the team could collect real user feedback, those 30 features ended up being irrelevant anyway. Instead, the team pivoted to build out the product based on that feedback.” A customer may want you to work on many extra features alongside your main task, only to later realize that many of those extra requests were not needed. If you were able to communicate to the customer that it would be best to implement those features at a later point in development, you would have saved a lot of time and effort for yourself, and money for your customer.

What I found to be most interesting about the article is how it relates the YAGNI principles to working with customers to make sure development teams don’t waste time and effort on implementations that don’t end up being used, or whole projects being scrapped all together.

Link to the article: https://builtin.com/software-engineering-perspectives/yagni

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

This week I dove into chapter 2 of Apprenticeship Patterns and read the pattern Your First Language. This pattern was about just starting out and only understanding a little bit of one or two programming languages. I thought I would go back to the basics for this week and this pattern would be a good read for that.

The problem this pattern presents is the feeling your job or finding a job depends on your proficiency in a specific programming language. The solution the pattern gives for this problem is to pick a language and become fluent in it. It says whatever language you pick should be your main one for years and will become your default skill you work on when practicing. The pattern mentions the choice is a challenge because it will be the foundation of your early career. Some of the examples the pattern talks about for how you can work on becoming fluent in a programming language is to work on a toy application and write tests for your programs so you can understand what is going on better. A big part of this pattern was finding an experienced coder that you can work with and help mentor you and how it can make the difference in spending minutes on a problem or days. The pattern also mentions the importance of not getting stuck on only using a single language and preventing you from learning a new one.

One of the reasons I chose this pattern is because I can relate to the problem it presents. As a college senior in my last semester finding a job in the software industry will be coming up very soon. I have used several programming languages over my years of school so I have not had to focus on a single language. After reading this pattern I think java should be the language I focus on and become more fluent in because it is the one I know best already. I think I should follow the advice of the chapter and look into working on a small project so I can get better at java. Another thing I would like to do is find a mentor to occasionally help me out. I think that could be very useful for my career. Overall I thought this was a good pattern to read about and it gave me ideas of what I can do to improve my programming skills and create the foundation my career will be built on.

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

This is one of the more interesting patterns in the book. It’s a pattern that discusses the interpersonal relationships between the apprentice the masters or journeymen. I try to portray a lot of enthusiasm when it comes to the workplace. Currently, I work at a sub shop. It’s not my preferred job, but it’s a job, nonetheless. It’s different when comparing this pattern from a software development setting because I feel that I’ve exhausted everything I’ve been able to learn from this job. I try to develop some enthusiasm when it comes down to it though because it’s easier to go through a rush when everyone is in a better mood.

The same thing could be said when it’s time for me to work with a software development team, I can imagine. It’s easy to find people who don’t exactly feel enthusiastic because as the book mentions, they have been working at their job for way too long, they are caught up in many projects and deadlines, and they have no time to stick behind incompetence. After working a couple of jobs, I’ve seen this happen more then I could count, and it’s not a good feeling to conform to everyone else’s mood of dread and pain about a task or subject when feeling the complete opposite.

This pattern can be applied to almost anything in life. The young and incompetent apprentice who feels very enthusiastic about their job is once again shut down by their team. They might feel rather timid in trying to discuss or propose ideas to the team because they are afraid that the team will shut down their enthusiasm. When I’m going through this, I usually began to talk to people I feel that I can express my ideas very clearly too, who won’t attempt to shut them down, or who I feel won’t react negatively toward them. It’s easier to be told wrong by one person than by a bunch of people, and if it ends up being a good idea then I start by telling more people about it until I feel confident that it should be proposed at a more public level.

Sources:

Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly, 2010.

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.