МОИ ЦЕЛИ В НАЧАЛЕ 1Т КАРЬЕРЫ: БУДУ УСЕРДНО РАБОТАТЬ, РАЗВИВАТЬСЯ И ОБЯЗАТЕЛЬНО СТАНУ КРУТЫМ РАЗРАБ / it-юмор :: работа :: geek (Прикольные гаджеты. Научный, инженерный и айтишный юмор)

Ты не понимаешь природу разработки

Вообще похую.

Расчехляем хаскель, пишем все на зав. типах. В процессе потребуется доказать n теорем. С вас 100тыщ миллионов

без тестирования все априори без багов

"у программиста есть геймдиз который скажет что делать и даст четкую задачу" - эх, живут же некоторые

Всё так. Особенно, проклятые мобильные донатные дрочильни

Большая часть компаний - говно

если у тебя старый проект, которому 20+ лет который работает еще на какой-нибудь 8ой джаве, или написан на С под старую архитектуру, у которого 300+ тыщ строк кода, и он обслуживает миллионы клиентов и при этом стабильно работает
его в большинстве случаев не будут переписывать на новые технологии, это супер-дорого

Тут может быть обратная реакция - если везде суешь свои паттерны, надо и не надо - то иди нафиг.
В соседнем отделе одного такого послали, после того, как он заявил на требование начальника добавить какую-то фичу - "не могу, паттерн такое не позволяет". И мне самому приходилось упрощать и оптимизировать код после таких любителей совать паттерны туда, где без них сделать проще и быстрее.

Это литералли обосрались и херовый ПМ. Если заказчик звонит напрямую разработчику и говорит что надо что-то сделать - то это не аджайл, это балаган.
Это задача менеджера - общаться с заказчиком.
И как ни странно, тогда все делается быстрее, и зкаказчик довольнее. Потому что как минимум "заказчик" - это обычно не один человек, а какое-то предприятие, с разными отделами и иногда порлитической грызней между ними.

А на практике в большинстве случаев возникает методология разработки под названием "скрамопад", сочитающая ритаулы аджайла с гибкостью водопада. (Нет, я, конечно, утрирую, никто не делает N месяцов проектирования, N месяцов разработки, N месяцов тестов и N месяцов деплоя, как этого требует классический водопад).

Вы команда. Вы зависите от K команд и еще M команд зависят от вас. Менеджеры, лиды, PMы и прочие черти собираются на шабаш и проводят свои темные ритуалы под названием "планируем релиз". В результате высирают расписание чо когда кому даёт свои deliverables.

Я тут где-то пропустил такой момент, что иногда ты нихера не знаешь, сколько времени надо делать фичу X, и чтобы это выяснить, тебе нужно потратить некое количество времени и произвести некие исследования. Когда великие боги расписания релизов не дают тебе времени, то производится оценка по методолгии "хер к носу".

Вы начинаете хуярить спринты.

В расово верном аджайле каждый юзер сторис дает атомарный deliverable и value заказчику, а каждый спринт - законченный отрезок работы. И можно депллоить, блять. Смешно, никогда такого не видел. Зачастую поебать и крупная задача (эпик) плюс-минус нарезается на юзерстори, но зачастую половина сделанных юзерсторей не имеет никакого смысла без второй половины.

Также в расово верном аджайле разраб способен хуярить не приходя в сознание, без исследований, проектирований и архитектур. Потому что подумать - это не deliverable. Нам было поебать, когда вещи нетривиальные, у нас иногда были целые юзерстори на подумать.

В какой-то момент вы обсираетесь. Методолгия оценки "хрен к носу" дала ошибку. Задача оказалось сложнее, чем ты думал. Разработчики оказались более ебланами. Или обосрался кто-то другой и входящие зависимости не успевают подвести в срок. Короче, задача растягивается. Одна, вторая, третья и так далее. Что это за звуки? Это трещит распсание релизов. Вместе с ним начинает трещать жопа у PMа, чтобы придумать, как всё все сделать, что надо (а всё надо!), а что надо чуть поменьше, и можно выкинуть.

Обосраться недостаточно. У нас же гибкие разработки. В какой-то момент к PM, менеджеру и прочим чертям приходят черти из других команд и говорят, что им очень, очень очень очень нужна фича Y. Но фичи A, B, C, которые мы запланировали на релиз и которые не успеваем, конечно же, тоже нужны. Крч, ебашьте. См. пикчу.

Чем реже релизы, тем сложнее шабаш, тем выше риск обосраться. При всем уважении к всяким веберам, наши релизы чаще всего поставляются в виде tar.gz всяким другим разработчикам, поэтому мы не CI/CD gonna brrr и катить релиз каждые два дня из мастера. (Это не значит, что CI и тестов нет) А если ваши релизы зашиваются в железо, то это еще больнее.

Копропилот сливает данные всем подряд, нарушая корпоративную тайну.

Юнит тесты это зачастую не более чем сверка входа и выхода зафиксированного ожидаемого результата.
На деле практически никогда они особо не пригождаются, потому что устаревают раньше времени.
Смысл они имеют только при Test Driven Development парадигме, когда ты пишешь тест раньше фичи, но эта концепция явно не для всех.
Поэтому эти ваши "надо уметь писать" это всё хуйня от тестировщиков.
Юнит тесты пишутся либо в середине разработки для отладки процессов, либо в конце разработки блока для фиксации результата.

Описание требований от заказчика и приоритизация задачи это тоже смешная история. Большинство заказчиков нихуя в этом вашем ИТ не понимает и редко даже может описать что им конкретно нужно. Поэтому все от менеджеров до техлидов ебутся с их хотелками приземляя их на землю.

Был потенциальный заказчик, который хотел систему, которая выдаст ему патенты и схемы и процесс изготовления по заданному в поиске изделию - аля, ввёл boeing 747 и получил все тех данные, чертежи и пошагово как на заводе слепить и чтобы всё с ИИ!!. Откуда брать схемы изготовления заказчик конечно же не уточнил.

Про "остальные задачи придётся отложить" тоже смешное. Бизнес в России живёт по принципу - набрать заказов чтобы делать их несколько лет, потому что потом денег может не быть. Поэтому одна команда может параллельно делать несколько проектов.

Людей не бесит неопределённость, потому что они являются её причиной. Их бесит как раз таки задержка и недопонимание почему в этом вашем ИТ за ваши ахуевшие деньги так долго всё делают. А то что он хуйни наворотил в своём ТЗ его особо не коробит.