TDA Tax Response Search: Individual Coding Portfolio

Nick Siscoe
Apr 30 · Unlisted

Building the TDA Tax Response Search web application with my team was a rewarding experience that challenged me to adhere to sound software engineering principles. Here are five pieces of code that I wrote for the project and how those pieces of code demonstrate my understanding of good software engineering:

Code Piece 1 — Response Edit UI

/app/tda-project-ui/src/app/components/response/

The response editing interface offers a simplistic approach to editing pre-written responses by allowing administrators to make changes to response content directly within the search interface. Building this UI presented some challenges because of the need for multiple “states” of editing associated with adding, editing, or deleting keywords.

Response editing is toggleable directly within a viewable response on the search page. As a result, implementing the “response edit” functionality required me to touch every piece of the pre-existing response component. However, lines 146 and after in the .ts file are particularly relevant to this code piece.

Salient Features

The response edit UI is especially effective at remaining confined to its core functionality in order to preserve speed. For example, data required to initiate the editing process is (with few exceptions) already pulled from the database by the higher-level search component. As a result, imports are used by the response component to avoid unnecessary hits to the backend. Additionally, the response edit UI doesn’t affect the normal, viewable, response component. By introducing HTML for two variations of the response component (uneditable and editable), I was able to avoid modifying elements with JavaScript (i.e. document.body.style modifications) and instead can simply set the state of the component using the “editing” variable. Using two HTML div variations rather than JavaScript modifications also helps to reduce bugs and prevent unforeseen CSS changes. In order to avoid JS modifications I had to write quite a few individual functions that handle the state of keyword editing, but the individual functions are more reliable than CSS modifications that manipulate HTML elements unpredictably. Ultimately, the response edit UI prioritizes speed where possible by having properties defined by its parent component and is modular.

Associated Software Engineering Principles

The response component, as finalized by my implementation of the response editing UI, has low coupling and has dependencies supplied by its parent (in the spirits of the single responsibility principle and the dependency injection principle). The response component has a lot baked into it due to the editing UI being in-line rather than on its own page, but I am very pleased with my approach to decoupling the uneditable response “component from its editable counterpart. Each bit of state-handling functionality is wrapped within its own function that is called almost exclusively by its corresponding editable element on the frontend, and editing responsibilities are kept isolated within the functions that handle each portion of the response edit (subject, topic, other keywords, etc.). Additionally, as previously mentioned, utilizing imports to reduce calls to the backend ensures that dependencies can be defined by the parent of the component and handled exactly the same. Abiding by this principle, in particular, made it much easier to get the editing UI up and running because the parent of the response component can dictate whether the response should be editable based on the imports it provides it.

Code Piece 2— User Edit UI

/app/tda-project-ui/src/app/components/user-line/

Similar to the response editing interface, the user edit UI allowed administrators to make modifications to users and their permission directly in-line with the user search. By avoiding using separate pages for edits, the UI is much easier to understand (there are just three simple tabs) and administrators can make changes much faster (no need to load new pages).

User editing is toggleable directly within a viewable response on the search page. As a result, implementing the “user edit” functionality required me to touch every piece of the pre-existing user component.

Salient Features

Besides the absence of the complicated keyword editing states, the user-line component shares an almost identical structure from a design standpoint as the response component and therefore shares almost the exact same advantageous design decisions. The user edit UI is especially effective at remaining confined to its core functionality in order to preserve speed. For example, data required to initiate the editing process is (with few exceptions) already pulled from the database by the higher-level manage-users component. As a result, imports are used by the user component to avoid unnecessary hits to the backend. Additionally, the user edit UI doesn’t affect the normal, viewable, user-line component. By introducing HTML for two variations of the user component (uneditable and editable), I was able to avoid modifying elements with JavaScript (i.e. document.body.style modifications) and instead can simply set the state of the component using the “editing” variable. Using two HTML div variations rather than JavaScript modifications also helps to reduce bugs and prevent unforeseen CSS changes. Additionally, type checking makes this UI secure (i.e. the validateEmail() function). Ultimately, the user edit UI prioritizes speed where possible by having properties defined by its parent component and is modular.

Associated Software Engineering Principles

Just as was the case with the response edit UI, the user editing interface abides by the spirit of principles like the single responsibility principle and the dependency injection principle. Despite there being multiple user states within the same component in order to simplify the user UI, individual states are wrapped in their own divs and all functionality is tightly wrapped into its own functions on the JavaScript side of things. Splitting the user component into toggleable states based on the “editing” variable allowed each state to contain its own necessary functionality while avoiding hairy JavaScript CSS modifications that would go against single responsibility by manipulating elements to serve different purposes at will. Additionally, all necessary dependencies of the user-line component are passed from its parent and the component handles its states based on the imports it receives on the fly.

