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

This short post from Coding Horror is an overview of common code smells, which the author wrote in response to being asked why he didn’t recommend a certain book on refactoring. He doesn’t think people ought to be relying on one set specific way of refactoring code in response to a particular smell, but that the important thing is to watch out for warning signs in the code you write.

I chose this post and this topic because I wanted to know right away what I shouldn’t be doing. I didn’t want to develop bad habits and then have to unlearn them later. Code smells were included as one of the topics in the syllabus, so I know we’ll be covering them at some point.

This post proved useful right away because of its commentary on comments. I know that my natural instinct would be to comment my code liberally for the sake of clarity, but knowing that too many comments can obscure has made me reconsider this approach. With this in mind, I’ll be more likely to ask myself whether I can make the code itself simpler to understand and limit my comments to useful ones – ones that explain why my code is written a certain way, not what’s going on.

Speculative Generality was also helpful to read about, because I know I’d want to try to anticipate what might be needed in the future instead of just solving the problem at hand. I hadn’t considered the drawbacks of this approach. It does make sense to limit yourself to addressing the problems that actually arise in the future, since over-planning might result in unnecessary code. I remember this being mentioned in class.

We also just today talked about how the strategy pattern can be used to avoid a mountain of conditional statements. The Conditional Complexity code smell mentions this, and it also recommends the patterns decorator and state. The decorator pattern sounds similar to the example of the strategy pattern we used in class today, only with behaviors being added to specific instances of a class instead of to subclasses. It’ll be good to know these approaches exist in the future, since in the past I’ve written some truly unwieldy nests of if statements in order to accomplish a task.

At the moment, the code smells that have to do with multiple classes are more theoretical for me than the intra-class code smells, but they’re good things to keep in mind for later (and I enjoyed some of the names).

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

https://airbrake.io/blog/design-patterns/software-design-patterns-guide

Design patterns provide guidelines for software developers to help deal with problems that could occur during their process in developing the software itself. In this blog written by Andrew Powell-Morse, he gives a brief overview about why design patterns are necessary in the world of software development and its origin.The origin of software design patterns can be extracted from the teachings of the book Design Patterns: Elements of Reusable Object-Oriented Software, which was published in 1995. The book explains object-oriented design techniques and different software design patterns, which are split into 3 categories: Creational, Structural, and Behavioral. 

Creational design patterns have several aspects that identifies that it is a creational design pattern such as abstract factory, builder, factory, prototype, and singleton. This type of design pattern emphasizes the automatic creation within code.

Structural design patterns have aspects such as adapter, bridge, composite, decorator, facade, flyweight, and proxy. This type of design pattern focuses on compositions of classes and objects.

Behavioral design patterns have aspects such as Chain of Responsibility, command, interpreter, iterator, mediator, memento, observer, state, strategy, template, and visitor. This type of design patterns focuses on the communication and assignment between objects.

I chose this blog because I wanted to know more of the basic overview in software design patterns. In today’s class lecture, the professor gave an example about how design patterns are useful with an example of a super class of ducks with sub-classes of different types of ducks and their behaviors. I was very interested in the example of ducks within the lecture, and after the lecture ended, I wanted to know a little bit more. I wondered if there were different design patterns and this blog led me to an answer that there were 3 categories of design.

Morse’s blog on design patterns was very informative and brief which was to my liking. It wasn’t too in depth because I only wanted to know a little more on the brief concepts of design patterns. This blog made me realize that there are many more design patterns out there in the world of software development. I’ve learned that the reason why there are so many design patterns out there is because those design patterns are meant to solve different problems that occur in many instances within the code during the process of developing the software. Considering that I do aspire to become a video game programmer and developer, I need to firmly grasp design patterns so when I go and create software for games, it’ll be easier for me to do so.

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

This week, I am going review and summarize Episode 262 of Software Engineering Radio.  This episode’s guest is Bill Curtis, Chief Scientist of CAST Software and Director for the Consortium for IT Software Quality.  Bill is on the show to discuss what software quality is and how architecture, Lean management, and following in big tech companies’ footsteps can help organizations achieve higher quality software.

Bill begins the podcast by defining high quality software as software that not only meets the functional requirements specified but also meets the needs of the user.  He insists that, in order to develop high quality software, the architecture of the system must be built properly in order to continually support the system as it grows.  To support this claim, Bill gives an example of a system that failed, at launch, due to a poorly built architecture – Obamacare.  According to Bill, the system architects for Obamacare built it in such a way that its users received, via download, more documentation than they probably needed, causing a rapid consumption of the Obamacare website’s bandwidth.  He believes that the Obama Administration was partly to blame for the failure because they requested that changes and additions be implemented late in development which only allowed for 2 weeks of testing to be conducted prior to launch.  I was intrigued by this story and chose this podcast to be the subject of this week’s blog post because it goes to show how crucial rigorous testing is to the production of high quality software.

