Стать лучшим исправителем ошибок

24

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

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

Однако, когда наступает время QA, и я работаю над исправлением ошибок, мое вдохновение принимает огромный спад. Я должен заставить себя довольно экстремальными способами (вы знаете, музыка с высоким BPM, чрезмерное количество кофеина и т. Д.), Чтобы что-то сделать. Моя работа обычно заключается в том, чтобы войти в существующий масштабный проект и добавить новые функции или исправить ошибки, поэтому я не могу точно сказать своему работодателю, что мне нужно пару недель, чтобы написать модульные тесты для всего их кода :) Кроме того, Серверная технология, которую мы часто используем, очень запретна как для модульного, так и для интеграционного тестирования, поскольку у нее довольно много проблем с загрузчиком классов Java. Я не совсем против исправления ошибок, иногда это может быть весело, но это совсем не весело когда вам нужно внести незначительные изменения и подождать от 30 секунд до 3 минут, чтобы увидеть, работают ли они или нет (из-за того, как работает система).

Как я могу улучшить свою производительность и мотивацию при исправлении ошибок? Это то, с чем имеет дело большинство программистов?

Нафтули Кей
источник
4
«поэтому я не могу точно сказать своему работодателю, что мне нужно пару недель, чтобы написать модульные тесты для всего их кода» . Есть ли причина для этого? Я много этим занимаюсь, и это действительно окупается для всех. Я имею в виду, что если вы потратите 3 недели на юнит-тестирование, вы можете просто сэкономить 3 недели исправления ошибок. Обычно я даже нахожу множество возможных ошибок, которые полностью попадают под радар QA. Конечно, вы, вероятно, не хотите делать это самостоятельно.
Сетевой кодер
10
Не пишите ошибки в своем коде ... проблема решена.
Майкл Браун
3
Я почти предпочитаю исправление ошибок написанию нового кода. Я особенно предпочитаю это написанию юнит-тестов. Может я странный
Пол Томблин
1
@PaulTomblin Я понимаю, что вы говорите. Я знаю некоторых разработчиков, которые любят разработку внешнего интерфейса ... мне больше всего нравится не-пользовательский код. Написание нового кода порой затруднено, потому что иногда вы получаете «блок писателя»
Майкл Браун
1
Трудно измерить «производительность» исправления ошибок, потому что вы могли бы потратить много времени, чтобы выяснить, в чем «не проблема», точно так же, как Edision якобы сказал, что нашел «1000 способов НЕ сделать лампочку» ", и я думаю, что исправления часто помогают научить вас, какие подсказки важны и текущую (и будущую) задачу по исправлению ошибок.
Зик Ханселл

Ответы:

21

совсем не весело, когда нужно вносить небольшие изменения и ждать от 30 секунд до 3 минут, чтобы увидеть, сработали они или нет

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

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

Ожидание обратной связи скучно и демотивирует, а не само исправление ошибок.

Гарретт Холл
источник
Вы когда-нибудь читали Мифический человеко-месяц? Просто представьте, что вы ждете до следующего утра и пытаетесь проанализировать содержимое дампа / регистра стека, которое присутствовало во время сбоя ...
sq33G
@ sq33G Или, что еще хуже, ваша команда тестировщиков в Индии, с которой вы общаетесь только по электронной почте (реальная история).
Гарретт Хол
13

Исправление ошибок - чрезвычайно важный навык, который вы должны освоить. Я где-то читал, что обычно 80% времени тратится на исправление 20% проблем в приложении.

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

ManuPK
источник
1
То, что ты пишешь, правда; однако, ваши 80% / 20% верны только потому, что в дикой природе так много дерьмового кода. Под дерьмовым я подразумеваю недостаточно разработанные или чрезмерно спроектированные или неправильно спроектированные или просто неаккуратные практики (программирование с ненормальной головой). При этом нет ничего плохого в том, что разработчик предпочитает разработку исправлению ошибок. Добавьте к этому тот факт, что большая часть программного обеспечения изначально плохо спроектирована, и вы уже настраиваете большинство исправителей ошибок на неудачу.
Уил Мур III
@wilmoore: Вы правы с дерьмовым кодом, и есть также изменяющееся требование.
ManuPK
6

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

Может быть, это поможет сделать игру, например, вместе с вашими коллегами ( кто исправляет больше ошибок в день? Или, что еще хуже, кто меньше всего перестраивает в день? )

Александр Гесслер
источник
Я категорически не согласен с тем, чтобы сделать это игрой, исправляющей большинство ошибок за день, или тому подобное. Некоторые ошибки легко изолировать и исправить, если вы знаете, как их вызывать: вставьте это конкретное значение в это поле и посмотрите: оставшаяся длина теперь неверна. (Возможно, вы подсчитываете байты вместо символов и забыли про пространство выше, скажем, U + 007F.) Другим (в частности, ошибкам, связанным с различными условиями гонки или многопоточностью), легко может потребоваться несколько дней работы для воспроизведения, но они будут критичны, когда они это делают. происходят в поле. Они оба гарантируют только одну запись в трекере ошибок.
CVn
В равной степени считать такие ошибки означало бы, что все будут просто исправлять простые ошибки, а не решать, например, условия гонки ... но разве это не относится и к немотивированным, несосредоточенным исправлениям ошибок? :-) Отказ от «трудных» ошибок в пользу простых вещей - это совершенно другая тема.
Александр Гесслер
Существует также вопрос качества исправления. Во многих случаях вы можете быстро исправить ошибку, не найдя причину, но затем аналогичная ошибка возникает либо в другом месте, либо в другой ситуации. Понимание и исправление природы ошибки часто занимает больше времени, но обычно приводит к гораздо более надежному исправлению. Если только это «это не сработает все время на производстве, и нам нужно опубликовать исправление сейчас », я знаю, какой подход я бы предпочел (и даже если это так, возвращение, чтобы исправить сломанную кость, а не просто нарезать полоску, было бы хорошая идея).
CVn
5

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

