For this week, I will be discussing about anti-patterns. I chose to talk about anti-patterns because it relates to one of the topics on our course syllabus, and it seems like it would be good for me to connect and refresh concepts learned in the previous blog posts to anti-patterns; for many of the design patterns and software concepts learned are used to prevent anti-patterns.

To supplement my knowledge on this topic, I watched two youtube videos and read one article on anti-patterns. The first video I watched was a very short video about a developer who introduces the concept, anti-patterns. In the video, he connects anti-patterns to code-smells and basically says that code-smells serve to indicate potential/likely problems in your code, which are the anti-patterns. The second video I chose was lengthier and was by the infamous ‘techlead’, where he satirically talks about his favorite anti-patterns he has seen in his work experience. Although satirical, I was able to decipher why anti-patterns are important to catch and also was able to learn some anti-patterns from his talk. The third source, the article served to list more formal definition and examples of anti-patterns. The article referred anti-patterns as “… a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences”. The article also listed examples of anti-patterns that were similar to the ones discussed in the techlead video.

I chose these three sources in that particular order because the intro video helped me better understand the general picture of anti-patterns, whereas the satirical anti-pattern video and the formal anti-pattern article helped to give more depth and understanding of anti-patterns. The satirical anti-pattern video also included real-world examples from an experienced developer which were helpful as well.

From all three sources I was able to consolidate a better understanding of anti-patterns and can see how they connect to previous material learned in my college courses. An important argument that caught me in the techleads videos was the importance of preventing/catching anti-patterns. He explains that antipatterns are dangerous because they are often irreversible and extraordinary hard to refactor once they are embedded into the architecture or code-base, and over time the damage accrues. In addition the anti-pattern article explains that anti-patterns are important to catch early because it may become a bad habit which will repeat itself. Many of the anti-patterns noted both in the anti-pattern video and article, pointed out common code-smells which appeared to be unnecessary-complexity and obscurity; which exemplifies the need for simple and readable code. This is also a common theme noted in the previous blog posts as well. One of the anti-patterns that I can relate to is the over-usage of refactoring, which is explained as bad because it slows-down readability of code during a code-review; yet it is taught extensively in some CS institutions. Overall, this topic made me realize the importance of learning proper usage of software design techniques and concepts in order to prevent anti-patterns in our code.

Sources linked below

https://www.javacodegeeks.com/2011/10/programming-antipatterns.html

From the blog CS@Worcester – Will K Chan by celticcelery and used with permission of the author. All other rights reserved by the author.

For this week, a topic that I chose to learn more about was the Law of Demeter. The Law of Demeter was chosen because it is one of the topics covered in our course syllabus and it is also a concept that I have not heard about before and so I was curious to learn more about it. To supplement my understanding of this concept I watched a youtube video about it and also looked at an article by hackernoon. I had chosen this video because it was short and concise and was uploaded by a channel catered towards teaching programming concepts. The summary of the video was that often in programming, cohesion is good and coupling is bad and the law of demeter is a design principle used to reduce coupling. Also the usage of the law demeter is implemented with some design pattern such as facade or adapter that performs some form of delegation to remove the need of chaining. The second source I used was an article on the Law of Demeter by hackernoon. I had used this second source because I wanted to see an example of this concept implemented in code; and also the code was implemented in java, which is language I was familiar with. The summary of this article regards the Law of Demeter as “Don’t talk to Strangers” rule and the article examples where Law of Demeter is implemented and violated.

In conjunction, these two sources helped me in understanding the Law of Demeter. In addition to the explanation of the Law of Demeter in the video source, I also enjoyed how the youtuber, Okravi, explains that the Law of Demeter is a design principle and that some people do not agree with it, and so he states that the Law of Demeter does not have to be strictly be followed and that you should just use the concept where it makes sense in code. From that statement, I thought that had related to many of my previous blog posts where I have listened to experience developers explain a topic; where they say that following a principle strictly is not realistic; and rather we should strive for using a concept when it makes sense in our code. Also reflecting on the Law of Demeter made me think more about the concepts of coupling and cohesion in my code; and also the many times where in our course the usage of chaining methods was acceptable; however after learning about the Law of Demeter, I can see that that code can be refactored.

Links to video and article below

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

From the blog CS@Worcester – Will K Chan by celticcelery and used with permission of the author. All other rights reserved by the author.

For this weeks topic, something I that I chose to learn more about and get a better understanding behind of is YAGNI; which stands for You Aren’t/Aint Gonna Need It. To supplement my understanding for this topic, I watched a small conference video about a Software Architect, Ian Thomas, who gives a talk about the importance of YAGNI in real world environments. Throughout the talk some of the main points were that YAGNI reduces costs, and he also gave fixes or solutions for promoting YAGNI in work environments; and he also gives examples from his experience to better explain the importance of YAGNI.

