The blog post this is written about can be found here.

I researched architectural decision records this week. I picked this blog post because it’s both informative and self-demonstrating; the post is itself structured like an architectural decision record. It starts by explaining the context, or the problem that produced the need for the solution provided by ADRs. Developers who are added to an ongoing project come in without knowing why or how decisions about the structure of the project were made. They are left with two options: blindly accept the decisions that have been made, or blindly change them. Neither of these are desirable. Additional context includes the fact that people are less likely to read or update long documents, so the solution to this problem should be a brief document that serves to keep track of the architectural decisions made for the project, why they were made, and their consequences.

The types of decisions recorded in ADRs are decisions that affect the structure of the software, its non-functional characteristics, its interfaces, dependencies, and construction techniques. They describe the set of forces that went into the decision-making, some of which are likely to be opposed to each other. They describe the decision reached in response to those forces, as well as the status of that decision. Decisions might be proposed, accepted, or superseded. It’s good to keep records of decisions even after they’ve been replaced, so anyone looking back can see the whole picture of how the project progressed. Finally, the record explains the consequences of this decision, which can be positive, negative, or neutral. The consequences of one decision often become the context of future decisions.

Agile software development is often thought of as opposed to documentation, but in actuality, it’s only opposed to useless documentation. ADRs can be extremely valuable for a software development team, particularly developers rotating through projects. The blog writer mentions that his team has been using architectural decision records for roughly three months, and in that time, every one of the six to ten developers being rotated through projects said that they appreciated the context they got by reading the ADRs. Additionally, they can be useful for the project’s stakeholders, who will want something brief to read to understand how the project is progressing.

Having read this blog post, I can imagine how ADRs might be used in some of the example projects we’ve seen in class. While refactoring the duck class, we might have created documents explaining our decisions to use the strategy pattern, the singleton pattern, and the factory pattern. Someone who came into the project after our final version might be confused by the seeming complexity, and records of those decisions would serve to clarify the significance of our decisions to them.

Going forward, I will keep in mind the value of ADRs and use them appropriately.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

For this week with my spare time, I have decided to read “Process Modeling (UML Diagrams)” from the mohamedelgendy blog. The reason I have decided to read this one is because it is crucial to understand the benefits of each UML diagram. It will help in understanding modeling and the cases from it.

This blog post goes over eight types of UML diagrams and how each diagram is used for modeling. So basically, UML is a set of standardized (Unified) diagrams that offers different views of the same system from construction (front elevation, electrical diagram, floor plan, etc.). The first and simplest one is the class diagram and it describes the structure of a system by showing the system’s classes, their attributes and the relationships among these classes. It is also a static structure which shows what interacts but not what happens when the classes interact. Second and third one is the component and deployment diagrams. Both diagrams in many cases are combined into one as component diagrams depict how the various components of a system and show the dependencies among them and then deployment diagrams show how they interact. For package diagram, it can be used to obtain an overview of a large system and the choose to display the individual classes inside the packages. Next is the state diagram which describes the behavior of a system where it shows all the possible states an object can get into. The sixth one, object diagram, is a static snapshot of a dynamic view that depicts a complete or partial view of the system at a specific time. For sequence diagram, it displays the sequence of events between entities of the system to show the dynamic view of the system. Finally, for the activity diagram, it is used to describe the sequencing of activities, actions, choices and system’s logic and will help with complexity.

Based on the contents of this blog, I would say that it was worth to read about. The author was on point with giving introductions to what is an UML diagram, definitions that are basic and good reminders to each diagram, and showing the implications when it is essential to know. What I try to understand the UML diagrams before is using the diagrams I do know such as flow charts. Using the diagrams, I would try to solve construction problems for example from the logic of it.

What I learned from this blog of UML diagrams is that while each of the diagrams has its uses, only use one style for something specific. The idea I got from this blog is that developers should try to find the right UML diagram that is essential to the design and not cause confusion from it.  For future practice, I should try to use the sequence diagram a lot more than the other seven diagrams because it benefits in organization for the overall structure and has a flow that is easy to understand.

