Category Archives: Week9

Get a (rewriting) hat!

One thing that stuck out to me is the concept of a refactoring hat! It is the idea that if you’re refactoring your code and you feel tempted to change the meaning of the code, don’t! So get that hat and remember to keep things intact when you start cleaning up!

For me, this was something that felt very important, since I often have a distinct issue where as I’m going back on old code, I realize that I could do something an entirely different way because of a new perspective. This often makes the code a bit better, but at the same time, I often change the functionality of it, so not only do I have to edit that one portion, but all the portions of my code! It isn’t that my code is too coupled together or that it’s rigid, but because my intent changed and this is hopefully where my refactoring hat comes in!

As noted in the website, a good way to recognize if you’re changing the intent of the code is to make sure that you are not rewriting Unit Test. If you’re refactoring and your Unit Test seems to still work without any changes, then that means you’re on the right track! But if you refactor and find that there are things you need to change in your Unit Test, you better put your hat on more securely because you’re past the point of refactoring!

This is essentially the concept of Rewriting vs Refactoring! To paraphrase MarnixKlooster, refactoring is cleaning things up, so you have more wiggle room when designing your code. In essence, making more design space! While Rewriting is creating code that meets new specifications and implements algorithms and data structures that are more efficient than the previous ones.

Though both of these seem similar, they are very different! From my understanding, Refactoring is like cleaning up your room, you know, sweeping it, mopping it, etc! But Rewriting is rearranging your room entirely! Move your bed, your table, add a new desk, all the little bits and bobs! Though they do seem similar, they are very different!

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

Find Mentors

Whether a beginner starts out with a training course or isself-taught, the first step on the path to softwarecraftsmanship is finding a craftsman to apprenticehimself to.Pete McBreen, Software Craftsmanship, p. 96 So far I like this pattern a lot, and I feel it’s close to what I’m trying to do during my studying, my previous … Continue reading Find Mentors

From the blog CS@Worcester – Shams's Bits and Bytes by Shams Al Farees and used with permission of the author. All other rights reserved by the author.

The Long Road

To become truly good at programming is a life’s work, anongoing enterprise of learning and practicing.Ron Jeffries et al., Extreme Programming Installed This pattern from chapter three caught my attention, the quotes they used in the beginning of this pattern were nice and  sometimes we need something to remind us that the 1000 mile journey … Continue reading The Long Road

From the blog CS@Worcester – Shams's Bits and Bytes by Shams Al Farees and used with permission of the author. All other rights reserved by the author.

Post #6: Quality Code Response

Hello and welcome back to Benderson’s Blog with me, Ben Anderson. This week we are discussing what is quality code for programming purposes. I grabbed a blog post from the blog Simple Programmer written by Peter Grainger where they discuss quality code and what makes up quality code.

The blog begins with what you should know to write quality software and they recommend a book to read that will give the directions more precisely, then he writes a section that is pretty interesting called “What you don’t code is more important than what you do code” and he sums it up with “The more code you write, the more potential bugs you could introduce”. I haven’t thought about it that way but that line definitely makes sense. Then he goes into setting goals and targeting a persona, you got to set what you want and what your users want from what you’re making and making quality code for that software is a mixture of the two and you go to be precise as you can. A key paragraph in the post is titled “Define the structure of the software in as much detail as possible” This is an important part of quality code as being the most detailed you can be, the more you will, and other people will, understand what is going on with the software.

The last couple sections discuss a couple things that I have talked about in past blogs such as the more tests you do, the better your code will be and the less bugs you will have, also the more reviews you have of your code the higher the quality and the fewer of errors you will find in the code and you just got to maintain your code and make sure its readable for future users and even yourself.

This blog was very informative on the subject of quality code and provided a great insight on what the writer thinks the common coder should know to write quality code. For me, an up and coming coder, its great to know how to write quality code for my future colleagues that I will be working with. The more they able to read and understand my code, the easier it will be for them and I to cooperate and work together on projects that are boss wants us to complete. In my class we are writing quality code to be tested to see if it will pass and we are doing that in groups which will already help me work in a team environment. I highly recommend checking this blog out, I provided the link at the bottom of this blog so you can go check it out. Thank you for joining me this week on Benderson’s blog and I will see you next week!


From the blog CS@Worcester – Benderson's Blog by Benderson's Blog and used with permission of the author. All other rights reserved by the author.


Team Retrospective – Sprint 3

