Caseflow: Tango / Hearings Codebase Frustrations and Confusions

[lomaxap]

Description

This ticket is a place to note frustrations or confusion in the Tango codebase or with hearings logic generally. These frustrations can create stop energy, and may also reveal some tech debt. This will help us get a better sense of areas of technical improvement that we can focus on to improve our experience with coding.

We will collect some issues here before deciding on how to proceed with prioritizing and tackling them.

Goals

The goal of this ticket is to discover common themes in our daily frustrations so that we can understand what they are and how we might best address them (better documentation, code/database changes, re-naming, improved tooling, perhaps even doing nothing at all).

Non-goals

This ticket will not be the place to propose solutions to any problems we surface during this frustration collection phase. If solutions become apparent during this phase, we will proposed them in separate Github tickets dedicated to the discussion of that particular solution.

Background/context/resources

This came from our retro Nov 16th, inspired by (and copied from) an Echo / Foxtrot ticket where they keep track of things that bother them specifically with tasks / Foxtrot code.

[ferristseng]

React components are difficult to unravel

(This might also be an issue outside of the hearings codebase) It's difficult to get a full understanding of how a frontend page works because of how separated the code is. To understand how a change gets propagated in a form, you might have to open 4-5 files to finally get to the update method. I'm wondering if we can reduce this friction, and make it more clear how components are related to one another.

Dead code

I ran into this while doing a refactor, but it seems like there's some hearings-related dead code. I tried out this tool (https://github.com/joshuaclayton/unused) to see if we could find things to remove, but never got around to looking at the output too closely. It might be worth reevaluating so we don't spend time maintaining dead code.

Files with multiple components

This is a minor nit pick, but we have some files where multiple components get defined (e.g. DailyDocketRowInputs). It makes it a bit difficult for me to pull up the code because I usually just search for a file assuming the class name matches. I don't know if other people run into this as well, but it usually takes me a second to realize that I need to check the imports statements to find where the component is actually defined.

[pshahVA]

@lomaxap, should we turn this into a running epic?

[ferristseng]

Some of this is captured in other places, so I'm going to remove this issue