Link to the blog: http://mohamedelgendy.com/blog/business-analysis/business-process-modeling.html

From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.

We have begun work on the web application for the final assignment, so I wanted to find out what design patterns and principles are most commonly used in the development of web applications.  The result the came up the most, in my search, was the Inversion of Control (IoC) principle, a design principle used to increase the modularity and extensibility of  programs, especially web applications that expect to experience growth.  This principle is also useful in event-driven programs, which is how it relates to a project like ours  While we don’t really need to consider the growth of our application in the context of our class, it could be potentially useful to follow the Inversion of Control principle as much of our application will be event-driven.  I found it incredibly interesting to learn about the IoC principle and knowing how it works will surely benefit me in the development of other web applications in the future.

IoC is a design principle in which most of a program’s flow of control is received from a framework, rather than being directly implemented in the main parts of the program.  In traditional programming, the code that expresses the purpose of the program calls into libaries to perform tasks, but with IoC, it is the framework that calls the task-specific code.  This principle is given its name because adhering to it effectively inverts the control of the program from implementation to frameworks.  Adhering to the IoC principle serves the purposes of decoupling execution of tasks from implementation, focusing a module on task it is designed for, freeing modules from assumptions, and preventing side effects when replacing a module.  Software frameworks, schedulers, event loops, dependency injections, template methods, and callbacks all follow the IoC principle.

The IoC design pattern is, in my opinion, a difficult one to fully grasp.  The most helpful explanation I found about the pattern was in a YouTube video uploaded by Christian Richards, entitled “Programming – What is… Inversion of Control”.  In the video, Christian provides the example of a program that wishes to make a new user; when constructed, an integer variable is passed in, as a parameter, to the User class’s constructor and is used to dictate what kind of SQL Database Access Layer (DAL) will be initialized and stored in the new user.

The fact that the User class is responsible for a new DAL object to store within itself means that the User class is tightly coupled with the creation of new DAL objects. 

In order to improve the modularity and extensibility of the program, Christian knows that he should adhere to the IoC principle, and decouple the creation of DAL objects from the User class.  The User class should not contain code for deciding which kind of DAL should it should use; instead it should simply know how to work with DALs, and let the implementation dictate which DAL to use.  This can be done by creating an interface to represent DAL objects (let’s call it ‘IDAL’), create concrete DAL objects for each different kind of DAL and implement IDAL in each one, modify the User class’s constructor to take objects of IDAL type, and then modify the main implementation of the program to create and pass in a concrete DAL object to the User constructor, upon construction.  Now, the User class is simply responsible for dealing with the DAL object, rather than deciding which kind of DAL object to use and only then working with it.

Here are excerpts of Christian’s program, before and after adherence to the IoC principle:

