Source: http://codermike.com/starting-c4

Getting Started with C4 by Mike Minutillo on Coder Mike is a blog post introducing the C4 Model. The C4 model is a way of allowing users to communicate and describe software architecture. This model is composed like a software system that is made up of containers, that each have components that are then implemented by classes. Lastly, context which is basically a description of the parts of the system or their relationships between each other. These four, context, containers, components, and classes is what makes up C4. Furthermore, Mike goes in-depth in explaining how it helped his situation from starting from a blank white board. By starting with a context diagram, he is able to map out the different problems of their design and revise it for the next version. This process would be repeated until they are satisfied and can continue down the right path.

Tools are developed over time to solve common issues faced in society today, by not utilizing existing tools provided by to us today would be a waste. Learning about UML Diagrams, would eventually lead into learning C4 Model. This model also utilizes UML diagrams in the classes section for its intended use. The idea of being able to clearly represent and describe parts of a software system like the UML diagrams purpose for classes makes this a worthwhile read. The various models within the model such as System context is extremely valuable to me because it allows me to explain how everything pieces together from a higher-level view.

Much like UML diagrams, the author stated that it your initial diagram doesn’t have to be perfect, it’s going to change over time. The value of being able to show, explain, and revise is much better than time spent working out a grandeur solution. Utilizing the different diagrams will grant a much better time spent on projects certainly when there is no clear starting point like Mike pointed out. First starting with Context diagram will explain what things do and their relationships to each other. Then we can go into the container diagram, where you separate important bits into parts like a database or an app. From there I can then start grouping related functions into components which is then accompanied by classes explained using UML diagrams. These four diagrams will provide a nice guide for myself and group members during implementation and provides proper documentation.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

Source: https://blog.codinghorror.com/if-it-isnt-documented-it-doesnt-exist/

“If It Isn’t Documented, It Doesn’t Exist” are probably some words to live by, written by Jeff Atwood. Jeff expresses his thoughts on proper documentation based on his personal experience while working on open source projects. This can be summarized into a single sentence “Good Documentation is hard to find” as stated in the blog. However, he agrees on a couple of key points made by James Bennett who wrote the blog post Choosing a JavaScript Library. These can be summarized to having a proper overview of each section of your project/design, having proper examples of usage when needed, documentation on everything, and your regular comments throughout the code itself. Although it was specifically written for his javascript explanation, I attempted to apply it to regular java coding as well. Ultimately leading up to another great statement “most treat documentation like an afterthought” made by Mr. Bennett.

Truthfully, upon finishing and reviewing my own code for Assignment 1 in my CS-343 class, I realized that documentation or comments within the code is non-existent. Leading up to relearning the importance of proper documentation, as once taught in my CS-140 class. Currently, I can see that it is not a requirement and has not been a big factor in assignments even in other previous CS courses I have taken between CS-140 and CS-343. However, it’s important to remember that a properly documented project can be easily benefit yourself and others in many ways. For example, it can be used to assist in explanations or allow others to understand what is done at a certain point. Also, it can be used to help yourself pick up where you left off after reading up on what you have written. Simply stated as “…if you’re the only one who understands it, it doesn’t do any good” by Nicholas Zakas.

Practicing proper documentation techniques early on will help develop proper skills for determining how much is necessary to document. Too much unnecessary documentation will hurt more than documenting only what is needed, which is a problem I had when I actually applied documentation within projects. This also includes being able to understand when and where to use comments, javadocs, etc. throughout a project. Currently, I do treat documentation like an afterthought, to the point that it isn’t applied. In the future, I hope to apply this skill and use it to my advantage, not only for myself but for others as well.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

Source: https://blog.codinghorror.com/flattening-arrow-code/

Stumbling across this week’s blog post Flattening Arrow Code by Jeff Atwood, I found myself reading about arrow code, which is self-explanatory. Basically, Jeff explains how he deals with Arrow Code, which is considered an Anti-pattern that is deemed a bad practice and should promptly be avoided wherever possible. The main benefit from refactoring is to reduce the cyclomatic complexity value, this value being used to determine how complex a piece of code is. The larger the value, the higher the complexity, the lower the value, the lower complexity. Another would be, from Jeff’s words “…to have code that scrolls vertically a lot… but not so much horizontally.”

When I look at code, I never suspect that there would be distinct patterns that are deemed as a bad practice. By reading about arrow code, I first thought, “Hey, I’ve seen that before” but left with “Oh, that is probably not the way to go about writing code”. In other words, I should probably learn this now. Anti-patterns, although the only one focused on in this blog is the arrow pattern is a great way to help avoid certain practices in the future. Even though, as of right now, I don’t understand most of what he said about converting negative checks into positive checks or decomposing conditional blocks into separate functions. Other things like guard clauses, being a conditional statement at the top of a function that bails out as soon as it can. Which I assume contributes to reducing time spent/resources spent running that function. Also, includes the idea of not sticking to the idea that there should only one exit point at the bottom of the function. Sometimes, it can be possible to exit at a different point rather than the very bottom. These two points, are good information as standalone practices.

Using this simple example, I can see that it is like YAGNI, KISS, Code Smells, etc., which means by understanding or being introduced to the bad practices early on. One, I am able to identify and solve the problems using common strategies already developed and tested. Two, I will be able to avoid putting myself into those situations where I would need to refactor the sections to be easily modifiable and maintainable. Although cyclomatic complexity is mentioned scarcely in the blog post, it reminded me of time complexity in algorithm analysis. Even though they are two different concepts, understanding that aiming for a smaller cyclomatic complexity value should result in a less extensive testing phase for the code. Which should save time, for future reference of course.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

