As I progress more in my CS studies, I’m starting to move beyond learning how to write the code for a project to how the project should be designed overall. In fact, this is one of the main purposes of two of my current CS classes. This has lead me to learning about TDD, or Test Driven Development. I’ve come across a fantastic article by Andrea Koutifaris which outlines the concept well called Test Driven Development: what it is, and what it is not.

In this article, I’ve learned the purpose of writing test driven code and what the plan for doing it should be. In TDD, tests come first in the process while writing production code comes second. This is in order to almost put oneself in a user’s shoes. If I myself in the user, what do I want my code to do? This is where the tests come in. Once the goals are clear and defined, the production code can be written.

The rules for TDD can be broken down to two essential parts:

• “Write only enough of a unit test to fail”
• “Write only enough production code to make the failing unit test pass”

Tests must be written to be very specific and achieve the ultimate application goals. Analysis of your tests can help you determine a method to writing your production code. They often not only outline what need to be achieved, but how it needs to be achieved.

The next part of TDD would be writing production code. As outlined before, the second essential rule of TDD is to “Write only enough production code to make the failing test unit pass.” Had production code been written first, output may not match user goals and unnecessary code may be written, which comes with its own set of problems. The focus is on writing clean code and limiting the amount which you write.

The last part of TDD would be the “refractor phase.” This is where code can be changed to be better, but what is stressed here is removing all duplicate code and consolidating.

The result of TDD should be efficient, clean code which serves its purpose. Although it can seem long-winded and like extra work, it’s mostly just inverting the process which we usually work by, so once the process is learned and practiced, it can help with writing better code more coherently and more focused on user goals, which is the ultimate goal as a programmer.

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

For this week’s pattern I have chosen “Craft over Art”. It describes of the pattern where you are given a problem and you are solving it for a customer. You can do it the simple and tested way or create a new solution that will let you express yourself as a programming artist and will look nice on the resume. It describes the conundrum of making something simple and useful right away or making something beautiful and complicated and not usable right away.

I have chosen this pattern because I have struggled with it many times before in my professional career. Many times have I been given a problem to solve for a customer and I had to decide to make it the quick and easy way that I already know will work, or should I do it some new, more complex way that can possibly save some time in the long run. The way that the “Apprenticeship Patterns” describes it should be done with a mix of both solutions, make it somewhat easy but tested way but with possible improvements. I think this is a good approach but there is a catch to it in my opinion, what is acceptable to the customer? Can they wait for a different, nicer way or quick, not totally efficient way will suffice? I think in the moments like that it is up to a Project Manager or the customer to decide and anybody working on this should act accordingly.

We as programmers and developers are in the end a service providers, unless we work for ourselves and do not have any hard deadlines, we need to stick to timelines and or project deadlines. What works and is tested very often is the right solution because time spent on implementing new solution can be something that ultimately may cause a project to fail and nobody wants that. The book also says that we as craftsmen need to provide at leas a minimal level of quality, and I think that if something is well defined and tested and works has that kind of quality. Why go for a new fancy way that might now work 100% of the time, or it requires a lot of time to be understood by somebody else. My boss likes to remind me that “if it is not broken do not fix it, because you will only cause more headaches to yourself and somebody who will work with my code later”.

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

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.