Author Archives: mesitecsblog

Uh Oh! Spaghetti Code!

Hello, once again my fellow readers! I am sorry to report that this will be my last blog post for this semester and in turn this class. Continuing with my trend of Antipatterns today I will talk about a delicious Antipattern, Spaghetti Code.

SPaghetti code is the Antipattern that everyone first falls into when learning how to code a new language, learning a new coding tool, or learning how to code in general. Spaghetti code is the Antipattern representing code that has very little software structure. As a result, this leaves the code with a lack of clarity or direction, even to the original developer. This is the classic moment where you uncover code from some time ago, sit down, look at it, and go, “What was I even trying to do here?”

It can be quite easy to identify Spaghetti Code. Simply look for methods being very process oriented. Object implementation will also dictate flox execution. You will see minimal relationships between objects. You will see a very predictable pattern of object use.

Spaghetti Code can result in many consequences. Spaghetti code results in a program with diminishing returns. If Spaghetti code is mined, only part of the code will even be suitable for reusable if any of the code is reusable at all. As well, maintaining the code will result in being much more wasteful and a diminishing return as well. It will be more practical and less wasteful if a new solution is developed. Spaghetti code is so detrimental, it can even remove the benefits of object-oriented design.

To fix Spaghetti Code, you can refactor your code. Refactoring code is a natural and excellent way to maintain your code and is a wonderful way to increase performance. Code refactoring first must achieve a sufficient structure. Then, performance critical code must be identified and then structure compromises must be implemented as to enhance performance. Of course, the best way to get rid of Spaghetti Code is to prevent it in the first place.

As I was reading this, I knew that this is something that I could apply this almost immediately. In my next semester, I will have to work in a team and build off of an existing program. This Antipattern will stay with me and I definitely will see how I can work refactoring into the process to ensure that no Spaghetti code will remain. I have a sneaking suspicion that refactoring will be an idea that if implemented, will be able to squash many different Antipatterns that show up or are already lurking.

Well folks, this going to be my last blog entry for this semester. Thanks for reading and learning along with me (or watching me read). Until next time, have a wonderful day!

 

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

I Know Halloween Was A Couple Months Ago But…

Hello, again my friendly neighboorhood readers!

This week I have been again been reading up on those crazy Antipatterns I discovered week. As you can probably tell by the title, the Antipattern I am writing about this week is a Halloween themed Antipattern. I know it’s a little late but today’s Antipattern is the Poltergeist.

A Poltergeist is a class that has a limited role to play or limited responsibilities in a system. This practice adds unnecessary abstraction and their short life cycle means more wasted resources. Poltergeists normally appear to initiate some other action of a class that has a more permanent status. A Poltergeist is easily identifiable as they will typically bear the “_manager” or “_controller” title in their name. The main three disastrous effects of the Poltergeist Antipattern is a waste of resources every time they are called, they utilize redundant navigation paths, and the clutter the object model, getting in the way of proper object-oriented design. If a Poltergeist Antipattern is left alone it can result in such occurrences as transient associations, stateless classes, redundant navigation paths, short duration, temporary classes, and objects, and single operation classes. Some typical causes that lead to a Poltergeist Antipattern manifesting are a lack of object-oriented architecture, using the incorrect tool for the job, and of course, a specific disaster such as management incompetence.

Now how do we fix this Poltergeist problem? Well, they gotta go. Of course, once the Poltergeists are gone, the functionality they had must be replaced with an adjustment to the architecture. Another solution is to utilize the 80% solution that we discussed in the post discussing the Blob Antipattern.

Now, I do not know about you reader, but I believe that this is definitely an Antipattern that every programmer falls prey too, especially when they are beginning. I can think of many programs that I have many over the years that have had at least one Poltergeist stalking around in them. This does make me rethink how I will program in the future. While the programs I may write now do not need any real optimization, in the future, optimization is going to be a required skill for me.

Well, that is it for today readers. Have a good week until next time!

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

Common Software Testing Techniques

Good day, again dear reader! With classes wrapping up this week and finals starting, I was a little curious at what other testing techniques there were for testing that were not discussed in class. Of course, this lead me to an article called, “The 7 Common Types of Software Testing“. This article had a mix of things discussed in class and some new ones as well.

The first type of test was a black box test, something we discussed in class. In fact, it was among the first we discussed. For a brief review, black box testing is when we are solely concerned with inputs and outputs and we don’t know anything about how the code works or calculates the actual results.

