Querly helps us effectively share project rules
Querly is a useful code analysis tool that automatically shows project rules and gives suggestions when an issue is found.

About Bit Journey, Inc.

Bit Journey, Inc. offers Kibela, an information sharing tool for companies from start-ups to major enterprises. Kibela empowers organizations with individuals’ ideas and voices. The product received a large number of subscribers before the official launch and has been highly rated by its users since its release.

Currently, Bit Journey uses Ruby and TypeScript to develop Kibela. The development team consists of six engineers who all use Sider. Goro Fuji (@gfx) and Michikawa Masayoshi (@mochimochi) from the team joined us for this interview.

Why do you use Sider?

- What led you to use Sider?

For startups, moving product development forward in order to survive is prioritized over code quality. So, we don't want to spend too much time and work on maintaining the programming environment, but there is a lot involved, code quality, discussions, suggestions, and revisions of code guidelines. Instead, we decided to automate code review.

At first, we tried using a different service to automate code review, but it took so much time to maintain, it defeated the purpose of using it. We decided to look for a well-managed service that minimized the operation cost. We stumbled onto Sider and tried it without really comparing it to other services.

- I see. So it was pure coincidence that you chose Sider. What do you think about Sider now that you’re using it?

After using Sider for a while, we came to like Querly supported by Sider. We found a lot of value in the usefulness of Querly, so we’re still using Sider now.

About Querly

- Can you let us know about how you use Querly?

Sure. In the last six months, I feel like we're taking full advantage of Querly since we now know how to use it. Compared to other linting tools such as RuboCop which requires us to follow 90% of the suggestions, we don’t have to fix 80% of the suggestions made by Querly because we can close issues that don’t apply. So we can easily create new rules. We update the configuration file more often now. Even though we get false-positives with this rule (see below), this is useful for new or part-time engineers who code for us.

- id: kibela.current_user_locale
  pattern: "current_user.locale"
  message: "When current_user is not logged in, the status will be nil. Use I18n.locale."

We have Querly installed on our local development environment, we create new rules by trying them with $ querly console first. When we find bugs, we add a new rule for it. When we create a feature branch and find something questionable, we just create a new rule for that as well.

Results

- Thanks for letting us know. Have you noticed any positive results from using Querly?

Actually, experienced programmers on our team only see suggestions from Querly twice or three times a week. People who write the rules receive fewer alerts because they subconsciously know how to deal with possible issues.

When someone new to the rules writes code, such as a designer or new team member, I find Querly to be very effective by providing suggestions. I'm happy that Querly automatically shows the project rules and helps engineers fix lines that aren't suitable.

The configuration file for Querly is the project's growth and history itself. It's become a great asset to our project.

- Thank you for joining us today!

Try Sider for free

Free 14-day trial for private repositories, and forever free for open source.
Sign up now, no credit card required!