Developer Tips: How to Take Your Rails Project to The Next Level

We all started at the same point - learning how to code. Most of us focused almost exclusively on learning how to program in a chosen language and practiced it. And there’s nothing wrong with that. It’s natural when you start your adventure with coding. I’ve been there, done that. 

When I participated in the Monterail Ruby bootcamp and joined a commercial project with a huge team of developers, I noticed how many various areas are important during everyday workflow. It turned out that coding is just a part of that.

I wish I had known that when I was looking for my first job.I could have learned these skills or at least have an idea about little (and bigger) things that make a difference and take the project to a whole new level. 

So in this article, I’d like to show you how to work on the project more effectively and what beginner’s mistakes you can easily avoid. I’ll also share some actionable advice to help you become a well-rounded junior developer, ready to take up professional challenges. 

Side note - you don’t need a real-life project along with experienced developers to improve. You can try working on a small and simple project with one of your friends who also wants to start their adventure with programming. 

So let’s compare working on a project on your own with a project developed by a team of developers.

Branches and pull requests

Working on your own 

Beginners tend to push code directly to the main branch. From my perspective, my work wasn’t organized at all so I used to push code I was currently working on. Therefore certain changes weren’t correlated with the rest of the code I pushed. Moreover, beginners usually don’t focus on commit messages even though it could be a great history of implemented changes.

Working in a team

It makes much more sense to split bigger projects into several smaller tasks. For example, split implementing accounts into smaller tasks like create, update, and delete users, changing password, sign in, and sign out. Implementing small changes is easier for your coworkers when doing code review. In bigger projects, every snippet of code should be checked by another developer. Even seniors make mistakes or see things differently or do not see a tricky edge case that you might see.

Push each task onto a separate branch. So you have a great opportunity to create a pull request! Now you can see all your or your coworker’s changes by comparing the code with the one in the main branch. This is a perfect place to comment on the code and introduce better ideas.

Pull request is also a perfect place for a task description. A good description should contain the purpose of the task, why the changes have to be applied, and how it was implemented. Thanks to that other developers can easily understand the idea of changes being implemented and revise the code.

Once everything is done you can merge your pull request with the main branch and you still have a chance to get back to that code, see the discussion and description to understand why things were implemented that way instead of another one, and even reverse the changes if needed. 

Standardization of code

Working on your own 

Usually, we are the only reviewer of our code. That means we try to match our code style to that one found in an article or a tutorial. After some time the code style deviates across the project. We need a convention on how to style our code or name methods and classes and stick to it.

Without unification we may mistakenly write methods or classes responsible for several, not correlated features. We know what they do but other developers would need our help to understand their functionality and jump into the project easily.

Working in a team

No matter what programming language you write in, it is always worth using a dedicated linter for it. Every language has its own linter. For Ruby, it can be Rubocop. Here you can see all linters.

Why do we use linters? It is a tool that unifies the look and a bit of syntax of our code. Hence the code is more readable and gives us some kind of convention to apply when coding. This helps new developers joining our project to fit into the existing code. A good example of code writing convention can be using indentation with 1 tab, or naming methods that fetch something from the database with the `fetch` prefix instead of the `fetch` prefix in one class and the `get` prefix in another one.

 Linters can limit code in classes or methods. That forces us to create functionality responsible for one specific action that makes the code more readable and easier to understand and debug.

Tests and documentation

Working on your own

Depending on a junior’s level, tests are written differently. Usually, tests describe only a happy path. That means the test assumes only a proper usage of our application by users. But we all know that as many users we get, there are even more different ways of using our application. Some of them aren’t happy paths and can lead users to unwanted errors.

Working in a team

Tests are one of the core parts of a well-developed application. They play a variety of significant roles. Therefore it’s worth spending the same amount of time on writing them as on developing code they are meant to test. In case of code change in one place, well-designed tests will show other spots in application, where code needs to be adjusted as well. This practice is particularly useful for new project joiners and reduces chances of implementing an error when developing new features.

Tests are also kind of project code documentation. Describing a certain class for test purposes we can specify what parameters it takes and what data structure we expect at its output. It is also a great place for testing cases contrary to a happy path. For example: what tested endpoint will return in case of passing incorrect parameters into it? 

When creating an API which front-end developers will use, it is useful to create documentation describing at what end-point and with what parameters one may expect response and more precisely what data structure is to be expected in return (it can be an array or an object with specified keys).API documentation can be created with the use of tests. Example tool can be Swagger. Thanks to it, the front-end team knows how to use the created API and doesn’t require special contact with the back-end team or know the back-end application.

Continuous Integration 

Working on your own

This part is rarely known to beginning programmers, at least it wasn’t obvious to me. Yet it is very helpful to set up continuous integration even if you are working on the project alone. 

Working in a team

Continuous Integration brings the best part of standardization to a team workflow. It organizes development by executing a set of actions in a specified situation, for example when someone pushes a commit to a pull request. 

In your case, the actions to execute can be running linter, tests, and checking if migrations are written properly and do not raise any database error. If CI like Github Actions passes all actions we have a green light to merge the task to our main branch or even deploy it to the production. 

If any action doesn’t pass, for example, some tests fail, we wouldn’t like to deploy the code to a production environment where we might have real users, would we?

Thanks to CI we are sure that action sets are executed every time we push code and it doesn’t require all developers to remember to run all actions on their own. We all are humans and we all make mistakes. Continuous Integration ensures we implement a good quality code.

Deployment

Working on your own

It is always great to deploy your application to the Internet ans share it with everyone. Heroku has an easy setup and most beginners deploy their applications using this platform. During the development process, we test the application locally, and when we are sure it works as desired we just merge the code to the main branch. Then it can be used on the internet by users (usually just us in the beginning of our adventure).

Working in a team

When you work for clients and develop projects that have their own users, we do not want to use only one environment. In real life, the project’s environment is multiplied into two versions - a production environment with real users and testing one for developers. It is necessary to use it when adding new features requested by clients or removing bugs found by the QA team. 

Often the testing environment gets split into a working environment that suits developers and QA team called staging and another one called pre-production, which holds a version of application with all new features previously tested and ready for client’s acceptance.

Summary

I hope this content will be useful in taking your skills to the next level. Remember that Rome wasn’t built in a day so don’t expect yourself to learn it all throughout the night. Everyone starts somewhere but with this list in hand, you can make your start easier. I keep my fingers crossed for your development!

And if you’re looking for a great place to work with ambitious projects, check out our job offers and look out for the upcoming bootcamps.