Floating FB popout byInfofru

For more plugins visitReviewresults

Twitter Feed Popout byInfofru

Information about what we do

Think about your code

Think about your code

write code so you can sleep at night

We recently released our first game title to Apple iTunes after a grueling development journey. It has been a long time coming, but we finally managed to ship the first release of the game for both iphone and ipad. To be honest, this project has been one of the most challenging development activities that we have undertaken. It involved ground breaking technical challenges only which game development projects can face, coupled with trying to build a reusable framework that all of our other games (in the future) will reuse. I am happy to say, that we have done exactly what we have set out to do. Except acquiring a few more grey hairs in the process. That was a mistake!

Developing any software requires proper planning, excellent project management, great developers, innovation, determination, excellent problem solving skills, proper tooling, patience and don't forget lots of beer! Even though you may have all of these factors, what makes great software is designing and creating the solution in such a way that makes it easy to maintain, fix bugs (when they pop their head up and they will) and add extra functionality without having to rewrite the whole system. Often what happens is when software is created, it is quickly put together which satisfies the required functionality and put into production use without question. Hey, it does the job right now, why plan for anything more right? But as changes are requested and/or needed (and it will happen), the system quickly becomes harder to change and maintain. Why? Well it generally comes down to a failure to create a design from the very beginning which caters for future potential changes, or at least, designed in such a way that you only have to make changes in single places, rather than multiple. I am not saying that if you plan a design up front or you use TDD, design patterns or any agile methodology your code change journey will be pain free. No, not at all. What I am saying, is it will be far less painful than if you didn't.

Our internal systems and products adhere to this design philosophy. We spend a bit more time in the beginning planning out the "potential" reusable parts of the system, whilst at the same time identifying where we can use design patterns even as we develop. Throughout every sprint, we always think to ourselves, "I may reuse this again, so I am going to write it in a way so I can", whether it is a function or an object. One of the most painful experiences that developers face day to day is making code changes to a legacy system for a requirement they get and it turns out that they have to make multiple changes because the code hasn't been designed in an appropriate way, to minimise the amount of code change. Oh my lord can that be painful!

One thing we strive to solve is to keep code change to a minimal (if possible). If things need to change, we only want to change them in one spot. We love the Single Responsibility Principal because it governs the way we think about our software, our objects, our methods and even our tests. Essentially what this principal identifies, is a piece of software, component, or method should only be responsible for one thing and one thing only. To put this statement into context, say I am writing a component that is responsible for handling an in game notification to the player while they are at the menu screen playing Bogan's Run. What this component is actually doing is:

  1. Making a http request  to facebook
  2. Parsing the response from facebook
  3. Showing a popup to the user to let them know they are online and only when they are online

If you break down the anatomy of this problem, you see that it is actually doing 3 pieces of discrete work. This functionality could be written like this

public void FacebookFriendNotifierPopup::showNotificationToPlayer(const string& friendsId){

//lots of code to get http

//lots of code to parse the result

//code to display the popup on the screen

}

As you can see, there is quite a bit of logic involved here. What might make sense is having this method, make calls to other methods. Each method does one thing only and one thing well. That way, this problem can be broken down into 3 methods, which then can be tested individually.

public void FacebookFriendNotifierPopup::showNotificationToPlayer(const string& friendsId){

auto resultFromFacebook = getResultFromFacebook();

auto facebookResultInfo = parseResultFromFacebook(resultFromFacebook);

return facebookResultInfo.isOnline()? true: false;

}

This is a very simple example of this principal, but it this is the foundation to writing more maintanable and reusable code. In this example, I am using methods, but these could easily to delegations to other objects/components/services, which then can be used else where in the code base! Mmmmm, code reuse.

Regardless of the type of software that you create, it should be created in such a way, that it is able to be changed relatively easily from the very start. As you create your system, you should also think "hey, is this useful? Can I use this again?". If the answers are yes, then, rip it out and put it into its own method. Even better, into its own object.

I often get questions when working on legacy code which hasn't been designed with maintainability in mind, like "how easy is it to make this change?". If the code has high coupling with lots of other stuff and has lots of duplicated logic scattered throughout the code base, I say....hmmmm, it's gonna be very painful. However when I see modular code, with lots of objects following the single responsibility principal, I say....hmmmmm, it's gonna be painful, but I'll live.

To sum up, what was all this about? Well, it was really just to show case the importance of writing great code, but writing great code that can be changed easily. People often marvel at their code creations and say that the system is great. It does X, Y, Z, it's rendering at 60 frames per second, or it can handle 3,000 requests simultaneously. I often say, "that's awesome. How easy is it to change it to do X?". I often get a glazed over look and quickly followed by silence because they think...it's gonna be painful.

My advise is really simple. Make sure you write your code to be maintainable, easy to test and use design patterns where appropriate. If you are not familiar with design patterns, I encourage you to look on the internet for the term "design patterns" and see if you can spend a bit of time reading about them, and even trying to use them within your existing code bases. Design patterns are great, and once you get familiar with them, you will start using them in design related conversations with your coworkers and every other aspect of your coding world.

Comments are closed