Overview : 

          This was a very pivotal sprint period for us as a team and class because we each began to work on the tasks and duties that we decided to contribute to this project. It seemed like it took forever for us to build traction on this project as a team but once we began to figure out which direction we wanted to go, everything began to speed up and move very quickly. We took upon the task of ensuring an offline service exist within the Ampath application where you would be able to log on and work even if you are offline. After many brainstorming moment and code reviews, realized that we cant even focus on building an up and running module before we try to collaborate with other teams because all are work and tasks have external dependencies on other teams tasks and involved factors that were beyond our control.

What Got Done 

As a team, we were able to accomplish many tasks that we set out to do. Initially, we all wanted to understand the code enough to be able to ring about ideas and how to approach our offline login task. we were able to create an overall architecture/design of offline login feature using Balsamiq. This was a task that was handled and led by George and Mathew. Another thing we decided to do was also look into the bridge designer pattern as it helped us understand and decide which approach we want to take our design’s architecture and functions. After extensive code review we decided finding out which servers  handled the current logon process and the methods would be key in our development of the offline logon process. Once we understand how they have it working , we could implement their methods and get ours up and running.

Conflicts/Issues Moving Forward

As of right now, we as a team have a few issues that need to be addressed in order for us to continue making progress. We realized that we would need to implement a database to be able to test and ensure that what we came up with works. The issue is that one of the teams in the class is also building a database for the project so we are at a point where we feel that we need to amplify communications between the two teams. We did decide to use a  mock/test database to aid us in building what we need and design the UI also and then after that, we would collaborate with the team to make sure that the specs and methods line up so that merging the two modular designs would be easy and compatible.  Through this process, i have learned that to build a software that involves multiple components, you need to communicate with the other teams working on the other components so that in the end, bring the software pieces together does not become too tedious. 

 Looking ahead, i feel as though we have a good grasp of the direction that we want to take our project but need to continue to collaborate and talk with the Ampath team and see if they see eye to eye with our approaches and designs. The next few weeks should be very interesting ! 




From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.

Blog 9: Decorator Design Pattern Response

In today’s blog I’m going to talk about a blog that was written by Brian Ambielli who is a Senior Software Engineer and he wrote a blog talking about a topic that I have to do a project for called the Decorator Design Pattern. There are many design patterns for programmers, some that I learned this year were strategy, singleton and factory patterns which we used for our first two projects in the class. Anyways, Brian goes in depth about what the Decorator pattern is about and how it is used.

The Decorator Pattern allows you to give your objects new responsibilities at run time without making any code changes to their underlying classes. This pattern allows the user to extend objects with added functionality at run time and also gives the developers the power to compose objects that are purpose driven for current demands of their users. Brian says that Decorators can be thought of as wrappers around the object they are decorating, the object being decorated in these cases is the SuperType, then the decorated object can be passed and used in a program in place of the original wrapped object. Then he shows a diagram exampling what the Decorator pattern looks like and after explains what each of the parts of the diagram do to make it a Decorator Pattern which is really nice if you don’t understand it by looking at it. Then Brian provides a example with a Pizza shop talking about its toppings and different crusts and all the variables that are considered with a pizza, he then puts another diagram up showing how the decorator pattern would look with this example. Lastly, Brian provides some negatives of the Decorator Pattern and why it can be a pain to use sometimes.

This blog by Brian was very helpful, not only helpful because I didn’t know what the Decorator class was before this blog but that it is also the same topic I’m doing my project on for my college class, so now I have something to look at and use for my tutorial that I have to write for this class. Brian providing examples will also help me with this project as it helps me understand it better and makes it easier for me to make my own so I can get a good grade on the project. Besides this being helpful for my school work, Brian provided a lot of detail in his blog that could be helpful to anyone trying to learn about the Decorator patterns, him providing examples and telling people how the Decorator class exactly works and may help people decide to use this for their programs in the future. Brian didn’t just do the decorator patterns, Brian has blogs on all different types of patterns. The blog also providing what the negatives of this patterns are helpful for people like me who want to see what could go wrong with using this design pattern in future cases. Thank you for reading my blog post on the blog by Brian for the Decorator pattern, if you want to check out any of Brian’s blogs on any other patterns, I’ll leave a link at the bottom.


From the blog CS@Worcester – Benderson's Blog by bendersonsblog and used with permission of the author. All other rights reserved by the author.