Source: https://blog.codinghorror.com/kiss-and-yagni/

This week’s reading is on KISS and YAGNI by Jeff Atwood on Coding Horror. Jeff touches upon and shows enthusiasm towards effective practices of KISS (Keep it simple, stupid!) and YAGNI (You Aren’t Gonna Need It). He mentions that just because you learned something complex that could be applied to your current project, it doesn’t mean that you should implement it when there is a more simpler option available. That is the idea of KISS. Lastly, he mentions that developers should follow YAGNI to combat the mindset of implementing solutions that you don’t need currently.

These two topics about KISS and YAGNI are very interesting because of how people are usually taught to think but when applied to programming, it doesn’t help but make things worse. Choosing to read up on this blog, allows me to see how more experienced developers feel about those who do not understand or value the two practices. Also, this is related to smelly code as it will help fight against dead code! In this case, I can feel that it is indeed a wise choice to pick-up KISS and YAGNI early on. Although, I have yet to write much programs that needed complex solutions. I do remember situations where my implementations were much longer when compared to other students, which could be a result of lesser understanding upon certain fundamental topics or lack of experience. Example being, the other student’s implementation of a loop for a solution is much shorter but does the same thing as my longer loop. It’s not exactly KISS, but it does show that sometimes things can be done in a simpler way.

Overall, understanding or knowing either practice will help save time when it comes down to getting things done. By knowing YAGNI, I will not implement things I don’t need until it is needed. By polluting the code with unused implementations, it will most likely create complications for later functions when it is used. However, if I don’t need it by then, the time spent creating the implementation for the future would be wasted time and not saved time. Then we have KISS which is rather straightforward, but should be a clear reminder that it’s when you can keep it simple, not always keep it simple. These two concepts will help me keep the code clean, and maintainable to a point where implementing newer features will not be as frustrating as when you work with smelly code.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

The blog that caught my interest this week is Good Programmers Get Off Their Butts by Jeff Atwood on Coding Horror. This post was centered around the author’s experience with UML diagrams and his overall view about its practicality in the field. Jeff finds that spending too much time on the design results in very little time for implementation. Then if there is very little planning, there is also a drag in the time for implementation. Which leads to his overall idea that, even if the design is vague, it is better to write some code than furthering the designing process in UML. His experience with proper designing procedures is a great read for many of us, that have recently learned about UML diagrams.

I chose this blog post because after reviewing countless articles, it seems to conclude that UML diagrams are useful in certain environments/situations and not a definite approach to design. These include being used as documentation or to explain specific code to people. Jeff explains a couple that are concerns of mine. One would be repeatedly updating the UML diagram to keep the design up to date or coming across a large problem in the design during the implementation process and having to scrap the design because of it. I would consider these to be time-consuming tasks and would stall development.

However, his message wasn’t all bleak as he does believe that it is useful from his comment that “Coding without planning is just as futile as coding with too much planning”. This comes back around to having a short design plan, perform the implementation, and then pan out the rest of the design as you go. I do see this as a future tool I could use, as time is a valuable asset. Relying on completing a full UML diagram will show what you need to do in theory, but when it comes down to implementation, not everything will go according to plan. This will result in turning back to the diagram, in attempt to solve the various issues that could arise later. However, if you have a rough idea of what the direction the design should go in, during implementation the process of editing the diagram won’t be so painful as there is little to change. Overall, grasping the concept of UML diagrams and understanding that it is a useful tool in general, but can work against you if you are overdependent on them is great to know for future projects.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

This week’s reading was Code Smells written by Jeff Atwood, on Coding Horror. As the title of the blog suggests, the message that the reader should get from the post is to familiarize themselves on the common smells to prevent design problems. With that, he lists the different type of smells into two categories, “Code Smells within Classes” and “Code Smells between Classes”. The first category deals with simplifying, removing or splitting code where its due to make reading methods easier. This idea is also applied to classes, which should reduce unnecessary classes or makes sure encapsulation is applied properly.

There is no definite reason as to why I chose this topic but it is said that developing your code nose early is useful for the future! From what I have gathered so far, the idea behind this topic is to have a good design where the earlier choices of methods/classes will not have conflicting issues for later additions or improvements to the code. Many of these code smells are already taught in earlier introductory CS courses such as, duplicated code and making useful comments.

After reading about the different types of code smells, I have noticed a couple that code be smells in previous school projects. One would be the overuse of comments, as I sometimes find myself not remembering what a certain function was used for, which compels myself to leave a comment here and there. Another would be oddball solutions, where sometimes issues mysteriously fixes itself as you continue with your code. This usually leads to problems in the future while adding newer functions. However, there are a couple of smells that are useful to remember now then later such as Speculative Generality. After being taught to prepare for future problems in life, it’s also sometimes applied to writing code but is a wrong mindset. Only implementing things when you need it will reduce clutter and seems to apply to the dead code smell, where you should delete unused code.

By exercising or having an open mind to these design problems will help prevent simple problems from appearing while working on projects. Having clean code benefits myself and others while reading the different classes/methods we each produce. Which should entail a better experience for group work, and saves time solving problems that should not have existed in the first place. There is no way to remember all the different smells, but being aware of them will help myself produce cleaner code in the future.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.