Have you ever wondered how to make sure that your determination to live a healthier life, not sweat the small stuff, and work smarter, not harder continues past Valentine’s Day? Psychologists say that breaking big goals into small steps is the best way to stick to your New Year’s resolutions.
This advice applies to programmers’ resolutions too. If you plan a large project that involves code refactoring, you may want to see the full picture of the required changes and plan accordingly. This is exactly what the IntelliJ team did when they needed to localize the IDE’s entire UI into Chinese, Japanese, and Korean.
Using Qodana, the code quality platform from JetBrains, as a single source of truth for their localization process, the IntelliJ team managed to finish the project much faster than expected. This positive outcome was a result of wise planning, accountability, and oversight. Here’s how they did it.
The challenge: isolate 13,000 hard-coded strings and monitor progress effectively
To streamline the localization of their UI into 3 different languages, the IntelliJ team needed to strip out all localizable items from the source code and put them into separate properties files to be handed over for translation.
With over 13,000 strings, it was easy for some localizable ones to be overlooked, meaning that they remained in the code. When localizing the UI, hard-coded strings can be the most difficult parts to deal with. They are hard to find because they do not show up until the software has been localized. As a result, if a user installed the Japanese language pack, for example, some parts of the UI would still be in English.
The team was therefore left with much tedious and repetitive work. As a result the head of the localization project was looking for a solution that would allow them to:
- Automate a huge chunk of the work by continuously inspecting the code base for hard-coded string literals.
- Assign issues to the developers who would be responsible for fixing them.
- Oversee the extraction of localizable strings.
The solution: automated code inspection for hard-coded string literals
The localization project lead chose Qodana to streamline the code inspection process, resulting in a project with the following steps:
#1. Connect Qodana to TeamCity
The IntelliJ team connected Qodana to their TeamCity pipeline and enabled the Internationalization code inspection to highlight hard-coded string literals that were not extracted into properties files as required.
#2. Configure the inspection profile
In the inspection profile, the team configured the scope of the inspection to make sure that the platform skipped parts like legacy code, literals without alphabetic characters, and strings consisting of only whitespace.
The team also made sure that TeamCity would produce a test report for each line inspected by Qodana and fail it if the string wasn’t extracted.
#3. Decide on the frequency of scans
Once fully configured, Qodana was set to inspect the code every 4 hours. It was especially important that the scan was running independently on the server, as opposed to on someone’s local machine. This ultimately saved the team valuable time.
The first Qodana run resulted in 10,000 failed tests in TeamCity.
Overview of the failed tests.
Qodana flags the hard-coded string literal remaining in the code as an error in the internationalized environment.
#4. Assign tasks
For each of the test failures, the project lead assigned a developer to investigate and extract the hard-coded string to the properties file.
How the assigned test is displayed in TeamCity.
#5. Monitor the results
After each Qodana inspection, TeamCity compared the previous results to the current report. If the developer responsible for an issue extracted the string, TeamCity marked the test as fixed. This allowed the project lead to monitor the progress without having to manually mark tests as fixed.
Additionally, the team was able to monitor progress in the Qodana Cloud dashboard, which updated information on the remaining code issues in real time and compared results between different Qodana runs.
_The Qodana Cloud dashboard example. _
Qodana also allowed adding selected issues to the baseline, otherwise known as the technical debt section. This way, the entire team could see the same list of issues and monitor progress right in the platform. Below is an example of how this works.
The Qodana baseline feature.
The key outcomes
In only a few months, the number of failed tests dropped from 10,000 to zero , an average of about 175 fixed tests per day. The team successfully removed all hard-coded string literals from the source code and the whole UI was localized seamlessly, with no unexpected elements in English.
With Qodana, the IntelliJ team required fewer manual steps in the localization process, thereby reducing the number of human errors and increasing confidence in the localized builds. Additionally, with checks running every 4 hours, they were able to detect issues sooner and prevent small problems from turning into big ones later on.
Finally, Qodana became the single source of truth for the team lead, making it easy to ensure that developers fixed the problems they were assigned.
Thanks to these results, the IntelliJ team will keep using Qodana as a code quality and resource planning platform when they deliver new functionalities or improve IntelliJ IDEA’s performance. More on that in our upcoming posts.
Happy developing and keep your code clean!
Top comments (0)