Our Mercury trading system has grown organically over time, leading to intertwined services, duplicated code, and complex state management. This document outlines a strategic approach to refactoring key components to improve maintainability, testability, and performance.
In our recent work on the Mercury TA service, we encountered an interesting challenge with our Ichimoku Cloud indicator implementation. The issue arose from using primitive boolean values to represent complex market states, leading to ambiguous and sometimes incorrect interpretations. This post outlines our three-step solution to create a more robust and maintainable technical analysis API.
In any growing project, there comes a time when the initial architecture starts showing signs of strain. As features expand and requirements evolve, what once seemed like a clear structure can become muddled. Today, I want to share our journey of refactoring TON Arcana, focusing on creating a more cohesive, domain-driven architecture.
Here are 10 elegant improvements we're implementing to make our codebase cleaner, more maintainable, and better aligned with domain concepts.
In our Mercury trading bot project, we started with a seemingly simple class called GistStateManager. Its initial purpose was to manage state persistence using GitHub gists as a storage mechanism. However, as the project evolved, this class accumulated more and more responsibilities.