Bill goes on to list his tips for improving software quality:
– Look at the architecture up front; it is incredibly difficult to refactor it in large systems.
– The most effective software engineering methodology to implement is one that combines Waterfall and Agile; building and testing for rapid feedback leads to structural quality.
– Strengthen management; Implementing a system similar to CMM or CMMi which transforms the organization into one that can effectively build big systems, dividing labor reasonably, giving developers and testers appropriate deadlines, getting control of commitments and baselines, weeding out practices that aren’t effective — stabalize, standardize, optimize, innovate.
– Follow rigorous processes for testing and measuring; allows organization to know what they can and can’t do, why they make mistakes, raises quality and improvement levels

I thoroughly enjoyed the discussion in this episode and felt that it was really pertinent to the work I have been doing lately.  I got a professional understanding of what it means for software to be of high quality,  learned the importance of rigorous testing and measurement throughout the development process, heard some examples of how failing to follow process can lead to failure, and received tips on how to improve quality of software architecture, organization, and management.

This blog post(1/9) is part of an assignment for the Fall 2017 session of CS443 @ Worcester State University.

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

For this week’s blog I wanted to keep to the theme of learning a new type of software testing. I discovered softwaretestinghelp.com from our classes Slack channel as I know a few people recommended it. For my article I chose “What is Incremental Testing: Detailed Explanation With Examples” because I have not learned this type of testing and it was one of the more current articles posted.

While I can infer things about incremental testing based on its name, this article covered it in detail. To start, incremental testing is one approach of integration testing and combines modular testing with it as well. Basically each module will be tested on its own and then integrated one by one to make sure that each module that is added interacts how it should. This is where the term incremental comes from.  Once each module has been integrated, the application or system is considered built. All modules should then be tested together to ensure smooth interaction and data flow.  A couple advantages for this type of testing are that defects can be found earlier and defects can be easier to target based on what module was added last. This can also reduce the cost and time of rework if modules were not added and tested incrementally.

There a few different methodologies in which incremental testing can be done. Three that are discussed are top down, bottom up, and sandwich testing. While there are different methodologies, they effectively use the same principles. They all utilize layered testing, a hierarchical design, and integrate modules one by one.

After reading about incremental testing it seems like a really good strategy to implement. I like the idea of testing a system piece by piece to avoid a possible large amount of rework. It also adds confidence as you work through a project that everything is working together correctly. I think this allows developers to give a more accurate and reliable time estimate for a project’s completion as well. My reason for this is that if defects are found earlier per each increment you can adjust and communicate time tables more effectively. The only downside I can see with incremental testing is repetitiveness. With each module that gets added, there will still need to be testing done for the modules that were already added and tested to make sure the current system still works correctly. This testing is still useful however I can see how it may increase the amount of work to be done up front.  In conclusion I’d like to try incremental testing on an upcoming project to weigh the advantages and disadvantages first hand.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

For this blog I chose an article on Tutorials Point called “Software Design Strategies”. I chose this because I have used tutorialspoint.com looking things up for projects in the past and I found their content very helpful. I chose this write up particularly because I want to get a foundation of design strategies before I continue to dive into specific ones.

To begin, it’s important to understand what software design is in its most basic form. It is the process of taking user requirements and then planning and implementing them with the optimal solution.  The design aspect is really HOW you choose to implement. There are a few major variants considered in software design. They include structured design, object oriented, and function oriented. Structured design focuses most on designing a solution which gives better understanding to how the problem can be solved. The primary problem is broken down into smaller problems which are solved with solution modules and then these modules are aligned in a hierarchy to communicate and solve the larger problem. Key traits of an effective structure design are high cohesion and low coupling arrangements. Function oriented design is considered to be a system which contains smaller sub-systems called functions. Every function should complete a task which is important to the system as a whole. Dividing functions up gives a means for abstraction because the functions can hide data and the underlying operation as they communicate with each other. When using function oriented design, usually you would use a data flow diagram to map out the main system as well as break it down at the function level. Object oriented design focuses on entities (called objects) and their characteristics. Objects are defined in classes which lay out attributes and methods giving the object its functionality. Other key traits that are important to object oriented design include inheritance, polymorphism, and encapsulation. When using this strategy it is important to define a class hierarchy. This determines relationships among the classes.

After reading this article I feel that I have a better understanding of the foundations of software design. The three strategies that were mentioned are important to understand because it gives options to how you are able to meet software’s requirements.  It seemed like the three strategies were discussed in order from least complex to most. If I had a difficult problem or set of requirements to meet, object oriented design would be my choice. If I had a problem which was mainly input and output I would go with the structured design as long as I did not need to hide implementation. In conclusion I think it’s important to make a conscious decision to what design method you are going to use from the beginning. Otherwise when you start implementing requirements, you may find your design to be less than optimal. As we move through the semester I plan to try and identify the base level of design for the code that we will work with.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

