Once again I was looking through the course topics for my CS-343 Class on Software Construction, Design, and Architecture where I came across refactoring. refactoring is the process of “editing and cleaning up previously written software code without changing the function of the code at all” by Sydney Stone in an article called “Code Refactoring Best Practices: When (and When Not) to Do It“. The technique of Red-Green-Refactor seems to be the most used type of refactoring process and focuses on the three steps of Red or consider what needs to be changed, Green or write enough code to pass the test written, and Refactor/clean up the code. Refactoring is clearly an important part of the software development process, but it is not something that I have used in my own coding experience so far. The continuous cleaning, optimizing of code, and adding of new functionality helps to ensure that the user receives the best experience using that code or program or tool. At the same time refactoring may not be the best solution due to time constraints and if the design or code is not worth refactoring because in some cases it’s much easier to just start from scratch.I have found myself in the hole of attempts to change and fix thing and I’m sure almost all people that code have fallen into this hole because its much more enticing to try to use or change something you already coded instead of starting over. I personally really like the style of Refactoring code and it seems to be more commonly used in things like games, applications, and other user based software.
I can certainly see myself using this technique in the future when working on code or being instructed to do a part of the refactoring process because it looks to be common practice in the field of Computer Science and especially software engineering. I knew that there was a process to updating and refining/adding new functionality to software but was unsure of the name or the actual process that takes place in order to yield the best results. I also had no idea that eclipse had a built-in automated refactoring support which makes me want to learn more about how to achieve this so I can apply it to my own software in the future. Testing also is an important part of refactoring so I can apply this method as I learn more about Software Testing and Quality Assurance which encourages me to learn more about good practices in both fields of Software engineering.

Link to Article referenced: https://www.altexsoft.com/blog/engineering/code-refactoring-best-practices-when-and-when-not-to-do-it/

From the blog CS@Worcester – Tyler Quist’s CS Blog by Tyler Quist and used with permission of the author. All other rights reserved by the author.

While looking at the course topics for my CS-343 class, the topic Law of Demeter caught my attention and I decided to dig deeper into the topic. I found a post by Arun Sasidharan called “Object Oriented Tricks: #2 Law of Demeter” which talks about what the law of Demeter is and how you should implement it into your code/design patterns. The Law of Demeter is basically that you shouldn’t give a single function the ability to know/navigate the entire system. Codes like ” obj.getX().getY().getZ().doSomething() ” has more knowledge of the structure system than it should. I think that it’s important to follow the Law of Demeter because not only does it look simpler to call only one method to solve a problem but it also avoids a possible security risk. If methods are able to be used and connected to figure out the layout of the system, then it makes the job of a hacker that much easier since they can figure out how they want to get to the information they want or to break the system.
The Law of Demeter seems to be a useful rule that helps to protect data and the overall structure of a system. I want to apply this to my own coding since it will simplify code and keep information secure. It seems that this is a difficult rule to apply and has some disadvantages to applying it as well like writing many wrapper methods and creating narrow interfaces. The Law of Demeter certainly fascinated me with how it can be used and why you should use it in your coding. I think that the Law of Demeter can and will be used as I learn more about it because for the most part I choose to take the easier approach in using multiple methods. Now that I know more about the Law of Demeter, I will look to apply it more in my code and find ways to avoid giving objects too much knowledge of the system structure. one thing that helped my understanding into what the Law of Demeter was was the use of the example of cells which was ” Cells don’t ask each other questions, they tell each other what to do”. this helped me to see how the Law of Demeter was applied and what it truly meant since the objects are the cells in this analogy, meaning that you shouldn’t have your objects asking around the system, the objects should be told what to do.

Link to Article Mentioned: https://hackernoon.com/object-oriented-tricks-2-law-of-demeter-4ecc9becad85

From the blog CS@Worcester – Tyler Quist’s CS Blog by Tyler Quist and used with permission of the author. All other rights reserved by the author.

While the title of this blog post doesn’t seem like it has to do with Software development, trust me it does. I was reading a blog post by Arvind Singh Baghel called “Software Design Principles DRY and KISS” which talks about important design principles and how they are violated and good tips on how to achieve these principles. DRY stands for “Do Not Repeat Yourself” which basically means avoid using the same code or iterations of the same code over and over or in different places since it wastes time for the people reading it and the software itself and creates unnecessary complexity. KISS stands for “Keep It Simple Stupid” which in terms of software development means keeping methods small and avoiding complexity. I chose this blog post because it lays of the important principles that keep designs of code simple and easy for later changes or if they are read by another person which is something that I feel I want to work on being better about. Looking back at a lot of my code, I rarely kept my code simple or avoided repeating myself for simplicity and time saving, but that would end up wasting more time later when I would need to go back and make changes or trace my code. The code that I would make would have methods that would use the exact same lines of code with minor changes or no changes at all, which made following the code that much harder since I had to look at each implementation of the same code and see what was slightly different. I would also try to fit as many different things into a single method as possible which would create extremely long methods. When methods would fail test cases these long methods of repeated code would make it much more difficult to figure out where the real issue was and took more time than it would have if I decided to split up the methods and not reuse code throughout the program. Simplicity seems to be a major key in any good design regardless of what you are designing and these rules of DRY and KISS would have saved me a lot of time on projects and coding assignments had I applied them and not tried to take the easy way out. I already have worked on applying this to my current projects and it has made a huge difference in both my experience with coding and the time and energy it takes to complete a project.

Link to blog post mentioned: https://programingthoughts.wordpress.com/2018/04/15/software-design-principles-dry-and-kiss/

From the blog CS@Worcester – Tyler Quist’s CS Blog by Tyler Quist and used with permission of the author. All other rights reserved by the author.

A topic that caught my eye when looking over the syllabus for my CS-343 class was Code Smells, so I decided to delve deeper into the topic. I read a blog post titled “CODE SMELLS THAT ARE FOUND THE MOST” by Ekaterina Novoseltseva, which talks about commonly found design flaws in code and how to address them. Ekaterina goes through a list of those design flaws like the bloater which are code, methods, or classes that are too large or have grown too large making them difficult to work with. Another mentioned design flaw would be the change preventer, which as its name implies prevents change by making the coder change multiple places in order to fix/change one section of code. There are many more examples of code smells that are explained in the blog.
One of the code smells that stood out to me was long methods because for a while that was something I would do while coding and it made my code almost impossible to track and understand, as well as, made it hard to trouble shoot where my issues where when my code did not pass test classes. Having long methods made coding extremely difficult and created more problems than it did good. another code smell that really hit home was duplicate code, even though it is easy for me to just copy and paste the same code into multiple methods, it makes more sense to create a single method that can be used in multiple places. simplification of code is something that I have been working on because it makes coding a lot smoother and easier to adjust and make changes to in the future. The last code smell that really spoke to me was dead code which is code that is not being used. Too many times I find myself writing code that is too complicated or doesn’t work, and then commenting it out or saving it for future changes and usually forgetting about it which makes it all the more confusing for some one reading or looking at my code. learning more about code smells has given me the confidence and knowledge to avoid them in the future and to make simpler and cleaner code. Design of all things is meant to be efficient and useful to both the designer and the user, so to practice and understand good design a person must understand bad design as well.
Link to the Blog Referenced in this post: https://apiumhub.com/tech-blog-barcelona/code-smells/

From the blog CS@Worcester – Tyler Quist’s CS Blog by Tyler Quist and used with permission of the author. All other rights reserved by the author.