The second test mentioned is white box testing. Another testing method discussed in class. If I remember correctly, it was discussed on the same day as black box testing. Here in white box testing, we can see inside and get a feel for how the program actually works and calculates outputs.

Acceptance testing is a new one to me. Acceptance testing is two-fold. It tests both the system as a whole and it tests the actual requirements of the customer. This test is geared more towards user-friendliness and usability that some of the other tests.

Automated testing is simply any test that has been automated. This I think is more part of other test techniques and not its own technique.

Regression testing is testing the system to ensure that it works the same way as the previous system. This is done in incremental development to ensure that as new parts are added, the original system isn’t broke.

Functional testing is the testing of the system to see if it is functional. The author points out that there is more than just functionality to test for a program and uses that to justify functional testing as its own technique. I’m not quite sure about this decision but I can stomach it for now.

Exploratory testing is testing a system without any actual test cases and exploring the system looking for things that might be wrong or unexpected. Reading the description, it appears to be for testing systems in unusual ways that might not be conventional and testing the boundaries of a system, possibly uncovering bugs that normal testing methods might not find.

Of these new test methods, none of them have really captivated me. Exploratory testing, being honest, sounds a little silly and I can’t really see too many benefits to it. Out of all seven I quite like acceptance testing as it seems to keep the focus shifted to the customer and not just to it the system works or not.

Until next time readers!

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

I’m Sorry, an Anti what now?

Good day once again my fellow readers! In my readings this week, I discovered something that I had never heard of before, antipatterns. Now that is quite a striking name and it piqued my interest in this subject. So today I will be talking about software development antipatterns, particularly the Blob.

First, let’s discuss what an antipattern even is. An antipattern is simply just an industry term for a common solution to a problem that generates negative consequences. what antipatterns can do for us is twofold. First, they provide a template to help us recognize common problems that can crop up in software development. With this knowledge, we can recognize an antipattern when we see one and identify the cause of it as well. The second part is that antipatterns provide a constructive solution to fix the underlying cause of the antipattern and to implement solutions that can be applied at several different layers in design. Let’s look at the first antipattern I discovered, the Blob.

The Blob is much like its namesake of horror film fame, the Blob. Here one single complex controller class is surrounded by many smaller data classes that merely encapsulate data. In this architecture process is separated from data, thus making this procedural style architecture. Some typical causes of the Blob are lack of object-oriented architecture or lack of any architecture whatsoever. A common occurrence of the Blob is from iterative development where code evolves from proof of concept to a prototype to a functional system. Another cause is a lack of architecture enforcement. But how can we fix this Blob problem?

Refactoring to the rescue! The first step is to locate sets of operations and attributes that directly relate to each other under a common goal. The next step is to locate natural homes from these groups and migrate them to their new homes. We then remove all redundant, indirect associations and migrate associates to derived classes to a common base class. Lastly, remove all transient associations, replacing them if appropriate with type specifiers to attributes and operations arguments.

This discovery of antipatterns for me was quite the find. I don’t know what but I still get a strange feeling when I hear antipatterns. It just sounds so menacing. The Blob was an interesting first antipattern to read as I’m positive that over my past coding projects, many of them would probably fall into this antipattern. It is nice to be aware of these potential issues now, rather than further down my career where it could have a greater impact if I ever do fall into the trap of an antipattern. I definitely plan to read more about these antipatterns and I plan to write about another one next week.

Until next time readers!

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

The Customer Wants What The Customer Wants

Hello, again my dear readers!

It appears that this week I am very focused on the customer this week as this article I read particularly focuses on what the customer wants. The article is titled, “Figuring Out What They Expected“. When it references they, the article is referencing the customer. The person you are programming the program or application for. Anyway, let us get into the meat of this article.

The article starts out defining two things. The first is what the user model is. The user model is effectively, what the user is expecting and thinking when they use the program. It bundles everything they know about computers and all their preconceived notions about using them when they sit down and use your program. How do I use this program and what does it do for me, the user? This is the model you are aiming to nail. If no one uses a program, does the program really exist? The answer is yes but we aren’t here to talk about that. The next model is the program model. This is what the programmer programmed into the program on how it looks, works, and operates. The idea in establishing this is that the user model and program model want to be overlapping or ideally mirroring each other. Now there are two ways to do this. The first is to change the user model. Good luck with that one. People are stubborn, stuck in their ways, and how would you even accomplish that anyway? Write a manual on how to use your program? We all know no one reads manuals anymore (although to be honest people really should) and if your program is different from what the user is used to, the user is likely to just not use your program. There is almost always another way. This leaves the program model changing to match the user model. I mean, let us face it, it might suck but you can change your program to match what the user will expect. It may be a pain but if it means your program is used more and ultimately bought more, I think it is worth biting the bullet.

