Профессионализм: защита качества кода

Добавление ответа, потому что другие ответы танцуют вокруг него, но никогда не обращаются конкретно в самой короткой возможной фразе:

Вам нужно "определение сделанного"

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

Хотя вы часто найдете эту концепцию под эгидой Agile/Scrum, эта рабочая среда не является необходимой для реализации этой идеи.

https://www.scruminc.com/definition-of-done/

https://www.agilealliance.org/glossary/definition-of-done/

На мой взгляд, виновата не политика, а человек, пытающийся злоупотребить политикой.

Как инженер я отвечаю за качество кода. До какой степени я должен бороться за это?

Пока вы за что-то отвечаете, вы должны следовать этому до тех пор, пока не сможете доказать, что любое отклонение не вызвано «вы» . Учитывая контекст, который вы упомянули, похоже, вы боретесь за правое дело. Речь идет не только о «руководстве по кодированию», цель состоит в том, чтобы иметь код , который действительно работает и выдает ожидаемый результат.

Уместно ли мне просить начальство изложить свои решения в письменной форме?

В данном случае очень даже да. Вы дали отрицательный отзыв, и если кто-то попросит вас отказаться от блокировщиков и позволить этому коду найти свое место в производственном коде, убедитесь, что это можно отследить до «спросить» в более поздний момент времени.

Если качество кода страдает из-за организационных проблем (способ вознаграждения подрядчика), уместно ли мне быть «судьей» или поднимать этот вопрос перед начальством или отделом кадров?

Я бы не сказал, что это HR, который может справиться, это должно быть сообщено вашему начальству и техническим менеджерам, которые могут понять влияние.

Вы уже попробовали некоторые из правильных вещей, чтобы попробовать в этом сценарии, однако я бы посоветовал еще одну вещь:

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

Похоже, процесс управления проектами проблематичен. Иногда лучше иметь частично завершенную функцию, чем недоступную, но есть и плюс. Дело в том, что перспектива отслеживания должна быть улучшена. Просто доставка кода (или выдача запроса на включение) не должна быть мерой доставки, ответственность за проверку кода и его слияние с производственным (окончательным) кодом лежит на владельце.

Подвести итог:

• Убедитесь, что в комментариях к обзору упоминается не только проблема в коде, но и неблагоприятный побочный эффект, который он будет нести, если разрешить слияние. Процитируйте правила/рекомендации, на основании которых вы делаете эти комментарии, чтобы стало очевидным, что вы не «придираетесь», а поднимаете обоснованные опасения в соответствии с хорошо установленными рекомендациями.
• Постарайтесь установить крайний срок доставки, который значительно опережает фактический срок поставки, чтобы оставалось достаточно времени для любых необходимых изменений/исправлений.
• Попросите, чтобы основные отчеты о тестировании были связаны с запросом на включение — таким образом у вас будет больше доказательств, чтобы установить свои точки.

Окончательно:

Тем не менее, некоторые коллеги в частном порядке говорили мне, что с таким отношением я далеко не продвинусь.

Что ж, это не очень хороший знак. Разрешение плохого кода не только плохо сказывается на качестве, но также свидетельствует о том, что те, кто выступает за разрешение, не уважают время и усилия, затраченные на процесс проверки, и, в свою очередь, не уважают работу, проделанную одним или больше сотрудников. Если это продолжится, вам лучше найти организацию, которая ценит усилия своих сотрудников.

Постарайтесь сделать критерии принятия объективными.

Как инженер я отвечаю за качество кода. До какой степени я должен бороться за это?

Да, качество кода — это ваша ответственность, но это не значит, что вы должны следить за тем, чтобы качество кода было на самом высоком уровне. Ваша задача — убедиться, что качество кода находится на должном уровне. Качественный код позволяет избежать ошибок и улучшить ремонтопригодность в будущем, но обычно это требует затрат (денег или времени), поэтому это не всегда то, что нужно, особенно если вы не пишете программное обеспечение для кардиостимуляторов или самолетов.

Вы пишете, что работаете в R&D и в этой сфере очень часто пишут прототипы, которые в 90% случаев будут выброшены.

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

Если вы тот, кто всегда говорит «нет» новым функциям, которые нужны бизнесу, вас в первую очередь будут воспринимать как нарушителя спокойствия. Может быть, через 4 года кто-то поймет, что вы всегда были правы в стремлении к качеству, но может случиться так, что к тому времени вас уже уволили.

Обойти это можно с помощью объективных критериев качества кода, которые поддерживаются заинтересованными сторонами.

Отсутствие документации

