As a beginner coder, I’m always learning new things about the software development world. This week, I read an article that made me think differently about “clean code,” something I thought was the ultimate goal for every developer.

The article, “Goodbye, Clean Code” by Dan Abramov, explained that while clean code is important, it’s not the only thing that matters. It’s like a tool we use to make code easy to understand, fix, and test. But sometimes, focusing too much on making code perfectly clean can actually slow us down.

I can totally relate to this! When I first started coding, I was obsessed with writing “perfect” code. I spent hours making sure every line was exactly right, even if it meant the code didn’t work as well. This approach didn’t really help me learn or be productive.

Instead of aiming for “cleanliness” all the time, Abramov suggests that we should focus on writing code that solves the problem we’re working on. This code should be clear, easy to understand, and easy to change if we need to. This way, we can learn more about coding and be more productive.

One of the things I really liked about the article was the idea of “incidental duplication.” This means that it’s okay for there to be some repeated code, especially when we’re first starting out. Of course, we don’t want to have a lot of repeated code, but a little bit is okay.

The article also talks about how important it is to work well with others when you’re coding. This is because we often share code with other people, and if we change someone else’s code without talking to them first, it can cause problems. This reminded me that coding is a team effort, and we need to communicate well and respect each other’s work.

Overall, “Goodbye, Clean Code” was a great read for me. It helped me understand that clean code is important, but it’s not the only thing that matters. It’s more important to write code that works and that we can understand and change easily. This is something I’ll keep in mind as I continue to learn and grow as a developer.

Link: Goodbye, Clean Code: https://overreacted.io/goodbye-clean-code/: https://overreacted.io/goodbye-clean-code/

From the blog CS@Worcester – Site Title by Iman Kondakciu and used with permission of the author. All other rights reserved by the author.

During this last week of class, I have been learning about clean code and how to write it as well as edit my previously written code in order to follow these guidelines. Clean code is exactly what it sounds like. It is code that is easy to read and understand, and isn’t too complicated or formatted poorly. Learning how to write clean code is going to be vital in working in the computer science industry. Everyone in this industry works with another programmer at some point in time, so having clean code will make their life and your life easier. While researching more about how to write clean code, I found a website called freecodecamp that does a great job explaining attributes of clean code while also giving examples. On top of explaining how to do it, it also has a section explaining why you should care about writing clean code. Personally, this really helped me understand why clean code is needed and why it is very important to understand.

The three main aspects of clean code are effectiveness, efficiency, and simplicity. Effectiveness is pretty self-explanatory. It means that the program should be able to solve the problem that it was designed to solve, otherwise it isn’t helpful. Once the program is considered to be effective, we need to also make sure that it is efficient. If a program solves a simple addition problem, but takes 36 hours to run, the program isn’t efficient as there are much faster and more simple solutions. If your program is post effective and efficient, then you also need to make sure that it has simplicity. While most sites will have different qualifications for simplicity, I think freecodecamp has most of them. Freecodecamp wants everyone that is trying to write clean code to ask themselves these questions about the code:

1. “Can you easily understand what the program does at each line?
2. Do functions and variables have names that clearly represent their responsibilities?
3. Is the code indented correctly and spaced with the same format all along the codebase?
4. Is there any documentation available for the code? Are comments used to explain complex parts of the program?
5. How quick can you identify in which part of the codebase are certain features of the program? Can you delete/add new features without the need of modifying many other parts of the code?
6. Does the code follow a modular approach, with different features separated in components?
7. Is code reused when possible?
8. Are the same architecture, design, and implementation decisions followed equally all along the codebase?”

While there are a ton of other ways that you can improve your code, these are the 3 main factors. Without these 3 foundational factors, you wouldn’t be able to write clean code which would make life harder for you and for everyone that reads your code.

Synopsis: https://www.freecodecamp.org/news/how-to-write-clean-code/#what-does-it-mean-to-write-clean-code-and-why-should-i-care

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.

Software Process Model

A software process model is an abstract framework that gives steps on ways to plan software development processes and how they can be organized and executed. There are different types of software process models but all include some form of:

• Specification – Defining what the system should do
• Design – Defining the structure of the system
• Implementation – Implementing the system
• Validation – Ensuring the system works as intended and that the system is what the customer wants
• Maintenance – Changing, modifying, updating to keep up with the customer needs/fixing bugs

Types of software process models

There are many different types of models that are available to be used by organizations. Some allow organizations to use the model directly while others are more flexible, allowing organizations to create custom steps that are more specific towards their needs.

Software processes are typically specified using Software Development Life Cycle (SDLC) models. These models specify the different steps of the software development process and the order they are executed. 

Waterfall Model

The waterfall model breaks down software process activities into sequential phases. Each phase depends on the outcomes of the phases before and cannot be started until all phases prior have been completed. Each phase corresponds to a software process. For example, the first phase would be specification/requirements analysis because developers cannot create a system without knowing its intended function. Once that step is completed, then the next phase can be started and so on.

V Model

