За годы в индустрии программирования многие взгляды неизбежно меняются: кто-то переходит от «динамически типизированных языков — навсегда» к «а без строгой типизации никуда», кто-то бросает фронтенд как «слишком хаотичный», а кто-то, наоборот, погружается с головой в функциональщину. С течением времени понимаешь, что никаких вечных истин нет — есть лишь убеждения, которые проходят проверку практикой, и убеждения, которые со временем ту практику не выдерживают. Ниже делюсь своими «переобуваниями», вдохновлёнными заметками «Software development topics I've changed my mind on after 10 years in the industry».
Что теперь вижу иначе
👉 Простота — это результат упорного труда
На старте карьеры может казаться, что «простые решения рождаются сами собой». На деле каждый дополнительный месяц работы над проектом напоминает, что нужна постоянная и осознанная борьба с усложнением. Вычистить «логический мусор», отказаться от лишних абстракций и написать три строчки кода там, где раньше было три интерфейса — это своего рода искусство.
👉 Строгая типизация на командах со смешанным опытом — спасение
Я любил динамику Python и JavaScript, но когда в проекте много разработчиков разного уровня, строгие типы предотвращают часть нелепых ошибок. Да, Typing может раздражать, но затраченное время оправдано, ведь оно спасает "прод" от коварных неявных багов.
👉 Java прекрасна своей «скучностью»
Парадоксально, но в корпоративной среде надёжная и консервативная Java позволяет фокусироваться на решении задач, а не на постоянных битвах с новыми фреймворками. «Скучно» здесь — знак стабильности и предсказуемости.
👉 REPL-подход не заменяет продуманного дизайна
Интерактивная консоль (REPL) — классная штука для быстрых экспериментов, но наивно полагаться, что она самостоятельно приведёт тебя к идеальному дизайну. Стоит сначала продумать архитектуру (пусть даже набросать её на бумаге), а уже потом «играть» в REPL, проверяя отдельные гипотезы.
👉 70% времени — работа до написания кода
Чем масштабнее проект, тем очевиднее, что большинство вопросов лучше решить в обсуждениях, схемах, документах и мозговых штурмах. «Сесть и кодить» — часто путь к запутанной архитектуре, которую затем приходится кардинально переделывать.
👉 Фронтенд стал кошмаром
Когда-то было весело экспериментировать с UI, но сейчас экосистема JavaScript (фреймворки, сборщики, тестовые инструменты) раздробилась настолько, что оптимизация процесса разработки превращается в бесконечную серию костылей. Некоторых это вдохновляет, но я лично больше наслаждения получаю от бэкенда.
👉 Элегантность кода — не абсолют
Раньше считал, что надо добиться эстетической «чистоты» в каждом методе. Теперь понимаю, что зачастую более приоритетно — понятность и поддерживаемость. Можно следовать строгим правилам стиля, но если это мешает задаче и командному взаимодействию, стоит спросить себя, зачем мы этим вообще занимаемся.
👉 Управление (management) — критично
Долгое время не верил, что «хороший менеджер» вообще существует: думал, что вся ценность в самих разработчиках. Но столкнувшись с грамотным менеджментом, видишь, как это поднимает эффективность, снимает конфликты и улучшает качество продукта.
👉 DynamoDB «в своём сегменте» — ок
При правильном сценарии (например, огромный масштаб и ключ-значение без сложных запросов) DynamoDB работает отлично. Но это не серебряная пуля, и для «универсальной» базы подходит редко.
👉 Объектная парадигма — не враг человечества
Бездумно следовать «чистой функциональщине» — значит отвергать множество задач, где объекты действительно удобны. С годами понял, что нужно грамотно совмещать подходы, а не «свято верить» в одно-единственное решение.
Новые убеждения, приобретённые с опытом
💡 Коммуникации важнее синтаксиса
Серьёзно, 80% времени мы обсуждаем, согласовываем, пишем доки, объясняем код коллегам. Код — лишь вершина айсберга.
💡 Глубокая молодёжь должна пробовать и ошибаться
Нет смысла «зажимать» джуниоров: пусть экспериментируют (в разумных пределах). Ошибки — лучший путь к росту.
💡 Инвестиция в софт-скиллы окупается моментально
Умение говорить «человеческим языком», презентовать идею, принимать и давать фидбэк — это то, что выделяет успешного инженера среди хороших.
💡 Абстракции чаще мешают, чем помогают
Большинство кодовых проектов решают конкретные «приземлённые» задачи. 90% «красивых архитектур» избыточны. Но если пишем библиотеку, тут уже да — придётся подумать о чистых абстракциях.
💡 ORM — это… дьявольщина?
Громко звучит, но я всё больше прихожу к мысли: там, где можно «просто» писать SQL, лучше это и делать. ORM часто порождают магию, которую потом сложно расколдовать.
💡 Функциональное программирование страдает от «фанатов»
Часто не сама концепция проблема, а «строгие адепты», которые отвергают всё остальное. Баланс снова рулит.
💡 Функции без сервера (Serverless Functions) — не панацея
На короткой дистанции может быть круто, но при долгосрочной перспективе (особенно с большим ростом) может вызвать боль и сожаления. Контроль над архитектурой и изоляцией сервисов куда важнее.
💡 Тесты должны быть щедро «задокументированы»
Порой в тестах нужны настоящие эссе о том, что проверяется, почему так, какие граничные случаи. Скупое описание затрудняет жизнь будущим читателям (и будущему себе).
О чём не передумал
😼 «Войны стиля кода» — странная трата сил
Люди, устраивающие драмы из-за пробелов и табуляций, кажутся мне всё такими же «упёртыми». Да, код должен быть читабельным, но общая картина важнее деталей.
😼 Процент покрытия тестами ≠ качество
Куча тестов может быть пустым шумом, если они не проверяют реальных сценариев. А иногда 100% coverage скрывает кучу дубликатов или невалидных тестов.
😼 Монолиты — до сих пор норм
Микросервисы неплохи, но требуют реальных обоснований. Многие проекты искусственно дробят код и усложняют деплой без веской причины.
😼 Реляционные СУБД (RDBMS) остаются чемпионами
Многолетние исследования СУБД принесли тонны оптимизаций и алгоритмов. С наскока их превзойти сложно, особенно если тебе нужны сложные запросы и транзакционность.
😼 Осторожно с «масштабом»
Всё хотят «скейлиться» на миллионы пользователей. Но реальные метрики часто скромнее. Преждевременная оптимизация убивает простоту и загоняет проект в угол.
😼 Про менеджеров
Надеялся, что мнение смягчится, но всё ещё думаю, что большая часть project-менеджеров лишь создают видимость занятости. Когда встречаешь отличных менеджеров, это редкий подарок.
Заключение
Со временем эйфория от новых технологий и парадигм сменяется прагматикой. Каждый год убеждаюсь, что нет магической пилюли — есть лишь набор инструментов, которые надо грамотно миксовать. Главное, что я уношу с собой на новый этап: цель разработки — не коллекционировать «крутые паттерны», а решать задачи бизнеса и помогать команде.
Если интересны подробности, загляните в оригинальный пост «Software development topics I've changed my mindon after 10 years in the industry». Автор (Chris Kiehl) делится сходными инсайтами из своего десятилетнего опыта.
Желаю всем разработчикам побольше здорового скепсиса и меньше догм — ведь мы все растём и меняемся, а значит, наши убеждения тоже вправе эволюционировать!