К сожалению, баги — это неотъемлемая часть процесса разработки программного обеспечения. Но я обратил внимание, что одни команды допускают значительно меньше багов, чем другие.
Почему так происходит? — задался я вопросом.
Первое, что приходит в голову — это опыт разработчиков внутри команд. И на первый взгляд, интуитивно очевидно, что опытные (senior) разработчики допускают меньше багов, чем начинающие (junior). Но я знаю много случаев, когда команды разработки не могли стабилизировать работу своих программ в течение множества месяцев. И такие команды, состояли только из опытных разработчиков уровня senior и middle.
Другая мысль, которая приходит в голову — это тестирование. Ведь тест — это инструмент проверки, что программа работает так, как от неё ожидается.
Действительно, ручное и/или автоматизированное тестирование разработчиком позволяет устранить баги на самом раннем этапе, и такие фиксы являются самыми дешёвыми в плане трудозатрат и прочих негативных последствий бага. И обычно успешные команды проводят тестирование на всех этапах разработки. Но тестирование в своей природе — процесс поиска уже созданных багов, и оно не препятствует созданию новых. И поэтому я задался другим вопросом:
Возможно ли разрабатывать так, чтобы не создавать багов вовсе?
И прежде чем я отвечу на вопрос, хочу рассказать о том, где же рождаются баги.
Где рождаются баги
Разработка программы в чём‑то напоминает строительство кирпичного дома, где разработчики кирпичик за кирпичиком добавляют новые фичи и выстраивают таким образом программу. И каждый новый кирпичик, читай блок кода, вместе с новыми фичами также добавляет в программу новые баги.
Другими словами, добавление нового кода в программу порождает в ней новые баги, большая часть из которых возникает в добавленном коде. Но существуют и другие места, где могут возникнуть баги при добавлении нового кода:
Как я уже упоминал, новый код — это место, где появление багов наиболее вероятно, поэтому новый код очень часто является основным объектом тестирования. Но это не означает, что баги появляются только там, ведь, как правило, новый код встраивается в существую кодовую базу и начинает взаимодействовать с ней.
Поэтому места стыка старого и нового кода тоже оказываются в зоне риска и там довольно часто могут появляться баги. Вероятность этого ниже, чем в новом коде, но она есть и довольно высокая. И цель регрессионного тестирования заключается в том, чтобы проверить, что старые функции программы после добавления новых изменений работают также как и раньше.
Но иногда программа может быть настолько сложной и запутанной по своему дизайну, что баги могут возникать в тех местах, которые мало связаны с местом добавления нового кода и напрямую с ним не взаимодействуют. Вероятность появления таких багов довольно мала, особенно для молодых программ. Но если такие баги появляются, то, как правило, шаги воспроизведения таких багов нетривиальные и требуют выполнения множества условий, поэтому находить такие баги очень сложно.
И так, подводя итог, выделяю три места в программе, где могут рождаться баги:
Внутри нового кода
На стыке старого кода с новым
Глубоко где‑то в старом коде (последствия вызова из нового кода)
Кодотрясение (codequake)
Я сравнил разработку программы с процессом постройки дома. На мой взгляд, они действительно похожи, но важно понимать, что в сущности это всё же разные процессы.
Например, практически невозможно вставить дополнительный кирпич в середину готовой кладки стены, но в разработке программы аналогичное действие, вставка новой строчки кода между существующими строками в программе, может быть очень легко выполнено. Более того, подобное действие программисты выполняют регулярно, решая стоящие перед ними задачи. И я решил изобразить такую операцию в виде такой круговой диаграммы:
Также эта диаграмма отражает три места, где рождаются баги, и вероятность их появления.
И как только новый код добавляется в существующую кодовую базу, то он порождает сейсмическую активность подобно землетрясению. Более того, кодовую базу начинает сильно трясти, если во время доработки новый код добавляется во множестве мест. И такие «улучшения» способны полностью сломать работу программы.
И это печально, т.к. огромное количество разработчиков вынуждены менять множество файлов, методов и классов для того, чтобы сделать одну единственную доработку. И такая активность порождает баги, множество багов.
И всё выглядит так, что разработчики повинны в добавлении багов... но действительно ли это так?
Причины рождения багов
Безусловно, действия разработчиков создают баги, потому что по должностным обязанностям они вынуждены добавлять новый код. Поэтому отчасти эта их зона ответственности, но не полностью.
Чтобы разобраться с зонами ответственности, я разделил баги на две группы:
Технические баги
Баги в бизнес‑логике
Технические баги
Технические баги — это ошибки подобно Null pointer exception, Out of Memory, проблемы с производительностью и т. п.
Такие баги возникают по причине того, что разработчик не сумел предвидеть их, либо допустил ошибку технического характера. Поэтому ответственность за такие виды ошибок целиком и полностью лежат на плечах разработчиков. И такие баги могут быть проблемой, т.к. они могут блокировать процесс тестирования или даже поставку программы в production окружение.
Выделяю следующие причины возникновения технических багов:
Низкая квалификация разработчика
Сжатые сроки и авральный режим работы, когда разработчик перегружен задачами и он пытается завершить каждую задачу как можно быстрее
Низкая культура разработки на проекте
(разработчики не следуют лучшим практикам принятым в отрасли, не используют передовые инструменты для разработки)Отсутствие тестирования разработчиком
(ручное и/или автоматизирование, например unit, интеграционные тесты)
Баги в бизнес-логике
У любой программы есть цель существования, причина ради которой она была создана. И обычно такая причина называется бизнес‑ценностью.
Поэтому, программа делает какую‑то работу, набор действий, что приносит бизнес‑ценность заказчику. И такие действия являются инструкциями, которые разработчики коддируют в тело программы. Поэтому, разработчикам приходится добавлять/менять код, когда меняется бизнес‑потребности заказчика.
А новый код порождает новые баги.
Но баги в бизнес‑логике возникают ещё до того, как разработчик написал хотя бы одну строчку кода по новой фиче. На первый взгляд, это выглядит контр‑интуитивно и не логично, ведь в конце концов все баги правятся в коде, в том числе и связанные с бизнес логикой. Отчасти это так, баги правятся в коде, если баг в бизнес‑логике был найден уже после написания кода. А код по бизнес‑логике — это всегда результат обсуждений людей. Поэтому если в коммуникации людей в команде проекта произошли сбои, которые породили баг в требованиях, то это неминуемо отразится на коде, т. е. баг перенесётся в кодовую базу.
Выделяю следующие причины возникновения багов бизнес‑логики:
баги в коммуникации людей на проекте
(общение между членами команды проекта, общение команды с заказчиком и т. п.)следствие технического бага
(например, не пришло уведомление из‑за ошибки NPE и не был запущен другой бизнес‑процесс)
Заключение
Так возвращаясь к вопросу: возможно ли разрабатывать так, чтобы не создавать багов вовсе?
На мой взгляд, это философский вопрос подобно тому: можно ли жить и не совершать ошибок в жизни?
Все люди совершают ошибки, и команды разработки тоже, ведь в них работают люди, а все люди совершают ошибки.
К счастью, за годы развития индустрии накопилось огромное количество практик, позволяющие минимизировать вероятность допущения ошибки. И я очень рекомендую следовать этим практикам, а также помнить о причинах, которые ведут к появлению новых багов.