At aFrogleap, we work with a nice mix of creatives, techies, sane and crazy people. With this development series of articles, we are going to have our techies write about topics that contribute to giving insights to our development process. Basically, a sneak peak under the hood at aFrogleap! This is the first article in this series that will focus on the setup of the development environment.
At aFrogleap we try to work according to what Valve calls “flat land”. This ensures all engineers are truly equal and all engineers’ decisions are open for discussion. The idea behind this philosophy is that all professionals should be able to suggest things without self interest. In other words, all suggestions should be realistic and truly beneficial for the quality of the project. Sometimes it can be difficult to accept someone else's ideas when you are invested in your own idea. But I suppose that makes you a professional is that you always seek for improvement.
Besides using other people ideas, you have to wonder about using certain tools. Some may look impressively but are rarely used in practice. A perfect example is Continuous Integration server (CI). It’s full of fancy build progress statistics with success and fail percentages and nightly builds and all the rest of those things that sound and look cool! Although they only become really cool when engineers actually use them. Before it gets too technical, let's break it down into byte-size chunks.
An Integrated development environment (or rather IDE) is the software tool that software engineers use to write code in. This usually enables them to have the source code in fancy colors so it doesn’t look like matrix code when you have to add code to an existing project. All the features that engineers often use are usually supported by the IDE. Like finding a given text in the entire source code (which can easily be over 9000 files) and replacing it with another value. Other features are following linked files to see what certain code blocks execute, and compiling the software. In theory, all these tasks can be performed with command line and basic tools such as notepad, but then it wouldn’t look as fancy as it does. For Android development the IDE is usually Android Studio.
This does not mean having control over many different versions of your app and/or website. Instead, it is a tool that maintains all the versions of code that have been written. From the moment the first character was added to the source code to the last one. It’s a ‘record keeper’ a librarian of the code, with letters being the books. It keeps a record of:
- What was done?
- By who?
- And why certain features were implemented?
It also enables engineers to work together on the same project and combine their newly written code as if they worked on the same computer at the same time. The version control tool Git is what we like to use and it’s also considered the leading standard in software development.
When an engineer has written a new feature for a project, the version control software is able to show the differences between the old version and the new version with the newly implemented feature code. At this point the engineer asks his fellow engineers to review his / her changes to see if nothing important was missed. This peer reviewing process can result in a technical discussion or just be agreed on. As a result of the review process even a new rule that should be addressed in all projects can be introduced.
Automation takes a long time to setup but it will save a lot of hassle in the long run. CI server is the logical starting point for automated processes. The CI server is a machine that does a few tasks that will take a lot of time to do manually and that nobody wants to do. Amongst those things is an automated process of reviewing code. It’s like a human code review, but then it’s done by a machine. A machine will be able to notice other things then a human. Humans usually tend to skip over certain parts that might look too simple, or skip parts that he or she doesn’t want to ‘complain’ about to his colleague, like formatting; proper indentation of source code or something trivial like that - computer reviews have no problem with ‘hurting’ engineers feelings in that way. An example of CI server that we like is Jenkins CI.
Functional testing will most likely save you the most time in the long run. It comes down to a script that runs every app or website. While the app or site runs it performs tests (certain user scenarios). For example, it will place an order or it will try to like a certain article. When new code is being implemented, it doesn’t make sense to have the engineer test everything single possibility in the app. The engineer will focus on testing the new thing that was just implemented.
At this point the CI server is happy to help run those human scenarios and see if all the defined scenario’s are still working. You might have guessed it, “automated testing” means that those steps need to be defined. They need to be programmed. It takes a lot of time to define those scenario’s first in code and then in a functional test. But when you have them , it makes a perfect world where you can find all your bugs before setting your app out in the wild. I’d rather have the CI server crashing the app than the app user, right? Calabash is a functional testing framework that I prefer over all the others for it's portability to iOS, and unlimited scalability.
In the end it all comes down to how serious the effort should be when it comes to software development. It may take a lot of time to replace a lot of manual code for some fancy library, or implement extensive functional tests that run every night. Even though the solution is technically a better solution, most of the times the reality is that time constraints prevent this. The engineers at aFrogleap deal with this on a daily basis where they have to choose between the real world and the right choice… It gets easier… right?