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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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