Привычка кодить

Прогноз проблем по привычкам программиста

(рубрика - Нюх на баги)

Исходя из многолетнего опыта работы программистом, аналитиком-внедренцем, в тестировании и техподдержке могу заверить вас, что у каждого разработчика есть свой почерк написания кода. И не важно насколько строгие правила кодирования приняты в компании: кто-то играет с порядком параметров, кто-то с наименованиями объектов, кто-то с самописными или стандартными подпрограммами. Одно и тоже действие можно написать, используя стандартные функции (тогда тестировщикам заранее известны слабые места кода), а могут сочинить универсальный или сложно-запутанный код, от которого тестировщикам можно будет ждать всяких непредвиденных ситуаций.
Поэтому, чтоб тестирование не получалось всегда неожиданностью, ниже сопоставлены некоторые человеческие особенности с написанным программистом кодом. А именно, с самым распространённым действием – чаепитие или кофе-брейк. В зависимости от того, как программист готовится или завершает чайно-кофейную церемонию, родились связки с его фирменными ошибками. Когда же сфера IT перешла в удалённый режим, и команды стали распределёнными, естественно пропала возможность наблюдать за общением программиста со "своей кружкой". Но, оказалось, что по скриншоту рабочего стола тоже можно определить тип программиста.
В начале карьеры мои обязанности ограничивались программированием и техподдержкой. В те времена о тестировании вообще никто не говорил и не слышал, потому что сами программисты выполняли аналитику, кодирование, отладку, внедрение и поддержку. Но в силу того, что отпуска в своём большинстве давались полностью (вплоть до 40 рабочих дней), то кому-то приходилось замещать сотрудника в ответственные дни отчётов. В до-САПР-овские времена, когда не было "Галактика" или "Axapta", автоматизация предприятий проводилась собственными силами, а это значит весь код был самописным, без особых корпоративных стандартов. В то время легко было определить почерк кодера: кто-то давал переменным и объектам особенные имена (короткие, нелогичные, без привязки к функционалу), кто-то использовал особые конструкции или ранее-написанные собственные блоки. И если вдруг в отсутствии замещаемого сотрудника падал код, то заместителю поначалу приходилось тратить не мало времени на понимание такого легаси. Вспомните себя студентом, переписывающим пропущенные конспекты лекций от разных однокашников: не с первой страницы начинаешь бегло читать чужой почерк. Также и с легаси-кодом – не с первого блока кода понимаешь логику прописанных команд.
После перехода из универсальных программистов в разряд всемогущих тестировщиков в моём арсенале разнообразия почерков программистов стало больше. При чём сюда добавились и аналитики, и конечные пользователи, присылающие своё видение на проблемы продукта. Высоким словом "разработчик" в некоторых компаниях называют программиста, совмещающего роль с аналитикой. Поэтому, как продумаешь логику, так она и отработает в коде. В моём докладе о лёгкости тестирования кода с помощью утилит аудиторов кода уже говорилось об основных причинах самых заковыристых багов. Они-то и кроются в особенностях почерка кодировщика. А коль скоро характер программиста не перевоспитаешь, то и его фирменные баги вы сможете вылавливать в первую очередь. На счёт скорости обнадёживать вас не буду, но направления для поиска вам будут очевидны.
Итак, типы почерков программистов делю на 6 групп.
Чистюля (аккуратист, педант)
На его рабочем столе никогда не бывает ничего лишнего, весь минимальный набор (клавиатура, мышь, за редкостью чистый лист и карандаш) расставлен "под линеечку", ни пылинки-соринки, ничего мешающего рабочему процессу. Если говорить об иконках на рабочем столе операционной системы компа, то там могут быть лишь стандартные приложения, либо всё необходимое разнесено по папкам. Свою кружку моет сразу после чаепития и убирает на строго отведённое место в закрытом шкафу.
Исходя из описанного поведения, программист-чистюля привык писать код так, чтобы объём и логика кода строго соответствовали описанному заданию, все переменные после использования были очищены. Вроде бы всё должно быть прекрасно, но программист-педант опасен тем, что программа часто недостаточно обрабатывает исключения, не прописанные в ТЗ, либо умышленно опущенные из-за их стандартности, он же привык, что всё разложено по полочкам и ничего лишнего не мешает его взгляду. Перед использованием переменных программист-аккуратист забывает проверить их на корректность объявления и присвоения значений, он же привык, что его кружка всегда чистая. Поэтому код от программиста-чистюли надо проверять исследовательским методом на неописанные в ТЗ ситуации, нагрузочные и интеграционные тесты делать на передаваемые и входящие переменные. В качестве профилактики можно применять правило Code Review, результатом проверки которого является список параметров процедуры, использованных не по назначению.  
Хозяйчик запасливый
Его рабочий стол напоминает склад тысячи мелочей, ящики тумбочки еле закрываются от всего "очень нужного", вполне вероятно он оккупировал и рядом стоящий шкаф под свои полезняшки. Иконок на рабочем столе компьютера видимо-невидимо, разбросаны по всей площади и на первый взгляд в хаотичном порядке. Скорее всего кружку для кофе или чая он держит на своём же рабочем столе, чтоб она всегда была "под контролем", моет её тщательно перед чаепитием. В силу привычек, программист-хозяйчик пишет код "с запасом", программирует неописанное в ТЗ, но на его взгляд возможное при исполнении программы. Код запасливого программиста надо проверять на избыточность объявленных переменных, на достаточность алгоритмов без половинчатого кодирования единичных исключений. Код хозяйственного программиста может быть похож на "лапшу", поэтому в качестве профилактики надо применять оптимизацию блок-схем и сокращать запланированное ему время на написание кода.
Всезнайка
Ученость всезнайки видно по обилию литературы на столе, рабочий стол компьютера – это научный отдел всемирной библиотеки или линки на всевозможные новостные каналы. У него отдельные кружки и стаканы, бокалы для чая, кофе и прочих жидкостей. Их много, и все они разные. Исходя из жизненных пристрастий, код всезнайки заумен, изобилует сторонними библиотеками, возможна перестраховка в виде шифрования. Проверку стоит начинать с поиска "мёртвого" кода. Множество унифицированных вспомогательных функций можно единожды привести в соответствие, но их использование заумным программистом усугубляет интеграционные баги. Обязательной профилактикой для всезнайки служит публичный процесс Code Review, нагрузка по передаче знаний и умений сотрудникам всех отраслей, что позволяет ему понять причины собственных ошибок. Не ограничивайте свои тесты программы от Всезнайки только теорией от гуру, поскольку его сочинение может оказаться слишком навороченным. Пример о граничных значениях: обе функции определяют принадлежность значения к определённому числовому промежутку, но описанный способ матрицы можно применить только к функции "if_cycl" при тестировании "чёрным ящиком".