The next part of the article goes over how to actually find that user model. The article has a simple and elegant solution… ask them. Then after you implement them, grab a few people and ask them to test them. Not a large group of people now. Only about 5 or 6 is required; after that, any more tests are fairly repetitive and not that useful. In the end, if the user has to guess how the program works, the program model is not quite there yet.

This article has reinforced my view that in this industry, the end user or customer is the ultimate determinant for a program or application. After all, we are programming an application for someone to use. If they can’t use it, its no good to them. I will admit, I’m surprised that only 5 or 6 people for usability testing are the norm. I do have a new appreciation for the Apple way of thinking where the simplest way to do something, is the way to do it.

Until next week readers!

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

Sure You Can Test, But Can You Really Test?

Good day my fellow readers!

As I have been learning all about software testing in class, the career of software tester has looked more and more like a job I would like to do. In my readings, I can across a blog post titled, “10 Qualities That Can Make You A  Good Tester.” I know hat you are thinking, “Ugh! Clickbait list articles.” but this one seemed relevant so I decided to have a read anyway.

The post starts off asking the question, ” What makes you think you are good at testing? Why do you qualify as a tester?” The author was saying that anyone with enough knowledge can test a program. It falls to different qualities of the tester that truly make them a good tester.

The first quality is that the tester understands priorities. What should be tested, what should be automated, what requires manual testing, what should be done first, ect. You are given a thing(s) to test and you have a limited amount of time to test them. Prioritization is a must.

Next, the tester should ask questions. The questions go farther than just, “What is my goal?” They must deeper like what changed, what was fixed, what is the product used for, or who will use it. The more understanding a tester has, the better they can do their testing.

The tester must be able to create a number of ideas. There isn’t just one way to test one thing and one product may be used in different ways. Simply put, more ideas = better testing.

The tester must be able to analyze data. Not knowing what data you get back means you are missing a big part of your testing as much of automated testing is reading and understanding data.

The tester must be able to report negative things in a positive light and be good at reporting. These are technically two points but they are practically the same thing. Reporting something in a positive way, even if negative, is a great way to build solid communication and improve teamwork. This plays into good reporting. People want to hear straight and to the point reports that get the point across and all the important parts. No one wants to sit there and read a list of negatives for minutes on end.

A tester must be able to support the developer. This goes beyond just finding a bug for example. A developer can’t fix a bug if they are having a hard time even recreating it.

The tester can co-relate real-time scenarios to testing. This sounds like a lot but it really boils down to A.B.T. Always Be Testing. Almost like improve testing. If you constantly test thing in your life outside the office, it can give you ideas to test things inside the office.

A tester must be a constant learner. Like the rest of the programming industry, nothing stands still and you shouldn’t either. Learn new technology, new tools, and new ideas.

The last trait is the tester must be able to wear the end user’s shoes. The ultimate goal of the product is to send it to the end user. If the tester can’t understand the end user, the end user will most likely not be happy with what they get.

One big thing stands out to me after reading this list… the end user is everything. In just about every article I have read the end user will without a doubt make an appearance in one way or another. If I can’t get my head around what the end user wants, I will not last long as a tester. The co-relate real -time scenarios was an interesting one as I like most, probably leave work at the office and never take it home. This takes work and home and fuses them keeping the skill of idea generation at the forefront. What surprised me a bit was that the reporting skills were geared toward streamlined and quick reports. I had expected reports in the testing world to be longer and more technical. This may just be the writer’s individual experience but it does make sense to me. The people testers report to literally made the thing they tested. They probably don’t need a nitty-gritty teardown.

Now I have some things to work on as a programmer before I graduate. They don’t seem hard thankfully, just something that requires a lot of time.

Until next time readers, have a good day!

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

Software Architecture Patterns: Building Better Software

Hello again, readers! Today I dove into an article by Peter Wayner detailing 5 different design architecture patterns for software design and their benefits and weaknesses.