Throughout the talk, I enjoyed some of the quotes and references he brings up because I thought they were powerful and changed my perspective of the software industry. In his introduction he brings up a Uncle Bob quote, which was ‘the number of developers in the world doubles every five years’; and then he points out that means half the developers entering the markets have less than 5 years of development. This is actually a worrisome quote when considering that one of the less experienced developers may be working on an airplane or automobile system that I may use in the future; however, Ian brings up this point because it ties to another reason for promoting YAGNI. This benefit of YAGNI is making material easier for new hire ups to understand and pick up; he refers to this as carry costs improvement.

Out of the other costs benefits he covers, he says that reducing carry costs is an important benefit of YAGNI often not acknowledged; it is also one I was not aware about. Carry costs may refer to the impact given from writing a new feature and when YAGNI is not upheld this often means that a new feature is overly complex, which would mean that it would take someone too much time to read before adding on or working in conjunction with that feature; this would also make it harder for new hire ups to pick it up. It appears that the code smells needless complexity and obscurity are byproducts of the absence of YAGNI in code.

Rather Ian mentions something important to think about when writing a new feature. A recurring theme that he brings up is thinking about the future; and so think, about writing/refactoring in a way that it’s not going to be too hard to write later on because you’ve taken the time to leave it in a good state now. And the quote he used for this was “it’s better to do a simple thing today and pay little more tomorrow to change it if if it needs it, than to do a more complicated thing today that may never be used anyway”.

And his takeaways to keep up YAGNI were narrowed down to keep things simple, to change things in small increments and also test them so you get to understand how the system is working and what you’re doing for your customers. Also he advises having courage in being able to stand up and explain why you are doing something and need to take the time to do it.

Link to Video Below

From the blog CS@Worcester – Will K Chan by celticcelery and used with permission of the author. All other rights reserved by the author.

A topic that is related to my CS-343 class, is the SOLID principles. SOLID principles are important in the design of object oriented software. They are also similar to the code smells that we have discussed in class as a detection of a code smell could mean one of the SOLID principles are broken and thus could lead to inefficiencies in one’s code; whereas fixing the code smell or SOLID principle with a design pattern/technique can make code more understandable, flexible, and maintainable. For this topic, my source of information comes from the Data Science Blog article, “The SOLID principles: a Guide for Object-Oriented Design”, which will be linked below this post. The post summarizes and explains each individual principle of SOLID, and it provides an example as well as advantages of implementing the principle and also the author’s advice on implementing the said principle.

The reason why I chose this topic was to learn more about common concepts that other programmers followed and are familiar with. Along with trying to familiarize myself with some well-known concepts in the programming world, I also chose to learn more about SOLID principles because it is a topic that I remember being brought up in a previous course that I had taken, which was aimed towards designing cleaner code. Because of this, I became curious and wanted to learn more about SOLID principles as well. From the blog post on SOLID principles, along with learning about each individual principle and implementation from the principles, I had also enjoyed learning a new tool of modeling code, which was the sequence diagram; which the author had to used to model the code example for the Single-Responsibility Principle.

While following the blog post, I also found that the article was a good refresher in tying/connecting to similar material that we have went over in my Software Design and Architecture course. One of the principles, ‘the open-closed principle’, was similar to the simple factory pattern, in that both designs had the pattern of ‘encapsulating what varies’. And the implementation of this principle reminded me of a code smell because the author provides a note to not cover this principle for all of an applications code, but to rather only apply the open-closed principle where it is deemed appropriate; otherwise it would create unnecessary abstraction; this ‘unnecessary abstraction’ segments relates to the code smell, needless complexity. And the fix for this code smell was implementing a decorator pattern fix, which is another subject that has been covered in my Software Design and Architecture course. Overall, I found the article to be a good read to learn more about SOLID principles as well as tying the principles to other programming topics covered in a design pattern course.

Link of source below.

https://www.datascienceblog.net/post/programming/object-oriented-design-solid-principles/

From the blog CS@Worcester – Will K Chan by celticcelery and used with permission of the author. All other rights reserved by the author.

A topic that I chose to learn more about for this week is ‘REST API Design’ as listed in our course syllabus. The source that I had used to supplement my learning was a conference talk on REST API called Never RESTing – RESTful API Best Practices using ASP.NET Web API – Spencer Schneidenbach. This source will be linked at the bottom of this post; however, I would like to mention that I enjoyed this conference talk as I found it both informative and insightful.

In the talk, Schneidenbach goes over his experiences and gives insight into building and designing RESTful API’s. He breaks down building/designing restful api into four activities, design, implementation, document, and maintenance; although he mentions that practically all four of these activities or a culmination of the two activities would be performed at once when working on api, he tries to separate the four activities in his talk. Throughout the talk he also brings up other topics such as explaining what REST and api’s are; however, I would rather discuss segments what I found informative or insightful from his talk.

One of the things he brings up when designing api is that ‘restful api != good api’; and this claim that an api that solely follows the constraints imposed for REST API does not solely make that api good; rather he argues that when building api we should be doing what makes sense and ‘throw out the rest’. I really resonated from this statement, as it made the designing process more practical in that when building api we must be flexible and logical with our decisions; and that theoretical rigid constraints are not what always works in real environments.

