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

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

Ну, Ваша локальная церковь могла бы быть более соответствующим местом для Вашего вопроса затем.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Так, ПОСКОЛЬКУ, я не только соглашаюсь с Вашим положением, у меня есть реальные данные из управляемого эксперимента для поддержки его. Это - однако, довольно небольшая выборка. Более тщательно продуманные тесты требуются, прежде чем мои заключения приемлемы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Относительно разработчиков Вы могли попытаться предложить:

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

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

IMO, 2 самых важных цели разработчика:

1) Заставьте программное обеспечение сделать то, что оно, как предполагается, делает.

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

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

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

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

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

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

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

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

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

@FOR: у Вас есть вторая проблема также, здесь это:

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

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