Рубаха-парень (общительный)
Любитель поболтать вместо кодирования опознаётся по количеству средств связи на рабочем столе. Это могут быть как различные виды телефонов, смартфонов, раций, так и иконки чатов, конференций, аудио-видео коммуникационных каналов. "Свой парень" предпочитает чайно-кофейные кружки из общей кухни, за которыми не надо следить и мыть. У общительного программиста вместо кода на первом месте коммуникации, поэтому программа может быть просто недописана, либо блоки после копи-паста недоправлены. В первую очередь продукт от ультра-разговорчивого программиста надо проверять на точное соответствие ТЗ в области полноты и законченности, каждый из новых пунктов проверять на корректность, не допуская частичной выборки классов эквивалентности. В качестве профилактики по недопущению им багов предлагается не отвлекать его от работы, а общение на нерабочие темы выносить только в перерывы.
Фантазёр жизнелюбивый, живчик
Радость жизни в код не впишешь, и по хаосу на рабочем столе его легко выявить. Среди иконок не мало игр. Кроме компьютера на столе бытовое множество вещей, будто дом или объект его увлечения переехал на работу. Разнообразные чайно-кофейные кружки, в том числе и чужие, можно найти не только на столе, но и в тумбочке, или на чужом столе. Он не замечает даже, когда меняет бокалы, стаканы на общественные или соседские. Это признаки (законы) общежития, и они отражаются в его коде в виде опечаток, обилия неоптимизированного кода, неочищенных переменных и параметров без присвоенных значений. Из-за лёгкого отношения программиста к жизни тестировщику нужно тщательно проводить регрессионные и нагрузочные тесты. Профилактикой может быть работа в паре с Чистюлей или Всезнайкой до момента, когда за него будут выполнять более 30-40% задач.
Пофигист (разгильдяй, тупокодер)
Бардак и грязь на столе, немытые кружки, минимум иконок – признаки тупокодера. Его код не низок, не высок, не узок, не широк, то есть на первый взгляд в точности соответствует ТЗ. Но опасайтесь недописанных блоков, недопроверенных опечаток, неучтённых исключений, незакрытых уязвимостей. Все виды и методы тестирования актуальны для кода от пофигиста. Растормошить его можно доверить любому увлечённому общим делом сотруднику.

Рекомендации по определению типов: смотрите когда и как тщательно программист моет кружку (до или после чае-кофе-пития), сколько их у него и в каком они состоянии, что ещё имеется на рабочем столе, изучите расположение иконок в его операционной системе. Проанализируйте баги и их причины, составьте таблицу в разрезе программистов. Обычное наблюдение даст вам понятие о почерке программиста: сопоставьте типы кодеров и их фирменные баги. Впоследствии можете начинать тестирование с фирменных багов, это ускорит Вашу работу и повысит качество продукта, потому что будете находить проблемы, казалось-бы не очевидные, но вполне вероятные на стороне конечного пользователя.
И ещё несколько подсказок.
Типы могут пересекаться в одном программисте, поэтому подглядывать за поведением кодера стоит регулярно, особенно перед передачей задачи на тестирование.
Не буду скрывать, к некоторым перечисленным типам относится и мой стиль кодирования.
Наиболее действенна профилактика багов, когда в неё вовлечены все сотрудники. Для этого можно на стендапах или ретроспективах выделять время для напоминалок, а сами правила формулировать в стишках, песенках, поговорках или анекдотах. Например, для забывающих очищать переменные упомяните лозунг "Уходя гасите свет" с расшифровкой о нагоревших киловаттах для пустоты. Также действенны публичные Code Review с привлечением тестировщиков в качестве слушателей. Такие собрания полноценно заменяют митинги о передаче знаний.
Надеюсь, у каждого из вас уже есть свой список типов программистов и их фирменных багов. Это хорошее подспорье для увеличения скорости проверки продуктов.