Отладка - плохой запах - как их убедить?

Ответ 1

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

Также иногда легче сосредоточиться на чем-то конкретном. Разве ваши коллеги даже говорят с точки зрения "запаха кода"? Возможно, вы могли бы сфокусироваться на таких особенностях, как "Когда модуль ABC выходит из строя, для его отладки требуется навсегда, гораздо быстрее использовать технику XYZ. Здесь позвольте мне продемонстрировать". Затем после этого вы можете упомянуть ваш основной принцип, который является отладчиком, который является полезным инструментом, но обычно есть другие более полезные.

Ответ 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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

Люди, которые считают, что режим отладки "стандартный" режим имеет тенденцию писать код что можно понять только преодолевая его

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

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

Ответ 5

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

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

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

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

Ответ 6

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

Ответ 7

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

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

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

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

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

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

Ответ 8

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

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

Ответ 9

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

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

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

Ответ 10

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

IMO, две наиболее важные цели разработчика:

1) Сделайте программное обеспечение так, как оно должно было делать.

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

Ответ 11

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

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

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

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

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

Ответ 12

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

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

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

Ответ 13

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

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

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