Доброго времени суток!
Для начала представлюсь: я бэкенд-разработчик с опытом более 8 лет. Участвовал в разнообразных проектах: в стартапах, в галерах, в крупных корпорациях и в среднем бизнесе. К сожалению, найти идеальную статистику по данной теме не представляется возможным, однако из общения с бывшими коллегами я понимаю, что то, что будет описано ниже, — не только мой личный опыт, но и то, что регулярно происходит в других компаниях.
Если вы проджект-менеджер и не поймёте содержание этой статьи, это только подтверждает, что вы не способны контролировать данный процесс, и вас практически наверняка водят за нос. Хотя текст по написанию планировался максимально понятным и наглядным с учётом специфики проблематики.
Исходить я буду в своих суждениях сугубо из прагматичной точки отсчёта, измеряя вред программистов там, где очевидно можно определить потерю денег компании.
Прежде чем мы приступим к разбору, хочу уточнить, что я прямой апологет бритвы Оккама, и важным правилом в моём подходе является не плодить сущности без необходимости. Если возможно написать сервис в 100 строк — лучше написать так. Потом, если потребуется, его будет несложно переработать под более удачную архитектуру.
Фанатики архитектур и паттернов
Архитектуры и паттерны — это, грубо говоря, подходы организации составных частей кода: по каким правилам одна структура связывается с другой. Стоит отметить, что я не отрицаю их пользу, но вспоминаем о том, что для их использования нужна необходимость. Кто-то может сказать: «Но как же, она же нужна, чтобы программисту было легче ориентироваться в коде», — а я отвечу, что для подавляющего большинства бэкенд-приложений трёхслойной архитектуры в виде View–BLL–Data Access вполне достаточно для подавляющего числа задач. Она является простой, и вполне себе можно по ней ориентироваться.
Ещё страшнее, когда фанатик одной архитектуры попадает на проект с другой архитектурой и начинает его переписывать под своё чувство прекрасного. За чей счёт? Правильно — за счёт компании. Не могу не вспомнить случай, когда попал на проект фанатика архитектуры DDD. Мы разрабатывали сервис, который регистрировал клиента в системе, и одним из методов нужно было сохранять email пользователя в базе. Благодаря стараниям фанатика запись в базу проходила 10 секунд. Можете себе представить, что он навертел ради такой простой операции… Недавно нашёл его профиль в Телеграме, где в статусе гордо написано, что он уже консультант по DDD.
Разумеется, это крайний случай, но подобное поведение проявляется и в более простых формах. Например, ООП-разработчики очень любят плодить интерфейс на каждый класс. Когда я спросил на своём проекте, зачем нам это делать, ещё и вызывать через DI, то мне ответили: «Ну как же, чтобы писать тесты и подменять классы». Угадайте, были ли написаны тесты на этот код? Конечно же нет. Разработчики просто как обезьяны продолжали писать этот код друг за другом, тратя своё время в никуда.
С паттернами та же самая история: некоторые их вставляют где ни попадя, тем самым повышая энтропию на проекте с каждой строчкой своего кода. Из последнего вспоминается случай, когда мне нужно было поддерживать работу сервиса отправки эмейлов адресату, которые он получал из очереди сообщений. Казалось бы, ничего сложного, но какой-то мегамозг сделал столько обёрток, что код занимал больше 500 строк на Python (это только на чтение сообщений из очереди). А из-за плохой сети дата-центра что-то постоянно падало, и найти причину бага было натуральной пыткой для моей команды. Я психанул и переписал это, уложился в 40 строк кода — и сейчас он работает как часы. Стоит ли объяснять, что если бы мы продолжали тянуть эту телегу, то просто раз за разом кто-то из разработчиков тратил по 8 часов на фиксы, связанные с ним, которых и быть-то не должно?..
Логирование? Нет, не слышал
Казалось бы, все должны знать и понимать, что логирование необходимо для разработки, для того чтобы выявлять и решать проблемы, связанные с приложением. Но как будто бы для большинства это пустой звук: на собеседовании разработчики даже не знают, что такое correlation ID и как его прокинуть в том языке, которым они якобы владеют. Логи или не пишутся, или пишутся с бесполезной информацией по типу Orders {orders_ids}. Да вам, скорее всего, даже не ответят внятно, чем отличается уровень warning от error. Из-за такого наплевательского подхода каждый поиск ошибки превращается в гадание на кофейной гуще. На последнем проекте, в котором я участвовал, благодаря простым правилам и сделав логи «чистыми», мне удалось добиться ускорения фиксов ошибок от разработчиков в 4 раза.
Комментарии? Зачем?
Тема комментариев очень схожа с логированием. Особенно веселит, когда линтер требует от разработчика написать docstring для метода или класса — и что он туда записывает? Правильно, название метода или класса. Никакой информации о контексте выполнения, никакой информации о том, почему было принято именно такое решение, а не какое-то другое. Гадай сам, что делает функция с названием swap_swap_swap(). И ведь проблема не в том, чтобы понять её алгоритм, а в том, что неясно, какую проблему она решает. Благодаря этому небольшому действию, которое требует черкануть максимум пару строк, а не писать целую документацию, по моему наблюдению, разработчики стали решать задачи вдвое быстрее. Опять же — не нужно писать комментарии везде, помним о бритве Оккама.
Тех собесы, лишённые практического смысла
Если вы умеете как попугай повторять зазубренные ответы и натренируетесь решать задачи с литкода — поздравляю, вас однозначно кто-то примет на работу. Но не я. На типичных собесах вы наверняка услышите: «А расскажите, что значит SOLID», — в то время как только буква S из этой аббревиатуры имеет как минимум 4 разных определения, разные по смыслу. Тонкости языка, которые не используются ровно никогда. Что такое ООП или REST — всё типичные вопросы на собеседованиях, когда люди не понимают, для чего они вообще задают эти вопросы. Наверное, они уверены, что так они отличат хорошего специалиста. На деле любой попугай это может зазубрить и тупо повторять.
Сразу вспоминается, как на собесе меня спрашивали о работе индексов, а потом на проекте я нашёл таблицу, на которую их навесили 9 штук, и разработчик хотел навесить 10-й, если бы я не остановил. Кстати, забавно: большинство разработчиков, если их спросить, не могут внятно сформулировать правила принятия решений, по которым вообще стоит навешивать индекс на колонку таблицы или нет. В итоге получается, что от собеса, где вас просто просят написать функцию для подсчёта ромашек, и то больше смысла. Таким образом, в команду попадают такие же не умеющие думать и решать задачи люди. Мыслящие в плоскости лишь «зафигачить задачу, чтобы не уволили», а остальное — гори огнём. И вообще, через год они уволятся и перейдут в другую компанию.
Хуже это только то, что разработчики нанимают таких же, как они, создающих видимость деятельности и фапающих на алгоритмы, а не специалистов, в которых компания на самом деле нуждается, тем самым поддерживая эту круговую поруку.
Скорость разработки важнее скорости и «правильности» алгоритма
Будучи зелёным юнцом, как-то ко мне обратился знакомый, имеющий строительный бизнес, с просьбой сделать пару правок на его сайте. Сайт был написан на PHP и имел довольно скудный функционал. Несмотря на то что там была не одна страница, даже код представления был не в шаблонах, а тупо копировался. Увидев это, я подумал: ну я-то самый умный, я знаю как «правильно», — и переписал этот сайт на C# с шаблонизацией страниц и т.д. Слава богу, мне хватило ума не залить это на его сервер.
Даже тогда до моего неопытного мозга дошло: а нафига я всё это делал, тратил столько времени, если то, что от меня требовалось, могло занять минут 20–30?
Подобное мышление приводит к тому, что простенькие сервисы, которые на каком-нибудь Python или PHP могли бы прекрасно работать и поддерживаться, пишутся на Go или C#. Фанаты этих языков будут с пеной у рта доказывать, насколько они быстрые. Но разработка на них не быстрее, а это — деньги компании. Сколько потеряет компания, если метод будет работать не 100 мс, а 200? Думаю, нисколько. Зато на времени разработчика траты будут однозначно. Самое смешное, что в 95% случаев какие-либо фризы находятся на стороне работы с базой данных, а не слоя бизнес-логики.
Вам точно нужны микросервисы?
Микросервисы отчасти относятся к проблеме того, что разработчики используют архитектурные решения там, где надо и не надо. Только тут они тратят деньги не только на усложнение разработки, но ещё и на технические ресурсы компании.
Грамотно спроектировать микросервисное приложение — задача не из простых. И хотя сам сервис должен получаться простым, его взаимодействие с другими сервисами — это совсем другая песня. И, как правило, в ней творится полный хаос. А зачем это было всё начинать?
Некоторые разработчики будут вешать вам лапшу на уши, рассказывая про отказоустойчивость такой системы. Спойлер: она чаще будет ломаться. Реально можно делить приложение на какие-то атомарные части, если у вас уже большая команда и нужно делать разработчика более узкоспециализированным в рамках отдельной группы. И вполне нормально, если у вас будет распределённый монолит.
Мы покрыли тестами 94% приложения
Если вы слышите фразу, указанную в заголовке — это значит, разработчики написали тесты на всё что угодно, но не на то, что действительно нужно. Написание тестов на функции по типу 2 + 2 = 4 — это самое настоящее вредительство. Рутина разработчика превращается в то, что нужно править тест, потому что изменилась логика, а не потому что реально его код неправильный.
Тесты же должны покрывать только то, что действительно легко может сломаться: какие-то сложные расчёты или хотя бы крупные блоки системы. В остальных случаях — это пустая трата времени разработчика, которая вполне может достигать удвоения времени решения задачи при разработке через тестирование.
Отдельно хочу упомянуть подход к тому, что приложение никогда не должно падать. Вспоминается случай, когда мне лид тестирования убеждал меня, что нужно проверять пагинацию на -1 страницу. На что он был послан… к ПМ, которому я уже объяснил, почему подобная практика вредна для бизнеса. Тестировщик тратит время на нереалистичные кейсы, разработчик тратит время на правку этих кейсов. Кто за это платит? Правильно, опять компания. Он мне ещё пытался доказывать, что вполне может представить ситуацию, где пользователь откроет инспектор и пошлёт такой запрос. Ну да, это ведь проблема бизнеса — такие пользователи.
Бутылочные горлышки
Если у вас в команде есть человек, через которого решаются все вопросы, он же человек-документация — поздравляю, вы в ситуации, когда вся система держится на одном человеке, и если он уйдёт в другую компанию, всё пойдёт по одному месту.
Подобная ситуация легко возникает, если, например, тимлид не даёт разработчикам разнообразные задачи, чтобы они лучше понимали проект в общем, а только узконаправленные. Попытки писать документацию эти проблемы не решают. Вы когда-нибудь проверяли, сколько людей реально читают документации? Я вот да, и скажу вам, что если разработчик может не открыть документацию — он это и сделает. А лучше спросит бутылочное горлышко, как это работает.
Собственно, поэтому я говорю, что всё самое важное нужно писать прямо в комментариях в коде — там хотя бы разработчик это увидит. Причиной этого также часто является слабая аналитика в проекте.
Нет код-ревью
Формально код-ревью может и быть, но на деле разработчик получает «братский апрув» от коллеги, потому что тому лень разбираться, как эта задача вообще была решена. К слову, внятные комментарии сильно упрощают код-ревью. Опять же, польза от код-ревью есть, только если разработчику не дают совершать действия, описанные в этой статье. В противном случае это также будет просто трата времени разработчика. Думаю, очевидно, что если людей не контролировать, то велика вероятность того, что в проект будет вливаться всякий шлак.
Созвоны ради созвонов
Вид имитации деятельности, который особенно часто встречается, если от разработчика требуют активности на все 8 часов его рабочего дня. В итоге люди делают видимость активности, обсуждая какие-то детали вместо реальной проблемы.
Конечно, грумминг задачи — вещь полезная, чтобы не сделать идиотское решение. Речь именно о злоупотреблении данной активностью. Разработчик тратит своё и чужое время на пустой трёп.
Пример такого рода созвонов может быть, как ни странно, ретроспектива. Проблема ретроспективы в том, что в ней, вместо того чтобы обсуждать реально острые проблемы в проекте, обсуждают какие-то мелочи, заводят на них тасочки, отчитываются, как они их сделали — что якобы повышает эффективность команды. Но на самом деле слон как стоял, так и стоит в комнате. Реальные проблемы не решаются. Потому что не может разработчик сказать на ретро: «А вот вы знаете, наш тимлид вообще-то поехавший, и его лучше бы уволить, а вместо него взять нормального».
Прочие виды имитации бурной деятельности
Вообще, лично моё мнение: лучше разработчик не делает ничего вообще, чем вредит проекту. Время простоя вполне себе естественно для специфики нашей работы. И попытки занять максимум времени разработчика ради отчётности приводят к обратному эффекту.
Разработчики начинают поднимать сто пятьсот тестовых контуров, усложняющих флоу задачи. Или собирать метрики там, где это вообще не нужно. Одним словом — придумывать и решать несуществующие проблемы. Но самое печальное в них — что они потом сказываются негативно на последующем рабочем процессе, когда реальные задачи появляются.
Заключение
Все вышеописанные явления — это не какие-то абстрактные ошибки, а прямые утечки времени, денег и человеческого ресурса, которые годами копятся в кодовой базе и оргструктуре, пока не становятся «непрходимым болотом», тормозящим любые попытки развития.
Эти проблемы не решаются просто повышением зарплаты сотрудникам или наймом «ещё одного сеньора». Они решаются только тогда, когда в команде появляется человек, который способен видеть систему целиком, убирать лишнее, раскладывать хаос по полочкам и выстраивать процессы, которые действительно работают. Не по модным книжкам, не по советам консультантов, а по фактической эффективности.
И если после прочтения этого текста у кого-то возникло ощущение дискомфорта — значит, всё было сказано не зря и имеет место быть.
Комментарии (31)
rsashka
16.06.2025 07:29По большей части правильно (в том числе и на основе собственного опыта), но не соглашусь с некоторыми очень категоричными утверждениями.
Во первых, любой менеджмент (в том числе и ПМ) обязан контролировать использование ресурсов, т.е. трудозатраты разработчиков. И если он этого не делает или не умеет делать, то это не проблемы разработчиков, а проблемы именно менеджеров, т.к. именно они управляют расстановкой приоритетов по задачам, а тогда как разработчик волен использовать свою сортировку задач (делать то, что ему наиболее интересно, например, изучать новые языки программирования или фреймворки).
Что же касается тестов (пагинация для -1 страницы), то тестировщик совершенно прав. Любой пользовательский ввод не должен полагаться на добросовестность пользователя и должен быть защищен от его злонамеренных действий.
alex_liebert Автор
16.06.2025 07:29Как пользователь введёт -1? Если на странице нет такой кнопки.
Gorthauer87
16.06.2025 07:29Через режим разработчика, особенно, если он конкурент. И вообще, от таких зачем не далеко до реальных дырок в безопасности.
Тот же -1 вполне может вызывать исключение и засирать ими логи, через это уже можно вполне себе способ навредить.
alex_liebert Автор
16.06.2025 07:29Это всё размышления на уровне "а что если", при этом в беклоге нельзя найти ни одной задачи на фикс подобных вещей за 6+ лет работы компании. Из-за такого мышления разработчики как раз и городят то, чего не должно быть в коде приложения вообще.
rpc1
16.06.2025 07:29Оставлю вам это здесь для информации о последствиях подобных багов
https://www.businessinsider.com/when-amazon-launched-a-bug-allowed-users-to-get-paid-by-the-company-2011-10
space2pacman
16.06.2025 07:29Одного такого пользователя "а что если" из 10 000 тысяч других будет достаточно.
Мне однажды такой "а что если" сломал сайт. Разгребал неделю.
AlexeyPolunin
16.06.2025 07:29Ок, открыл, ввел, получил ошибку, что дальше? Как это вредит безопасности если там препереды и ограничения доступа по другим параметрам?
CrazyOpossum
16.06.2025 07:29Если вся статья про "чик-чик и в продакшн", вы думаете одной ошибкой пагинации всё ограничится?
rsashka
16.06.2025 07:29Для этого кнопка не нужна, а как, зависит от конкретного сайта, например тут на Хабре, это будет https://habr.com/ru/articles/page-1/
karrakoliko
16.06.2025 07:29рандомный индийский бот тыкнет прямо в урл.
и может там увидеть какое нибудь интересное, совершенно внезапно
тестировщик как специалист делает свою работу, и покрывает ваши разработческие задницы (вы забыли енв переключить/ошибку обработать - и вместо страницы ошибки бот получил полный трейс ошибки с путями, данными, и не дай бог енв переменными со всеми кредами).
че бухтим?
panzerfaust
16.06.2025 07:29простенькие сервисы, которые на каком-нибудь Python или PHP могли бы прекрасно работать и поддерживаться, пишутся на Go или C#. ... Но разработка на них не быстрее, а это — деньги компании
...
И если после прочтения этого текста у кого-то возникло ощущение дискомфорта — значит, всё было сказано не зря и имеет место быть.
У меня возникло ощущение дискомфорта и даже кринжа от беспруфных утверждений, что разработка на одних популярных языках как-то заметно быстрее, чем на других. Веб-фреймворки есть для каждого языка. С ними типовые джейсоноукладчики везде пишутся одинаково. Про ИИ-помогайки вообще молчу. А для нетиповых решений нужно как раз инженерную думалку включать, а не просто тезис "разработчики по ночам у бизнеса деньги воруют".
alex_liebert Автор
16.06.2025 07:29Google делал ресерч на эту тему с доказательствами, что разработка на Python и PHP быстрее
panzerfaust
16.06.2025 07:29... и продолжили развивать Go и поддерживать Kotlin. Вот же дурачки.
alex_liebert Автор
16.06.2025 07:29Я не говорил, что в этих языках нет необходимости, я говорил что в подавляющем большинстве серверных решений в них нет необходимости. Даже если у вас будет какой-то сложный расчёт в приложении его можно отдельно написать на Go или C, вполне нормально отношусь к такому.
panzerfaust
16.06.2025 07:29На основе чего вывод о "подавляющем большинстве"? Пруфы, статистика, описание кейсов? Душещипательные истории, как выкинули бэкенд на JVM, переписали на Python, и плакали от счастья?
А, ну да, понимаю. Джентльменам принято верить на слово.
terrier
16.06.2025 07:29Наши глубочайшие приветствия, Алексей ( или Александр )!
Мы — группа IT-специалистов из Корейской Народно-Демократической Республики, обладающих определёнными навыками в области информационных технологий (но никак не хакеров!). Мы впечатлены вашим подходом к разработке и хотим глубже изучить ваши проекты — настоящий кладезь знаний и опыта. Пожалуйста, предоставьте нам ссылки на ваши проекты, и, если возможно, сразу на пагинацию.
pnmv
16.06.2025 07:29correlation ID
как вы будете его "прокидывать", в известном вам языке?
создается впечатление, что вы имеете в виду какой-нибудь конкретный фреймворк, для конкретного языка программирования, подразумевая, что читатель поймет вас, на интуитивном уровне, но читатель не поймёт, в рамках ваших предположений. читатель поймёт по-своему.
WayMax
16.06.2025 07:29лид тестирования убеждал меня, что нужно проверять пагинацию на -1 страницу. На что он был послан…
Уровень вашей компетенции понятен.
Drucocu
16.06.2025 07:29Почему-то создаётся впечатление, что при первых же трудностях автор возьмёт на себя ровно 0 ответственности:
это программисты выбрали неверную архитектуру, и наплодили легаси
это тестировщики не дотестировали и пустили баги в прод
А автор при этом героически спасал бизнес, и вообще дайте ему премию.
alex_liebert Автор
16.06.2025 07:29Интересно почему, учитывая, что я наоборот против ситуаций когда коллективная ответственность слишком размывает ответственность отдельного специалиста. Как раз в таких ситуациях люди и творят что захотят.
Drucocu
16.06.2025 07:29Опыт взаимодействия с людьми. Софт-скиллы, если хотите.
Показательно, что про коллективную ответственность я и не говорил, это ваша личная ассоциация. Я, как раз, не сомневаюсь, что вы всегда найдёте виновного. Просто это никогда не будете вы: судя по тону статьи, а тем более по вашим ответами, у вас слишком большое самомнение, чтобы признать ошибку.
gun_dose
16.06.2025 07:29Что касается паттернов и архитектур, всё это нужно для упрощения восприятия кода. Код с хорошей архитектурой не только легче сопровождать, но и изначально он пишется быстрее. Если разработчик говорит, что он может написать решение абы-как за день, либо с хорошей архитектурой, но за неделю, это говорит о том, что у такого разработчика отсутствует понимание самой цели, что он делает.
Паттерн рождается, когда ты смотришь на код (или представляешь его в голове) и пытаешься понять, как сделать его более лаконичным и удобным для использования. Но вместо этого очень многие разработчики (если не большинство) первично смотрят не в код, а читают всякие статьи в стиле "Топ-10 сеньорских паттернов сезона весна-лето 2025". И потом спешно тащат это в свой проект, чтобы выглядеть "круто" в глазах коллег.
Правда в том, что все статьи, книги и видео о программировании превращаются в бесполезный мусор, если не искать примеры использования этого в реальных проектах, написанных не тобой и проверенных временем. В книжке тебе возьмут пример в 50 строк кода и отрефакторят тремя разными паттернами. Но это совсем не показывает то, как поведёт себя этот паттерн в проекте на 100 тысяч строк. Для этого нужно залезть в код какого-нибудь фреймворка. А ещё лучше залезть туда с дебагером, чтобы понять саму механику работы всех этих паттернов. Чтобы понять, почему там сделали так, у не по-другому.
Но вместо этого все учат голую теорию. Более того, голую теорию теперь спрашивают при приёме на работу. Как будто они принимают людей в Академию наук, а не в организацию, занимающуюся созданием коммерческих продуктов.
Farongy
16.06.2025 07:29Сразу вспоминается, как на собесе меня спрашивали о работе индексов, а потом на проекте я нашёл таблицу, на которую их навесили 9 штук, и разработчик хотел навесить 10-й, если бы я не остановил.
И? Без конкретики совсем не очевидно, что нужно было останавливать.
Гадай сам, что делает функция с названием swap_swap_swap(). И ведь проблема не в том, чтобы понять её алгоритм, а в том, что неясно, какую проблему она решает.
Как будто можно просто функции понятнее называть. Тогда и комментарии, за редким исключением, будут не нужны.
Если вы слышите фразу, указанную в заголовке — это значит, разработчики написали тесты на всё что угодно, но не на то, что действительно нужно. Написание тестов на функции по типу 2 + 2 = 4 — это самое настоящее вредительство.
Как вы определяете что "действительно нужно"? Если функция вместо 4, начнёт возвращать 10 это действительно будет ок?
Neusser
16.06.2025 07:29Гадай сам, что делает функция с названием swap_swap_swap().
Вот бы кто придумал какое-нибудь языковое соглашение по названию функций, переменных итп.
Вспоминается случай, когда мне лид тестирования убеждал меня, что нужно проверять пагинацию на -1 страницу.
А пагинацию на 0 страницу надо тестировать? А на max+1?
Будучи зелёным юнцом, как-то ко мне обратился знакомый, имеющий строительный бизнес,
Кто был зеленым юнцом? Исходя из содержания текста - автор. Исходя и грамматики - знакомый, имеющий строительный бизнес.
Lewigh
16.06.2025 07:29Если возможно написать сервис в 100 строк — лучше написать так. Потом, если потребуется, его будет несложно переработать под более удачную архитектуру.
Видно что Вы или редко или не сталкивались с такими задачами. Лично по моему опыту, классическая ситуация, аналитики РП уговорили сделать тяп ляп в 100 строк кода сейчас, потому что сдаем проект через полгода и забываем. На деле, через полтора года - теперь чтобы "переработать под более удачную архитектуру" нужно в 10-15 раз больше времени а исправление багов почему то стало занимать не часы а дни и недели.
Никогда такого не было и вот опять.Ещё страшнее, когда фанатик одной архитектуры попадает на проект с другой архитектурой и начинает его переписывать под своё чувство прекрасного. За чей счёт? Правильно — за счёт компании.
В целом если это не оправдано то да. Но часто бывает что с прошлой архитектурой работать очень сложно и неудобно. Работа будет малоэффективной, задачу и баги будут делаться долго. За чей счёт?
Например, ООП-разработчики очень любят плодить интерфейс на каждый класс.
А теперь спросите себя насколько создание интерфейса или дописывание в него метода замедляет разработку. На 10-60 секунд? А когда потребуется все таки писать тесты сколько это сэкономит?
Подобное мышление приводит к тому, что простенькие сервисы, которые на каком-нибудь Python или PHP могли бы прекрасно работать и поддерживаться, пишутся на Go или C#. Фанаты этих языков будут с пеной у рта доказывать, насколько они быстрые. Но разработка на них не быстрее, а это — деньги компании. Сколько потеряет компания, если метод будет работать не 100 мс, а 200? Думаю, нисколько.
Сколько потеряет компания когда их мелки сервис разрастется, когда нужно будет куча ресурсов и в конце концов когда все равно все перепишут на на Go или C# и потратят на это огромную кучу денег вместо того чтобы сделать сразу нормально. Сколько компаний с этим столкнулось и столкнутся.
Никогда такого не было и вот опять.Подобная ситуация легко возникает, если, например, тимлид не даёт разработчикам разнообразные задачи, чтобы они лучше понимали проект в общем, а только узконаправленные.
У Вас противоречие - если тимлид раздает задачи разным людям значит все эксперты в своих областях и рассказываете Вы про человека на котором держится все команда.
В целом со многих согласен. Но...
В статье типичная ошибка - качели в одну сторону. Вы описываете как вредит оверинжиниринг. Но жизнь то вещь сложная и разработка тоже. Нельзя просто "Если возможно написать сервис в 100 строк — лучше написать так ", если бы там все просто было и оверинженерига бы не было а оно рождается из как раз из гипертрофированных попыток исправить тот ад который обычно случается после подобных советов.
Сложность в балансе.
AlexeyPolunin
16.06.2025 07:29Разработчик он за зарплату. Деньги не его. Методичек много, поле для деятельности большое. Эффективность бизнеса - не его задача. Смерть проекта от 1000 порезов не его проблема. Утверждения про безопасность - ну так что угодно объясняется. Становится безопасности больше от применения всех методичек вперемешку - по разному, если навертели в 4 этажа, что самим непонятно как работает, ну какая там безопасность. Кто-то говорит публично, что это дичь - ну это как против использования микросервисов в проекте трехстоаничного сайта рот открывать.
Wolfdp
16.06.2025 07:29Вот не уверен, с некоторыми тезисами явно не соглашусь:
Разработчик налегал на DDD, но не смог написать сохранение в базу. Кажись тут проблема не в том что он налегал на DDD, а что он просто плохой кодер, и прикрывается всякими умными вещами.
На вопрос "зачем DI c интерфейсами" нужно отвечать "потому что так удобней на сложной архитектуре". Тесты это прекрасно, но вообще-то в первую очередь решается типичная проблема что в глубь нужно прокинуть десяток другой тех или иных классов/интерфейсов, и тащить всё это добро через все конструкторы сверху вниз -- заманаешься. А когда ещё и скоп появляется, то удачи всё это дело организовать без ioc-контейнера. Я уже молчу что всякие либы предполагающие использование DI для быстрого внедрения в код.
На C# (а если точнее, то на asp.net core) сайты пишуться довольно элементарно, не особо понимаю чем там PHP радикально быстрее. Возможно всё же подразумевалось что на PHP есть много CMS и прочих решений "из коробки", что имеет смысл применять в тех или иных ситуациях.
Идея "сделать сейчас 100 строк кода" может быть как отличной, так и фатальной. Без контекста это обсуждение сферического коня в вакууме. И обычно вся сложно как раз в том чтобы понять как решать задачу в данный момент -- в 100 строчек или расписывать с запасом на будущие правки.
alex_liebert Автор
16.06.2025 07:29Я вроде ясно дал понять, что не являюсь противником сложных решений, вопрос в том что они должны быть обоснованными, а не просто потому захотелось вот. Буквально пару недель назад собесил разработчика, который сделал обработку запросов на RabbitMQ, а response ожидал ответ в Redis и тупо спамил его запросами по ключу чтобы достать ответ. Вы спросите зачем? Так он сам лично сказал, что просто хотел эти технологии просто попробовать. Его желание самообучаться теперь живёт в реальном проекте. Сложные решения нужны, вопрос в том что должна быть НЕОБХОДИМОСТЬ для них, а её очень часто нет.
pnmv
наличие таких сотрудников на должностях означает, что проект уже идет ко дну, а не потонет когда-то там.