Доброго времени суток!
Для начала представлюсь: я бэкенд-разработчик с опытом более 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 часов его рабочего дня. В итоге люди делают видимость активности, обсуждая какие-то детали вместо реальной проблемы.
Конечно, грумминг задачи — вещь полезная, чтобы не сделать идиотское решение. Речь именно о злоупотреблении данной активностью. Разработчик тратит своё и чужое время на пустой трёп.
Пример такого рода созвонов может быть, как ни странно, ретроспектива. Проблема ретроспективы в том, что в ней, вместо того чтобы обсуждать реально острые проблемы в проекте, обсуждают какие-то мелочи, заводят на них тасочки, отчитываются, как они их сделали — что якобы повышает эффективность команды. Но на самом деле слон как стоял, так и стоит в комнате. Реальные проблемы не решаются. Потому что не может разработчик сказать на ретро: «А вот вы знаете, наш тимлид вообще-то поехавший, и его лучше бы уволить, а вместо него взять нормального».
Прочие виды имитации бурной деятельности
Вообще, лично моё мнение: пусть лучше разработчик не делает ничего вообще, чем вредит проекту. Время простоя вполне себе естественно для специфики нашей работы. И попытки занять максимум времени разработчика ради отчётности приводят к обратному эффекту.
Разработчики начинают поднимать сто пятьсот тестовых контуров, усложняющих флоу задачи. Или собирать метрики там, где это вообще не нужно. Одним словом — придумывать и решать несуществующие проблемы. Но самое печальное в них — что они потом сказываются негативно на последующем рабочем процессе, когда реальные задачи появляются.
Заключение
Все вышеописанные явления — это не какие-то абстрактные ошибки, а прямые утечки времени, денег и человеческого ресурса, которые годами копятся в кодовой базе и оргструктуре, пока не становятся «непрходимым болотом», тормозящим любые попытки развития.
Эти проблемы не решаются просто повышением зарплаты сотрудникам или наймом «ещё одного сеньора». Они решаются только тогда, когда в команде появляется человек, который способен видеть систему целиком, убирать лишнее, раскладывать хаос по полочкам и выстраивать процессы, которые действительно работают. Не по модным книжкам, не по советам консультантов, а по фактической эффективности.
И если после прочтения этого текста у кого-то возникло ощущение дискомфорта — значит, всё было сказано не зря и имеет место быть.
Комментарии (61)
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 тысяч других будет достаточно.
Мне однажды такой "а что если" сломал сайт. Разгребал неделю.
gres_84
16.06.2025 07:29Вопрос, что вам дешевле - пофиксить сейчас или разбираться потом с редким багом. Я работал в кампании, поставляющей решения для городского транспорта. И там один баг, проявляющийся раз на миллион попыток заканчивался регулярными обращениями граждан к организатору перевозок и штрафами. Поэтому фиксились даже самые тупые на первый взгляд ситуации.
Например, мне вспомнилась ситуация, когда человек зашел в один автобус, потом пересел в другой, а потом вернулся в первый.
Но даже если баг по вашему мнению невозможен сейчас, он вполне может стать возможным позже после рефакторинга/дописывания.
Neusser
16.06.2025 07:29Например, мне вспомнилась ситуация, когда человек зашел в один автобус, потом пересел в другой, а потом вернулся в первый.
Да это ж навигация гуглокарт! (только заменить "автобус" на "улица").
gres_84
16.06.2025 07:29Физически это было не так то просто, потому что в конце рейса данные обновлялись, и проблемы бы при пересадке не было. Нужно было успеть войти в один и тот же автобус в течение одного рейса.
AlexeyPolunin
16.06.2025 07:29Ок, открыл, ввел, получил ошибку, что дальше? Как это вредит безопасности если там препереды и ограничения доступа по другим параметрам?
CrazyOpossum
16.06.2025 07:29Если вся статья про "чик-чик и в продакшн", вы думаете одной ошибкой пагинации всё ограничится?
AlexeyPolunin
16.06.2025 07:29Не ограничится, будут еще другие, такие-же некритичные. Есть какая-то идея, что некритичные ошибки — ведут к критичным для системы, это не совсем так. Если сосредотачиваться на реальной безопасности и оставить на потом, если потребуется, такого рода штуковины как пагинация -1, то сделать получится существенно больше за те-же деньги/время. Но разработчику на время/деньги все-равно — платит корпорация, она за эффективность не доплачивает, зато делает мозг за мелкие недочеты.
И я читаю эту статью так: если у вас нет 2 миллиардов рублей на сервис из четырех табличек, то не стоит пытаться разрабатывать так, как разрабатывает корпорация, вы просто не доживете до запуска — неважно будет, есть там у вас железобетонная защита от всего на свете и красивые 404 во всех местах или нет.
panzerfaust
16.06.2025 07:29Если сосредотачиваться на реальной безопасности и оставить на потом, если потребуется, такого рода штуковины как пагинация -1, то сделать получится существенно больше за те-же деньги/время
Можно подумать, что добавить 1 тесткейс к своему тестсьюту - это никак не меньше 1 человекомесяц работы и 5 млн затрат.
А фактически это пара клац-клац по клаве и 1 глоток чая. Для модных-молодежных 1 промпт в ИИ-помогайку. Весь описанный в статье "оверинжиниринг" - это тупо рутина для сеньора, которая просто теряется на фоне остальной работы. Например, на фоне выяснения у пресловутого "бизнеса", чего же он все-таки хочет. Но эти потери никто не считает. А вот лишний тесткейс или лишний интерфейс - это ай-ай-ай и вообще вредительство.
ponikrf
16.06.2025 07:29Был как то у меня случай из жизни. Я еще был совсем юный, тогда еще php4 было. Я подошел к одному человеку, мы вместе тусовались тогда небольшой группой единомышленников. И вот он тогда специализировался на взломе сайтов. Мы с ним болтаем, я его спрашиваю - мол как можно взломать сайт и все такое. Он мне говорит, ну вот видишь, переменные тут в строке отправляются, он мне на примере сайта который они же и разрабатывали, начал показывать. Мол смотри как реагирует если это отправить, если то отправить.
Адресная строка уже стала довольно длинной. Он редактирует очередную переменную в попытке получить ошибку. В очередную переменную вводит 123456789 нажимает ентер и сайт открывается с админскими правами.
Мы с ним стоим и смотрим на произошедшее. Мы вместе не могли поверить, что все могло быть настолько просто, только каждый из нас думал об этом в разрезе своего понимания.
rsashka
16.06.2025 07:29Для этого кнопка не нужна, а как, зависит от конкретного сайта, например тут на Хабре, это будет https://habr.com/ru/articles/page-1/
karrakoliko
16.06.2025 07:29рандомный индийский бот тыкнет прямо в урл.
и может там увидеть какое нибудь интересное, совершенно внезапно
тестировщик как специалист делает свою работу, и покрывает ваши разработческие задницы (вы забыли енв переключить/ошибку обработать - и вместо страницы ошибки бот получил полный трейс ошибки с путями, данными, и не дай бог енв переменными со всеми кредами).
че бухтим?
Zulu0
16.06.2025 07:29Что же касается тестов (пагинация для -1 страницы), то тестировщик совершенно прав. Любой пользовательский ввод не должен полагаться на добросовестность пользователя и должен быть защищен от его злонамеренных действий.
Если у вас есть веб морда, то у вас на лбу должна быть гравировка: все данные от пользователя надо проверять, они опасные. И никаких проблем не будет.
aleksandy
16.06.2025 07:29При чём тут есть морда или нет? Любые приходящие из вне данные априори невалидны, пока не доказано обратное. И не важно насколько ты контролируешь источник этих данных, хоть на все 146%, всё равно валидация на входе обязана присутствовать.
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-специалистов из Корейской Народно-Демократической Республики, обладающих определёнными навыками в области информационных технологий (но никак не хакеров!). Мы впечатлены вашим подходом к разработке и хотим глубже изучить ваши проекты — настоящий кладезь знаний и опыта. Пожалуйста, предоставьте нам ссылки на ваши проекты, и, если возможно, сразу на пагинацию.
Zulu0
16.06.2025 07:29и продолжили развивать Go и поддерживать Kotlin. Вот же дурачки.
Но самый дешевый хостинг для сайтов, погоди-погоди, на апаче+пехепе+мускль (ой а почему?)
panzerfaust
16.06.2025 07:29Ну так я и говорю: дурачье. На питоне быстрее, на пыхе дешевле, а они какой-то ерундой маются. Надо им письмо написать, чтобы подумали о своем поведении.
Zulu0
16.06.2025 07:29Надо им письмо написать, чтобы подумали о своем поведении
Есть такая поговорка: Дорога ложка к обеду. Если кричать на каждом углу что одна технология круче другой, можно этой ложкой однажды по лбу схлопотать. Простите.
pecheny
16.06.2025 07:29Может показаться неочевидным, но если речь идет о конкретной ситуации в конкретной компании, то разрабатывать сервис быстрее/дешевле на том языке, который знает разработчик/команда, а не на том, который в тестах гугла набрал больше попугаев.
И даже если какой-то инструмент объективно лучше подходил для решения задачи, то для бизнеса может оказаться выгодным выбор того, который знает/любит команда.
Drucocu
16.06.2025 07:29Может показаться ещё менее очевидным, но во всём нужен баланс, иначе можно застрять на PHP версии 5.6, потому что версии свежее разработчики не освоили и им быстрее запилить на том, что они знают.
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 и тупо спамил его запросами по ключу чтобы достать ответ. Вы спросите зачем? Так он сам лично сказал, что просто хотел эти технологии просто попробовать. Его желание самообучаться теперь живёт в реальном проекте. Сложные решения нужны, вопрос в том что должна быть НЕОБХОДИМОСТЬ для них, а её очень часто нет.
rpc1
16.06.2025 07:29Боюсь спросить а у вас refinement сессии проходят, обсуждают предлагаемые решения, архитектуру и оценивается сложность? а ревью кода? Мне вот сложно представить возникший ниоткуда Redis, которые даже не предполагалось использовать. Может все таки у вас проблема с процессами?
mvv-rus
16.06.2025 07:29вопрос в том что они должны быть обоснованными
...
Так он сам лично сказал, что просто хотел эти технологии просто попробовать.Ну, вот вам и обоснование: разработчик захотел повысить свою цену на рынке труда, за счет фирмы. И, с позции разработчиков, он прав. А с позиции фирмы... Да какое дело разработчику до позиции фирмы?
Единственно, в чем он не прав - в том, что, вместо того, чтобы прикрыться обтекателем, придумать уважительные причины, честно рассказал о своих реальных мотивах на собеседовании: собеседование-то обычно менеджер проводит, а у менеджера, даже если он линейный, и к земле близко, всё-таки в трудовые обязанности входит отстаивать интересы фирмы.
muhachev
16.06.2025 07:29Противоречивый текст. Вы просто со своей относительно субъективной точки зрения заменили одни относительно субъективные шаблоны на свои относительно субъективные шаблоны, считая свою позицию более объективной.
Даже про бритву Оккама можно относительно субъективно вам возразить тем, что использование паттернов как раз и является способом уменьшения информационной энтропии и избеганием изобретения новых сущностей.
Но вы уже высказали свою точку зрения на этот вопрос, и сформировали свою субъективно относительную систему отсчёта, в рамках которой пытаетесь уже как бы обективно обосновать выбор той или иной противоположности при разрешении противоречий.
Абсолютизация своей субъективной относительности, присуща всем субъектам, но она полезна только в относительном пространстве данного субъекта, поскольку позволяет избежать аналитического паралича в результате бесконечных колебаний при выборе противоречивых способов действий.
В публичных пространствах попытки выдать свою относительно субъективную точку зрения за абсолютно объективную, и тем самым неявно навязать её публике, путём противопоставления её другим способам действий, ничего, кроме раздражения и холивара не вызывает.
Более разумно, прогрессивно и эффективно было бы просто поделиться своими относительными успехами и их открытыми секретами, без явного противопоставления и высокомерной критики противоположных методов, пускай может быть и в ущерб паттерну подобного литературного жанра.
Но на такое не все способны, к сожалению.
alex_liebert Автор
16.06.2025 07:29На самом деле согласен с вами, просто цель статьи была в другом, я не особо верю что она кого-то чему-то научит, те кто поняли суть, а не докапывались до частностей и так это знают. Я специально писал в провокационной форме, чтобы посмотреть какой будет резонанс.
akakoychenko
16.06.2025 07:29По сути, из невежества все проблемы. Невежества разработчиков, которые тупо херачат по шаблонам и догмам, не задаваясь вопросом, а зачем. Невежества тех, кто ставит задачу, и не задается вопросом, а понимает ли исполнитель, для чего и с какой целью он это делает.
И, как будто бы, сама инфраструктура масштабируемого написания кода за деньги просмотрена именно так, чтобы это невежество масштабировать
brukva
16.06.2025 07:29Полагаю, те 8 лет опыта, что есть у автора привели его к вполне логичным выводам. Для того, чтобы понять необходимость многого из перечисленного, потребуется ещё столько же. Особенно очевидно на примере ретроспективы. Создается впечатление, что автор просто не уживается с многими членами команды, и его решение - уволить их и нанять кого-то нормального, а лучше никого, он сам все напишет, потому что не будет тратить время на тесты, архитектуру, паттерны - профит! Но только так не работает. И ретроспективы придуманы именно для того, чтобы внедрять идеи, которые работают, о них надо говорить, а не о том, что тимлид - мудак.
qeeveex
16.06.2025 07:29Перевожу на человеческий: зачем нам железный мост с расчетами по нагрузке, ща деревянный так нафигачим, и нормально будет. Если что сделаем подпорки.
Сколько потеряет компания, если метод будет работать не 100 мс, а 200?
В крупных компаниях идет война за каждый 10ms, ибо SLA, а это бабки.
С паттернами та же самая история: некоторые их вставляют где ни попадя, тем самым повышая энтропию на проекте с каждой строчкой своего кода.
Сталкиваюсь периодически с такими вещами, как отправка вебхуков прямо из коньсюмера кафки))) Авто, это случайно был не ты?!))
что такое correlation ID и как его прокинуть в том языке, которым они якобы владеют
Сейчас никто за это не запаривается, а может быть и не задумывается, так как уже является лучшей практикой использовать opentelemetry с его trace_id, библиотеки для которого есть для всех языков на любой вкус, но автор видимо не в курсе.
pnmv
наличие таких сотрудников на должностях означает, что проект уже идет ко дну, а не потонет когда-то там.
gres_84
По этому критерию. все проекты, на которых я работал, идут ко дну. Некоторые шли больше 10 лет.
Я не говорю, что это хорошо. При увольнении или смерти (было и так) такого сотрудника некоторое время всем больно. Но иногда просто невозможно найти полноценную замену, ресурсы не позволяют.
pnmv
всякое бывает, конечно, но можно же вести документацию.
у меня был случай, когда человек-документация, имея зарплату в три раза выше, ещё и с меня денег хотел, за консультации, которые ему отдельно оплачивал работодатель.
gres_84
Можно и нужно, но я только 2 раза видел действительно актуальную документацию, один раз ее просто делали сами программисты, что тоже по распределению ресурсов сомнительно.
Ну это точно дно. Не сталкивался с таким и, надеюсь, не столкнусь.
pnmv
я видел, в более-менее актуальном виде, только ту, что сам же и обновлял.