The first is Layered architecture. This is where data enters the top layer and as it passes through each layer, the layer performs a specific task. A major benefit is that each layer is maintainable, testable, can easily be assigned roles, and are easy to update and enhance. However, this can result in the source code being very messy, the code can be slow, the whole program can be hard to understand, and changing a small part could be impossible as you may need to change the whole program.

The second is Event-driven architecture. A central unit is built that accepts all data and then delegates task to separate modules to ensure that your program isn’t just waiting around for something to happen. This allows for the program to be scalable, adaptable, and easily extendable. This can lead to complexity when testing and error handling can cause troubles in development. Essentially, the more each module is dependant on the others, the more troublesome the entire program becomes.

The third architecture is Microkernel architecture. This architecture uses a set of core operations that are repeated over and over again in different patterns depending on the data given. If needed, different modules can be tacked on to allow the program to perform different functions and patterns. The difficulty with this architecture is that getting the plug-ins and microkernels to cooperate can be tricky. There is also the trouble of not being able to modify the microkernel once plug-ins start to depend on the microkernel.

The fourth architecture is Microservices Architecture. The main idea here is to build a number of different tiny programs that will handle one specific task instead of having one big program do everything. This also allows some individual programs to be scalable up to a large size while others are kept small. Some downsides are that some tasks can’t be easily split up into a single microservice. Each microservice must also be independent or the cloud can become unbalanced. Lastly, if tasks are split up amongst several microservices, the communication costs can begin to skyrocket.

The final architecture is Space Based architecture. This architecture is designed to split up processing and storage between multiple servers. This protects against collapse under a great load. Data is stored across the nodes and information stored in RAM. This does make many simple tasks quicker but can also slow down computational tasks. This architecture can also be referred to as Cloud Architecture. The main drawback with this is that with RAM databases, transactional support is difficult. Testing the entire system can be difficult as well.

This was an interesting read as it went one step higher than what we learned in class so far. This covered the upper level where multiple programs come together while in class we cover designing a single program. The Space Base architecture was quite familiar as I learned about it in a Cloud Computing course I took earlier in the year that dealt with Hadoop. The Microkernel architecture was cool as well as I personally use Eclipse to work on in-class projects and learning more about its overall architecture is something I thought I would never dive into. The Event-Driven Architecture has given me an idea for a way to work on the final project that was recently assigned to us in class. Hopefully, it works out as putting something you learned to use is always a rewarding experience.

Until next time readers. Have a wonderful day and see you next week!

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

Time Isn’t Something I Can Afford To Waste!

Good day, my dear reader! As I continue my education in Software Quality Assurance, I continue to read blogs and keep finding myself reading a blog about how to do one particular topic, or how to test in one specific method. Now those reads were all good and useful but one particular article caught my attention, “5 Reasons you are wasting your testing time“. Now I will admit, I did succumb to the very obviously clickbait title but, this was one title I am glad that I followed. In class, there is a lot to learn but some things are best learned on the job or get glanced over or forgotten in the classroom. This particular blog was about 5 ways to review your testing time and see where you are wasting yours.

The first way is not setting a clear goal. Establish a goal for the testing session and ensure that by the end of your testing session, the goal has been met. The second way is that you might not understand the value of the tested feature to the end user. This is saying that, while we are tasked to test a feature we should keep in mind if this feature actually is useful or helpful to the end user. The third way is that one doesn’t keep track of what was tested and your finding. This boils down to that you need to be able to adapt your tests as you are testing. Fourth is not consulting existing information to get testing insights. The last reason is refusing to do post-test reviews or feedback sessions.

The first thing that popped out to me is the consideration for the end user. This is definitely something that is not talked about in class. It’s something I keep running across and I hope I can keep it in mind as I head out into the job market. The end goal is to create a usable, program that an end user will actually use or purchase. The next thing that jumped out at me is that some testers, “…who say they consciously prefer not to see the previous test-runs or the bugs found in an area of the system in order to avoid any bias towards those areas during their current testing session.” I found this kind of silly that some people see testing a program like a clinical double-blind study. When I hear testing, I think of video game testers effectively ramming their heads against a particular part of a game until it breaks or they do. While I doubt I will ever have this mindset, it’s always good to know what to avoid. The last thing that caught me was that testing, “While at the same time it is an art, as you need to (almost instinctively) know how to adapt and change your testing based on actual stuff you find along the way.” This caught me off guard admittedly. Testing does seem dynamic to me but not in that sense of having to change the nature of a test mid-session. This is something that I will have to remember and try to put into practice out in the field.

