Technical-Debt

There’s a widespread belief in software development circles that we should minimize complexity at all costs. It’s treated like a cardinal sin, whispered about in code reviews like some kind of software taboo. “Keep it simple,” they say. “Reduce complexity,” the metrics dashboards scream. But here’s the thing—I’m going to take a stance that might get me some raised eyebrows: complexity isn’t your enemy. Negligence is. Before you close this tab thinking I’ve lost my mind, hear me out....

В сфере разработки программного обеспечения широко распространено мнение, что мы должны любой ценой избегать сложности. Её считают смертным грехом и обсуждают во время ревью кода как какое-то табу. «Держите всё просто», — говорят они. «Сокращайте сложность», — кричат панели с метриками. Но вот в чём дело — я собираюсь высказать мысль, которая может вызвать у некоторых удивление: сложность — не ваш враг. Врагом является небрежность. Прежде чем закрыть эту вкладку, решив, что я потерял рассудок, выслушайте меня....

I’m going to start with a confession: your tech stack is probably wrong. Not maybe wrong. Probably wrong. And you know what? Mine was too. In fact, I’d wager that if you can name your entire tech stack off the top of your head without checking the documentation, there’s a solid chance you’ve over-engineered something spectacular. Let me explain why this keeps happening—and more importantly, what to do about it....

Я начну с признания: ваш технологический стек, скорее всего, неправильный. Не может быть неправильным, а именно неправильным. И знаете что? Мой тоже был неправильным. На самом деле, я готов поспорить, что если вы можете назвать весь свой технологический стек, не заглядывая в документацию, есть хорошие шансы, что вы что-то чрезмерно усложнили. Позвольте мне объяснить, почему это происходит, и, что более важно, что с этим делать. Соблазнительный танец «лучшего в классе» Вот где большинство проектов идут не так....

Your codebase is a mess. You know it. Your team knows it. That one function has 47 parameters. Variables are named after your cats. And somewhere in there, a comment from 2015 says “TODO: fix this before production” in a voice that sounds increasingly desperate. So naturally, you do what any self-respecting developer does: you commit to a massive refactoring sprint. Two weeks, you think. Maybe three. You’ll rewrite everything beautifully, apply design patterns like they’re going out of style, and emerge victorious with a codebase so clean you could eat off it....