Bit Journey is developing an information sharing tool, "Kibela", for companies small and big. Currently under development, it is a service attracting much attention from the public, receiving many applications during the pre-registration period which ended the other day .
This time, I got the pleasure of interviewing two of the engineers at Bit Journey developing services such like that. They are both expert engineers, having the same backbone of previously working at Cookpad Inc.
－Please tell me about your thoughts about code rules.
Mr.Deguchi: Being a product manager, I value focusing on products on a regular basis, so I think spending too much time on things that don't have anything to do with the true nature of the product is kind of a waste of time, such as setting up those rules, pointing them out, and revising. But, also being an engineer myself, I also understand that properly making use of code rules have an important role in improving productivity.
Personally, speaking of the rules themselves, I am not so picky about the contents, as long as they're there. If there's an industry's best practice, I'll follow it. Well, of course, I wouldn't want to if they're something coming from personal preference. (laughs)
Mr.Fuji: I'm one that's pretty particular about coding rules and styles. At my previous company, Cookpad, discussion about code rules was very active, having their styleguide open to the public. Some code rules are decided by "preference", and I think such parts should be written as one wants. But, there are some rare cases where "correctness" has an impact on the discussion, and it's hard to back down on matters concerning such "correctness". There were times when we couldn't reach a conclusion, stubbornly discussing.
The things we discussed about coding rules surely weren't something we could easily compromise about, having much impact and having the styleguide open to the public,
but looking back at it now, it certainly didn't have much to do with the quality of the product itself (laughs).
Mr.Deguchi: Our situations have changed with time, haven't they?
Mr.Fuji: Yes, definitely.
Mr.Deguchi: You used to work on infrastructure those days, but products are your main now.
Mr.Fuji: Well, that's right. With the styleguide being targeted to the public, and being in a department that sustains code quality, I couldn't give in easily.
Although, there were times when the need to discuss just disappeared as we were struggling to reach a conclusion, like when Swift came out in place of ObjC, and the behavior of the part we were discussing changed completely (laughs).
－Please tell us about code management in Bit Journey
Mr.Deguchi: In talking about startups, working hard on product development and surviving as a company is the top priority, rather than improving code quality. So, you usually don't want to spend too much time and manpower in preparing an environment for improving code quality, discussing code rules, pointing them out and revising.
Thinking about the technology we use when developing, we use not only Ruby, but things like ES2015, React.js, and Haml. In cases like this, using many languages, frameworks, and "technology" of that sort, discussing code rules one by one isn't realistic, and I think is better to be widely handled by tools.
As for the content of the rules, I don't have much of a strong opinion on how it should be, but Mr.Fuji does, so I suppose following Mr.Fuji's suggestions will work fine.
Mr.Fuji: And talking about tools for checking rules, when the rules on the config file side are too strict or don't suit the team's situation, there are many times you disable those rules in the code. But that doesn't make much sense as a rule, so we made the config file side rules more lenient, and changed the rules so they won't be disabled in the code.
We check for parts of rules we know about, but the changes in trends of JS libraries are very quick, so keeping up with best practices using SideCI is really convenient.
－Tell me why you introduced SideCI.
Mr.Deguchi: We used to use Lint tools and maintained them by hosting HoundCI on our own, but it took too much of our time, and that was misplacing priorities, so we started looking for a managed service. Well, it wasn't like we chose really strictly though (laughs)
We knew that there was a managed service called SideCI and we gave it a try, but when we did, we found a bug. And when we made an inquiry about it using the chat, we received a convincing answer right away, so we thought "hey, we can rely on this one" and continued using it.
Mr.Fuji: I wasn't there at the time of introduction, but after that I made inquiries several times, and always received pretty convincing answers every time.
Mr.Fuji: Well, being convincing is important, right? It impresses you that they're responding to you properly , even if it's something that can't be solved on the spot.
Mr.Deguchi: We understand since we're running a service too, that there are specifications and various reasons for things. There are times when bugs are found, too. So, what was important was if we could then get an answer that can convince us.
Also, in the sense of the worth of using it, I feel value in being able to leave the execution of not only Lint tools but also tools for improving code quality, such as Brakeman, all up to SideCI. You can forget about the presence of SideCi while developing, in a good way. It's really helpful.
We were able to learn about the connection between coding rules and product development, understood by being
in an environment being particular about coding rules.
Hearing about the states of the two, making decisions on thinking thoroughly about what you need in which situations, I became very eager to try out Kibela by Bit Journey, upholding "One's idea to everyone's power".