Refactoring Code

Refactoring is an important process when maintaining code bases. The goal of refactoring is to change the implementation, definition, and/or the structure of the code without changing pre-existing functionality of the application. Refactoring allows for better extensibility, maintainability, and readability. Refactoring usually results in smaller and simpler code bases, allowing new functionality easier to implement.

When to refactor?

Because refactoring results in simpler code bases, refactoring should be done before adding new features. Working with clean code after refactoring makes the process of adding new functionality easier. For example, if the code base is not extensible, then adding new functionality might break the code leading to more work to fix the problem. Refactoring should also be done before code reviews or before addressing bugs.

What code needs refactoring?

Code smells can be defined as structures in the code that indicate violations of fundamental design principles and negatively impact design quality. Code smells can be used to identify what needs to be refactored. There are over 70 refactoring techniques that help identify problems and provide a known solution. Some techniques are the Extract Method, Replacing Temp with Query, and Encapsulation of a Field.

Refactoring techniques

Extract Method

The Extract Method can be used when code can be grouped together. For example, there is a class called ‘Student’ that has two print statements that prints student details such as name and year. Refactoring would include grouping the two print statements together into its own function. This is helpful because if you wanted to add more details to be printed, you only have to add one line to the function.

Replace Temp with Query

Temp refers to a temporary variable that holds a value of an expression to be used later in the code. This technique replaces the temp variable with a query method that returns the result of an expression. For example, there is a variable where ‘basePrice = quantity * costPerItem’. The variable can be represented as a new method called ‘basePrice()’ that returns the expression, ‘quantity * costPerItem’. If the temp variable is used among multiple classes, having a common method would more manageable.

Encapsulate Field

Encapsulating a field involves using methods that read and write data rather than accessing data directly. When accessing variables directly, they are often set to public which allows the data to be modified without a way to validate the change. Getter and Setter methods should be used to access class variables instead because the access level for the variables can be set to private, meaning the data itself cannot be accessed unless using the access methods. Using access methods provides a way to validate changes.

Reflection

This resource was used because it was clear and concise, making the content easy to understand. The article also included code examples of the techniques which improved comprehension. Before reading, I was unaware of some of the techniques listed which will be helpful when refactoring in the future.

Resources:

https://www.geeksforgeeks.org/refactoring-introduction-and-its-techniques/#

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

Ever struggle to read another developer’s code? Code should be easy to follow along with, especially for a reader entirely new to the codebase. However, sometimes developers write “spaghetti code”, with random variables or methods mixed together in a non-understandable manner. 

Gary Espinosa of Reflectoring.io believes that clean code is the best code, and it’s super important for companies and coworkers. He lists suggestions such as variable names being descriptive, methods shortened, code broken up, etc. Let’s dive into what he suggests.

Espinosa discusses the huge importance of clean code, and how it can make or break a codebase. Not only is code the flesh and blood of a program, but it is also a form of communication between collaborating developers. It helps enable easy understanding of code and editability without errors. Companies who need to ensure their code is clean often spend time and resources just making it easy to comprehend.

Clean code should be readable; this involves grouping similar functions and classes together, similar variables, etc. The document should flow like an “engaging narrative from top to bottom” (Espinosa). If possible, one idea per line and one action per statement is key.

You should also be able to keep your code consistent. There must be a standard for writing code, variables, and methods. Examples of this would be using camelCase for all your variable and method names, using specific indentation rules, and more. A unifying language reduces differences.

One should strive for simplicity, but with descriptive language as well. Variables, methods, and classes should have meaningful names that describe the point of themselves easily. For example, you shouldn’t use a name like “x1” or “yY” as they don’t provide the reader any insight as to what they’re for.  

I selected this resource because it lines up with what we’re currently learning, and it is a key importance to being a software developer in the industry. If you want to have your pull requests approved, write clean, understandable code. This topic intrigued me because it’s quite simple but I wasn’t sure if there were any specific industry standards for clean code. There are definitely certain uniforms industry-wide, but I’m sure that it depends from company to company.

Espinosa’s article was informative, and explained what’s important and why about clean code. It’s useful to those new to programming, or those who are experienced in coding but just entering the professional industry.

I learned how important clean code actually is, not only to the programmer but to their coworkers and the company as a whole. Alongside this, the article taught me how to effectively organize and write code in a clean and understandable manner. This led to an increase in my confidence in my ability to clean up my code. I want to apply this knowledge to my future jobs and perhaps go back and clean up my old projects to make them easier to comprehend.

Article: https://reflectoring.io/clean-code/

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.

I’ve taken programming classes for over five years, however, just programming is not my end goal. My goal has been to get into the field of game development. 

