Говнокод как вид саботажа

Еще один из занятных блогов на любимом DTF был посвящен болезни, как виду саботажа. Блог был интересный, срач в каментах – тоже отменный. Впрочем, разговор не про это. Можно тихо ненавидеть/завидовать человеку, который весело отметил воскресенье и по этому поводу задержался на час, а можно заняться более серьезной оптимизацией рабочего процесса. Как показывает практика, в отечественной компании из 5 программистов потери на отладке могут достигать 5 человеко/дней (это именно потери, а не общее время, затраченное на debugging).

Итак – вот сидят 5 программистов, над которыми находится лид с кнутом и пряником. Что-то кодают, отлаживают, программа семимильными (или не очень) шагами продвигается к заветному майлстоуну. О чем здесь надо думать лиду?


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

Основные моменты, которые должен контролировать лид, чтобы не допускать заторов – это следующее:

  1. Разработка и внедрение в компании процессов, которые обеспечивают наиболее эффективную и быструю разработку ПО; возникающие ошибки должны детектироваться на наиболее раннем этапе и легко исправляться. Регламентация стилей и приемов кодирования, которые исключают написание bug friendly кода (расстановка констрейнтов кодирования);
  2. Организация пайплайна “от редактора до игры”, который обеспечивает наиболее быстрый процесс What You See Is What You Play (WYSIWYP), причем любые отклонения в сторону этого пайплайна (художниками, геймдизайнерами, …) должны наиболее быстро и эффективно детектироваться и пресекаться.

Вроде бы подобные процессы можно поставить быстро. На практике оказывается не так. Во первых, на работу приходят новые люди, которые считают большой удачей найти очередную лазейку в констрейнтах, дабы насрать в код максимально возможное количество гавна. Поэтому приходится постоянно носиться по коду, искать, кто еще и как ухитрился порезвиться, и возводить новые констрейнты. Кроме того, движок растет, появляется новый функционал, начинают вылезать в профайлере новые функции, то, что раньше было WYSIWYP, становится WYSIWY will play tomorrow :). Да и сам езыг программирования, как правило, не предполагает жестких ограничений для “вольных программистов”.

===========================================
В молодости, когда проектов в 1С у меня было немного, я мог себе позволить слетать куда-нибудь на “подебажиться”. Был очень геморройный проект, падения были хроническими, шансов получить более-менее стабильный билд (> 2 минут геймплея) не было вообще. В общем, взяв билет в один конец и пообещав приехать со стабильной версией обратно, я отправился ловить жуков. Жук был стандартный – падение в ntdll “Heap modified after free” и все такое. Как с этой ошибкой боролись – это отдельная тема, но результатом было удивительное открытие: проект был напичкан с ног до головы следующими конструкциями: если какой-то компоненте требуется какой-то поинтер, она берет его и пихает в собственный std::list. Ни о каких прочистках этих списков при уничтожении указателя речи и не велось.

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

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