class Program
{
static void Main(string[] args)
{
User user = new User(1);
}
}
class User
{
IDAL dal;
public User(int IDALtype)
{
if(IDALtype == 1)
{
dal = new MySQLDAL();
}
else
{
dal = new SqlServerDAL();
}
}

class Program
{
static void Main(string[] args)
{
User user = new User(new MySQLDAL());
}
}
class User
{
IDAL dal;
public User(IDAL IDALtype)
{
dal = IDALtype;
}
}

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

My teammate and I are currently finishing up our Angular “Blackjack” project. The program seems to be running fine and doing everything we originally intended it to do. Now comes the important task of “cleaning up” our project. Examples of this are going through our program, rectifying any remaining bugs, and fixing any potential style inefficiencies within our code.

In order for us to clean up our code as efficiently as possible, I feel it is a good idea to brush up on ideal Angular style practices. By doing so, we can ensure our code is up to par with Angular standards. There is an excellent Angular Style Guide article that I strongly feel can help us in our “clean-up” task.

The guide is an article directly from the official Angular website. It gives examples of various “Angular style” coding techniques. Each is followed by a suggestion of whether the developer should (“do”) follow the example style, “consider” the style, or abandon the style (“don’t”) for a better alternative. I will outline certain styles mentioned in this article. I will also offer my personal takeaways on these style suggestions, as well as the Angular article in general.

General Naming Guidelines

Angular asserts the best practice is to name project files in a way that specifically identifies the function of that file. Each should follow the standard pattern of ‘feature.type.extension’. For example, our Blackjack project has a “player hand” component. Based on the suggestions of this article, we felt it was most appropriate to name each of the “player hands” companion files as ‘player-hand.component.ts’, ‘player-hand.component.html’, etc. Furthermore, the article suggests that each component, service, etc, along with their companion files, should all be located within the “src” folder in their own sub-directory. When going through the process of “cleaning up” our code, we will ensure that each section (service, component, etc) are in the folders they ought to be, in accordance with Angular standards.

Single Responsibility Principle (SRP)

The Angular article suggests that a project should follow the SRP whenever possible. Based on everything I’ve learned in the Computer Science program so far, it is always best to have a function to do just “one thing” as clearly and efficient as possible. Thus I feel it should follow that in Angular, we should only have the code for one component per file, one service per file, and so on. Though it is technically possible to write code for multiple types within one file, according to this article, it is bad practice to do so. When looking over our code, we will ensure we have all of our components, services, etc within their own appropriately named files.

The Angular article goes in great detail of good Angular style practices, and which ones to avoid. We have referenced this article a great deal during our project, thus I feel it directly relates to this course. I am sure this article will be useful during my professional career when working on additional Angular projects.

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

We’ve recently conducted “group code reviews” on a given project, where the goal was to identify any issues and/or bugs we could find within the project’s code. I found this to be a good exercise because I will likely be doing many code reviews during my professional career.

My ultimate goal regarding code reviewing at this point is to learn how to do it as efficiently as possible. Sara Tansey has a great blog on the topic, entitled 7 ways to up-level your code review skills. She identifies several strategies in particular that she feels are important when reviewing code. I will outline a few of these strategies that I found especially relative to our course’s content, along with my personal thoughts and takeaways.

“Prioritize the goals of code reviews with your team.”

I feel this is an important topic which I am glad Sara mentions in her blog. The main idea here is to make sure your team is up to speed with what each individual team member should be looking for. One example I can think of is the following: perhaps “Person A” could be looking specifically for bugs while “Person B” concentrates on code style. Then perhaps each team member can go through the code together and see if there is anything they have missed.

“Run the app and try playing with the features.”

Sara brings up potential difficulties of trying to perform effective code reviews solely on the basis of reading the code. I agree with her stance that code reviewers ought to run the program and “play with” the features as well. I believe this is a good strategy because seeing the program in action may provide some clarification on what the code is doing, and what it is intended to do.

“Always give approval, unless you can prove that there is a bug.”

I believe what Sara is referring to here is a code reviewing team that has the responsibility of either approving or denying a developer’s request to continue with production. Giving approval to proceed barring the existence of bugs makes sense to me. There doesn’t seem to be much of a reason to halt production on the sole basis of “less than optimal code style” in my opinion. I feel if the code works, certain style inefficiencies can easily be addressed based on the feedback of code reviewers.

I enjoyed reading Sara’s blog and feel she brought up many good strategies to conduct efficient and high-quality code reviews. I especially like her suggestion that we ought to be running and going through the apps themselves, rather than just reading the code alone. Running the program might give us some context that we may have missed if we relied on simply reading code lines without actually seeing the app in action. During my professional career, I will adhere to Sara’s suggestions while conducting code reviews for given projects. I will run through the actual program as well.

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

So for this week, I have decided to read another blog and that is “3 Principles to simplify your life as a developer” from the iTexico Blog. The reason I have chosen to read this blog is because I usually do not get a clear grasp of these kinds of principles. With getting a clear understanding of these principles, they will help in applying code, simplicity, and managing the overall process.

As the title applies, this blog post basically goes over 3 principles that are basic but powerful that will make life as developers easier and they are KISS, YAGNI, and DRY. The first principle KISS stands for Keep It Simple, Stupid and the meaning of it is straightforward. The simpler the code is, the simpler it will be easier to maintain in the future. This means that according to the author’s advice, developers should avoid using fancy features from the programming language they are having it in on. It does not mean developers should not use these features, it is to say only use them when there are perceptible benefits to solving a problem. Second principle YAGNI stands for You Aren’t Gonna Need It and the meaning is rather related to programming the first time. We do not want to waste time coding extra features that might not fit to what is needed or in the worst-case scenario, it will not be used. So from the author’s advice, when there is an unexplained anxiety to code extra features, take a deep breath and see the pending work at the moment. The third principle DRY stands Don’t Repeat Yourself and the meaning is clear to understand. We must try to maintain the behavior of a functionality of the system in a single piece of code. This means to keep it in a steady pace to avoid redundancy.

Based on the contents of this blog, like the concept of KISS, I would say this was simple and easy to read. The author gave the meaning of the principle, explained the origin of it, and advice on how to apply it while programming. What I did before to try to understand these principles while coding is that I try my best to not write down a method twice or an extra class unless needed.

What I learned from this blog about the principles is that DRY should be not used all the time in the life as a developer. The idea I got from this blog is that while DRY is a good principle to follow, it will sometimes when violated lead to a solution which is called WET or Write Everything Twice and that is a bit of time spent. For future practice, I should try to apply the KISS and YAGNI principles a bit more while writing down code as it will not only save from being overwhelmed on how the code works but also others that can benefit from it.

Link to the blog: http://www.itexico.com/blog/bid/99765/software-development-kiss-yagni-dry-3-principles-to-simplify-your-life

From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.

Last week, I wrote my blog on Code Reviews. This week I am writing about how much time we should be spending during Code Reviews. I found an interesting article titled “Don’t Waste Time on Code Reviews” on DZone written by Jim Bird.

According to the article, research shows that reviewers find far more maintainability issues than defects (a ratio of 75:25) and spend more time on code clarity and understandability problems than correctness issues. There are a few reasons for this. Finding bugs in code is hard. Finding bugs in someone else’s code is even harder. In many cases, reviewers don’t know enough to find material bugs or offer meaningful insight on how to solve problems. Or they don’t have time to do a good job. So they cherry pick easy code clarity issues like poor naming or formatting inconsistencies. But even experienced and serious reviewers can get caught up in what at first seem to be minor issues about naming or formatting, because they need to understand the code before they can find bugs, and code that is unnecessarily hard to read gets in the way and distracts them from more important issues.

Code reviews add to the cost of development, and if you don’t do them right they can destroy productivity and alienate the team. But they are also an important way to find bugs and for developers to help each other to write better code. So do them right. Don’t waste time on meetings and moderators and paper work. Do reviews early and often. Keep the feedback loops as tight as possible. Ask everyone to take reviews seriously – developers and reviewers. No rubber stamping, or letting each other off of the hook. Make reviews simple, but not sloppy. Ask the reviewers to focus on what really matters: correctness issues, and things that make the code harder to understand and harder to maintain. Don’t waste time arguing about formatting or style. Make sure that you always review high risk code and high risk changes. Get the best people available to do the job – when it comes to reviewers, quality is much more important than quantity. Remember that code reviews are only one part of a quality program. Instead of asking more people to review code, you will get more value by putting time into design reviews or writing better testing tools or better tests. A code review is a terrible thing to waste.

I would say that the title was somewhat misleading though. I wish the title was less misleading, though – it’s easy to read as “Don’t do code reviews,” which isn’t what the post was saying. I think the title was either poorly worded or it was written that way intentionally as click bait. I think a better title would have been “Don’t Waste Time During Code Reviews”. I was spending lots of time reviewing code that a static code review tools can do. Form now, I would rather use tools like FindBugs and PMD which uses static analysis to look for bugs.

Source: https://dzone.com/articles/dont-waste-time-code-reviews

From the blog CS@Worcester – Not just another CS blog by osworup007 and used with permission of the author. All other rights reserved by the author.