Classes that tackle game development are rather rare and aren’t offered at most schools, so I haven’t had the opportunity to learn in a classroom environment. This means that my goal depends on my drive to learn game development in my own time. After looking into what makes a game, specifically the technical aspects of it, I found that I have much to learn. 

Development of a game can be divided into five general sections: the engine, programming, visuals, audio, and testing.

Engines are software platforms that provide “the core functionalities and features for developing and running games.” The most popular game engines today, such as Unreal Engine and Unity, are extremely versatile and allow the whole or most of the game development process to be done in that platform alone. 

Any game, at its core, is a bunch of code. And while you can develop games without programming knowledge, it becomes very difficult at the higher, more professional levels. Programming language is usually up to user preference, although some tools may require specific languages.

Visuals and audio are rather similar in the fact that both require great creativity and are crucial to games today. Any model, texture, sound effect, and music are created from scratch or borrowed from some library. Software for both categories are typically used by artists of all kinds; music producers, artists, graphic designers, and such.

Finally, testing is the “last” process of developing the game. This could be seen as the verification and maintenance steps of software development. Making sure that there are no bugs and that every other section is working properly is crucial to a better user experience.

That’s a lot of things to do in order to create a game. So many processes, so many programs and tools to learn, and so many skills I need to learn. Learning a tool is one thing, mastering one takes so much time and effort. It makes me think about how I want to tackle my goal, do I focus on one section of game development? Do I learn a decent bit of every section? I have no clue.

It feels like the path to achieve what I want becomes longer and longer. Procrastination, poor time management, and lack of dedication only worsen that. 

If you want to achieve things, you have to take the first steps towards them. I want to land a career in game development and in order to do so, I need to learn. In my free time, I will spend some of it learning online and tinker around with free game development tools until I feel confident in my ability. I could then develop my own game and take those next steps toward my goal.

https://www.linkedin.com/advice/0/which-technologies-tools-do-you-use-game-development#:~:text=Some%20of%20the%20testing%20tools,analytics%20to%20improve%20your%20game.

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

A Scrum Sprint is an event that allows a scrum team to work towards a goal in a time-boxed event that is known as a Sprint. In my class we have been talking a lot about Sprints as well as all of the different roles that each of the team members may be. On top of that, we discussed what each role does and even had a mock Sprint in order to see what they are like. I think that Sprints are really helpful in order to help get work done, and that it works a lot better with less people as long as you trust that they will get their work done successfully. As a computer science major, I feel like I will take place in a Sprint at least one time throughout my career, so I enjoyed having a mock in order to feel what it is like. However, since the mock was only one day, we didn’t get to experience the different roles in a team. But while researching, I came across a website called Atlassian which I think does a really good job at explaining all of the different steps in a Sprint, as well as what each of the roles in a Sprint team does and how they help achieve the Sprint goal.

There are three major roles in a Scrum Team. These roles are developers, the product owner, and the scrum master. In my opinion, developers are the most crucial role in a Scrum Team. Developers are the ones that do the actual work in the Sprint allowing the team to get closer to the Sprint Goal. They do things such as organize, design, test, and deliver the software. Basically, they are the workers that make the develop the software and make sure it does what it is supposed to. One of the other major roles is known as the product owner. The product owner is the member of the Scrum Team that interacts and communicates with the customer. They find out what the customer is looking for in the product and then relays it to the rest of the team, which results is finding out the product goal. According to Atlassian, “Since agile teams are, by design, flexible and responsive, it is the responsibility of the product owner to ensure that they are delivering the most value. The business is represented by the product owner who tells the development what is important to deliver.” This further shows that the product owner needs to be a trustworthy person and good at communicating with others, otherwise the Sprint could fail before it even begins. The final major role in a Scrum Team is known as the scrum master. The scrum master is the glue of the group. This role helps out the other two by helping the product owner define value, while also helping the developers deliver the value that was promised to the customer. The scrum master is like the leader of the group, helping where they can while also making sure that the work gets done on time without error.

Synopsis: https://www.atlassian.com/agile/scrum/roles

From the blog CS@Worcester – One pixel at a time by gizmo10203 and used with permission of the author. All other rights reserved by the author.

The blog post I selected this week is an article by Sanura Hettiarachchi called “10 Clean Coding Practices”. I chose this article with the homework and the expected lectures coming up this week on coding practices. Prior to reading the article I understand effectively using white space, making comments, and declaring meaningful variable names are practices often recommended. When reading the blog, the article goes through each of practices mentioned in detail as well as other tips. When writing variable names, I often have a hard time making meaningful variable names for long declarations. In the article it provides good examples of condensing these variable names for example, changing

“Person [] peopleFromIndiaWhoCanSpeakFrench;” can be condensed to “indiansSpeakingFrench”. The article also provides bad coding practices with variable names that many without understanding of clean coding may not follow.

