We, the interns (Lawrence, Raunak and Andrew) have been here at Unboxed Consulting now for a little over 3 months. As a little introduction to ourselves and what we have learned, we felt a short blog article about our experience would be fitting. We would like to discuss what we have been learning over the course of the internship.
So, to move one then, the first thing that we would like to discuss is test driven and behaviour driven development using RSpec and Cucumber. Coming from a background with little formal training in the way of web development, I personally have often found it hard to write clean structured code. Many of my earlier projects involved a great deal of ‘hacky’ and ‘bodged’ ideas. Admittedly this was often down to a lack of planning and as such, only building upon an idea and learning a great deal of the substance and processes involved in creating a large web project along the way.
Much of the ethos I have found here at Unboxed Consulting so far has focussed on precisely this issue, making sure that projects are clearly planned, well communicated and above all “Agile”. It is for this precise reason I have found my time here so far to be not only informative but also structured and organised and most importantly helped to improve self discipline in the way a project is approached.
The main point I would like to focus on here though, is the use of Cucumber and RSpec to carry out test driven and behaviour driven development. The idea here is to layout, explicitly, the users experience throughout a web based application. Cucumber allows us to create simple step by step “walkthrough guides” of an application, allowing us to see precisely what our goal is within a project. Once these step by step guides have been created we can then begin the process of writing an application with the simple purpose of passing a test. Although writing underlying code to interpret these verbose tests takes time, in many cases this time can be made up by simply having a step by step plan of what we would like to create. When working on a project we no longer ‘bumble’ through a project making components ‘sort of work’ with no real sense of direction. Instead we can create clean code which simply meets the requirements of the task at hand. For myself, I feel much more structured in the way i work and spend much less time focusing on smaller issues or being sidetracked by from the point and functionality of a project. In many of my previous projects features became more important than functionality and often code would become bloated or simply illogical because of poor planning and an indecisive attitude.
There is a saying I often hear at Unboxed Consulting, “Are you sure you need that?!”. I guess, in my eyes, this doesn’t necessarily mean forsake features but simply look at what is really required. If you don’t think you need something yet, then don’t implement it yet. What you think you may need now may well change drastically in the future. As one of my lecturers always used to say “KISS! - Keep it simple stupid!”