Author Archives: Seth Boudreau

Refactoring Code

When looking for some ideas with what to write about for this blog post, I settled in on refactoring code. For starters I know what it is and why we do it, but I wanted to go more in depth by looking at other resources and what they have to say about it. One of the first sources I came across was a blog post called “How to create a culture of continuously refactoring code?” by Stas Wishnevetsky. This post from Medium revealed something that for some reasons wasn’t so obvious to me and this was that refactoring isn’t a one and done kind of thing. Instead, it is more of a routine and should be done as one to keep code maintained properly and to make sure it remains easy to use.

The first thing that really struck me when reading this article was talking about code like it is something physical and biological. This comparison was made to show how code can “decay” and “rot”. While the code itself doesn’t break down and fall apart with time, there are multiple reasons that make it seem like it does. These reasons include: coding abilities improving over time, business needs and scale fluctuating, and deliberate tech debt. The article then goes on to explain why we should refactor and the end goal of maintaining stability and creating improvement.

I guess I have never had the need to deal with refactoring my code since most the time I program one time assignments and never had the need to upkeep some kind of program. I have, however experience my abilities improving while creating a project and have had some parts be sloppy while later improvements are better done. I suppose I should have gone back and refactored those early parts but the bottom line is that I’ve never had the need to. I would also run into problems trying to make small changes which would be risky in my program. This is one of the many pains explained in the article I read and makes lots of sense.

I know going forward in my career refactoring will become very prominent in my work and understanding it more now makes me feel better about it. This also really shows the amount of effort that is put into big programs we use on a day to day basis. Starting the practice of constantly and consistently refactoring my code, even simple projects, will be super beneficial for me going forward.

From the blog CS@Worcester – Works for Me by Seth Boudreau and used with permission of the author. All other rights reserved by the author.

The Importance of Keeping Code Clean.

After reviewing its meaning and apply the practice in my class, I wanted to search for a good source on clean code principles and some more reasons why it is important. i came across and read an article from the Codacy blog called “What is Clean Code? A Guide to Principles and Best Practices.” This article really went into depth on what it means to have your code be clean and have it makes to not only you, but other people as well. The link to the original post is right here: https://blog.codacy.com/what-is-clean-code

One of the first things this blog states is “writing code is like giving a speech. If you use too many big words, you confuse your audience. Define every word, and you end up putting your audience to sleep.” This very starting statement is what drew me to this post. Thinking about it like this makes so much sense. I believe I am pretty decent at public speaking myself so relating code it really helps define clean code to me. This post contains nine different methods on how to do this such as following code-writing standards and refactoring continuously. The article also explains how clean code helps development teams: teamwork is way easier, debugging becomes more straightforward, and overall it helps prevent many mistakes.

In class we’ve gone over many concepts this post explains, such as DRY(don’ repeat yourself), using comments sparingly, and writing short, straight forward functions. The most backwards concept for me is the comments. In past classes many professors have told me to write lots of comments explaining what certain things do. Now I’m being told to try not to use any? It does make sense, focus on making your code readable so you don’t need any comments.

Going forward for myself, making code simply and understandable will be a main focus for me. Keeping things simple and understandable makes way more sense than making code I need comments in. Another big thing for me is eliminating repetition. Using functions and calls instead of writing the same code over and over again will one hundred percent make my computer science life way easier and save me tons of time as well. I’ve only just started writing code in teams so I’ve only ever written code for my professors or just for myself. I know that keeping this readable will prevent meetings with teammates and hours explaining what the code I’ve created does.

From the blog CS@Worcester – Works for Me by Seth Boudreau and used with permission of the author. All other rights reserved by the author.

Behavioral Design Patterns

Design patterns provide many benefits when it comes to coding and software development. They are essentially blueprints to help guide and solve problems through the process of designing software. While there are three types of design patterns, the one I will be focusing on here is behavioral patterns. Behavioral design patterns mostly focus on the assignment of responsibilities between objects and help with communications between those objects.

There are many different types of behavioral design patterns. Some of these patterns include:

  • Chain pf Responsibility
  • Command
  • Interpreter
  • Mediator
  • Memento
  • Observer
  • State
  • Strategy
  • Template Method
  • Visitor

All of these of different uses along with different pros and cons. For example, command patterns turns request into stand-alone objects called a command. This pattern allows you to capture each component of a request allowing the undo and redo of operations. However, this may cause overcomplications of code because of the layer between senders and receivers. Design patterns are easily customizable to help you approach any problem and provide solutions to many problems you may be having within development.

We’ve begun to touch on design patterns within class using UML diagrams and showing different ways to solve problems. We used the example of a duck class and different types of ducks. More duck types were added that were unusual types of ducks that had different behavior types. We used a couple different methods to help make the program work including overriding, interfaces, and behavior types. Each of these solutions had different pros and cons depending on what the user wanted out of the program.

All-in-all, each different type of design pattern has their own uses and downfalls. When working with design patterns, understand what a client or users want out of a program is key to really determining what design pattern to actually use.

From the blog CS@Worcester – Works for Me by Seth Boudreau and used with permission of the author. All other rights reserved by the author.

CS Introduction

My name is Seth Boudreau and I am a computer science student attending Worcester State University. I am going into my fourth year now as a student here and I am mainly making this blog to go along with my studies. Most of the information that I will type here will be for my two courses this semester: CS-343 and CS-348 and topics will vary based on information within the two courses.

From the blog CS@Worcester – Works for Me by Seth Boudreau and used with permission of the author. All other rights reserved by the author.