Thus ends another blog and another week of discovery and learning. I can only wonder what I will learn next week and I am definitely excited to find out. Until then, have a good night folks!

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

Round Earth, Round Testing

As class has progressed this semester, we have learned several testing methods and strategies. While perusing the internet, I found another intriguing test strategy not discussed in class called the Round Earth Test Strategy. This testing strategy turns the test automation pyramid on its head by adding spheres to the triangle.

At the core of these spheres is the Earth, that classic blue sphere we all know and love. We then add concentric spheres around the Earth sphere representing the different levels of testing. Add in some static and dynamic elements such as data and from this we can then take a big slice and lay it out, giving us our Round Earth Test Strategy. One will notice that it does, in fact, turn the test automation pyramid on its head as the base of the triangle is now on top. This maintains that during testing our attention must be towards the surface and the user experience. It also takes our attention away from the lower part of the pyramid which represents the lowest level of the technology, something we rarely test or even can test for that matter. The Round Earth analogy lends itself to good analogies and to deep reasoning as the analogy greases the mental wheels gets the gears turning. The presence of data in the test strategy reminds the testers about data and the model can show testing problems that can occur at multiple levels. Lastly, the model reminds the testers about testability.

The first thing that struck me about this model is that it keeps the user in the forefront of the testing. The author reminds the reader that the worst person to test a program is the developer themselves. The “curse of expertise” puts the developer in the “underground” of the model while the users are living on the surface of the model, a different world compared to the world the developers are in.

Another interesting thing that struck me was that the model puts an emphasis on data. Just recently, in class, we did some work with a half-finished program and tested it using dummy data. What strikes me was that while testing there was little to no concern for what the data actually meant and we only cared in the program compiled and passed the tests, and the Round Earth method puts emphasis towards that data.

The last bit that struck me was that this model lends itself well to the analogy and that makes it easier for people to understand. While this isn’t necessarily helpful for a good model it is always helpful when trying to explain it to your colleagues for a second opinion!

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

Keep Software Design Simple

Good day my dear reader! With it being quite deep in the semester now, one can correctly assume that I have learned quite a bit regarding Software Design and I have. With all this new information, I read an article that has helped me put all of it in perspective. This article was Simplicity in Software Design: KISS, YAGNI, and Occam’s Razor from the Effective Software Design blog.

This particular blog post is all about keeping your software design simple and details three different design principles to keep in mind while designing software and the effects of making a design too complex and conversely too simplistic.

The first principle is, “Keep it simple, stupid” more commonly known as KISS heralding that keeping designs simpler is a key to a successful design.

“The KISS principle states that most systems work best if they are kept simple rather than made complex; therefore simplicity should be a key goal in design and unnecessary complexity should be avoided.”

The next principle is, “You Aren’t Gonna Need It” or YAGNI stating that functionality should be added only when it is actually needed and not before.

The last principle is Occam’s Razor, saying that when creating a design, we should avoid basing our designs in our own assumptions.

Not following these principles can result in complex designs that lead to feature creep, software bloat, and over-engineering. It could alternatively result in oversimplification where the design is too simplistic. This could lead to trouble down the line in areas such as maintainability, extensibility, and reusability.

Reading this blog post, made me sit back and think about my previous programming assignments. Looking back, my programs have been indeed, overly complex. A great quote provided in the blog post is from Brian Kernighan.

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”

This gave me a good chuckle and is something I can definitely agree with and have done in the past. I will admit, that I had never considered the consequences of oversimplification. When the majority of your programs are single use for a specific scenario, you never really have to consider the consequences outside of getting the program done. An excellent quote provided by the author in the blog is from Albert Einstein.

“Keep it simple, as simple as possible, but not simpler.”

I completely agree with the author here that this quote expresses the danger of simplistic design that must be considered. It is easier to make things too simplistic rather than hitting the sweet spot of as simple as it needs to be.

This article will be one that I intend to keep in mind whenever I sit down to start a new programming project, especially as class projects start to roll up this time of the semester and I do believe that simple software design will greatly improve any designs that I come up with, keeping KISS, YAGNI, and Occam’s Razor in mind.

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.