DEV Community: Seito Tanaka

Develop a consciousness of internal quality to maintain our productivity

Seito Tanaka — Tue, 18 Jun 2024 13:27:00 +0000

I love coding because it allows me to create what I want from my imagination. But it's not fun when software design is more complex and buggy.
Developers need to maintain maintainability by constantly checking the scope of impact when making changes to the code and continuing to test and refactor.
This movement has senior developers who catch the code smells, but it is always difficult to be conscious of impacting code changes.
We should easily know the impacting code changes to support developers.

The slowing pace of development

As a developer, you've probably experienced the frustration of a service becoming more complex over time, leading to a slower pace of development.
Even if it works fine when you add a feature, if the scope of the change is difficult to understand and the design is hard for future colleagues to understand, it will gradually become more likely to break.
Creating unintended relationships in a program is easy, so maintaining maintainability within a team can be a tough challenge.

Developing while looking at the impact map

The Inga plugin's Impact Map visualizes the modules and components affected by the developer's code changes in real-time.

The impact can be checked in the following development phases.

Individual development phase:
By integrating with the IDE, the Inga plugin empowers developers to develop while always being aware of the impact on the internal design. This control helps to prevent unintended negative effects, giving developers more confidence in their coding.

Team code review phase:
Since the team, not the individual, protects the design, reports can be posted to a pull request by CI so that the whole team can check the impact during code review.

Inga will contribute to productivity. If you sympathize with this concept, you can try it out without hesitation, as it is free. Also, since code analysis is performed entirely on the local machine, you can use it with peace of mind. We welcome feedback on both good and bad points. Thank you.

References

https://www.martinfowler.com/articles/is-quality-worth-cost.html

Visualizing Service Maps with Static Analysis

Seito Tanaka — Sun, 31 Mar 2024 05:49:00 +0000

I created a new feature to visualize service maps on Inga. This tool can help the developer by visualizing impacted endpoints from code changes.
Now, I supported analysis for SOA (e.g., microservices), which can find relationships if they are separated from HTTP requests.

How to Get Service Maps

Similar features have tools, for example, Codecov, CodeSee, and AppMap, which tools require runtime information, such as OpenTelemetry tracing data. The analysis approach for Inga does not require runtime information; it uses static code analysis only. Thus, safe as it does not require sensitive data on your system.
However, using static analysis has difficult challenges. If get relationships between services, the below info is required with servers and clients:

method (e.g., GET, POST..)
path (e.g., "/users/{id}")

For example, if you have the below client call, Inga found the getForObject API is a GET method and finds path definitions from uri variable references.

return restTemplate.getForObject(uri, User.class);

In Java, there are many HTTP clients such as RestTemplate and WebClient, so it is difficult to support all APIs, but I believe that the number of commonly used client libraries is limited to some extent, so this analysis method is adopted.

Inga is still in beta, if you're interested, check out my Patreon 😄

GitHub:

Visualizing the Impact of Code Changes

Seito Tanaka — Fri, 26 May 2023 15:07:18 +0000

Have you ever encountered a problem where modifying your code inadvertently affected other parts of your program? I have been working on the development of an open-source static analysis tool called Inga. Its purpose is to automate the visualization of API endpoints and UI components influenced by code changes in a continuous integration (CI) environment.

What is AST?

To better understand how code analysis works, let's start by discussing the concept of an Abstract Syntax Tree (AST). When working with code, it is challenging to identify code references and analyze the structure solely based on characters. Therefore, before performing code analysis, we convert the code into AST, which represents the code's structure in a tree-like format.
AST contains the following essential data:

Type (e.g., class, method)
Name
Code range
Child nodes

How to find the Impact of Code Changes

Now, let's explore how we find the affected code changes using AST. Two key aspects are to consider: definitions (such as methods or members) and references. We compare the code and the AST.

Find Definitions

For example, if we make a code change within the block of the create method, we can locate the affected definition by examining the start and end text positions of the corresponding AST node.
However, finding references is more complex. Since create can be defined in multiple places within a project, we cannot rely on a simple search.

	process	found name
1	Get package node name	app.service
2	Get class node name	app.service.Order
3	Get method node name	app.service.Order.create

Find References

To find the method invocation, we search for a specific type of AST node that corresponds to the method call. In this case, we are looking for a node that matches the target method name create, which we have just searched for. From there, we can traverse the tree upwards to determine the class name and eventually obtain the unique name "app.service.Order.create," which is associated with the target definition.

	process	found name
1	Find the `create` method call	create
2	Find the class definition of the `order` member	Order.create
3	Find imports for `Order`	app.service.Order.create