In addition the article talks about following correct name conventions corresponding to different coding languages. The example brought up was someone in C# would Pascal Case while someone in Java would use CamelCase and it is important to research practices for a specific language to keep documentation clean.

When writings methods, the article suggests method names that effectively describe its uses but something that stuck out to me when describing practices for methods were keeping parameters to a minimum of three. Often in my practices in Java, I use alot of parameters in my methods which I will not keep into account.

Also described that I found very helpful is where to declare variables, Sanura recommends declaring variables at their point of use instead of at the top of a method so that you don’t have to scroll back and forth to understand the code.

Another really good practice I saw in the article is reducing numbers which can be simplified to a constant variable.

Other practices mentioned include not to leave dead code/commented code, minimizing extensive nested conditions, try not to implement long functions, avoid code duplication.

When reflecting on this blog on it’s use of the course as well as in my career, I can see these coding practices being very useful and something I can always use. In addition, I am expecting to see some of these practices in the upcoming lecture this Tuesday and Thursday coming up. With the project on Markdown to HTML I can see the importance of following clean coding practices especially while working in a group with others to ensure everyone is on the same page.

https://medium.com/swlh/10-clean-coding-practices-e37ac283184d

From the blog CS@Worcester – Anthony Duong CS Blog by anthony duong and used with permission of the author. All other rights reserved by the author.

Since I am reading the way that I am while reading, I find myself not knowing what chapter I’m on unless I actively decide to take a look. After finally looking there was an entire chapter dedicated to an accurate self-assessment, the chapter with the pattern entitled “Be the Worst”. The pattern describes surrounding yourself with people who are much better than you are in efforts to improve one’s own abilities. Eventually you end up progressing to a point where you end up as equals with your team. I was then led to consider the team in which I would “take” on this adventure and my role in a team setting. I feel like this chapter allows for a good moment to reflect on your own career in relationship to others. You can’t accurately assess yourself without assessing how you are around other people. Each person on a team provides their own level of experience that can be brought to the table to progress not only the work but the team as well. 

The problem that this pattern resolves is the problem that your “rate of learning has leveled off”.  Knowing this I wish that I had recognized that this might be a problem that I was facing sooner. I think I had come to a point where I could have only taught myself so much that I needed to look to others in a way that would allow me to improve myself in the same way that I described previously. As much as I am often aggravated by cultural norms, I should see that I too am influenced by them. The cultural norm at play is the encouragement of attaining a position of superiority as fast as you can. It has influenced in a way that may have stunted my growth a bit and could have potentially led me towards something a bit more selfish instead of a more noble pursuit such as mastery.

After learning of this pattern, I think I will work in a more self-aware way. Perhaps in a way that is not so clouded by ego but more so driven by the pursuit of mastery that many others alike are also on.

From the blog CS@Worcester – Sovibol's Glass Case by Sovibol Keo and used with permission of the author. All other rights reserved by the author.

Hello and welcome back to another week of my blog. This week, I looked through chapter 5 of the book Apprenticeship Patterns by Dave Hoover named “Perpetual Learning.” I was quite interested in the apprenticeship pattern called “Reflect as you work” once I read it. This pattern talks about how important it is to reflect on your own work and what you have learned in order to improve and progress as a computer science apprentice. All computer science apprentices should plan for a time to regularly review their work and see what areas they can improve in. It is also important to see what you accomplished and identify where you succeeded. You should always cherish those successes. “Reflect as you work” recommends you as an aspiring computer science major to draw a personal map for your own working habits and focus on the habits that have not changed in a while. Figure out if changing one habit would make you more productive and adopt that change.

To apply “Reflect as you work” to myself, I am going to make an analogy to playing video games again. No matter what video game I play, I always reflect on my actions, both when I succeed and fail. If one strategy fails, then I look back and try to identify points of failure and see how I can correct those mistakes. If my strategy succeeds, I celebrate that I’ve won (mentally in my head) and then look back and see if I can make the strategy better or make it more efficient. This is just a habit I’ve developed over years and years of playing video games. The same can be applied to being a software apprentice. If I fail to write working code, then I will try to identify the errors and try to correct them. If the code does work, then I will analyze it to see where it can be more efficient. In the future, I will always reflect as I work. As an example, look at this code:

int count;

count = 0;

while (count < 3){

System.out.println(count);

count = count + 1;

}

This code can be condensed down into:

int count = 0;

while (count < 3) {

    System.out.println(count++);

}

Which can be further condensed down to: 