In his blog post, James Bach picks apart the Wikipedia article on equivalence class testing (ECT) as a way to explain the way in which ECT acts as a heuristic founded on logic rather than a rigid procedure that applies only to computer science.

His main points are:

A) That ECT is not purely based on input partitioning, nor is it purely based in computer science.  It comes from logical partitioning of sets.

B) That ECT is useful for dividing inputs (and outputs) into groups which are likely to expose the same bug in a system.

C) That ECT is about prioritization of bugs rather than exhaustive exposure.

In essence, he states that equivalence class testing is not an algorithm used to generate test cases, but a heuristic technique used to partition conditions such that they reveal the most important bugs first.

I chose this article because it relates to equivalence class testing (which we covered recently in class) and also refutes points made by a resource commonly used for basic knowledge.  I (and I think many other students) frequently use Wikipedia for summaries of subjects, and getting an expert opinion on what’s wrong with that kind of source helps deepen understanding of why they need to at the very least be supplemented by more nuanced sources.  It moves my understanding beyond the high school teacher’s decree of “DO NOT USE WIKIPEDIA IT IS NOT A GOOD SOURCE”.

While I think that picking apart the phrasing and wording of specific passages from a Wikipedia article is needlessly pedantic, I also think it’s important to critically interrogate sources of “common knowledge”.  When it comes to testing, it is necessary to understand the ways in which techniques are grounded in needs and conditions outside of just the code.  A tester should not only know how to test but also why those tests are used and what they are best at uncovering.  Bach’s article helped me think about why we test things, why we use the techniques that we use, and what we hope to get out of them.  When it comes to ECT, we partition conditions into classes in order to make a model of the ways in which the product under testing behaves.  The model can and should be modified through the testing process; conditions can be grouped differently in order to reveal different bugs.  Back presents ECT as well as other techniques as a fallable but important tool, and I think that’s good to keep in mind as I learn more about testing.

Link to blog post.

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

I blogged a bit last week about the functionality and purpose of Unified Modeling Language (UML). Since we’re still discussing the topic in class, I figured this would be a good opportunity to give a more in-depth account on the subject. I just finished reading an informative article from SmartDraw that offered me some additional insight regarding UML; it’s appropriately entitled “Everything You Need to Know about UML Diagrams.”

Some of the main topics discussed in SmartDraw’s article are: what a UML Diagram is, why we use UML, and types of UML diagrams.

SmartDraw’s article begins by explaining that the UML gives us the capability of visualizing programs through a series of diagrams. Originally developed for the purpose of Object Oriented Design, UML has worked its way into being implemented in many other forms of Software Development as well. We use UML diagrams to provide clear and ubiquitous visual explanations to our projects. The goal of UML is to help increase efficiency and team productivity.

SmartDraw indicates that UML diagrams can generally be divided into two main categories: Structural and Behavioral. Structural diagrams tend to focus on the physical attributes of a program or system, whereas behavioral diagrams are more interested in the consequences and responses from the actions within our structure.

Both groups include several other subcategories which, with the help of SmartDraw’s article, I will attempt to summarize some of which I have found particularly interesting.

Structural:

• Class Diagram: the “backbone” of almost every object-oriented method, it shows how certain classes, objects, attributes, and operations are related to each other.
• Object Diagram: describe the static structure of a system at a given time; can test class diagrams to ensure accuracy.
• Component Diagram: describe the organization of physical software, including source code, run-time (binary) code, and executables. It describes the organization and wiring of physical components within a system.

Behavioral:

• Activity Diagram: illustrate the flow of control from one activity to the next. Typically used to model the internal operation of workflow.
• Sequence Diagram: also called an event diagram, describe interactions among classes by means of periodic message exchanges.  It provides good visualization and validation among a variety of runtime situations.
• Use Case Diagram: models functionality using “actors” and provides descriptions of results for every possible action by these actors.

SmartDraw’s article went into great detail about UML, providing explanations of its purpose and why we use it. It also elaborated on several different subcategories of Structural and Behavioral UML diagrams. This article made me think of how important these diagrams seem to be in Software Development in general; they’re our blueprints for developing software. A contractor likely wouldn’t even think about building a house without a blueprint, so it seems to me that a Software Developer should adhere to that same advice.

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

While looking for a quality blog to share with you, I came across one from QA Symphony about the future of software testing from the eyes of experts. It can be found here: https://www.qasymphony.com/blog/5-trends-future-software-testing/ .