Conclusion

We can determine the entry points of call references by utilizing a cyclomatic approach to identify unique names within both definitions and references. This analysis technique allows us to work with projects written in multiple languages such as Java and Kotlin.
Inga is currently under development. If you find this tool interesting, please consider giving it a star ⭐️ and providing feedback. Thank you!

seachicken / inga

Visualizing the Impact of Code Changes

Inga

A static analysis tool that searches references from changed code to detect entry points that have a strong impact on the user.

Why?

Code changes daily, and it is always important to check the impact of changes In many cases, checking the impact of a change depends on how vigilant the author is in writing the code, making it difficult to detect unintended effects during the code review and QA phases. This tool improves software quality by detecting unintended changes at an early phase.

Supported Languages

Java
JavaScript
Kotlin
TypeScript

Usage

inga [options]

Options

--diff <string>

Analyze the result of git diff --unified=0 (use "-" to read from standard input)

--root-path <string>

Relative path of the project to be analyzed, so if you do not give this option, it defaults to the command execute path.

--include <string>

Filenames of glob pattern matching to include from analysis. (e.g. "core/**/*.ts")

--exclude…

View on GitHub

Visualize code changes and impact on users

Seito Tanaka — Fri, 23 Sep 2022 23:49:18 +0000

Code changes daily, and it is always important to check the impact of changes.
In many cases, the process of checking the impact of a change depends on how vigilant the author is in writing the code, making it difficult to detect unintended effects during the code review and QA phases.

I created Inga. This tool improves software quality by detecting unintended changes at an early phase.

How it works

Inga takes the code diff and parses it into AST to find functions and variables that are affected by the change. It then uses Language Server Protocol (LSP), which supports many languages, to further search for references.
Currently, when you submit Pull Requests, you can have CI run Inga and automatically comment analysis results.

Next steps

Currently, the front-end is only supported for projects written in React + TypeScript and the back-end for projects written in Java, but other support can be technically increased.
In the future, it would be interesting to be able to trace the impact of changes to the back-end on the front-end. If you are interested in this project, please post your ideas on GitHub Discussions ☕️

Safely clean up your local branches

Seito Tanaka — Sun, 07 Nov 2021 02:18:21 +0000

If you squash-merge a branch, you can't delete it in the usual way, git branch -d, because there is no history of merging into the default branch.
In the figure below, squash-merge the commit on your topic branch, D, and it's merged into your default branch as a new commit, E. Then the git history becomes a child of B, and it loses its relevance to the topic branch.

To delete a topic branch that has lost its merge history, you must forcibly delete with git branch -D, and you are always worried that you might accidentally delete another branch you are working on.

To solve this problem, I created a tool called gh poi ("poi" means "feel free to throw it away" in Japanese).

What tools?

gh poi is an extension that runs as a subcommand of the GitHub CLI, which is officially provided by GitHub.

GitHub CLI v2.0.0 (released August 2021) and later versions allow you to develop and install extensions.
By providing it as an extension, you don't need to issue an access token to GitHub for each tool and can use it easily.

Deletion strategy

As mentioned earlier, squash-merge branches can only be deleted by forcibly delete. Since gh poi also executes forced deletion internally, it is important to correctly determine the branch to delete.

Deletion flow

Use gh repo view to get the remote repository name
Use the git command to get a list of commit hashes for the branches that exist in the current directory
Use gh api to search for all the pull requests associated with the repository name and commit hash mentioned above
Determine deletion branches and execute based on search results

How to determine deletion

The GitHub API is used to check the pull requests associated with the head commit hash in each local branch, and if the status of the pull request is merged, the local work is considered complete and can be deleted. Since it uses the GitHub API, the best feature of it is that it can determine the deletion of any merge method including "Squash and merge".
In some cases, a pull request is closed and a new pull request is created. In this case, there will be multiple pull requests related to the branch, but if there is at least one pull request that has been merged and all other related branches are closed, it is determined that the branch can be deleted.
If there are still open pull requests, they are not included in the deletion list because they may continue to be worked on locally. We can easily run gh poi at any time to clean up the working environment.

In addition, if there is a forked repository in the first step, it also gets the name of the upstream repository, so it can make the same deletion decision when we merged the pull request to the forked repository. This is useful when contributing to OSS.

I found a few ways to delete squash-merge branches, but I couldn't find a tool that worked with GitHub and could delete them cleanly as expected, so I decided to make my own.
If you are interested in this project, please also register for ⭐️ Star from gh-poi.
Thanks for reading ☕️