Comments 61
Если у вас в команде есть человек, через которого решаются все вопросы, он же человек-документация — поздравляю, вы в ситуации, когда вся система держится на одном человеке, и если он уйдёт в другую компанию, всё пойдёт по одному месту.
наличие таких сотрудников на должностях означает, что проект уже идет ко дну, а не потонет когда-то там.
По этому критерию. все проекты, на которых я работал, идут ко дну. Некоторые шли больше 10 лет.
Я не говорю, что это хорошо. При увольнении или смерти (было и так) такого сотрудника некоторое время всем больно. Но иногда просто невозможно найти полноценную замену, ресурсы не позволяют.
всякое бывает, конечно, но можно же вести документацию.
у меня был случай, когда человек-документация, имея зарплату в три раза выше, ещё и с меня денег хотел, за консультации, которые ему отдельно оплачивал работодатель.
По большей части правильно (в том числе и на основе собственного опыта), но не соглашусь с некоторыми очень категоричными утверждениями.
Во первых, любой менеджмент (в том числе и ПМ) обязан контролировать использование ресурсов, т.е. трудозатраты разработчиков. И если он этого не делает или не умеет делать, то это не проблемы разработчиков, а проблемы именно менеджеров, т.к. именно они управляют расстановкой приоритетов по задачам, а тогда как разработчик волен использовать свою сортировку задач (делать то, что ему наиболее интересно, например, изучать новые языки программирования или фреймворки).
Что же касается тестов (пагинация для -1 страницы), то тестировщик совершенно прав. Любой пользовательский ввод не должен полагаться на добросовестность пользователя и должен быть защищен от его злонамеренных действий.
Как пользователь введёт -1? Если на странице нет такой кнопки.
Через режим разработчика, особенно, если он конкурент. И вообще, от таких зачем не далеко до реальных дырок в безопасности.
Тот же -1 вполне может вызывать исключение и засирать ими логи, через это уже можно вполне себе способ навредить.
Это всё размышления на уровне "а что если", при этом в беклоге нельзя найти ни одной задачи на фикс подобных вещей за 6+ лет работы компании. Из-за такого мышления разработчики как раз и городят то, чего не должно быть в коде приложения вообще.
Надеюсь, у вас открыт багбаунти? Выглядит как лёгкие деньги.
Оставлю вам это здесь для информации о последствиях подобных багов
https://www.businessinsider.com/when-amazon-launched-a-bug-allowed-users-to-get-paid-by-the-company-2011-10
Одного такого пользователя "а что если" из 10 000 тысяч других будет достаточно.
Мне однажды такой "а что если" сломал сайт. Разгребал неделю.
Вопрос, что вам дешевле - пофиксить сейчас или разбираться потом с редким багом. Я работал в кампании, поставляющей решения для городского транспорта. И там один баг, проявляющийся раз на миллион попыток заканчивался регулярными обращениями граждан к организатору перевозок и штрафами. Поэтому фиксились даже самые тупые на первый взгляд ситуации.
Например, мне вспомнилась ситуация, когда человек зашел в один автобус, потом пересел в другой, а потом вернулся в первый.
Но даже если баг по вашему мнению невозможен сейчас, он вполне может стать возможным позже после рефакторинга/дописывания.
Ок, открыл, ввел, получил ошибку, что дальше? Как это вредит безопасности если там препереды и ограничения доступа по другим параметрам?
Если вся статья про "чик-чик и в продакшн", вы думаете одной ошибкой пагинации всё ограничится?
Не ограничится, будут еще другие, такие-же некритичные. Есть какая-то идея, что некритичные ошибки — ведут к критичным для системы, это не совсем так. Если сосредотачиваться на реальной безопасности и оставить на потом, если потребуется, такого рода штуковины как пагинация -1, то сделать получится существенно больше за те-же деньги/время. Но разработчику на время/деньги все-равно — платит корпорация, она за эффективность не доплачивает, зато делает мозг за мелкие недочеты.
И я читаю эту статью так: если у вас нет 2 миллиардов рублей на сервис из четырех табличек, то не стоит пытаться разрабатывать так, как разрабатывает корпорация, вы просто не доживете до запуска — неважно будет, есть там у вас железобетонная защита от всего на свете и красивые 404 во всех местах или нет.
Если сосредотачиваться на реальной безопасности и оставить на потом, если потребуется, такого рода штуковины как пагинация -1, то сделать получится существенно больше за те-же деньги/время
Можно подумать, что добавить 1 тесткейс к своему тестсьюту - это никак не меньше 1 человекомесяц работы и 5 млн затрат.
А фактически это пара клац-клац по клаве и 1 глоток чая. Для модных-молодежных 1 промпт в ИИ-помогайку. Весь описанный в статье "оверинжиниринг" - это тупо рутина для сеньора, которая просто теряется на фоне остальной работы. Например, на фоне выяснения у пресловутого "бизнеса", чего же он все-таки хочет. Но эти потери никто не считает. А вот лишний тесткейс или лишний интерфейс - это ай-ай-ай и вообще вредительство.
Был как то у меня случай из жизни. Я еще был совсем юный, тогда еще php4 было. Я подошел к одному человеку, мы вместе тусовались тогда небольшой группой единомышленников. И вот он тогда специализировался на взломе сайтов. Мы с ним болтаем, я его спрашиваю - мол как можно взломать сайт и все такое. Он мне говорит, ну вот видишь, переменные тут в строке отправляются, он мне на примере сайта который они же и разрабатывали, начал показывать. Мол смотри как реагирует если это отправить, если то отправить.
Адресная строка уже стала довольно длинной. Он редактирует очередную переменную в попытке получить ошибку. В очередную переменную вводит 123456789 нажимает ентер и сайт открывается с админскими правами.
Мы с ним стоим и смотрим на произошедшее. Мы вместе не могли поверить, что все могло быть настолько просто, только каждый из нас думал об этом в разрезе своего понимания.
Для этого кнопка не нужна, а как, зависит от конкретного сайта, например тут на Хабре, это будет https://habr.com/ru/articles/page-1/
рандомный индийский бот тыкнет прямо в урл.
и может там увидеть какое нибудь интересное, совершенно внезапно
тестировщик как специалист делает свою работу, и покрывает ваши разработческие задницы (вы забыли енв переключить/ошибку обработать - и вместо страницы ошибки бот получил полный трейс ошибки с путями, данными, и не дай бог енв переменными со всеми кредами).
че бухтим?
Такое сканеры SQL инъекций делают влёт.
Что же касается тестов (пагинация для -1 страницы), то тестировщик совершенно прав. Любой пользовательский ввод не должен полагаться на добросовестность пользователя и должен быть защищен от его злонамеренных действий.
Если у вас есть веб морда, то у вас на лбу должна быть гравировка: все данные от пользователя надо проверять, они опасные. И никаких проблем не будет.
простенькие сервисы, которые на каком-нибудь Python или PHP могли бы прекрасно работать и поддерживаться, пишутся на Go или C#. ... Но разработка на них не быстрее, а это — деньги компании
...
И если после прочтения этого текста у кого-то возникло ощущение дискомфорта — значит, всё было сказано не зря и имеет место быть.
У меня возникло ощущение дискомфорта и даже кринжа от беспруфных утверждений, что разработка на одних популярных языках как-то заметно быстрее, чем на других. Веб-фреймворки есть для каждого языка. С ними типовые джейсоноукладчики везде пишутся одинаково. Про ИИ-помогайки вообще молчу. А для нетиповых решений нужно как раз инженерную думалку включать, а не просто тезис "разработчики по ночам у бизнеса деньги воруют".
Google делал ресерч на эту тему с доказательствами, что разработка на Python и PHP быстрее
... и продолжили развивать Go и поддерживать Kotlin. Вот же дурачки.
Я не говорил, что в этих языках нет необходимости, я говорил что в подавляющем большинстве серверных решений в них нет необходимости. Даже если у вас будет какой-то сложный расчёт в приложении его можно отдельно написать на Go или C, вполне нормально отношусь к такому.
На основе чего вывод о "подавляющем большинстве"? Пруфы, статистика, описание кейсов? Душещипательные истории, как выкинули бэкенд на JVM, переписали на Python, и плакали от счастья?
А, ну да, понимаю. Джентльменам принято верить на слово.
Наши глубочайшие приветствия, Алексей ( или Александр )!
Мы — группа IT-специалистов из Корейской Народно-Демократической Республики, обладающих определёнными навыками в области информационных технологий (но никак не хакеров!). Мы впечатлены вашим подходом к разработке и хотим глубже изучить ваши проекты — настоящий кладезь знаний и опыта. Пожалуйста, предоставьте нам ссылки на ваши проекты, и, если возможно, сразу на пагинацию.
и продолжили развивать Go и поддерживать Kotlin. Вот же дурачки.
Но самый дешевый хостинг для сайтов, погоди-погоди, на апаче+пехепе+мускль (ой а почему?)
Может показаться неочевидным, но если речь идет о конкретной ситуации в конкретной компании, то разрабатывать сервис быстрее/дешевле на том языке, который знает разработчик/команда, а не на том, который в тестах гугла набрал больше попугаев.
И даже если какой-то инструмент объективно лучше подходил для решения задачи, то для бизнеса может оказаться выгодным выбор того, который знает/любит команда.
correlation ID
как вы будете его "прокидывать", в известном вам языке?
создается впечатление, что вы имеете в виду какой-нибудь конкретный фреймворк, для конкретного языка программирования, подразумевая, что читатель поймет вас, на интуитивном уровне, но читатель не поймёт, в рамках ваших предположений. читатель поймёт по-своему.
лид тестирования убеждал меня, что нужно проверять пагинацию на -1 страницу. На что он был послан…
Уровень вашей компетенции понятен.
Почему-то создаётся впечатление, что при первых же трудностях автор возьмёт на себя ровно 0 ответственности:
это программисты выбрали неверную архитектуру, и наплодили легаси
это тестировщики не дотестировали и пустили баги в прод
А автор при этом героически спасал бизнес, и вообще дайте ему премию.
Интересно почему, учитывая, что я наоборот против ситуаций когда коллективная ответственность слишком размывает ответственность отдельного специалиста. Как раз в таких ситуациях люди и творят что захотят.
Опыт взаимодействия с людьми. Софт-скиллы, если хотите.
Показательно, что про коллективную ответственность я и не говорил, это ваша личная ассоциация. Я, как раз, не сомневаюсь, что вы всегда найдёте виновного. Просто это никогда не будете вы: судя по тону статьи, а тем более по вашим ответами, у вас слишком большое самомнение, чтобы признать ошибку.
Что касается паттернов и архитектур, всё это нужно для упрощения восприятия кода. Код с хорошей архитектурой не только легче сопровождать, но и изначально он пишется быстрее. Если разработчик говорит, что он может написать решение абы-как за день, либо с хорошей архитектурой, но за неделю, это говорит о том, что у такого разработчика отсутствует понимание самой цели, что он делает.
Паттерн рождается, когда ты смотришь на код (или представляешь его в голове) и пытаешься понять, как сделать его более лаконичным и удобным для использования. Но вместо этого очень многие разработчики (если не большинство) первично смотрят не в код, а читают всякие статьи в стиле "Топ-10 сеньорских паттернов сезона весна-лето 2025". И потом спешно тащат это в свой проект, чтобы выглядеть "круто" в глазах коллег.
Правда в том, что все статьи, книги и видео о программировании превращаются в бесполезный мусор, если не искать примеры использования этого в реальных проектах, написанных не тобой и проверенных временем. В книжке тебе возьмут пример в 50 строк кода и отрефакторят тремя разными паттернами. Но это совсем не показывает то, как поведёт себя этот паттерн в проекте на 100 тысяч строк. Для этого нужно залезть в код какого-нибудь фреймворка. А ещё лучше залезть туда с дебагером, чтобы понять саму механику работы всех этих паттернов. Чтобы понять, почему там сделали так, у не по-другому.
Но вместо этого все учат голую теорию. Более того, голую теорию теперь спрашивают при приёме на работу. Как будто они принимают людей в Академию наук, а не в организацию, занимающуюся созданием коммерческих продуктов.
Сразу вспоминается, как на собесе меня спрашивали о работе индексов, а потом на проекте я нашёл таблицу, на которую их навесили 9 штук, и разработчик хотел навесить 10-й, если бы я не остановил.
И? Без конкретики совсем не очевидно, что нужно было останавливать.
Гадай сам, что делает функция с названием swap_swap_swap(). И ведь проблема не в том, чтобы понять её алгоритм, а в том, что неясно, какую проблему она решает.
Как будто можно просто функции понятнее называть. Тогда и комментарии, за редким исключением, будут не нужны.
Если вы слышите фразу, указанную в заголовке — это значит, разработчики написали тесты на всё что угодно, но не на то, что действительно нужно. Написание тестов на функции по типу 2 + 2 = 4 — это самое настоящее вредительство.
Как вы определяете что "действительно нужно"? Если функция вместо 4, начнёт возвращать 10 это действительно будет ок?
Гадай сам, что делает функция с названием swap_swap_swap().
Вот бы кто придумал какое-нибудь языковое соглашение по названию функций, переменных итп.
Вспоминается случай, когда мне лид тестирования убеждал меня, что нужно проверять пагинацию на -1 страницу.
А пагинацию на 0 страницу надо тестировать? А на max+1?
Будучи зелёным юнцом, как-то ко мне обратился знакомый, имеющий строительный бизнес,
Кто был зеленым юнцом? Исходя из содержания текста - автор. Исходя и грамматики - знакомый, имеющий строительный бизнес.
Зачем вообще бизнесу эти разработчики? От них одни проблемы да убытки.
Если возможно написать сервис в 100 строк — лучше написать так. Потом, если потребуется, его будет несложно переработать под более удачную архитектуру.
Видно что Вы или редко или не сталкивались с такими задачами. Лично по моему опыту, классическая ситуация, аналитики РП уговорили сделать тяп ляп в 100 строк кода сейчас, потому что сдаем проект через полгода и забываем. На деле, через полтора года - теперь чтобы "переработать под более удачную архитектуру" нужно в 10-15 раз больше времени а исправление багов почему то стало занимать не часы а дни и недели.
Никогда такого не было и вот опять.
Ещё страшнее, когда фанатик одной архитектуры попадает на проект с другой архитектурой и начинает его переписывать под своё чувство прекрасного. За чей счёт? Правильно — за счёт компании.
В целом если это не оправдано то да. Но часто бывает что с прошлой архитектурой работать очень сложно и неудобно. Работа будет малоэффективной, задачу и баги будут делаться долго. За чей счёт?
Например, ООП-разработчики очень любят плодить интерфейс на каждый класс.
А теперь спросите себя насколько создание интерфейса или дописывание в него метода замедляет разработку. На 10-60 секунд? А когда потребуется все таки писать тесты сколько это сэкономит?
Подобное мышление приводит к тому, что простенькие сервисы, которые на каком-нибудь Python или PHP могли бы прекрасно работать и поддерживаться, пишутся на Go или C#. Фанаты этих языков будут с пеной у рта доказывать, насколько они быстрые. Но разработка на них не быстрее, а это — деньги компании. Сколько потеряет компания, если метод будет работать не 100 мс, а 200? Думаю, нисколько.
Сколько потеряет компания когда их мелки сервис разрастется, когда нужно будет куча ресурсов и в конце концов когда все равно все перепишут на на Go или C# и потратят на это огромную кучу денег вместо того чтобы сделать сразу нормально. Сколько компаний с этим столкнулось и столкнутся.
Никогда такого не было и вот опять.
Подобная ситуация легко возникает, если, например, тимлид не даёт разработчикам разнообразные задачи, чтобы они лучше понимали проект в общем, а только узконаправленные.
У Вас противоречие - если тимлид раздает задачи разным людям значит все эксперты в своих областях и рассказываете Вы про человека на котором держится все команда.
В целом со многих согласен. Но...
В статье типичная ошибка - качели в одну сторону. Вы описываете как вредит оверинжиниринг. Но жизнь то вещь сложная и разработка тоже. Нельзя просто "Если возможно написать сервис в 100 строк — лучше написать так ", если бы там все просто было и оверинженерига бы не было а оно рождается из как раз из гипертрофированных попыток исправить тот ад который обычно случается после подобных советов.
Сложность в балансе.
Разработчик он за зарплату. Деньги не его. Методичек много, поле для деятельности большое. Эффективность бизнеса - не его задача. Смерть проекта от 1000 порезов не его проблема. Утверждения про безопасность - ну так что угодно объясняется. Становится безопасности больше от применения всех методичек вперемешку - по разному, если навертели в 4 этажа, что самим непонятно как работает, ну какая там безопасность. Кто-то говорит публично, что это дичь - ну это как против использования микросервисов в проекте трехстоаничного сайта рот открывать.
Вот не уверен, с некоторыми тезисами явно не соглашусь:
Разработчик налегал на DDD, но не смог написать сохранение в базу. Кажись тут проблема не в том что он налегал на DDD, а что он просто плохой кодер, и прикрывается всякими умными вещами.
На вопрос "зачем DI c интерфейсами" нужно отвечать "потому что так удобней на сложной архитектуре". Тесты это прекрасно, но вообще-то в первую очередь решается типичная проблема что в глубь нужно прокинуть десяток другой тех или иных классов/интерфейсов, и тащить всё это добро через все конструкторы сверху вниз -- заманаешься. А когда ещё и скоп появляется, то удачи всё это дело организовать без ioc-контейнера. Я уже молчу что всякие либы предполагающие использование DI для быстрого внедрения в код.
На C# (а если точнее, то на asp.net core) сайты пишуться довольно элементарно, не особо понимаю чем там PHP радикально быстрее. Возможно всё же подразумевалось что на PHP есть много CMS и прочих решений "из коробки", что имеет смысл применять в тех или иных ситуациях.
Идея "сделать сейчас 100 строк кода" может быть как отличной, так и фатальной. Без контекста это обсуждение сферического коня в вакууме. И обычно вся сложно как раз в том чтобы понять как решать задачу в данный момент -- в 100 строчек или расписывать с запасом на будущие правки.
Я вроде ясно дал понять, что не являюсь противником сложных решений, вопрос в том что они должны быть обоснованными, а не просто потому захотелось вот. Буквально пару недель назад собесил разработчика, который сделал обработку запросов на RabbitMQ, а response ожидал ответ в Redis и тупо спамил его запросами по ключу чтобы достать ответ. Вы спросите зачем? Так он сам лично сказал, что просто хотел эти технологии просто попробовать. Его желание самообучаться теперь живёт в реальном проекте. Сложные решения нужны, вопрос в том что должна быть НЕОБХОДИМОСТЬ для них, а её очень часто нет.
Боюсь спросить а у вас refinement сессии проходят, обсуждают предлагаемые решения, архитектуру и оценивается сложность? а ревью кода? Мне вот сложно представить возникший ниоткуда Redis, которые даже не предполагалось использовать. Может все таки у вас проблема с процессами?
вопрос в том что они должны быть обоснованными
...
Так он сам лично сказал, что просто хотел эти технологии просто попробовать.
Ну, вот вам и обоснование: разработчик захотел повысить свою цену на рынке труда, за счет фирмы. И, с позции разработчиков, он прав. А с позиции фирмы... Да какое дело разработчику до позиции фирмы?
Единственно, в чем он не прав - в том, что, вместо того, чтобы прикрыться обтекателем, придумать уважительные причины, честно рассказал о своих реальных мотивах на собеседовании: собеседование-то обычно менеджер проводит, а у менеджера, даже если он линейный, и к земле близко, всё-таки в трудовые обязанности входит отстаивать интересы фирмы.
Противоречивый текст. Вы просто со своей относительно субъективной точки зрения заменили одни относительно субъективные шаблоны на свои относительно субъективные шаблоны, считая свою позицию более объективной.
Даже про бритву Оккама можно относительно субъективно вам возразить тем, что использование паттернов как раз и является способом уменьшения информационной энтропии и избеганием изобретения новых сущностей.
Но вы уже высказали свою точку зрения на этот вопрос, и сформировали свою субъективно относительную систему отсчёта, в рамках которой пытаетесь уже как бы обективно обосновать выбор той или иной противоположности при разрешении противоречий.
Абсолютизация своей субъективной относительности, присуща всем субъектам, но она полезна только в относительном пространстве данного субъекта, поскольку позволяет избежать аналитического паралича в результате бесконечных колебаний при выборе противоречивых способов действий.
В публичных пространствах попытки выдать свою относительно субъективную точку зрения за абсолютно объективную, и тем самым неявно навязать её публике, путём противопоставления её другим способам действий, ничего, кроме раздражения и холивара не вызывает.
Более разумно, прогрессивно и эффективно было бы просто поделиться своими относительными успехами и их открытыми секретами, без явного противопоставления и высокомерной критики противоположных методов, пускай может быть и в ущерб паттерну подобного литературного жанра.
Но на такое не все способны, к сожалению.
По сути, из невежества все проблемы. Невежества разработчиков, которые тупо херачат по шаблонам и догмам, не задаваясь вопросом, а зачем. Невежества тех, кто ставит задачу, и не задается вопросом, а понимает ли исполнитель, для чего и с какой целью он это делает.
И, как будто бы, сама инфраструктура масштабируемого написания кода за деньги просмотрена именно так, чтобы это невежество масштабировать
Замечал, что такое поведение свойственно людям, которые всю жизнь работают в профессии и не являются вайтишниками
Автор статьи видимо не слышал о job security driven development.
Полагаю, те 8 лет опыта, что есть у автора привели его к вполне логичным выводам. Для того, чтобы понять необходимость многого из перечисленного, потребуется ещё столько же. Особенно очевидно на примере ретроспективы. Создается впечатление, что автор просто не уживается с многими членами команды, и его решение - уволить их и нанять кого-то нормального, а лучше никого, он сам все напишет, потому что не будет тратить время на тесты, архитектуру, паттерны - профит! Но только так не работает. И ретроспективы придуманы именно для того, чтобы внедрять идеи, которые работают, о них надо говорить, а не о том, что тимлид - мудак.
Перевожу на человеческий: зачем нам железный мост с расчетами по нагрузке, ща деревянный так нафигачим, и нормально будет. Если что сделаем подпорки.
Сколько потеряет компания, если метод будет работать не 100 мс, а 200?
В крупных компаниях идет война за каждый 10ms, ибо SLA, а это бабки.
С паттернами та же самая история: некоторые их вставляют где ни попадя, тем самым повышая энтропию на проекте с каждой строчкой своего кода.
Сталкиваюсь периодически с такими вещами, как отправка вебхуков прямо из коньсюмера кафки))) Авто, это случайно был не ты?!))
что такое correlation ID и как его прокинуть в том языке, которым они якобы владеют
Сейчас никто за это не запаривается, а может быть и не задумывается, так как уже является лучшей практикой использовать opentelemetry с его trace_id, библиотеки для которого есть для всех языков на любой вкус, но автор видимо не в курсе.
Как разработчики убивают бизнес