At the company conference NHN FORWARD held in November 2019, we ran a Frontend Counseling Center to address concerns or questions about frontend development. There were various concerns, but I noticed that the questions and worries were similar across different years of experience and job titles. The concerns ranged from troubleshooting that required clear solutions to the future direction for frontend developers.

Counseling Center (A view of the counseling center... we're not selling phones)

A significant portion of the counseling involved concerns about development culture. Since I believe I work in a team with a fairly decent development culture and have been part of that process, I could answer based on my experiences. Because the situations of the counselors were so diverse, the conversations took slightly different directions for each person, even on the same topic. However, I clearly conveyed one thing: if your organization has at least two members, start with code review.

This article shares my slightly different opinions on code review that I couldn't fully express at the counseling center.

Another Benefit of Code Review

To get straight to the point, I believe code review has additional benefits beyond the commonly known ones. You can easily search for the known benefits. The additional benefits are as follows:

• It can lower the barrier for expressing opinions equally.
• It brings various hidden problems within the team to light (including hidden conflicts among members).
• It allows for mutual review of the results of adopted frameworks or methodologies, enabling the sharing of better methods and collaborative problem-solving.
• It continuously provides topics for finding areas of improvement within the organization.
• It is the starting point of a virtuous cycle of finding and collectively solving organizational improvements.

I think those familiar with code review will likely agree with these points. Now, I will explain why I think this way.

Concerns of the Counselors

Most concerns about development culture from the counselors revolved around how to introduce testing or code review into their teams or companies. Here, testing refers to writing test code in any form to automate tests or developing using TDD. The counselors' problem wasn't how to introduce it well, but how to introduce it without resistance from team members. If there was a side wanting to introduce it, there was an opposing force (?). These forces sometimes consisted of the team lead and team members, seniors and juniors, or old-timers and newbies.

In today's environment where information about code review or testing is easily accessible, and good examples are readily available, this situation was difficult to understand. I asked about the reasons for opposition. Although I needed to hear both sides for accuracy, summarizing the stories from our side (?), there were reasonable justifications like realistic productivity concerns, but many situations felt like they simply didn't want to do it.

There were also opposing forces who couldn't find a reason to object. So, although it was introduced, it wasn't properly maintained and fizzled out. Honestly, if it can't be maintained properly, it's worse than not doing it at all. If those who reluctantly agreed show a half-hearted attitude and intentionally obstruct it, and succeed, it will be difficult to establish anything new in the organization in the future.

Whatever is decided to be introduced into the organization, all members must actively participate, deliberate together to adapt and modify it to fit the organization. This is especially true for testing. Unreliable test cases are completely useless legacy code that only incurs maintenance costs and are poison among poisons. Therefore, the team must continuously discuss and improve what constitutes reliable testing, considering its scope and methods. While this article doesn't delve into what reliable testing is, I believe my own understanding of testing was possible thanks to constant communication with team members. Now, it has become the team's common knowledge, so we don't talk about testing as much as before. But if another point for improvement is found, we will discuss it relentlessly again.

Good Development Culture?

What exactly is a good culture? Having a good culture in an organization doesn't simply mean that the organization conducts code reviews or writes test code. Regardless of the methodology or technology, the measure of whether a team's culture is good or bad is whether the team members themselves consider introducing something to develop better or increase productivity, and if introduced, whether they can devise a method suitable for the team and ultimately find the right approach.

Ultimately, each individual team member is important. That means everyone's opinions and experiences must be respected, and members should be able to voice their opinions regardless of rank or position. Many companies or teams eliminate job titles and use nicknames to facilitate equal communication. Using nicknames without titles is a good way to naturally lead to equal communication. However, the essence lies in free communication. If communication isn't free, eliminating titles is meaningless. Surprisingly, it's often harder for juniors to properly understand and accept seniors' opinions than for seniors to accept juniors' opinions equally. Both sides need to make an effort.

If my opinions or ideas can be implemented regardless of rank, and the team's practices are continuously improved based on individual opinions, practically benefiting each person, it leads to more opinions and ideas. It creates a continuous virtuous cycle. Undoubtedly, team members will feel pride and affection for the organization.

Starting with Code Review

If the team's constitution improves based on free communication, it can digest any technology or methodology appropriately. I believe code review is the best starting point for improving communication within a development team. It can help improve situations where problems are already identified, but it also functions to determine whether problems exist or not. The beginning of improvement is identifying areas for improvement. Through code review, developers review each other's code and exchange opinions about it. And those opinions can be somewhat sensitive. This applies to both the reviewer and the reviewee; it's cautious and sensitive. Feeling like you learned something from code review can be encouraging, while feeling bad about a code review can be emotional. However, beyond these potentially brief and temporary exchanges of opinion, code review makes developers reach agreements through code, draw conclusions, and look towards the same goal. That is, it derives the team's provisional best opinion through member consensus. When this process repeats and becomes a team habit, the team's constitution gradually improves. It can evolve from simply deciding whether to use spaces or not to jointly 고민하는 what constitutes efficient testing.

Code reviews don't need to be amicable. They aren't meant to confirm mutual affection in the first place. Rather, sharp opinions or conflicting views are often more helpful to the individuals involved and those participating in the review. It can be tough for developers to receive criticism on the code they wrote. This is because, especially for diligent developers, every piece of code they write carries a story. Through code review, team members must practice accepting other people's opinions if they are right, even if they differ from their own. Everyone has different personalities, so catering to every individual is impossible. However, the personal feelings that arise during the code review process cannot be continuously ignored.

For code review to be successful, the code review process itself must be periodically reviewed, debated for right and wrong, and rules must be established. During this process, issues where personal feelings were unintentionally hurt during code review should also be addressed. For example, if a debate gets too heated, maybe switch places, have a chat over tea face-to-face, or postpone it to a scrum or team meeting to discuss and decide together with all members. Once rules are set and a certain atmosphere develops around code review, an organizational personality emerges that transcends individual personalities.

An organization's personality can be good or bad. When experienced or new developers join and adapt to the organization over time, they align with its personality. If it's an excellent personality, they will adapt well. But even in an organization with a less-than-excellent personality, they will adapt well. In fact, bad habits are often adapted more quickly, and behaviors align rapidly. That's why effort is crucial to improve the team's constitution and cultivate a good personality.

FE Development Lab's Case

Enough with the abstract talk, let me introduce a case from our team where the culture improved through code review. It was when we first introduced code review. At that time, we only agreed beforehand to be careful not to make each other sensitive and just started. Once we began, we found that much of the review time was consumed by discussions about style or conventions rather than important logic or structure. While reviewing style, different opinions about style emerged, and no matter how trivial, if a debate arose, we held separate meetings to choose the best possible option and made it a convention. As this process repeated, the team conventions improved and became solid.

Our lab strengthened its internal conventions through code review. Detailed code conventions also improve code readability. This makes code review even smoother. I'm now so accustomed to these conventions that sometimes I can't tell if I wrote the code or someone else did. Occasionally, some ask if it's necessary to make style conventions so detailed. Some even bring up individual expression here. No. Code isn't just about whether algorithms, structures, or design patterns were used appropriately. Just as algorithms, structures, or design patterns are improved through code review, style should also have better alternatives selected, made into conventions, and used without deliberation. If opinions diverge between method A and method B during code review, factors like readability, performance, and extensibility should be considered to make it a team convention. If A and B are equally comparable, we might even decide by majority vote. We do code review to select, without hesitation, the single method decided by the team as better for the same problem, whatever that may be. The more such best-case decision examples accumulate, the higher the team's productivity. Style is no exception.

Let me elaborate on the case. Improving and expanding conventions was good, but as conventions increased and covered broader areas, code review became more difficult. Most of the code review time was wasted catching code that violated conventions. At first, we didn't see this time as a problem and even enjoyed (?) catching each other's minor mistakes. However, as wasting time on the same style issues repeated with every code review, it gradually became recognized as a problem, and we eventually started seeking solutions.

The solution was simple. We introduced static analysis tools. Previously, we used various static analysis tools individually without specific rules, but we standardized on ESLint and made it mandatory. ESLint was easy to extend and had various rules, making it suitable for adapting to team conventions. We shared ESLint rules applying our existing conventions, but ESLint had rules beyond what we had considered. Since we decided to adopt ESLint, we had to establish team conventions for these other rules as well. So, we set internal team conventions corresponding to these rules and held regular ESLint convention meetings to reflect rules added or changed by ESLint updates. Under the consensus of all members, ESLint rules were applied, effectively becoming our conventions. Incidentally, this meeting essentially became a regular meeting to review and improve the team's conventions. Our team's ESLint rules are democratic rules reflecting the opinions of all participating members.

Later, due to similar issues, we judged ESLint alone was insufficient and introduced Prettier. Now, style-related reviews are almost non-existent in our code reviews. Nowadays, ESLint and Prettier are quite standard, but they weren't back then. I chose examples that were as detailed and clear as possible, preferably issues that occurred early on. I thought early examples would be more helpful for teams that haven't yet adopted code review.

Summary

When team members repeatedly collaborate to identify and solve problems, the organizational culture inevitably improves. I believe code review is the most effective starting point for this. It's about solving small problems first through code review. As such activities are encouraged, a good culture takes root in the team.

So, does the FE Development Lab currently enjoy the best culture? I wouldn't say that. However, our lab develops using methods that all lab members agree are the best, and adopts behaviors considered optimal. It's the best we can do for now. These methods will eventually be improved upon when someone identifies areas for enhancement, which we will discuss and implement together. We will also share, review, and coordinate to ensure these improvements are effectively reflected. Organizational culture is too broad for a mere developer like me to definitively judge as good or bad. At the very least, I believe our lab is a healthy organization with a good constitution and character.

Recently, a junior developer in the lab proposed and is leading the effort to apply Lerna to the TOAST UI project. This is a major undertaking, almost amounting to restructuring all TOAST UI repositories. (Not that it's difficult......) He shared what he organized while leading the effort on his blog. I just mentioned it because I wanted to brag a bit.

If you're curious about how the FE Development Lab conducts code reviews, you can check it out right now. All TOAST UI projects are open source, and all work details can be found on GitHub. Please check the Pull Requests in each project repository.