Separation of Concerns

9. August 2011 17:57 by Cameron in Programming  //  Tags: , ,   //   Comments

A good programmer makes sure to provide proper separation of concerns while coding applications. This makes maintaining the application's source code much more manageable and it also prevents the application's source code from becoming one large function that does everything. Back in the days before object oriented programming and even procedural, it was difficult to separate functionality of one part of an application from another.

With procedural programming in a language like BASIC, many of you might remember the GOTO statement, quite possibly the worst programming language mechanism ever conceived. Using GOTO statements made application maintenance quite a challenge. People should never have to manage program flow manually through GOTO statements. They behave essentially like a JUMP instruction in assembly. However, in assembly, using constructs such as GOTO or JUMP is required as there is no other way to control program flow in assembly.

In languages such as C or later versions of Microsoft Quick Basic or QBASIC, the languages provide the ability to call functions from a main function, presenting a huge improvement in programming history. This made it possible to separate business logic from database/filesystem logic and thus was the beginning of better code.

With the continuing popularity of object oriented programming, separation of concerns is improved exponentially beyond what procedural programming had done previously. Programmers have the ability to separate their application's functions into objects that represent various parts of the application. For instance, in part of a user authentication system, one might create a user class that can then be instantiated and passed to the user data access object, the object that handles all the low level database interactions.

Using object oriented design, applications are clearly divided up into objects that serve their own individual purpose, while achieving the same end goal: a finished product. While there may be better approaches than object oriented design that become evident in the future, it is clearly one of the best way of modelling the real world in a virtual environment. Also, people think in terms of tangible items and enjoy representing application parts with objects. It will be interesting to see how the industry develops in the next 10 years and how design paradigms shift.

My thoughts on continuous integration

8. August 2011 17:29 by Cameron in Continuous Integration  //  Tags: , , , ,   //   Comments

Whether the choice is SVN or git or another version control system, I believe it is vital for software development groups to have a central source repository. My preferred version control system is git as it provides huge improvments over Subversion and you can work with a local repository without needing to affect the remote repository. With each commit or push to a team's central repository, it is important to check that the latest commit/commit doesn't break the main build. This is where continuous integration comes into play.

Continuous integration servers can attempt to build the source committed/pushed to the central repository and if the build passes, it can then integrate the changes into the main development branch. Some continuous integration servers will push the code to production once the code passes a series of unit tests and builds with the rest of the main development branch. However, if the build fails, the code will not be integrated into the main build and the failed build will be logged for reviewing. The event logging helps immensely with finding and fixing software bugs quickly, allowing the main branch to accept the changes made by the original user. This feature saves developers time and frustration in trying to sift through thousands of lines of code. Why should anyone manually check for a software bug if a computer can analyze the source code and find it for you?

With various continuous integration servers, project maintainers can view statistics such as commit/build success rate and code redundancy. In general practice, developers should never just copy and paste code. This is not coding. It's laziness. Usually, if you are copying and pasting code, you can probably refactor your code to use only one set of the code you were originally going to copy. There's no point having duplicate code in a code project if you can help it. One of the reasons it's a bad idea to copy and paste code is that the code base becomes harder to maintain. Another reason is that copied code doesn't necessarily work everywhere you paste it to. Just because it works in one place doesn't mean it will work as expected in another place.

With all of the benefits of continuous integration, I believe that every software development team should have some sort of continuous integration to track their projects whether they are an open source shop or Microsoft shop. Continuous integration really promotes the agile software development cycle and everyone should enjoy the advantages that it provides. I can definitely say that with all collaborated personal software projects that I work with I will make sure that continuous integration is key part of the development process.

 

Month List

Tag cloud