Весь остальной код задокументирован или его нет только в коде Джо? Каковы последствия отсутствия документации?

форматирование в соответствии с нашими рекомендациями

Это должен быть четкий случай, у вас есть руководящие принципы (я предполагаю, что они санкционированы компанией или отделом), которые применимы ко всем. Однако иногда рекомендации устаревают, и никто им не следует. Если другие пожилые люди следуют им, вы можете смело настаивать на них.

Отсутствие тестов

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

Архитектура несовместима с тем, что мы пытались достичь в будущем. Проблемы с производительностью.

Это я считаю самым сложным, так как очень сложно судить, хороша архитектура кода или плоха. Но у вас может быть два объективных критерия: а) Соблюдены ли нефункциональные требования? (Только если вы заранее определили нефункциональные требования) b.) Вписывается ли код в общую системную архитектуру (Только если у вас есть задокументированная системная архитектура)

Плохо не работает

Это не проблема, никто не должен критиковать вас за нерабочий код. Если только вы не переусердствуете и не потребуете идеального кода, где хорошего кода будет достаточно.

Мне приходилось работать сверхурочно, чтобы исправить проблемы с кодом Джо, потому что, как только он был одобрен и оплачен, он ничего не чувствовал, и никто не возлагал на него ответственность за исправление ошибок.

Это проблема. Вы могли бы привести лучший в мире аргумент о качестве кода, но если его оплата основана на функциях, то именно это он и сделает. В конце концов, зачем ему тратить время на исправление уже принятого кода, если ему за это не платят?

Я вспоминаю время в истории, когда LOC (строки кода) были основным способом продвижения по службе или оплаты. Вы бы целый день писали о простых вещах. Очень сложно добавлять функции или даже следовать за ними.

Джо обычно подходил ко мне с рассказом о том, что ему не заплатят, если его код не будет принят вовремя.

Он даже сказал вам, что не будет это чинить, потому что ему за это не платят.

Первый аргумент заключается в том, чтобы выяснить, как исправить условия этого контракта. В конечном счете, это зависит от вашего бизнеса, но ваши главные аргументы 3:

1. Вы тратите время на «починку» того, что он сломал. Вам платят за исправление его ошибок или вам платят за другие вещи? Я бы получил разъяснения по этому поводу.
2. Оплата по функциям не работает. Вы можете объяснить это в сочетании с № 1.
3. Если № 1 является вашим основным сотрудником, вам нужно подумать о поиске новой работы. Если они не желают исправлять условия, вам нужно идти независимо.

Вы уже ответили на свой вопрос:

Джо получает оплату за каждую завершенную функцию, а не почасовую ставку. У меня сложилось впечатление, что Джо пытается сделать как можно больше функций, часто экономя при этом на документации/качестве кода.

Переключите Джо на почасовой контракт и посмотрите, что произойдет. Если он хоть немного хорош, его качество улучшится — если только он не обманывает систему, затягивая дела, поэтому устанавливайте разумные сроки.

Если его качество не улучшится, замените его.

Я думаю, что вы делаете свою работу с честью, даже если она довольно напряженная. Как инженер по качеству, вы не должны пропускать очень низкокачественную работу.

Как я это вижу сейчас, есть несколько альтернатив, и ни одна из них не идеальна.

1. Убедите начальство взять на себя ответственность в письменном виде (по электронной почте можно). Чем больше боссов, тем лучше.
   • одно электронное письмо на инцидент;
   • одно электронное письмо, чтобы управлять ими всеми; это в значительной степени отменяет качественные действия в проекте;
2. Откажитесь от своей деятельности в качестве инженера по качеству или хотя бы от работы по принятию/отклонению чужой работы. Кажется, у вас уже достаточно работы;
3. Убедить руководство позволить Джо принять/отклонить работу команды. Что бы ни случилось, Джо ответит — в том числе и за свою работу.
4. (в худшем случае) Подумайте о другой компании, которая соответствует вашим ожиданиям, и начните «переход» туда.

Судя по тому, что и начальство, и ваши коллеги имеют плохое представление о необходимости качества работы, вариант 4 кажется вашим лучшим другом.

Да вы неразумны. Пока это не вопрос жизни или смерти, вы должны передать код, потому что руководство заботится только о деньгах, а технический долг — это не то, что они могут понять. Я написал дерьмовый код, потому что мне поставили сроки, которые не дают достаточно времени, чтобы сделать хорошую работу, и как подрядчику мне не платят за сверхурочную работу. Если бы я мог установить крайний срок, тогда все было бы иначе.