Code Piece 3— Action Engine

api/TDAProject/Engines/

The action engine is an instrumental part of the administrator auditing functionality of the TDA Tax Response Search application. This engine is responsible for processing and formatting action and history data such that history data can show an entire summary of actions taken by administrators in a particular change.

The action engine was built to make administrator audits efficient and informative. I was responsible for the entirety of the engine.

Salient Features

The single most important feature of the action engine is its simplification of action data as a “mediator” between the action controller and the action, history, and user accessors. The action engine uses its accessor dependencies to manipulate data in an understandable way — for example, associating history data with the timestamped action data that it corresponds to. Additionally, the action engine handles invalid or incomplete data from its dependencies where necessary while providing useful returns for things like puts and deletes.

Associated Software Engineering Principles

First and foremost, the dependency injection principle is a key consideration of the action engine. Using dependency injection, various implementations of the action, history, and user accessors can be used, which is also useful in testing with mocked accessors. Additionally, it is easy to see the use of multiple interfaces for each relevant accessor at this engine level. This highlights the overall approach to interface segregation that I took when building action functionality on the backend — The various dependencies of the action engine don’t have to worry about implementing functionality that they don’t need because there are isolated interfaces where appropriate. Finally, as with the UI components that I built, the single responsibility principle was a key consideration. Each function of the action engine focuses on its own required functionality and does not deviate to serve other purposes.

Code Piece 4— Action Accessor

api/TDAProject/Accessors/Accessors/ActionAccessor.cs

api/TDAProject/Core/Interfaces/Accessors/

The Action Accessor is instrumental in the system’s architecture as the key code that interfaces with our SQL database to execute on functionality requested by the end user.

I was responsible for the entirety of the action accessor.

Salient Features

Without the action accessor, higher levels of our system hierarchy would not be able to utilize data from our SQL database. Besides this core functionality of the accessor, I implemented a number of salient features through the Action Accessor: First, the use of an interface ensures that modifications to the accessor are difficult to produce by accident. Secondly, a constructor-introduced connection string allows for easy changing of the underlying system SQL resource — which is also useful for testing purposes. Finally, I made sure that my accessor functions always had useful return values, even for functions like a delete.

Associated Software Engineering Principles

Writing a good accessor meant following single responsibility and interface segregation, in particular. In abiding by the single responsibility principle, I thought extensively about how to compartmentalize the piece of functionality that was important (and less important) to overall end-user access to action data and made sure to write functions that “stayed within their lane.” Although the interface associated with this code piece was, ultimately, part of a larger discussion about how many and what type of interfaces should be used, the Action Interface is sufficiently segregated and does not force the Action Accessor to implement unnecessary functionality.

Code Piece 5— Action Info Toggle

app/tda-project-ui/src/app/components/action/action.component.ts

The action info UI allows administrators to click a toggleable button to choose to display more information about the specifics of a change in the change log. The information, when toggled to be displayed, is represented like a Git Diff in which changes are highlighted as additions and deletions in an intuitive manner (accomplished via an Angular wrapper from a node package).

Action info toggling is directly in line with action components on the changelog. The core of the changes associated with this feature is in the .ts file from lines 24 to 36 and 60 to 95.

Salient Features

The most important salient feature of the Action Toggle UI is easily understandable diff presentation to the end user. Using a package called ng-diff-match-patch I was able to simply use a <pre></pre> tag with special properties to render the difference between old and new data. For this to work, it required an intuitive presentation of the underlying data objects in the first place, which is why I spent time developing a function to format data objects into strings depending on their action type. Another great functionality of this feature is the ability to toggle the diff presentation. With a simple switch to “More Info” or “Less Info,” users can choose to see more or less information about a change on the changelog and don’t have to scroll through a wall of text that they aren’t needing at a given time.

Associated Software Engineering Principles

This piece of code primarily abides by the single responsibility principle. There were a couple of functions that could have been strewn together, but by splitting things apart (i.e. making keywordParser()its own function) I wrote the Action Toggle UI functions with single responsibilities. I would also argue that this code piece follows the open/closed principle to a certain degree. By formatting underlying data for the diff presentation based on the action type, the Action Toggle UI allows for extensible data formatting because it doesn’t require modifications to the action component to format data in a particular way — it all depends on what the action type is set to as data is imported from a parent component to the action component.

Overall Thoughts

I am incredibly proud of the work that my team and I put into making our vision for this solution a reality. We believe that TD Ameritrade can, potentially, receive a lot of value from using our Tax Response Search application. Thank you for a great semester!

Unlisted

    Nick Siscoe

    Written by

    I’m an aspiring Product Manager studying at the Jeffrey S. Raikes School of Computer Science and Management. Check out my life’s Kanban board: www.nicksiscoe.me

    Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
    Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
    Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade