"Я пофиксил баг и задеплоил патч в прод" бла бла бла — такой зашквар в мэйнстриме воспринимается сегодня чуть ли не как геройство

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

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

"Нормой" это стало в том смысле, что дескать ошибки это естественно для человеков, ой ой ой надо обязательно выделять 50-70% времени на отладку и тестирование иначе невозможно... Главное — быстро баги фиксить и сразу выкатывать (ну или накопительными патчами :), и тогда это вообще не проблема. Пользователи потерпят.

Надо отметить, что c Windows ещё терпимая ситуация, потому что например в некоторых известных ОС РВ фикс может занимать и полгода :) Что в принципе понятно, потому что они используются в космических станциях, атомных реакторах и боевых роботах, и надо перепроверять всё очень-очень тщательно.

Но всё равно, это ужасный способ обращения с клиентами.

Ошибки — это абсолютно неестественно, если дисциплинированно придерживаться ключевых правил чистоплотности кодирования.

Прямая обязанность инженеров-разработчиков — поставлять _заведомо_ хороший, качественный, надёжный код, а не "продукт", который со временем протухает, и превращается в нечто более или менее приемлемое только к третьей версии после тысячи патчей.

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

Более того, патчи по живому спасли многие серьёзные проекты. Mars Pathfinder во время полёта уже совсем почти сбился с пути из-за бага в расчёте траектории (рассказывал тут немного "3 совета, как программировать спутники, чтобы они не падали" https://vk.com/wall-152484379_1096 ), но удалённо загруженный фикс спас всю миссию. Также и марсоход Mars Exploration затупил, взявшись бурить скалу :) запутался в некорректной схеме управления файловой системой, и тоже успешно был пропатчен вживую.

=

Имею в виду, что в мире только 23% средних и крупных ИТ-компаний применяют промышленные методы производства софта (а среди мелких и всяческих стартапов таковых наверное 0% :), которые имеют под собой научно-практическую основу и по которым проводится скучная официальная сертификация, которая хотя бы минимально гарантирует, что компания придерживается best practices, рекомендованных экспертами программной инженерии. Этим 23% удается удалить из кода 90% ошибок перед деплоем своим пользователям. И есть элита 0.4% , которые вычищают 99% багов.

Но разве это нормально?

PSP TSP CMM ISO PMBoK?

Нет, не слышали. И так сойдёт.

Патчи по живому — это факт в всём ИТ, но это именно патчи, это "приляпки", это отстой. Куда более важны качественные процессы разработки, которые только и приводят повторяемо к созданию правильного и всё более качественного кода.

Но вы их ощущали на себе хоть когда-нибудь?

=

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

Что лично вы можете сделать в своей маленькой зоне ответственности, чтобы хоть немного поднять уровень качества своего кода и кода коллег, хотя бы на миллиметр, в направлении SotA?

Во-первых, это "самый эффективный способ минимизации багов, которым вы скорее всего не пользуетесь"

https://vk.com/wall-152484379_1758

Во-вторых, часто пишу про большую пользу классических обзоров кода, например "7 причин в пользу регулярных обзоров кода"

https://vk.com/wall-152484379_3372

Имеется огромное количество доказательств огромной пользы code review, даже тесты не дотягивают до них по продуктивности, да и здравый смысл показывает, что в поиске проблем две головы лучше, чем одна :)

Особый плюс обзоров кода, что добавление ещё одного инспектора в процесс code review может дать неплохой результат, даже если перед ним этим уже занималось 10 человек. Зависимость как минимум логарифмическая.

=

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

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

Ответственность тут целиком лежит на тилиде или техническом директоре :)

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

Проводился ли вообще code review той части кода, где возник баг? Сколько времени он занял? Были ли выявлены попутно другие проблемы? Вполне возможно, функция или класс были слишком сложными (тогда вопрос к проектировщикам — почему нарушен SRP?), и в ходе инспекции кода было обнаружено множество других проблем.

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

Итак, покажите метрики сложности того кода c ошибкой — перед code review и после него.

Или — о ужас!— разработчики сократили инспекцию, или провели её для галочки, вообще ничего не выявив, а то и вовсе забили на неё? :)

А может быть, ошибка вкралась позже, уже после нормального code review — из-за неэффективной практики управления изменениями, за которые отвечает DevOps?

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

=

Можно ли как-то автоматизировать такой процесс?

Ну вот простейшая рекомендация, которую вы можете (обязаны) внедрить в свой процесс разработки прямо сейчас, и на тимлида свалить ответственность не получится :)

В Стэнфорде 20 лет назад было проведено исследование процесса разработки Linux (на тот момент 1,6 миллиона строк кода) с помощью автоматизированных инструментов статического анализа. Оказалось, что даже просто сам по себе плохо написанный код — верный признак, что программисты тут тупят, слабо понимают, а что вообще они делают, и отсюда высокая корреляция с плохим качеством кода — наличие реальных багов в нём, или в соседних, связанных с ним модулях.

Речь, в частности, об избыточном коде — идемпотентные операции (присвоение переменной самой себя), или присвоение значений, которые впоследствии не используются, избыточные проверки, вообще любой мёртвый код, а также любая копипаста. Даже если он безвреден, файлы с такой избыточностью — первый кандидат на code review, так как программист явно фигачил в не очень адекватном состоянии, и очень вероятно, реально накосячил немало где.

Стэнфордские учёные отметили в итоге такую типичную порочную анти-практику, что разработчики относились к предупреждениям линтеров как к мелким безобидным стилистическим проблемам. Однако теперь однозначно можно утверждать, что =>

многие (все) сообщения линтеров действительно сигнализирует о чем-то таком, что может быть критически важным — даже не в самих местах предупреждений, а во всём данном модуле в целом.

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

1. Всегда по нескольку раз просматривайте написанный код методом пристального взгляда, в идеале даже до запуска компилятора, чтобы отвыкнуть синтаксические ошибки лепить. Отключите смарт-режим в редакторе, если есть такая возможность (когда он подсказывает синтаксические ошибки на лету), а лучше пишите и тестируйте код не в IDE, как в детском саду, а по взрослому: vim + командная строка.

2. Всегда применяйте линтеры, следуя всем без исключения выдаваемым рекомендациям (доказано Стэнфордом).

3. Ликвидируйте абсолютно все варнинги компилятора, выставив их на максимум (доказано Карнеги-Меллоном).

Потому что любое даже самое маленькое предупреждение от системы разработки — признак, что ваш мозг начал сбоить (и возможно, уже давно).

=

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

Великий C.A.R. Hoare по этому поводу давно заявлял, что "настоящая ценность тестов не в том, что они обнаруживают ошибки в коде, а в том, что они обнаруживают недостатки в методах разработки, и выявляют слабую внимательность и плохие навыки тех, кто пишет код".

То же самое можно сказать и про линтеры, и про code review.

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

Источник: vk.com

Комментарии: