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.
The current job queue system has several issues:
Сегодня я пришёл к пониманию одной фундаментальной истины: быть уебком легко, а писать простой код — сложно. Особенно, если вместо того, чтобы смотреть на уже существующие решения, ты изобретаешь свой велосипед с ядерным реактором и квантовым генератором промптов.
When building a TypeScript project, type declarations are your first line of defense against bugs and maintainability issues. However, certain type declaration patterns can actually work against you, creating technical debt and making your codebase harder to maintain. Let's explore 10 specific anti-patterns we've identified in our analysis of real-world TypeScript projects.
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.