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

Question

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

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

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

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

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

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

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

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

Answer 1

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

Также иногда легче сосредоточиться на чем-то конкретном. Ваши коллеги вообще говорят в терминах «запаха кода»? Возможно, вы могли бы сосредоточиться на таких особенностях, как «Когда модуль ABC выходит из строя, его отладка занимает целую вечность; гораздо быстрее использовать технику XYZ. Вот, давайте я покажу». Затем вы можете упомянуть свой основной принцип: отладчик - полезный инструмент, но обычно есть и другие, более полезные.

Answer 2

Это кросс-пост, потому что в первый раз он был скорее сторонним ответом на другой вопрос . На этот вопрос это прямой ответ.

Отладка ухудшает код качества код, который мы производим, потому что он позволяет нам уйти с более низким уровнем подготовка и менее умственный дисциплина. Я узнал это от случайно контролируемый эксперимент в начало 2000 года, о котором я сейчас рассказываю:

Я взял контракт как Delphi кодер, и первая назначенная задача была написать шаблонный движок концептуально похож на отчетность Движок - используя Java, язык с который я был незнаком.

Странно, работодатель был довольно счастлив платить мне контрактные ставки потратить месяцы, становясь опытным с новый язык, но не будет платить за книги или отладчики. Мне сказали скачать компилятор и научиться использовать онлайн-ресурсы (Java Trails были довольно хорошо).

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

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

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

Короче говоря, это то, что когда отладка более болезненна, чем проектирование, путь наименьшего сопротивление лучше дизайна.

Что превратило это из наблюдения чтобы наверняка был успех проект. Внезапно появился бюджет и У меня была "правильная" IDE с встроенный отладчик. По ходу из следующих двух недель я заметил возвращение к прежним привычкам, с «эскизный» код, созданный для работы итеративное уточнение в отладчике.

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

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

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

Итак, ЗА, я не только согласен с вашей позицией, у меня есть реальные данные из контролируемого эксперимента, подтверждающие это. Это, однако, довольно маленький образец. Требуются более сложные тесты, прежде чем мои выводы будут подтверждены.

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

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

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

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

---

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

Answer 3

Я думаю, что настоящая проблема здесь

Люди, которые считают, что режим отладки «стандартный» режим имеет тенденцию писать код это можно понять только шагая через это

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

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

Answer 4

Здесь что-то не так, но мне трудно это понять. Возможно, реальная проблема заключается в том, что в коде есть другие запахи, которые затрудняют его понимание. Я согласен, что с TDD следует использовать отладчик меньше, чем больше, поскольку вы будете разрабатывать код небольшими шагами. Но если вы не можете взглянуть на код и понять его, возможно, это связано с тем, что дизайн слишком связан - слишком много взаимосвязанных классов требуется для работы.

Если код действительно должен быть настолько сложным, что наблюдения не будет достаточно, то, возможно, вам нужно инвестировать в некоторые хорошие комментарии, объясняющие, что происходит, - хотя я бы предпочел, чтобы вещи были реорганизованы до такой степени, что комментарии не нужно. Я подозреваю, что отладчик может быть симптомом, а не проблемой.

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

Answer 5

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

Ну, тогда ваша местная Церковь может быть более подходящим местом для вашего вопроса.

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

(Я все еще не согласен с вами, но это не главное, поскольку вы не хотели обсуждать.)

Answer 6

Это будет звучать как аргумент, который вы сказали, что не хотите иметь, но я думаю, что если вы хотите убедить своих товарищей по команде, вам нужно будет привести более веские аргументы. Я не понимаю вашего возражения. Я часто перебираю код, который пытаюсь понять с помощью отладчика. Это отличный способ увидеть, что происходит. Вы не доказали, что люди, которые используют отладчик таким образом, как правило, пишут код, который в противном случае трудно понять. Единственный убедительный способ сделать это - провести какое-то исследование типа «случай / контроль», в котором пытались измерить и сравнить читабельность кода, написанного людьми с различными подходами к отладчику. И вы даже не рассказали правдоподобную историю, объясняющую, почему вы думаете, что использование инструмента для понимания выполнения кода имеет тенденцию приводить к неаккуратному построению кода. Для меня это полный не секвестр .

Answer 7

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

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

Как только вы решили, что хотите продолжить свою инициативу по изменениям, вы должны принять во внимание, что разные люди убеждены в разных вещах. Некоторые люди уже будут убеждены, попробовав что-то новое и захватывающее. Некоторых убедят цифры (метрики). Некоторым рассказывают об этом, когда они едят свой любимый тип печенья (серьезно!), А другим - слышат об этом от своего любимого гуру. Некоторые читают об этом в журнале. Некоторые видят, что «все остальные тоже делают это». И т. П.

В InfoQ есть проницательное интервью с Линдой Райзинг на эту тему: http://www.infoq.com/interviews/Linda-Rising-Fearless-Change. Она может сказать это намного лучше меня. Книга тоже неплохая.

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

Answer 8

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

ИМО, 2 наиболее важные цели разработчика:

1) Заставьте программу делать то, что она должна делать.

2) Напишите код, чтобы разработчик по техническому обслуживанию через 2 года получил опыт изменения существующих или добавления новых функций.

Answer 9

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

Это сказанное, давайте перейдем к моей точке. Хотите, чтобы команда не отлаживала ... комментируйте, комментируйте комментируйте. Ничто не сравнится с желанием отладить быстрее. Конечно, они все еще будут делать это, но они будут более склонны перешагнуть хорошо документированный код.

О, и хотя это должно быть само собой разумеющимся, я все равно сделаю это. нет ошибок в вашем коде. :)

Answer 10

Я думаю, что лучше сформулировать этот вопрос так: «Не является ли TDD запахом кода?» Кажется, что TDD приводит к меньшему времени, затрачиваемому в отладчике, из-за большего времени, затрачиваемого на написание / провал / прохождение тестов. Без TDD вы с большей вероятностью проведете время в отладчике для диагностики ошибок.

По крайней мере, в Visual Studio использование отладчика не так уж и болезненно, поэтому вам будет сложно объяснить своим товарищам по команде, как TDD сделает их разработку более приятной, продуктивной и успешной. Просто отказ от отладчика, вероятно, не является достаточной причиной для того, чтобы команда сменила методологию разработки.