Outsourcing software development and code is usually not anyone’s first choice.
And we get it, it would be perfect if everyone could have the same in-house dev team forever. To not have to worry about onboarding new hires, rewriting code after the previous ones, and just wasting hours trying to understand what the heck that code was supposed to do.
But in some areas there are more tech jobs than developers. Building a dev team can take many months.
Most companies still prefer to wait for their perfect in-house hire, because they believe bringing in an outside developer is more trouble than it’s worth.
We’ve spent a lot of time optimizing our process to make sure those fears are wrong.
So let us show you how we make sure that bringing in our developers doesn’t disturb your workflow and taking over the code after us is an easy transition.
#1 Stylish code
When you’re a Cowboy Coder, you can create your code in the image of your messy, non-intuitive mind. If that works for you.
But when you’re hired to build an MVP, or to write a small part of a project, or as a temporary hire, following clean code principles is an obligation. If it takes months to make sense of the mess you left in the code, no one will want to work with you.
To make sure our code is elegant and clean, we use Rubocop, a static code analyzer for Ruby that helps bring our work to the Ruby Style Guide standards.
#2 Self-documenting code
Did you hear that comments in the code are like an apology for messing up?
Although this seems exaggerated, there is some truth to it.
We structure our code for maximum readability. We use meaningful names to convey intention. We make our codebase as self-explaining as possible. Thanks to all this we rarely have the need to put comments in code. But there are situations where comments are justified and beneficial.
For example, sometimes you need to work around browser bugs – in such case we leave a comment explaining exactly what the problem is.
For another example, comments make it easier for project managers to navigate a big codebase.
#3 Tests included
Strict TDD (test-driven development) is not always the best choice.
While there’s no doubt that it reduces the number of bugs, it also inflates the size of code that needs to be maintained. And sometimes, like in the case of front-end dev, TDD resembles building a kitchen robot and a pizza oven just to make a toast.
So we usually practice a more liberal variation on test-driven development:
We write tests, it’s part of our working culture, but we use different approaches depending on what’s needed: TDD, BDD, writing tests after writing a functionality. Or in some cases, just manual testing. For example: it would be a waste of time to write an automatic test for a simple text-to-JPG generator.
#4 Separating backend and frontend
We recognize that in modern web development, backend and frontend are actually two separate applications. Both parts communicate with each other via clean, thoughtfully designed REST API. This separation brings important benefits.
You can’t always hire full-stack developers. Sometimes you hire just front-end devs, mobile devs and back-end devs who stay in their own separate apps.
Our clients can base all their front-end apps – web or mobile – on one ready-made backend. You don’t need your frontend dev to know Ruby in order to get data from the backend.
#5 Using well-known standards
So if your front-end developer has worked with any REST API before, they’ll easily find their way around ours. Same goes for mobile devs – they just need to build the front end for the mobile app.
In the JS ecosystem there is a myriad of available libraries and frameworks for every imaginable task. This is increasingly becoming a problem. We use well-known and standard frameworks, such as AngularJS, so that you don’t need to learn some exotic technology to maintain the code we produce.
#6 Refactoring as we go
Some devs leave refactoring for when they finish the original code.
We know it’s never finished.
So we aim to refactor as we go. As soon as we see a code block that should be optimized, we do it. Not when it causes a predictable problem, not when its dependecies grow into a CPU-eating vortex.
The first rule of refactoring is: If it ain’t broken, don’t fix it. :) So we always balance between correcting every imperfect line of code, and leaving refactoring until the end. If you hire a developer, you don’t want to pay them for tinkering with something that works perfectly fine.