for (int count = 0; count < 3; count++) {

    System.out.println(count);

}

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and welcome back to another week of my blog. This week, I looked through chapter 5 of the book Apprenticeship Patterns by Dave Hoover named “Perpetual Learning.” I was quite interested in the apprenticeship pattern called “Reflect as you work” once I read it. This pattern talks about how important it is to reflect on your own work and what you have learned in order to improve and progress as a computer science apprentice. All computer science apprentices should plan for a time to regularly review their work and see what areas they can improve in. It is also important to see what you accomplished and identify where you succeeded. You should always cherish those successes. “Reflect as you work” recommends you as an aspiring computer science major to draw a personal map for your own working habits and focus on the habits that have not changed in a while. Figure out if changing one habit would make you more productive and adopt that change.

To apply “Reflect as you work” to myself, I am going to make an analogy to playing video games again. No matter what video game I play, I always reflect on my actions, both when I succeed and fail. If one strategy fails, then I look back and try to identify points of failure and see how I can correct those mistakes. If my strategy succeeds, I celebrate that I’ve won (mentally in my head) and then look back and see if I can make the strategy better or make it more efficient. This is just a habit I’ve developed over years and years of playing video games. The same can be applied to being a software apprentice. If I fail to write working code, then I will try to identify the errors and try to correct them. If the code does work, then I will analyze it to see where it can be more efficient. In the future, I will always reflect as I work. As an example, look at this code:

int count;

count = 0;

while (count < 3){

System.out.println(count);

count = count + 1;

}

This code can be condensed down into:

int count = 0;

while (count < 3) {

    System.out.println(count++);

}

Which can be further condensed down to: 

for (int count = 0; count < 3; count++) {

    System.out.println(count);

}

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and welcome back to another week of my blog. This week, I looked through chapter 5 of the book Apprenticeship Patterns by Dave Hoover named “Perpetual Learning.” I was quite interested in the apprenticeship pattern called “Reflect as you work” once I read it. This pattern talks about how important it is to reflect on your own work and what you have learned in order to improve and progress as a computer science apprentice. All computer science apprentices should plan for a time to regularly review their work and see what areas they can improve in. It is also important to see what you accomplished and identify where you succeeded. You should always cherish those successes. “Reflect as you work” recommends you as an aspiring computer science major to draw a personal map for your own working habits and focus on the habits that have not changed in a while. Figure out if changing one habit would make you more productive and adopt that change.

To apply “Reflect as you work” to myself, I am going to make an analogy to playing video games again. No matter what video game I play, I always reflect on my actions, both when I succeed and fail. If one strategy fails, then I look back and try to identify points of failure and see how I can correct those mistakes. If my strategy succeeds, I celebrate that I’ve won (mentally in my head) and then look back and see if I can make the strategy better or make it more efficient. This is just a habit I’ve developed over years and years of playing video games. The same can be applied to being a software apprentice. If I fail to write working code, then I will try to identify the errors and try to correct them. If the code does work, then I will analyze it to see where it can be more efficient. In the future, I will always reflect as I work. As an example, look at this code:

int count;

count = 0;

while (count < 3){

System.out.println(count);

count = count + 1;

}

This code can be condensed down into:

int count = 0;

while (count < 3) {

    System.out.println(count++);

}

Which can be further condensed down to: 

for (int count = 0; count < 3; count++) {

    System.out.println(count);

}

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and welcome back to another week of my blog. This week, I looked through chapter 5 of the book Apprenticeship Patterns by Dave Hoover named “Perpetual Learning.” I was quite interested in the apprenticeship pattern called “Reflect as you work” once I read it. This pattern talks about how important it is to reflect on your own work and what you have learned in order to improve and progress as a computer science apprentice. All computer science apprentices should plan for a time to regularly review their work and see what areas they can improve in. It is also important to see what you accomplished and identify where you succeeded. You should always cherish those successes. “Reflect as you work” recommends you as an aspiring computer science major to draw a personal map for your own working habits and focus on the habits that have not changed in a while. Figure out if changing one habit would make you more productive and adopt that change.

To apply “Reflect as you work” to myself, I am going to make an analogy to playing video games again. No matter what video game I play, I always reflect on my actions, both when I succeed and fail. If one strategy fails, then I look back and try to identify points of failure and see how I can correct those mistakes. If my strategy succeeds, I celebrate that I’ve won (mentally in my head) and then look back and see if I can make the strategy better or make it more efficient. This is just a habit I’ve developed over years and years of playing video games. The same can be applied to being a software apprentice. If I fail to write working code, then I will try to identify the errors and try to correct them. If the code does work, then I will analyze it to see where it can be more efficient. In the future, I will always reflect as I work. As an example, look at this code:

int count;

count = 0;

while (count < 3){

System.out.println(count);

count = count + 1;

}

This code can be condensed down into:

int count = 0;

while (count < 3) {

    System.out.println(count++);

}

Which can be further condensed down to: 

for (int count = 0; count < 3; count++) {

    System.out.println(count);

}

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.