Comments 20
Очередное рацпредложение как правильно контролировать процесс? Вместо того чтобы просто смотреть время от времени на реальные результаты? Ну ок.
Да, единственный вариант как сделать так, чтобы сотрудник работал хорошо - это сделать так, чтобы он был сам заинтересован в результатах своей работы. И тут все рецепты давно известны. Либо работа должна быть такая, чтобы человека от ней штырило. Либо у человека должен быть прямой финансовый интерес в компании (доля/RSU/опционы). Оптимально и то и другое.
А на каждый новый кнут найдутся нехитрые способы его обойти.
Не знаю, где вы увидели здесь кнут. Идея была обратная, призванная показать, что 2 строки кода могут даваться очень непросто, в то время, как кнут требует отчитаться, куда ты потратил 2 недели.
А зачем вообще нужно отчитываться и показывать чего-то кому-то, если это про процесс, а не про результат?
У вас же не абстрактные "две строки кода", у вас тикет на них. И на тикет есть какой-то эстимейт. И пусть это будет даже не две строки а минус две строки. А может и вообще ноль строк. Но если тикет закрыт - то результат есть.
Вопросы тут могут быть только если он закрыт за две недели, а заэстимейтен он был на четыре часа. Вот тут да, можно просто поинтересоваться кто был настолько оптимистичен и как избежать этого в будущем (либо эстимейтить лучше, либо в следующий раз поручать такого типа задачи тому, кто сделает их за два часа, а не за две недели).
Зачем отчитываться? Но вы сами говорите про эстимейты. Зачем тогда они? Тикет закрыт, результат есть и ладно. Зачем эстимейты? Для отчетности. Для планирования. Для оценки. Для приоритетов. Бизнес хочет знать, сколько ему это будет стоить до начала, сколько это реально стоило и насколько действительно задача сложная. Но это все суррогат, потому что измеряет теплое в килограммах.
Кто ставит эти эстимейты? Люди. На основании чего? Субъективной оценки: я угадаю эту мелодию с трех нот. Если речь идет о разработке с нуля или линейных изменениях, типа покрасить кнопочку, тогда да, можно оценить трудозатраты. Дизайн есть? АПИ есть? Тогда 10 минут.
Но если ставится задача починить баг или оптимизировать какой-то кусок в легаси. Какая здесь может быть оценка? Это пальцем в небо. Я оптимизирую этот запрос из 500 строк за 2 часа. Что? Как можно дать такую оценку не зная причины тормозов? Там может быть все что угодно, от конфигов до блокировок и умирающих дисков.
А если кто-то скажет месяц, но починит за час, нужно ли здесь поинтересоваться, кто был настолько пессимистичен и как избежать этого в будущем? А может кто-то справился бы за полчаса. Нужно ли передать такого типа задачи тому, кто справился бы за полчаса?
Здесь уже оценка скорее сводится тому, насколько эта починка необходима. Некий верхний порог, типа если за 2 дня не удастся разобраться - откладываем на неопределенный срок.
Все, что описано в статье, это про то, почему на задачу было потрачено Х часов. Действительно человек ей занимался или просто сказал что она сложная, а сам развлекался неделю, даже не прикасаясь к ней. После сорванных сроков попросил еще времени. Суррогатные метрики обесценивают труд одних, но необоснованно поднимая стоимость других.
Я вам расскажу историю из студенческих лет.
Подрабатывал я в автосервисе электриком. Однажды состоятельный клиент привез старый УАЗик, чтобы подготовить его для охоты. Он не скупился на запчасти. Там поменяли КПП, половину мотора и прочего. Одной из задач было установить туда новое электрооборудование: стеклоочиститель, новые фары, вывести управление светом на подрулевой переключатель и прочее. Как вы знаете, в старом УАЗике подрулевой только один, управляющий поворотниками. Был куплен новый руль от волги, торпеда, подрулевые, двигатель дворников с несколькими скоростями и программируемым интервалом. Осталось дело за малым - подключить это все.
Я 2 недели приходил по вечерам, прозванивал, обжимал клеммы, плел новые жгуты из проводов, каждый провод был с биркой и подписан. Никакой изоленты. Схему нарисовал.
Знаете, как руководство сервиса оценило мою работу? Они взяли нормачасы из официальной книжки автоваза.
Замена подрулевого (с/у) 10 минут.
Замена кнопки габаритов (с/у) 3 минуты.
Замена реле стеклоочистителя (с/у) 1 минута.
И т.д.
Получите 300р.
Якобы это я такой медленный, раз делал так долго. Вон, в книжке все давно рассчитано и клиента они возьмут по книжке. (конечно они все понимали, просто не хотели мне платить 30%, как изначально договорились)
(с УАЗика они взяли за эту работу 5000р, а 95 бензин тогда стоил 17р)
Так какой тут должен был быть эстимейт? По книжке ~30 минут.
Ну тут у вас ключевой вопрос "а кто эстимейтит".
Зачем эстимейтить понятно - не для отчётности, а именно для планирования. Когда не влезает в отведённые сроки, надо урезать функционал.
А вот эстимейтят либо сами инженеры, либо PM со слов тех же инженеров. Если это происходит как-то по-другому, то надо просто в спокойном режиме искать нормальную работу.
Умиляет такой стиль кода:
вместо:
if (a == b) c = d; else c = e;писать:
if (a == b) {
c = d;
}
else {
c = e;
}Мастер-класс по KPI.
c = a == b ? d : e;
Вообще форматтеры у всех давным-давно живут. И запускаются либо в pre-commit hook, либо вообще по любому изменению в файле.
Так что как не пиши отформатирует одинаково.
А потом добавится еще действий, и все равно разворачивать.
Мне ваш вариант не нравится: это он в однобуквенных переменных читается, а в длинных - либо уйдет за экран, либо сам перенесется. Не лучше тогда и скобочки добавить для будущих поколений.
И Diff наглядней будет.
Я как-то по запарке после такого if ещё строчку вставил и потом долго тупил со странных результатов. После этого предпочитаю всегда фигурные скобки ставить, а для компактности тернарный оператор есть.
В Гугл, похоже, об этом тоже что-то знают
https://google.github.io/styleguide/javaguide.html#s4.1-braces
Braces are used with
if,else,for,doandwhilestatements, even when the body is empty or contains only a single statement.
Есть мнение, что платить нужно именно за количество строк кода.
Что толку от того что вы поправили 2 строчки кода? Через месяц причину уже не вспомнить, придет другой человек и уберет их, чтобы поправить очередной баг, и тоже потратит на удаление целую неделю. Кроме этих 2-х строчек должны были родиться тесты на 100 строчек кода. И вот за эти 102 строчки и нужно начислять зарплату.
Руководители и старшие разработчики не в счет. Их сложно померить. Можно предложить считать строчки кода подчиненных с некоторым коэффициентом.
Давайте не будем придумывать, какими способами можно еще греть планету через инференс. Всегда же можно рендерить котиков!
А по сути, эта статья как будто из года 2005. Ностальгия есть, к этим замечательным временам "неделя мучения, и вот они заветные три строки". Но сейчас нет. Если это багфикс, то хоть и сам фикс может занимать даже одну строку, или один символ, как артефакты работы нужны еще тесты, которые не проходятся старым кодом, и скорее всего, очевидно, небольшое изменение архитектуры, чтобы эти тесты подключить к проблемному коду (и если "не повезет" очень как дофига придется замокать). Если это архитектурное изменение, то хорошо, редко, но возможно, что все изменение в API это три строки. Но это еще пачка вики-док с описанием как мигрировать, чем лучше новое решение, как минимум. И опять же тесты. Ну а фичи на три строчки маловероятны. Тут наоборот, в каком-нибудь легаси, кажется что фича на три строки, а в реальности пришлось перелопатить полтысячи.
А в 2005 да, бывало такое, что эти три строки достались сутками ковыряния бинарей в дизассемблере и отладчике. Но обычно это когда что-то сделать "нельзя, не надо, но очень хочется". Но сейчас такие практики, мб, только у вирусописателей и остались.
Не верю я в три строчки, не верю.
Конечно 3 строчки это багфикс/оптимизация или доработка. Разве где-то речь шла о том, что это новая фича?
О каком 2005 и дизассемблере вы говорите? Я вам приведу десятки примеров, как в современных архитектурах не могли починить месяцами плавающий баг авторизации из-за куков. Выделяли каждый спринт несколько часов. Каждый новый решатель говорил, что предыдущий балбес, а я вот точно знаю где искать. Но обломали зубы. Баг так и живет.
О том 2005, где в небольшой компании живет жесткий водопад, репозиторий cvs (это хорошо, если так) и файлики. Там же в этих файликах выкидывались какие-то progress_module1.txt, какие-то сборочные артефакты, какие-то тестовые бинари и у кого как. Тогда да, работа это то, что попадает в репозиторий, а остальное раз в месяц сносил админ (на самом деле эникей, которого пнули, что место на шаре мол кончается). В тех же файликах еще нередко валялись фотки с новогоднего корпоратива, ppt презентации для заказчиков, какие-то небольшие игрухи. Замечательные были врема, спору нет...
И если Вы продолжаете в них жить, да при текущем уровне зарплат, то ничуть не сострадаю вашей проблеме, скорее просто завидую.
Но какие багфиксы на три строчки в этом мире? Говорите, плавающая проблема? Так первое с чего начинают, строят образ проблемной конфигурации (даже в самом унылом случае, это виртуалка с специально сконфигурированной средой, которая попадает потом в бинарные артефакты), а чаще это отдельный бранч, где плавающий баг специально доталкивается до повторяющегося отдельным кодом. И это еще до непосредственно исследования бага и его исправления. Потом отладка, и исправление. Да даже если непосредственно обход проблемы занимает три строчки, нужно всегда смотреть на окружение этого кода, постараться рефакторить то, что этот баг скрывало. Ну и в конце концов тесты. Чтобы вот четенько было видно, что до фикса тест был красненьким (да-да, этого не обязательно можно добиться юнит-тестами, и тогда проблемные конфиги надо включать уже в интеграционные тесты, в общем тут еще больше вариантов), но вот эти тесты точно никак нигде и никогда не будут тремя строчками.
С моим опытом скажу, что любые PR в три строчки без других артефактов (обозначено выше) можно сначала отклонить, а потом уже изучить. Потому что это не будут фиксы, в 98% это просто костыли. В 1%, ой-бой, это исправление безобидного недосмотра уволившегося коллеги. Еще 1% остается на то, что это валидный кейс.
А дальше все просто, если у сотрудника эти 1% превращаются в хотя бы 20% его работы, то вывод даже без теоремы Байеса понятен, он халтурит.
Про оптимизации еще смешнее. Вот тут хочу любой пример. Да, в три строчки где-то можно поменять под задачу коллекцию вроде дерева, на хэш-мапу. Или убрать лишний запрос к БД, потому что в соседнем поле эти данные и так болтаются. Но остаются два вопроса, как в эти три строчки уместить еще и доказательство того, что оптимизация полезна в принципе (то есть как "у себя локально потестил", вроде в 2 раза быстрее, а вам зачем знать, что и как я тестил), и что там можно две недели оптимизировать, когда профайлеры всего и везде есть.
Все когда-то халтурили, все иногда выгорали, изредка можно встретить реально противную проблемку, но что бы три строчки кода за две недели без других артефактов было хоть чем-то похожим на норму говорить смешно. А если это превращается в 6 строчек за месяц, то грустно, и пора с человеком прощаться.
Я не очень понимаю вектор этого разговора. Зачем вы навешиваете на меня ярлыки, которых нет. "2005 год, водопад..." Это не моя проблема. Я не пишу код уже давно (о чем говорил в самом начале), хотя по-прежнему очень близок к разработке. И как бы если посмотреть с этой позиции, можно сказать, что мне все равно, как там ПМ оценивают свои сторипоинты. Я лишь поделился размышлениями и не более.
Если суть статьи вам не понравилась и вы не увидели в нем рационального зерна, ок.
Может вам не понравился заголовок статьи и вы хотите сказать, что он неправдоподобен? Это просто заголовок. В статье несколько другой посыл.
построить образ проблемной конфигурации
А разве чтобы его построить, не нужно вникнуть в проблему и изучить хотя бы условия, при которых это воспроизводится. Разве это не интеллектуальная деятельность?
Все это окружение, виртуалки, эксперименты, о которых вы говорите, разве будут как-то отражены в финальном комите? Но вы их делали. Вы тратили время на гипотезы и их проверки.
Там будет только фикс по делу. Артефакты могут остаться, если кто-то требует их в качестве доказательств, но это не всегда и не везде так. Если у вас этот процесс налажен - прекрасно. Но я видел массу примеров в весьма крупных финтехах, когда разраб пофиксил багу и никаких тестов не появилось, а ручник даже не удосужился сделать несколько скринов о том, что он это протестил. Вы скажете, что это проблема команды и процессов. Нужно повесить техлида и разогнать сеньора QA. Возможно. Но идеального мира не существует. Косяков полно везде.
Потом отладка, и исправление
Вот в этом и кроется вся соль задумки. Отладка это не нажатие одной кнопки. Весь процесс этой отладки никто не видит. Не видно количества усилий, которые были на это затрачены. Видно только результат фикса, новые тесты, что-то еще. Это все готовый результаты. Они не появились по щелчку пальцев. Вы работали, думали, искали нестыковки. Это интеллектуальная деятельность, объем которой не виден в комите и в скринах. Этого артефакта просто нет, потому что нет системы, которая могла бы его зафиксировать. Не видно путь, который вы прошли, чтобы получить результат.
Вы говорите про высокий уровень разработки в современном мире? Скорее он перегружен процессами вокруг, а багов стало только больше. Фреймворки генерят что-то под капотом, создавая мусорный код, а разраб не знает, как работает ORM и дергает в цикле атрибут БД.
Пример про баг в три строчки: когда убрали WITH NOLOCK, который кто-то когда-то добавил. Халтура это была или оправданный хинт на тот момент - неизвестно. Но он был. А человек уже давно не работает. В какой-то момент это выстрелило. Оказалось, что он где-то внутри вложенного запроса в хранимке, которая вызывается только в одном месте раз в квартал. И это то, о чем вы говорите:
В 1%, ой-бой, это исправление
безобидногонедосмотра уволившегося коллеги. Еще 1% остается на то, что это валидный кейс.
Это не значит, что так не бывает.
Пример оправданной оптимизации:
Чтобы в наше время кто-то действительно этим занимался... В современном мире мне назвать такой пример сложно. Это скорее исключение. Потому что сторипоинты показывают, что проще докупить еще мощностей в ЦОД. Проще послать пользователя подальше, и сказать, что у него старый телефон, чем заниматься оптимизацией. Это реальность. Куча багованого софта, который никто никогда не будет исправлять, потому что якобы всего одна жалоба за все время, а не мажор. Зато там все покрыто автотестами.
Вы пользуетесь оперой? У нас же явно сказано, что мы гарантируем только хром.
Разве не так выглядит реальность? Но это уже очень большое отступление от темы статьи.
Повторюсь, мне непонятен контекст разговора. Что мы обсуждаем?
PS. Статья не предлагает менять подход к разработке. Статья лишь предлагает попробовать оценить когнитивные затраты.
Мне очень нравилось и до сих пор нравится когда у тебя в пуле разные задачи: в одних тебе надо потратить неделю и в результуте написать две сьрочки, в других за 1 день написать 500. В этом случае ты можешь начать с непонятной баги, котрая случается только на проде, и если нет прогресса, перейти к какой-то скучной технической таске.
Мне скидывали вот такие видео от одного известного в своих кругах товарища:
https://youtube.com/shorts/FZqBp1i73tI?si=p6MKkKS2DyrdPgpb
https://www.youtube.com/live/\_H0isUrZ8l0?si=WvLa7Hf4eSxJm4aP&t=35m52s
Вот. Самая актуальная тема разработчик и оценка его деятельности. Я бы предложил кто захочет пусть кидают предложения как проверить что программист вообще работал. Тут просто вариантов много, но нужен самый эффективный.
Три строки кода за две недели — это не всегда лень