Отладка - дурной запах - как их уговорить?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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