In conjunction to this statement, he also mentioned two prime rules he kept in mind which were, KISS and be consistent. KISS meant to keep things simple, but an element of KISS that I found insightful, was asking who we are keeping things simple for. He argues that when designing we should always keep in mind the user experience or the consumer who will be using the api. I thought this was interesting perspective to think of how to keep things simple for a consumer to use the api when designing it; in addition to this rule, he also added to not be creative and just provide enough that is necessary and no more or less, which I agreed with. For the consistency principle, it was straightforward strategy to keep things consistent with accepted best practices; however, I also enjoyed his second comment ‘be consistent, but be flexible when it makes sense’. This comment reiterated a theme in design that there is no silver bullet in designing api, and that although there are solid principles that we should follow, we need to be have some sense to find a balance with what our consumers require and want.

From the blog CS@Worcester – Will K Chan by celticcelery and used with permission of the author. All other rights reserved by the author.

Similar to how code and design smells were covered in class. I was interested in digging more into code smells and seeing how they influence development of code and how they can be rectified. I found that this would be a useful topic to further delve into because being able to pick up smells from your code will help prevent further mess in the future. To supplement my learning in this topic I got around to watching a seminar or conference video on code smells in java, which was hosted by Stanly Lau, a software development coach/mentor and also someone having experience of looking at companies code and giving advice on code smells and refactoring. In his seminar he basically went over code smells and refactoring techniques used to remove to code smells; in the seminar this is done by an example he goes over with the participants.

Besides going over code smells, what I really like from this seminar, was how he explains the significance of catching code smells in our code; he explains this via system diagrams to show that code smells are in a reinforcing loop relationship with bad code, and bad code is in a balancing loop with developer motivation; because of this we need to reduce bad code via refactoring. Refactoring is important because it instigates flexibility and helps to remove bad code or code smells. And flexibility is important in order to deal with change and he states “[i]f you cannot deal with change or how to improve with change easily, then you are probably in the wrong business”. The was a powerful I really appreciated, that change is inevitable in programming and in order to deal with change we must make our code more flexible, and that is where finding code smells and refactoring comes in.

I also enjoyed watching Stanly going over his example code of detecting and refactoring the code smells. His methodology appeared that he would look at the code and try to understand what is going on with the code (reading before coding) and then would see if he can detect any code smells such as comments, duplicated code, feature envy, long methods, primitive obsession, or magic number. Afterwards he would choose a means to refactor that code smell; the aspect of refactoring that he describes as ‘making small steps without breaking the code for too long’ is what I found helpful and will incorporate next time I am reviewing my code. Rather than just choosing a technique such as extraction method, I should be compartmentalizing steps to fix a problem and then work on improving on that refactoring. Overall it was a supplement for my learning in code smells as I was able to see a demonstration and also learn some more techniques use ide’s as well.

I attached the links to video as well as the diagram that explains effects of code smells in a developers environment below.

From the blog CS@Worcester – Will K Chan by celticcelery and used with permission of the author. All other rights reserved by the author.

When using principles or techniques in code, we need to use them in moderation and understand the meaning behind them; otherwise we over-salt our code. The post that I will use in discussion explains a common salting problem in programming, the article was found in an early programming blogpost from Coding Horror, to reflect a topic that is relevant in programming and also discussed in one of my courses. The topic is Object Oriented Design.

In the article that I chose, titled, “Your Code: OOP or POO?”, the author, Jeff Atwood, talks about how many programmers these days are not using Object Oriented Programming correctly. He attributes this problem to institutions that rush and advise the usage of OOP to their students without properly explaining when and why objects are necessary in programming design. In addition, he also blames the pro-object culture that is common among programming communities, where programmers glorify objects and boast the superiority of object oriented languages over non-object languages. Due to these influence, he explains that it causes programmers to undergo object happiness, a frenzy of object-izing everything in their code. This mess, is the coding horror that is seen when Object Oriented Design is used improperly.

To address these concerns, Atwood recommends POO, Programming fOr Others, which brings in the element of empathy into programming design. What Atwood proposes is that programmers should be thinking about their audience, such as their readers, who will have to make sense and use their code. So, along with implementing other OOP principles, such as, encapsulation, simplicity, re-use and maintainability; Atwood encourages empathy and to build code while keeping in mind what their readers would want or need and to anticipate what they need to do next when following the code. Atwood concludes his argument with ‘programming as if people mattered will always be a more effective strategy than satisfying the architecture astronauts’.

Although this is an early post, which was posted on 2007, the topic of this post still holds relevance. While continuing my CS undergrad studies at WSU, I have noticed this pro-object culture, where object oriented languages are remarked as superior than non-object languages and I have also noticed that some of my peers falling victim to object happiness and not having a firm grasp of OOP principles. I also feel that this post was a good reminder, that we should be questioning our studies and what we are taught at institutions in programming. In a sense, it was a good step back for me to reevaluate my principles and goals in coding. It also brought in a new perspective, the element of empathy; where one should code as if people mattered; rather than solely focusing on the efficiency of the solution; we should also consider readability and simplicity of our code.

The link of the source can be found here

From the blog CS@Worcester – Will K Chan by celticcelery and used with permission of the author. All other rights reserved by the author.