Отладка - это неприятный запах - как их убедить?

Question

Я работал над проектом, который больше нельзя назвать «маленьким» (40+ месяцев), с командой, которую больше нельзя назвать «маленькой» (~ 30 человек). Мы все время использовали методики Agile / Scrum (1) и здоровую дозу TDD.

Я не уверен, что взял это из Agile или TDD, скорее всего, из комбинации двух, но теперь я явно в лагере людей, которые считают отладку плохим запахом. Под «отладкой» я имею в виду не более абстрактную концепцию выяснения того, что может быть не так с системой, но конкретную деятельность по запуску системы в режиме отладки, пошаговое выполнение кода для выяснения деталей, которые иначе непостижимы.

Поскольку я вполне убежден, этот вопрос не о том, является ли отладка плохим запахом или нет. Скорее я хотел бы знать, как я могу убедить своих товарищей по команде об этом.

Люди, которые считают, что режим отладки является «стандартным» режимом, обычно пишут код, который можно понять только путем отладки, что приводит к потере времени, т. К. Каждый раз, когда вы работаете над элементом кода, разработанным кем-то, в противном случае вы сначала тратите немало времени на его отладку (и, поскольку здесь нет ошибок .. термин становится все более и более нелепым) - и тогда возникают бункеры. Поэтому я хотел бы убедить некоторых из моих товарищей по команде, что избегать режима отладки - это хорошо (2). Так как они привыкли жить в режиме отладки, они, похоже, не видят проблемы; для них нормой является тратить часы на отладку чужого кода, прежде чем он начнет делать что-либо, связанное с их новым элементом; они не видят в этом ничего плохого. Кроме того, поскольку они тратят время на «выяснение этого», они знают, что в конечном итоге разработчик, работавший в этой области, станет доступным, и элемент будет передан им (что приведет к еще одному бункеру).

Помогите мне придумать план, как отвратить их от Темной стороны!

Заранее спасибо.

(1) Также называется SCRUM (все заглавные буквы). Если не принимать во внимание аргументы в пользу капитализации, я думаю, что следует использовать звездочку после этого термина, поскольку, что неудивительно, наша организация «подправила» процесс Agile и Scrum, чтобы удовлетворить предполагаемые потребности всех заинтересованных сторон. Так что, честно говоря, я не буду притворяться, что это на 100% согласно теории, но это не относится к моему вопросу.

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

Answer 1

«План», чтобы убедить их в преимуществе другого подхода, заключается в установлении метрик , привязанных к количеству времени отладки та же функция для различных ошибок.

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

Таким образом, вы не полностью избавляетесь от привычки «отладки», но убеждаете их в создании надежного набора тестов, позволяющего им сосредоточиться на действительно полезном сеансе отладки, если это необходимо.

Если вы рассмотрите этот порядок действий (метрики), вы должны знать, что его реализация включает в себя всю иерархию (заинтересованная сторона, менеджер проекта, архитектор, разработчики). Все они должны быть вовлечены в эти показатели, чтобы воздействовать на них.

Что касается разработчиков, вы можете попытаться предложить:

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

Answer 2

Хорошей практикой является проектирование программного обеспечения путем отладки .

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

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

Answer 3

@ FOR: У вас тоже есть вторая проблема, вот она:

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

Как вы намереваетесь заставить их хотеть быть более продуктивными, когда им нечего (видимого) получить?