Отладка может быть очень утомительной, особенно со сложным кодом, который вы не написали. Придумайте цель «Исправить ошибку 13533 к пятнице». Затем назначьте награду, если вы достигнете цели: «Возьмите пинту с моими друзьями в пятницу вечером». Это поможет сделать его немного более полезным.

Кроме этого, иногда работа - это просто ... работа.

Майкл Райс
источник
Для этого текущего проекта у меня фактически написаны модульные тесты. Единственная проблема состоит в том, что независимо от того, что я могу доказать, используя мои модульные тесты, все идет к черту в производстве / реальной жизни из-за проблем с серверной технологией. К сожалению, другой альтернативы нет, и я не в том месте, чтобы сменить двигатель, так сказать.
Нафтули Кей
Вам нужно написать подпрограмму «обработчик неожиданных ошибок», чтобы помочь вам поймать их ;-)
Zeke Hansell
2

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

Но еще не все потеряно. Работайте над решением своих мета-проблем и вкладывайте в это свою энергию. Почему обратная связь занимает от 30 секунд до 3 минут? Как вы можете сократить это время? (Может быть, вы можете написать какой-нибудь скрипт или служебное приложение, которое вы не отметите, чтобы помочь вам в этом). Это ваша новая проблемная область - ваш новый творческий вызов.

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

Короче говоря, я бы сказал «всегда развиваться». :)

Эрик Дитрих
источник
Я слышу тебя. Я хотел бы сделать что-то для автоматизации вещей. У меня есть сервер и клиент, и я не могу точно автоматизировать клиент легко. Эта операция состоит из нескольких этапов, и между этапами возникает множество ошибок, поэтому мне нужно выполнить 30-секундный этап, затем 3-минутный этап или наоборот. Итог, это довольно кошмарно> :)
Naftuli Kay
2

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

  1. Напишите несколько модульных тестов только для того кода, который ломается. Убедитесь, что у вас есть тесты, проверяющие все желаемые функции, а также тесты, которые особенно изолируют ошибочное поведение.
  2. Напишите новый код, который пройдет все тесты, которые вы только что написали.
  3. Замените старый код новым.
  4. Запустите несколько интеграционных тестов. Именно здесь вы столкнетесь с вашими трехминутными перезагрузками сервера, но это должно быть сведено к минимуму, если вы хорошо выполнили шаги 1-3.
  5. Вуаля!
Мэтью Флинн
источник
2

Возможно, вам стоит взглянуть на статью Debianging Myself Брайана Хейса , опубликованную в American Scientist в 1995 году. Вы можете предпринять шаги (например, обычное использование условий Йоды ), чтобы уменьшить или устранить самые ненавистные виды ошибок, которые вы производите.

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

Брюс Эдигер
источник
1

Если разработка программного обеспечения скучна, вы делаете это неправильно. Другими словами, это не проблема с вами, а проблема с вашей платформой и процессом. Рассматривали ли вы поиск позиции с использованием динамического языка (например, Python, Ruby, JavaScript), где вам не нужно ждать перезагрузки сервера?

Кевин Клайн
источник
К сожалению, на данном этапе это не вариант. Кроме того, рабочий процесс, как упоминалось выше, требует нескольких этапов и этапов, и между этими этапами возникают ошибки. Если бы я писал это с нуля, я бы наверняка изучил язык сценариев, но мы застряли на том, что имеем сейчас.
Нафтули Кей
1
@TK: В моей последней компании мы с большим успехом интегрировали Groovy в процесс разработки Java для автоматизации ранее ручных процессов. Это не Java, но он был достаточно близок и настолько эффективен, что у нас было очень мало отталкивания.
Кевин Клайн
1

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

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

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

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

Алан Делимон
источник
1

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

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

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

Во-первых, чем дольше время вашего теста, тем более вы должны быть против культа груза. Если вы вносите изменения, думайте об этом, пока не будете уверены, что это исправит ошибку . Конечно, насколько уверенно зависит от длины вашего цикла испытаний. Но если ваши тестовые циклы становятся длиннее, а длительных тестов нельзя избежать, потратьте больше времени на размышления, и вы будете вознаграждены и более счастливы в отладке, потому что это быстрее и дает полезный эффект хорошего момента "Fiat Lux" ».

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

thiton
источник
1

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

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

Найдите эту ошибку и исправьте ее.

Джей
источник
1

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

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

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

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

Зик Ханселл
источник
0

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

Так как ты делаешь это забавным? Ну, я не могу ответить на это для вас, потому что я действительно не могу представить, что именно плывет на вашей отдельной лодке. Для меня я немного наркоман, поэтому ответ был в том, чтобы иметь очень надежную цепочку инструментов и гибкий процесс разработки, которые все способствуют тому, чтобы устранять неполадки, а не просто решать проблемы. быстро. В настоящее время я занимаюсь разработкой в ​​основном на C #, и я всегда в поиске инструментов, которые уберут утомительную часть времени написания программного обеспечения. Я использую тестовый подход к разработке, поддерживаемый очень хорошим BDD API под названием StoryQ . Я использую Resharper для автоматизации большей части своего рефакторинга, а StyleCop - для контроля над такими вещами, как стиль кодирования. Мое последнее дополнение к цепочке инструментов должно было включатьNCrunch, который выполняет мои тесты непрерывно и одновременно в фоновом режиме, пока я пишу код, и это действительно был NCrunch, который доказал , что это изменит правила игры.

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

S.Robins
источник