#Инсектарий_программиста.
⚡️О багах
Давайте поговорим о багах.
Баги - это ошибки в программном коде, и основной предмет заботы программиста: как избежать багов - как обнаружить баги - как пофиксить баги, избежав новых багов и далее по кругу.
("пофиксить" - это значит "исправить", вдруг кто не знает)
"Баги есть у всех", - так говорил мой начальник, когда я только начал работать программистом, - рассказывает наш системный архитектор.
Писать без багов невозможно, так что не нужно строить иллюзий и убиваться из-за того, что даже после многих лет разработки в вашем коде продолжают встречаться баги. Причем, порой, самые глупейшие.
Да, баги есть у всех, поэтому важно не само наличие багов в вашем коде, а вполне конкретные метрики:
▫️Количество багов, о которых узнаёте только вы.
Про них вам говорит компилятор, юнит тесты, дизайн тесты и прочее. Вы находите их самостоятельно, и никто про них не узнаёт кроме вас. И вашего психоаналитика😅
▫️Количество багов, о которых узнаёт ваша команда.
Это баги, которые были обнаружены коллегами в ревью или на девелоперских сборках, или в CI тестировании. Понимающий взгляд, дружеское похлопывание по плечу, мол, у всех бывает, давай, поправь по-быстрому, и внимательнее потом.
▫️Количество багов, о которых узнают в других командах.
Тестеры, интеграторы, команды смежных проектов. К вам прилетает запрос на исправление, возможно, организуется собрание, возможно, немного съезжают сроки, но всё остается внутри компании. Сор в избе, все ок.
▫️Худший вариант - баги, которые вышли наружу и о них узнал заказчик.
Он, конечно, тоже знает, что баги есть у всех, однако, давать ему лишний повод в этом убедиться не очень хорошо.
▫️Кроме количества багов крайне важна стоимость устранения бага.
Она выражается как в прямых трудозатратах разработчика, так и в косвенных потерях: простой других команд, неисполнение договора, репутационные потери и т.п. Очевидно, что стоимость устранения минимальна для ваших собственных багов и максимальная для тех, что обнаружены у заказчика.
Ваша задача, как разработчика - минимизировать эти метрики, уменьшая как количество багов на каждом уровне, так и стоимость их устранения.
Даже баг у заказчика не так страшен, если вы смогли устранить его за пару часов. И, с другой стороны, ваши внутренние баги становятся реальной проблемой, если вы целыми днями боретесь с ошибками компиляции и фейлами юнит тестов.
💡Проиллюстрируем все вышесказанное простой бытовой ситуацией: в тарелке с супом обнаружена муха.
Неприятно, конечно, но бывает, и вот, случилось. И тут самое важное - кто эту муху нашел:
▫️Повар (программист).
Считайте, что мухи не было. Потому что никто не узнает.
▫️Официант (тестер или инженер по внедрению).
Повар получает втык по-тихому. Муху по-тихому убирают. Клиент ничего не знает.
▫️Посетитель (клиент, заказчик).
Скандал, позор, вызов администратора. Втык всем. Компенсация посетителю. Отрицательный отзыв заведению и т.п.
Трудоёмкость фикса во всех случаях одинакова - достать муху из супа. Однако, сопутствующие потери различаются кардинально.
Мораль:
Повар, избавься от мух на кухне!
Официант, хорошо проверяй каждую тарелку!
Посетитель, смирись - баги есть у всех, и тебе просто повезло, если ты их не видел😏
#mfisoft
⚡️О багах
Давайте поговорим о багах.
Баги - это ошибки в программном коде, и основной предмет заботы программиста: как избежать багов - как обнаружить баги - как пофиксить баги, избежав новых багов и далее по кругу.
("пофиксить" - это значит "исправить", вдруг кто не знает)
"Баги есть у всех", - так говорил мой начальник, когда я только начал работать программистом, - рассказывает наш системный архитектор.
Писать без багов невозможно, так что не нужно строить иллюзий и убиваться из-за того, что даже после многих лет разработки в вашем коде продолжают встречаться баги. Причем, порой, самые глупейшие.
Да, баги есть у всех, поэтому важно не само наличие багов в вашем коде, а вполне конкретные метрики:
▫️Количество багов, о которых узнаёте только вы.
Про них вам говорит компилятор, юнит тесты, дизайн тесты и прочее. Вы находите их самостоятельно, и никто про них не узнаёт кроме вас. И вашего психоаналитика😅
▫️Количество багов, о которых узнаёт ваша команда.
Это баги, которые были обнаружены коллегами в ревью или на девелоперских сборках, или в CI тестировании. Понимающий взгляд, дружеское похлопывание по плечу, мол, у всех бывает, давай, поправь по-быстрому, и внимательнее потом.
▫️Количество багов, о которых узнают в других командах.
Тестеры, интеграторы, команды смежных проектов. К вам прилетает запрос на исправление, возможно, организуется собрание, возможно, немного съезжают сроки, но всё остается внутри компании. Сор в избе, все ок.
▫️Худший вариант - баги, которые вышли наружу и о них узнал заказчик.
Он, конечно, тоже знает, что баги есть у всех, однако, давать ему лишний повод в этом убедиться не очень хорошо.
▫️Кроме количества багов крайне важна стоимость устранения бага.
Она выражается как в прямых трудозатратах разработчика, так и в косвенных потерях: простой других команд, неисполнение договора, репутационные потери и т.п. Очевидно, что стоимость устранения минимальна для ваших собственных багов и максимальная для тех, что обнаружены у заказчика.
Ваша задача, как разработчика - минимизировать эти метрики, уменьшая как количество багов на каждом уровне, так и стоимость их устранения.
Даже баг у заказчика не так страшен, если вы смогли устранить его за пару часов. И, с другой стороны, ваши внутренние баги становятся реальной проблемой, если вы целыми днями боретесь с ошибками компиляции и фейлами юнит тестов.
💡Проиллюстрируем все вышесказанное простой бытовой ситуацией: в тарелке с супом обнаружена муха.
Неприятно, конечно, но бывает, и вот, случилось. И тут самое важное - кто эту муху нашел:
▫️Повар (программист).
Считайте, что мухи не было. Потому что никто не узнает.
▫️Официант (тестер или инженер по внедрению).
Повар получает втык по-тихому. Муху по-тихому убирают. Клиент ничего не знает.
▫️Посетитель (клиент, заказчик).
Скандал, позор, вызов администратора. Втык всем. Компенсация посетителю. Отрицательный отзыв заведению и т.п.
Трудоёмкость фикса во всех случаях одинакова - достать муху из супа. Однако, сопутствующие потери различаются кардинально.
Мораль:
Повар, избавься от мух на кухне!
Официант, хорошо проверяй каждую тарелку!
Посетитель, смирись - баги есть у всех, и тебе просто повезло, если ты их не видел😏
#mfisoft