Если вам достался проект, в котором копаться — всё равно что распутывать спагетти в боксерских перчатках, вы, скорее всего, сталкнулись с антипаттернами. К этим практикам сначала прибегают как к быстрым решениям, но затем они превращаются в повторяющиеся ночные кошмары. Представьте себе магическую кнопку деплоя, которая ломает всё в 2 часа ночи — а дежурите вы.
Технические команды часто избегают лишней документации, но информация всё равно каким-то образом передаётся, сохраняется и развивается. В этой статье — попытка разобрать скрытые механизмы общения внутри инженерных команд: как выстраиваются негласные соглашения, каким образом рождаются «внутренние диалекты» и зачем вообще всё это, если есть JIRA, Confluence и куча других инструментов. Много примеров, блоков кода на разных языках и немного личного опыта.
Серия псевдофилософских мини-эссе о работе функционального архитектора.
Очень полезная практика – осознанно записывать архитектурные решения, принятые на проекте. Желательно сопровождать это описанием причин, по которым был сделан выбор в пользу принятого решения. В идеале дополнять описанием альтернативных вариантов решения, которые рассматривались, с их ключевыми плюсами и минусами.
Делать это нужно в каждой ситуации дуальности. Даже если в моменте принятое решение кажется вам очевидным.
Мой друг-программист уже месяц жалуется на парочку токсичных коллег. Сценарий всегда одинаковый: Вася просит помощи на полдня, а в итоговом отчёте вдруг оказывается, что всё сделал он один; Петя слизывает идею, которой мой друг поделился «у кулера», и оперативно реализует её сам; кто-то отпускает колкие комментарии на дейликах или распускает сплетни за спиной.
Я слушал его и не совсем понимал. На моей текущей работе команда адекватная, никаких подковёрных игр. Да и казалось, что подобные интриги уж точно обходят современные айти-компании.
Какие предметы вам нравились в школе? Я очень любила математику. Меня завораживали цифры, формулы и логические рассуждения. А самое главное, даже если решать задачу несколькими разными способами – единственно верный ответ всегда будет один. И проверив его, можно быть уверенным, что задача решена правильно.
Сейчас, проектируя программные системы, я тоже решаю задачи, но они принципиально отличаются от математических, где всегда есть единственно верное решение. Если в школе небольшого условия задачи было достаточно, при проектировании это не так. Как говорил итальянский программист Альберто Брандолини: (далее…)
Эта статья про историю SDLC — System (Software) Development Life Cycle. Он принадлежит далёкому прошлому, но на него тем не менее продолжают ссылаться на конференциях и пытаются использовать.
В последние пару лет цифровой рынок в России переживает фундаментальные изменения, которые затрагивают обе стороны — и работодателей, и специалистов. Один из самых ярких трендов — рост так называемого поливоркинга, когда один специалист совмещает сразу несколько проектов или даже полноценных работ. И если раньше это воспринималось как редкость или «читерство», то сегодня — это новая норма. Особенно в digital: разработка, дизайн, маркетинг, продукт, аналитика.
Да, это создаёт вызовы для работодателей. Но в 2025 году уже очевидно: с трендом бессмысленно бороться. Его надо возглавить.
Иногда стек технологий в разработке становится похож на зоопарк. Количество технологий растет, одни и те же задачи решаются разными инструментами, которые дублируют друг друга. В итоге команде «смотрителей» каждый раз нужно выбирать, кого из голодных львов покормить первым.
Меня зовут Ирина Колесникова — я тимлид в финтех-компании Точка. В этой статье расскажу, как мы столкнулись с «зоопарком» при переезде с Vue на React, и что помогло превратить хаос в систему.