I have never actually met an expert software tester or anyone that is solely that, a tester. So when I saw a blog that interviewed 12 of the supposed best software testing experts around, I thought I could learn a thing or two from them.

The blog is written in categories, so it is easy to read and understand exactly what they are talking about. I also really enjoyed the setup of the tabs on the left side.

Anyways, the blog is mainly about the upcoming changes and what we are going to have to do as software testers to keep up with the tempo.

The categories the blog includes talks about automation, up and coming tech., willingness to adapt and learn, blurry lines, and how skill sets will bear the test of time. Below, I have pulled out some of the information from the blog that I thought would be useful to know.

Automation

All of the experts that were interviewed agreed that automation is extremely important in the field of testing. However, most of them stated that it is a dangerous place to “over-automate”. The compromise that the experts talked about that I will be keeping in mind is that automation should be used to free up some time to explore into your testing further. Don’t get lazy.

Up and Coming Technology

The biggest focus in this section was machine learning and AI. One of the experts, Seghal, states “these technologies will give us an additional layer of automation. They will become prescriptive, they will augment testing and they will become self-adaptive.”

This is obviously huge in the area of testing. To have a computer learn the best way to test a certain program and then do it for you without even asking? Sounds like a dream, too good to be true. But it really isn’t!

While the experts talk about how hopeful these technologies can be, they also talk about the challenges they will cause, which the next section covers.

Willingness to adapt and learn

One of the experts, Suma Daniel says “To succeed in the future, testers need to be willing to adapt and learn new technologies and embrace more fluid development cycles, such as DevOps.”

Always question the way you are testing, if you think you can do better, than try and do better. This blog emphasizes that you should invest yourself in your company and try to improve and advance to be better than before. You would think this is obvious, but some testers just don’t think the same way as developers.

Lines will get blurred

All this means is that when you are testing, you should be working very closely with the people creating the software. Have communication and be ready to work in a development environment rather than just a production environment.

Skills bear the test of time

With all this said about new technology, don’t forget about the human touch.”Critical thinking, communication and interactional expertise are vital to being valuable to your business and managing risk.” I think this is my favorite part because those basic skills are extremely vital to your success as a software tester.

From the blog CS@Worcester – Rookey Mistake by Shane Rookey and used with permission of the author. All other rights reserved by the author.

In the world of computing, many computer users have been in a state of cleaning up code whenever it is a task, a project, or even just for the sake of the product. This state is called refactoring in which I have decided to read about. So for this first week of blog development, I have chosen to read “Refactoring is About Features” from Code Simplicity. The reason that I have chosen this blog post because as a programmer, I have only heard the word refactoring a few times from doing coding projects in classes and the questions on my mind was: why is “refactoring” important and how does the word come into the ideals of coding. I wanted to know more on how the concept of refactoring and the ideas around it.

This blog post basically goes over the ideas of refactoring and principles of having to refactor. So, by the definition providing by the author, refactoring is an organizational process that you go through in order to make production possible. When it comes to refactoring, you want to be sure the service from it is really making progress. Variety of problems will occur if refactoring isn’t going into real production. On the other hand, if a system was produced and reorganizing was never done, production of the actual product becomes difficult or impossible. Both of these tasks have to be done in order for the product to be produced reliably and quickly while having the system be organized in an effective way. The principles are to refactor a feature service, have the system be in better condition and not worry about being “perfect” but better designed for an intended purpose. If organization is left out, the product is not as envisioned, and if production is left out, then the reason for doing refactoring is not even there anymore. So the overall message is while it’s nice to add new codes, clean up the real obstacles for the intended design to be a reality.

So based on the content the blog post provided with analogies of the real world experience, I would say this was great to read. The author provided some ideas of knowing what purpose of the overall product would be from refactoring and giving tips that shows cleaning development directly and indirectly.  From my experience when it comes to cleaning up coding, my mindset would be writing the implied codes that is needed to be clarified and then write a bit of documentation that which shows as much the code is used up to a certain point. In this way, it gives an insight on the structure of the overall design and then like discussions can be made when I ask peers if the piece of code can serve this purpose or even help in finding the real problem.

From this blog about refactoring, I learned is that always be aware to change the design from being not serving an uneventful state to a design with the very current purpose can do with the piece of code it has as it leads to greater productivity and less redundancy. Learning the ideas about refactoring from this blog gives me the reality of seeing that for myself, there should be a boundary in cleaning up coding as I see fit. The reason I say this is while my experience seems to work, I must be aware there should be consistency with using this method and sometimes people do not want to see the same method repeatedly. So I hope to use the knowledge I learned from this blog and build upon it to be flexible within my skills in coding.

-Dennis Tran

Link to the blog: http://www.codesimplicity.com/post/refactoring-is-about-features/

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.