Behind the Scenes of Web App Development

In this blog post I will try to explain parts of web app development process that clients usually do not see: planning, some aspects of writing code, refactoring and code reviews. Even though our clients rarely pay much attention to these processes, they are important parts of building high-quality web applications.

Web app development typically goes through the following steps:


Before starting to code the first feature of a web application, we create a private git repository where we will store the code. This repository is shared with the clients so that they can access the code we write, see commits with comments, and know who is doing what almost in real time.

After this, we generate a starter Rails app and enhance it with a set of standard libraries for testing, monitoring, and useful tools for future usage.

At this stage we also consider various libraries that can help us to speed up the development process down the road. For example, we can use ActiveAdmin as an admin dashboard, a CMS library for managing web application’s content, a ready to use open source forum, or a blog engine. We also consider using third party APIs, JS libraries for visual data presentation, and more. It’s critical to plan this before any coding starts, as it can be hard to replace some libraries with another at a later stage.

Next, we think about how to build the data model, how to build connections between elements, and which relations we will need to achieve our goals. As a result of this step, we have a hypothetical business model structure. For example when we are going to build a ticketing service, we may have following models: Event, Ticket, TicketType, Order, Client.

As you might have already noticed, we haven’t written a single line of code yet. Investing enough time in defining and modeling base elements of future system is extremely important, since changing the plan in the future might significantly increase web app development cost. Imagine a situation where developers select a specific JS library for data visualization and after 3 months of work you see that it is not possible to implement a new feature with this library. The only solutions to this issue are either to drop the feature or replace the library and redo 3 months of work related to data visualization.

Writing code to implement features is a simple process when it is clear what should be done. Because of this, we invest time in clearly defining how everything will work, what behavior we expect, and what goals should be reached by web app users. When all is clear, building a new feature becomes easy.

Along with writing code for new functionality, developers also write tests to make sure the code works as expected.

When we iterate on specific functionality a number of times, it might become necessary to refactor existing code. The first version of the code is not always the best of what’s possible, and after a few iterations, it becomes obvious where existing code can be improved. As a result of the refactoring process, the code becomes easier to understand and easier to maintain. The process also has the added benefit of decreasing the probability of new bugs appearing in the future.

If it takes just a few hours to refactor the code, we often do not even notify our clients about this work (and don’t bill for it); sometimes, however, refactoring can take days to complete and in this case we explain the pros and cons and ask for the client’s approval before proceeding.

An important part of the coding process is code review. We do this on a weekly basis when every developer looks at the code of his colleague. A fresh pair of eyes always sees code differently and can point to code that “smells.” There are number of stamps of bad code, and the goal of code review is to find those parts and bring them to the developer’s attention. Code review can be done in a pair or going through the git repository. We use both methods.

Another part of writing the code is knowledge sharing. Any of our developers can ask any other developer for help and comments. It is common practice for us to help each other by sitting together and thinking on one challenge with two heads – this significantly improves the quality of the work we do.

As a result of all those steps, we deliver clear code of a quality web application that is scalable and easy to be maintained by any Ruby on Rails developer.