The V model is similar to the waterfall model where steps are followed in a sequential order. Initially after each step, the model progresses downwards to move onto the next step. Once the the coding/developing stage is complete, the model then bends upwards to create a V shape. This model highlights the relationships between each phase of the development life cycle and its corresponding phase of testing. The downward process is called the Verification Phase, while the upward process of the model is called the Validation Phase which are completed by developers and testers, respectively.

Agile

Unlike the two previous models, Agile is not a model with specific steps to follow. Rather Agile is a broader term for a set of methods and practices that encompasses values from the Agile Manifesto. These values helps teams to react quickly to any unforeseen changes, while reducing risk. The software development approach to Agile is usually rapid and small cycles. Doing this results in more frequent releases with each building upon the previous releases. Agile can be implemented by using frameworks such as Scrum and Kanban.

Reflection

I chose this resource because before simply listing different types of models, it clearly defined what the software processes are. This ensures a foundation is established. Although only three of the models in the article are listed above, there are several more models which I found interesting as I was unfamiliar with some of them. Because organizations use different models, being aware of the more popular ones will be beneficial in the future.

Resources:

https://www.visual-paradigm.com/guide/software-development-process/what-is-a-software-process-model/

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.

For this week, I wanted to talk about the creation of comic books, and how it relates to Software Process Management and Software Design. Within the article linked below, it describes the process of how a comic is created, and the steps needed to reach a final project. I specifically wanted to look more into this as the process is quite similar to how software is developed.

The second step is writing a plot, which is much like creating a backlog for your process, planning the beginning, middle and end of the process.

Then, its off to creating the art, which is a multi-step process, which is much like creating the code. For the artists, they need to sketch, then line, then ink and even maybe color the panels of the comic, which parallels how code will need a framework, then main code, supplemental code, and comments to build on top of each other. This process isn’t always in a predetermined order, and can vary from project to project.

And then theres editing and review. Everyone looks over the draft of the work they’ve made, and then tweaks whatever needs adjustments as needed. This process might lead to the recreation of art or code, depending on which process we’re discussing. Once a review gets a pass, they’re ready to finalize and move onto the last step, which is…

Publishing and marketing! Once you’re done, you send the finished copy of the work to consumers to receive, and perhaps you’ll even advertise it, if its not well-known. This can include things like advertisements, sponsorships, and even word of mouth.

The parallels of the dynamics in which these processes interest me a ton as someone whos also minoring in art, and wants to go into a digital design or digital-art focused field, whether it be game design or webcomics. It’s kinda awesome to see that theres a sort of venn diagram between my two passions, and that they can intersect.

EDIT: I meant to post this earlier before, but I had connectivity issues and it never posted when I thought it did. I only realized because a friend wanted to read my blog, haha. To clarify, this blog is intended for Week-12, and for both classes, not 13, it just was posted late due to issues. My apologies for this inconvenience.

From the blog CS@Worcester – You're Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Now I know what everyone is thinking, ‘You lied in your last blog.’ Yes, I did, and guess what? This is my blog, so that’s okay. You see, I could not pass up on this beautiful opportunity to kill two birds with one stone. As you may remember from my last blog, I complained about how hard it was to come up with topic ideas for CS-343. Well, well, if by some miracle I read that if topics intertwine between your two classes (343/348), we could count one blog for both classes (shoutout Prof Wurst :)).

Enough yapping, clean code time. I believe it was only a year ago when I first started taking coding seriously, and I can recall how awful my code looked. It worked… but if you wanted to debug, you had to pray before opening it. We are talking about one-function programs, with no formatting and variable names that would drive any professor mad. I quickly realized how important clean code was after watching some YouTube videos and seeing how much easier debugging was if your code had a good flow and was properly formatted. This is where I stopped when it came to clean code, unknowing that there were 100+ other factors that all combine to make clean code.

While exploring LinkedIn, I came across this article by Oleabhiele Donald titled ‘Benefits of Clean Code In Your Application Development.’ I gave this a full read and was really surprised about all the little ways I could make my code even better than it already was. Now I 1000% recommend giving it a full read, but I’m going to talk about some of the techniques that were mentioned that I didn’t know at the time or found most beneficial to me.

Use comments sparingly:

• Limit the use of comments to when necessary, ensuring clarity and conciseness. Overusing comments can clutter the code, making it harder to read. Aim for clear and concise comments that add value.

Write small, focused methods:

• Break down larger methods into smaller, focused ones, each with a single responsibility. This approach improves code understanding and facilitates easier modification.

Use unit testing:

• Incorporate unit testing practices to verify code functionality and prevent the introduction of errors. Well-designed unit tests contribute to clean and reliable code.

Avoid duplication:

• Identify and eliminate code duplication by utilizing methods, classes, and inheritance. Reducing duplication enhances code maintainability and modifiability.

These techniques stood out to me mostly because they were things I just didn’t think about. I love to keep a list on my desktop notepad that always reminds me of some of the key steps to clean code.

Why Clean Code? This a very simple answer thanks to the article, clean code is important enhances readability, making it easier for developers to understand, maintain, and collaborate on software projects. It also improves efficiency, scalability, and reduces the likelihood of introducing bugs, ultimately leading to more reliable software and a happier programmer.

Source: https://www.linkedin.com/pulse/benefits-clean-code-your-application-development-daniel-donald/

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.