Company Name: ZIGExN Co., Ltd.
Interviewees: Engineer and VeNtura PM Mr. Takashi Asanuma, Engineer(VeNtura) Mr. Vinh Nguyen, Frontend Engineer Mrs. Yukie Kasai
This time, we interviewed members from ZIGExN, which runs medias for support in making the best decisions in many life events, such as Arubaito-Ex
It all started from "not wanting my code to be reviewed" and "not wanting to do such reviews"
- Please tell us how it was like when Mr.Asanuma joined to get development back into shape At the time, a project where Japan and Vietnam both were involved started, but in doing joint development on GitHub, a situation where both sides didn't want to review codes occurred. This resulted from the Japan side not wanting to read codes with inconsistent coding standards and low readability, and the Vietnam side, with some cultural influence, feeling embarrassed about their code being read by others. We were pressed to do something about it before the development ground to a halt.
Until then, in Vietnam, one engineer was in charge of one product and developed independently. The finished products functioned as required, but this situation was not suited for multiple engineers to develop one product since everyone developed in their own styles.
In Japan, on the other hand, since code reviews were done on a daily basis, reviews on the Vietnam side source codes were done in the joint development, but we encountered many obstacles there. First of all, there are differences in time and language between Japan and Vietnam. Being in such an environment where there's difficulty in communicating, and the Japan side insisting there won't be enough time to indicate every little difference in style, and the Vietnam side stating there's no need for their source codes to be reviewed and revised when they work properly, both sides ended up not wanting to do reviews.
So, to unify coding standards, I handed RuboCop, a program which analyzes codes according to the specified coding standards, to the Vietnam side, but I couldn't confirm if it was being used properly, and couldn't feel it was making the situation any better.
Also, as a cultural difference, differences in the sense for reviews was a big factor in reviews losing their purpose, the Vietnam side not only feeling that reviewing is meaningless and takes us time for coding but also not wanting to be called out from younger people and feeling embarrassed for their code being read by others.
Management of coding standards in the development process
- Please tell us about the introduction of SideCI When we instructed the usage of RuboCop, we couldn't make use of it such as each individual's state of execution and indications could be seen, so we searched for a tool that could collaborate with GitHub and solve these problems so that the Japan side doesn't have to make indications about coding standards, and came across SideCI. We introduced SideCI because it could be started easily and because we judged that how the codes acquired for the analysis were handled was safe. Also, in talking about trust, we also rated the fact that we received a convincing answer immediately after we made an inquiry about its features highly. Furthermore, being able to be integrated into the development process, being run on PRs on GitHub, was very appealing.
Next, about the effects of introduction, the engineers on the Vietnam side who felt embarrassed for their code to be read, now felt embarrassed that their codes didn't follow the coding standards, as the indications were put where everyone can see. Thanks to changes like these, coding standards began to be followed smoothly on the Vietnam side as well.
We started doing reviews on the Japanese side after the checking the code for mistakes such as differences in coding standards with SideCI. The Vietnam side, first reluctant about reviews, now gladly accepts the reviews in anticipation of learning technical improvements. Recently, simple indications aren't made much, and were replaced by discussions at higher levels such as "we should do it like this because it follows the specifications better".
Unification of Engineer Culture
With the introduction of tools like GitHub, SideCi, and Jenkins, we could do development the same way in both Japan and Vietnam.
Now in Vietnam, code reviews are done regularly, since everyone felt the increase in productivity as their codes got easier to maintain by everyone following the same coding standards. For the team's situation, development by dividing work got smoother, becoming able to entrust a wider range of work to leaders and other individuals. Also, now the engineers develop taking into account the reviewer's perspective, like being careful about readability, naming conventions, and how you separate classes.
The coding standards got thoroughly followed on the Japan side as well, and a culture where the goods of both sides were taken in was created. The Vietnam development team is now our essential partner, especially in overseas projects. They are very reliable members, able to speak multiple languages such as English, Japanese, and Vietnamese and also able to do engineering.
On the Japan side, SideCI has spread among not only the server-side members but also the front-side members and also started using scss-lint.
In introducing SideCI, we were careful not to address the past parts, with the intention of focusing on codings done after the introduction and making sure we can continue on using comfortably. For the parts in new development, as the development process has become established, we need to consider how to create processes for incorporating redesigning and implementing.
Also, we think it will be vital for us to do joint development with the Vietnam side in other future projects as well.