А вы никогда не задумывались, почему, с одной стороны, у нас появляются всё более крутые и мощные инструменты для разработки? На бэкенде мы можем делать микросервисы, писать офигительные SPA-приложения — но при этом будто бы сама программа становится всё хуже и хуже.

Каждый раз происходит одна и та же история: мы хотим сделать как лучше, но код в итоге всё равно превращается во что-то странное и не поддерживаемое.

Откуда берётся эта эрозия программного обеспечения? Почему так выходит, что новые технологии не только не помогают, но иногда даже мешают нам писать качественные программы? Почему, когда мы стараемся делать хорошо — получается плохо?
И главное — что с этим делать?

Скорочтение — это не про то, чтобы глотать страницы книг. Обучение — это не про курсы. Архитектурное мышление — это не про чертежи систем.

В этой статье я расскажу, как скорочтение, обучение и архитектурное мышление на самом деле говорят об одном и том же: о построении непротиворечивой картины знаний.

Мы разберём, почему память — это не набор фактов, а сеть связей, как правильно готовить себя к обучению, и почему эффективное усвоение информации — это навык, доступный каждому.

И самое интересное — вы сами увидите, как архитектурное мышление проявляется там, где его меньше всего ждёшь.

Я сейчас занимаюсь разработкой своего pet-проекта: LMS на базе TG, и подошел к стадии набрасывания первых модели: курсы, лекции и их контент. Всё это вывел для дебага.

Но давайте вернёмся к теме. Раз я занялся моделью предметной области, есть один неочевидный момент, который многие упускают на старте проекта: когда проект только начинается, мало кто задумывается, как в будущем мы будем анализировать данные. Но уверяю вас, желание анализировать данные у вас обязательно появится, причём захочется анализировать больше, чем то, что изначально доступно.

Когда люди впервые сталкиваются с аналитикой, они думают: "Надо добавить событийную аналитику и логировать каждое действие." Но у такого подхода есть два основных минуса...

В какой-то определенный момент после старта нового проекта, когда «временный» MVP почти готов, весь интересный код уже написан, пакеты еще свежие и обновляются, команды начинают замедляться в Time to Market.

Для разработчиков обычно это выражается в переходе от «нам бы перестать добавлять технический долг» к пониманию того, что он нам уже реально мешает. Бизнес начинает все больше подгонять вперед, а разработчикам все сложнее держать код проекта в голове и безопасно его переписывать. Но уже поздно: проект прошел точку невозврата, и по опыту с таким подходом дальше будет только хуже.

Проект становится поддерживать все сложнее, свежий проект перестает быть таковым, а желания и возможности вносить в него крутые технические решения становятся все труднее реализовать.

И вот мы здесь, с молодым, но уже «легаси» проектом, никто не понимает, как он работает, и нет места, где можно почитать требования, чтобы не отвлекать коллег.

Предлагаю сегодня вместе разобраться, что конкретно вы можете с этим сделать. Ситуация хоть и знакомая и запущенная, но не безвыходная.