Вопросы в общем-то очевидные, но их надо поставить в голове, продумать, и получить исчерпывающий ответ. Результатов может быть большое количество: ввести smart/weak pointers или специальные списки, использовать заполнение блоков отладочного менеджера памяти для регулярной проверки поинтеров на валидность, ввести тесты на выгрузку/перезагрузку игр начиная с playable prototype, просмотреть все std::list в модулях этого программиста и в коде вообще, внести изменения в coding standards и coding tips; в общем, список можно продолжать…

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

  • belaz

    Про процент времени на отладке.
    Макконнелл как-то приводил данные, что до 50% времени и ресурсов идёт отладка/QA. Но там не геймдев. Соответственно можно оценить, насколько в геймдеве хуже и небрежнее тестируют.

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

    P.S. Думал, что “Мир 1С” – светлее (не только потому, что жёлтый ;-) ). Выходит, что всякое бывает…

  • shodan

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

    Всецело.

    Путь офис-самурая это путь увольнения.

  • shodan

    > Почему бы вам у себя не разработать обязательную техническую сертификацию

    Потому что хреновая ничего не решит – а поумовую не пройдет НИКТО.

  • lenik

    > Макконнелл как-то приводил данные, что до 50% времени и ресурсов идёт отладка/QA

    Как-то нереально мало. 50% — это обычно цифра из оптимистично настроенных планов, суровая реальность обычно куда хуже =)

  • dDIMA

    2 belaz
    > Макконнелл как-то приводил данные, что до 50% времени и ресурсов идёт отладка/QA
    Еще раз повторюсь – я не про дебаггинг вообще, а про дебаггинг, которого можно было бы избежать, потому что “точно такой же дебаггинг уже был в прошлом месяце”.

    > P.S. Думал, что “Мир 1С” – светлее (не только потому, что жёлтый ;-) ). Выходит, что всякое бывает…
    Не очень понял, при чем тут “Мир 1С”? Речь вроде про внешние независимые команды и по проектам, которые заключались много лет назад…

  • green

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

    а нафига? если человек пишет подобные вещи на С++, то его вообще не стоило брать на эту должность – ни “ключевым” ни “другим” специалистом. Опять же, что делать с теми, кто эту сертификацию не прошёл? Увольнять? Может тогда и брать не стоило?

    Правда вот что делать я не скажу. Наверное поэтому я и не лид :-)

    Всякие coding standards и т.п. не канают как вариант потому что из моих наблюдений их не все читают и мало кто выполняет. Как логичное дополнение к coding standards мне видится code review (ну то есть review не только на предмет соответствия этим стандартам, но и просто ревью на предмет поиска таких вот багов). Только, говорят, дорогой он – типа на review уходит чуть ли не столько же времени, сколько на написание, а то и больше (причём времени обычно более квалифицированного специалиста). Ну и, честно говоря, я не видел контор, в которых его реально применяют. Может быть в гигантах типа MS и бывает.

    Хотя кого я учить вздумал, это уже всё даже в книжках написано, а воз и ныне там :-)

  • dDIMA

    2 green
    В MS применяют, да. Семен об этом писал на блогах. И не только в MS.
    Coding Standards пишутся именно для того, чтобы их выполняли. Если не выполняют, то это еще бОльший саботаж, чем если вся команда будет ежемесячно уходить на трое суток в запой.
    Ну а review, осмысленное тестирование и прочие вещи – это как баланс в Старкрафте – надо потратить какое-то время на прокачку, чтобы потом работать сильно эффективнее.

    Ну а кстати про техническую сертификацию разработчиков passed/not passed – такое ИМХО не приживется. Ну то есть можно рассматривать техническую сертификацию _независимых_ разработчиков как один из способов оценки рисков, но не более того.

  • belaz

    > Как-то нереально мало. 50% — это обычно цифра из оптимистично настроенных планов

    50% не от стоимости программирования, а от стоимости всего проекта, вместе с системным анализом, разработкой требований, документированием, внедрением и прочим…

  • belaz

    > Не очень понял, при чем тут “Мир 1С”?
    Не имел в виду внутренние студии, конечно. Просто нормально поставленная работа с издателем предполагает некую отчётность, которая у разных издателей проходит на разном уровне. В этом смысле.

  • belaz

    > а нафига? если человек пишет подобные вещи на С++, то его вообще не стоило брать на эту должность

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

    А вообще – code review – обычная практика, по крайней мере в крупных западных конторах. Кто-то писал, что часто проходит “прозрачно” для обычных разработчиков, а просто техлид коммиты читает когда время есть (естественно – выделяется время под это).

  • belaz

    > Потому что хреновая ничего не решит – а поумовую не пройдет НИКТО.

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

  • look4awhile

    пусть пишут на C#. будет легче.
    по крайней мере всё что провисло, не будеть ронять насмерть. просто течь до падения с out of memory
    а такое в разы легче отлаживать

  • Anton

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

    Я так понимаю, что как раз для этого и есть dDima

  • green

    Всё же трёхдневный запой и несоблюдение стандартов – это разные вещи.

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

    Как я понимаю, code review (и парное программирование отчасти) нужны в частности для того, чтобы не пропускать говнокод, проверять соответствие стандартам и т.п. Ну хотя меру тоже знать надо, иначе про сроки можно забыть совсем.

    Ну и кстати, по поводу “обычная практика” – если опыт парного программирования у меня был (очень понравилось, кстати), то про регулярный code review в местных конторах я вообще не слышал даже :-)

  • dDIMA

    > Человек ведь не машина, он может и накосячить, забыть про гайдлайны, написать говнокод и т.п. А узнает начальник про это только когда начнётся конец света.
    Вот задача начальника и заключается в том, чтобы конец света по возможности наступал автоматически и через 15 минут после любого говнокоммита )))

  • belaz

    > Ну и кстати, по поводу “обычная практика” – если опыт парного программирования у меня был ,
    > то про регулярный code review в местных конторах я вообще не слышал даже

    А при “ненавязчивом” его применении никто может и не знать кроме ответственного за него человека ;-)
    Если нормально пишут обычно, конечно…

  • IronPeter

    Хочу сделать коммит-хуки. На определенные директории – если нет в логе CR by Peter Popov – не зальете.

    Иначе не вижу как бороться с говном. Последние два говнокоммита на удивление одинаковые.

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

    Второй вставил в общую структуру данных для VisualObject ( это такой визуальный объект – геометрия, партиклы, стейт драйвен ) какие-то там проектные portrait settings.

    Пришлось писать письмо на soft, откатывать коммиты вчистую.

  • ilya

    Жжошь, дядя Дима. Так хорошо :))
    А вообще – истинная правда
    > Основная задача лид-программера в компании, как это не странно – стать ненужным.
    Точно подмечено. Надо к этому стремится
    Из соображений – как. Можно применить весьма кардинальный метод – меньше программировать. Меньше кода – меньше багов. Только для этого надо сделать так, чтобы игру можно было сделать с этим “маленьким программированием”. В общем – писать тулсет разнообразный. Для художников и ГД. Чтобы они как можно больше сами могли. Если написанное еще и в следующем проекте использовать удастся – вообще круто. Это кроме других плюсов.
    Я эту замечательную мысль осознал только сделав 5 проектов.

  • dDIMA

    2 ilya
    Спасибо, но позволь чуть-чуть с тобой не согласиться.
    Девелопмент должен сочетать в себе два момента: хороший тулсет, причем главным его достоинством (и это тоже задача лида) должны быть надежность и информативность. Он не должен падать, должен в любой ситуации давать осмысленную диагностику и требовать от программиста максимум – это взгляда на лог, чтобы выяснить проблему.
    Но слишком хороший инструментарий начинает иметь две другие беды:
    1. Он начинает быть слишком универсальным, что незибежно сказывается на производительности.
    2. Он должен соблюдать баланс между объемом арт-работ и тем, что дешевле захардкодить в конкретной игре под конкретные задачи.

  • ilya

    Понятное дело, что код в любом случае писать придется. И без внедрения практик/культуры программирования не обойтись (ну, вернее, обойтись, только результат будет плачевным). Но это, так сказать, экстенсивный путь. А интенсивный – сводить _возможности_ делать ошибки к минимуму. Уменьшать риски, говоря по-модному :). Не зря весь просвещенный мир движется в сторону визуального программирования и т.п. (вспоини хоть Ф.А.Новикова :) ). Но это – в теории. В практике же мы имеем жесткие ограничения по производительности/памяти, поэтому какое уж тут визуальное программирование. Но уменьшать количество рукописного кода все равно надо. Выбирая между настройкой графа анимаций в коде или в редакторе, я выберу редактор. Что дает, кстати, еще один, причем – более важный, плюс – итеративность настроек без привлечения программистов. Т.е. художник/ГД может большое количество раз _сам_ поменять параметры и получить оптимальный результат. Не привлекая программистов, время которых очень дорого и которого просто не хватает на то, чтобы сидеть рядом и изменять код по запросам. Более того, пользуясь тулами, упомянутые художники/ГД гарантировано (ну, почти гарантировано) не сломают код. Не заведут “висячий” указатель, не обратятся по нулл-пойнтеру, не передадут невалидный параметр в функцию.
    Писать очень уж универсальный инструментарий – сложно. Да и врят ли нужно. Если ты делаешь большую игру, со сроком разработки, скажем, больше 3-х лет, то имеет смысл писать тулы именно под эту игру. Вот, к примеру, редактор в Варкрафте – это редактор для Варкрафта, а не супер-редактор-для-Варкрафта-Старкрафта-WoW. А если ты делаешь маленький проект – то тоже имеет смысл писать инструментраий под этот проект, просто потому, что писать что-то сложнее – нет бюджета. А потом, если что, зарефакторим на следующем. :)

  • my.name

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

  • http://www.visual3d.net arilou

    Дядя Дима, отжиг классный. Нельзя не согласиться. Если бы ваши слова да в уши некоторым англоговорящим товарищам, с которыми приходиццо по долгу службы работать :-)