This blog will be following my cs-448 class for this spring 2020 semester.

From the blog cs@worcester – Zac's Blog by zloureiro 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.

Programming was extremely hard for me at first. Once I discovered that programming isn’t just typing code, I spent so much time worrying about getting the perfect design, imagining what could go wrong, and researching alternatives that I rarely actually coded anything, at least for a brief period. While this concern may have taught me a lot in my research, I know better now. There’s a trade-off between time spent designing and time actually making software work.

Likewise, there is a trade-off between creating high-quality software and adding more valuable features, as Martin Fowler discusses in this blog post. Fowler is a software developer and author who has written extensively on the topic of software quality and design. In this blog post, he poses the question “is high quality software worth the cost?”.

Short answer: yes it is. To go further, Fowler believes that the question really doesn’t apply to software because high quality software is cheaper. He also makes the distinction between internal and external quality in software. For example, users notice a quality user interface, but have no idea which design patterns were used.

Internal quality is the goal of quality assurance and testing, and while it isn’t directly visible to the user, it makes it so much easier to provide a user with additional features by adding to an existing code base. In my last post, I wrote about SOLID and a podcast by Coding Blocks. They discussed how good patterns take a lot more code to write in the beginning, because things are broken up into smaller classes, with more, smaller methods. But as Fowler describes, the initial work more than pays off in the long run when code is easy to read and understand.

Anyone who has learned to program has spent hours looking for a mistake on a small project. These get harder to find as a project grows, especially when there are hidden dependencies among poorly-formatted code. Now imagine you wrote the code 2 years ago. And you can’t even fix it because you’re on vacation, but it’s preventing users from accessing their accounts so your coworker has to. Quality code and tests will drastically improve the chances that the problem is quickly patched and your users are happy. Take it one step further: this problem could have prevented entirely with sufficient testing and more focus on quality.

Most time is spent reading code rather than writing it. Fowler mentions this, but it is also an important theme in Clean Code by Robert C. Martin [1]. If you write quality code now, you can write even more quality code in the future.

[1] Martin, Robert C., et al. Clean Code: a Handbook of Agile Software Craftsmanship. Prentice Hall, 2016.

From the blog CS@Worcester – Inquiries and Queries by ausausdauer and used with permission of the author. All other rights reserved by the author.

At the core of software design must be basic principles. Following basic principles allows us to make sure we are on track with a standard. It creates consistency and makes it easier to maintain our code in the future, because we will know what to expect.

Following a single principle might be easy, but there are many object-oriented design principles. Sometimes, it is quicker to hack a solution together than to think up an elegant solution. These solutions may then be built upon, and the project will slowly stray from its original intent. Gaining the intuition of when and how to apply these principles is necessary to ensure that a project doesn’t become a mess of spaghetti as these quick-fix solutions add up.

“Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.”

– Steve Jobs

Coding Blocks Episode 7 discusses these topics in the context of five of the most important design principles, known as SOLID. This podcast is great and I highly recommend it: it is hosted by professional programmers who discuss and debate the topics of each episode.

Each of these principles likely warrants its own podcast, and one or more blog posts to describe them in detail. Below is a short description of each one.

S: Single Responsibility Principle

• An object should only do one thing.

O: Open Closed Principle

• Code should have the ability to be extended, but it shouldn’t have to be modified.

L: Liskov Substitution Principle

• Replacing an object with one of its subtypes should not break the code.

I: Interface Segregation Principle

• Smaller, more specific interfaces are better. If an interface is too broad, an object may need to implement many methods it doesn’t need.

D: Dependency Inversion Principle

• Within a class, you don’t want to depend on an implementation. Instead, a higher-level class should depend on interfaces, which are implemented by lower-level classes. Don’t have an abstraction relying on an implementation. Have the implementation relying on an abstraction (interfaces).

Conclusion

The biggest takeaway from this podcast episode was that even professional programmers do not follow all of these principles all the time. Some of the concepts are confusing and contradict other principles. Some of them should only be applied when refactoring code after it is working, with the goal of improving your code.

However, when learning these principles, projects should be created with the sole goal of implementing these principles. Mentally solidifying these concepts by focusing on each one and converting it into code will help a developer to predict issues that may come up in the future when implementing production code. Knowing the context of the system, code can be written that mostly follows these principles right off the bat, and improvements can be made later as code is added and the patterns emerge. Most importantly: the foundation will be SOLID.

From the blog CS@Worcester – Inquiries and Queries by ausausdauer and used with permission of the author. All other rights reserved by the author.

          The book describes the “Learn How You Fail” pattern by talking about failure in general throughout a developer’s life. It explains that everyone fails at some point in their life and it shows the potential of growth. The blog continues to say that identifying where an individual specially fails can create better self-knowledge for their habits and behaviors. The main goal of this pattern is to then learn from these habits and behaviors to correct the ones that limit your potential. It brings to light the importance of creating an accurate self-assessment and awareness of weaknesses to find a realistic goal that can be accomplished. The book gives an example for coding where the programmer should try to use a text editor to implement a binary search in any language. Then write the tests for that search and run through it without a compiler manually to find any possible error you have made. You can compile the code after doing this to find any remaining errors that you may not have picked up.

          I found this pattern very interesting and informative in terms of self-understanding and creating reasonable goals. The way the pattern explains how habits and behaviors can become second nature which eventually leads to errors that we make unintendedly was very thought provoking. I enjoyed following the logic behind this and understanding how this can affect me in the long run as a developer if I don’t look for these errors now. This pattern has caused me to value my failures even more by teaching me more about learning from them. I always went with the logic that if I failed, I should simply not make that mistake again. However, this pattern showed me that instead of avoiding mistakes, I should naturally make them and learn from them in detail. This learning experience could provide me with deeper insight on how I will learn in the future and plan for my profession in a much easier light. I don’t disagree with the pattern at all, in fact, I thoroughly enjoyed every part of it. I especially enjoyed the example given using the text editor as a IDE to find mistakes in writing and compiling code.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

When I picked up Apprenticeship Patterns, on Chapter 2, Emptying the Cup, the very first pattern caught my eye when the context and problem they presented seemed to apply to my situation closely. The pattern is “Your first language”, and the authors hit the nail on the head in my case when they explain the case of a budding programmer who only has limited knowledge of one or two programming languages, but the job opportunities demand a high level of technical proficiency.

Their advice is to stick with one language and become fluent in it. The logic is to hone your language skills by solving real world problems, developing code through test driven development, with the guide of experienced programmers.

The authors stress the importance of deciding which language to take on as your first. It makes sense, seen as how that language will be the primary tool we use to solve problems. In my case, it seems clear to me which is the right one. As many of us, my first and most familiar language is Java. Not only that, I am fortunate enough to have an internship opportunity which uses Java and JavaScript. So I have the real world opportunity to hone my knowledge, and access to mentors who are more knowledgeable than myself.

One final piece of advice the authors gave which I will take them up on is to find a community of people who are focusing on the same language and have similar experiences as you. For me right now that is my peers, and it is plain to me the mutual benefits of working with others who are in the same boat.

As much as I feel internal pressure to learn a variety of languages like C++, Python, etc., reading this pattern resonated with me and helped me make an informed decision to focus on what is pragmatic, as opposed to getting caught up in the ocean of possibilities. Since my first professional opportunity is using Java and JavaScript, I will focus on honing my skills in those areas as opposed to spending that time getting a surface level understanding of a different language that I might not immediately use.

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