Как избежать критических ошибок в новой среде кода?

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

У меня нет опыта работы с Java, и хотя я знаю, как писать код на C# и т. д., и знаком с API, недавно я столкнулся с серьезной проблемой при проверке своего кода в нашем исходном репозитории.

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

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

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

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

Я должен добавить, что мой код изменений также проверил один из разработчиков бэкенда, который, я уверен, спросил, упоминается ли API где-либо еще. Поскольку мой поиск и проверка ничего не показали в среде IDE, поскольку она не проверяет файлы BPMN, я ответил «нет».

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

Дополнительные примечания в ответ на комментарии и ответы:

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

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

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

Комментарии не для расширенного обсуждения; этот разговор был перемещен в чат .
Такие вещи должны быть задокументированы с источником именно для этой цели. Они не всегда. Вы читали документацию, от которой можно было ожидать?
Это звучит как запах кода, Java, как и C#, является строго типизированным языком. Если механизмы, используемые для проверки типов, не запускаются в тестах, у вас может быть более глубокая проблема, связанная с неправильным использованием интерфейсов.
Именно поэтому существуют обзоры кода. Я предполагаю, что вы используете систему управления версиями; почему разработчикам было так сложно просмотреть последнюю дюжину или около того коммитов, чтобы обнаружить проблему?
Вот почему перед выпуском кода в промежуточной среде должен быть надежный набор тестов, сервер CI и QA. Похоже, что вашей компании не хватает этих компонентов, что позволяет выпускать ошибки, которые можно легко обнаружить.
Я бы посоветовал вам не связываться с разработчиком, выполняющим проверку вашего кода. Они должны получить спецификации, которые вам дали, и ваш код из репозитория. Если у них есть вопросы о чем-то, пусть они задают их другому разработчику, а не вам. Когда вы объясните это, вы можете заставить их пропустить ошибку, которую они бы поймали.
@ J.ChrisCompton, я бы с этим согласился. Однако в моей компании в настоящее время нам не дают полные спецификации, и, возможно, это личное дело, но я часто вижу, что люди просто бегло просматривают код-ревью, если вас нет рядом, чтобы подсказать им посмотреть на определенные области, когда вы идете . Возможно, это неправильно, и я согласен, что они должны подсказать мне больше.
«4-дневная проблема с 2-4 бэкенд-разработчиками» — Значит, для обнаружения ошибки потребовалось от 8 до 16 дней бэкэнд-разработчика? Тогда проблема не так «тривиальна, чтобы увидеть и избежать», как некоторые могут притворяться. Если они знают «свои» вещи, они могут быстро найти ошибку. Если это займет у них пару дней, вы не виноваты, что заранее не знали, что с чем связано в новой среде. Если проблема не была четко задокументирована. Но тогда почему им потребовались бы дни, чтобы исправить это?
@ Im-Harrison Да, я понимаю, что у тебя, вероятно, ограниченный контроль. (1) Проблема «просмотра» может быть меньше, если и программист, и рецензент кода вызываются на каждую встречу, когда что-то идет не так. Никто не должен знать, кто из вас его закодировал (хотя обычно знают). (2) Даже если у вас нет сквозных спецификаций, у вас должно быть что-то. Если это устно, напишите электронное письмо и отправьте его человеку, дающему вам спецификации, — тогда у вас есть кое-что для рецензента кода (и это также может избавить вас от беспокойства :) Не объясняйте рецензенту кода, если это не требуется (согласно политике или неписаному правилу).

Ответы (8)

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

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

Я бы также посоветовал быть немного более громким с вашими коллегами. Если вы вносите изменения в критически важную систему, сообщите им об этом. Даже если это простой запрос вроде «Я собираюсь изменить этот важный элемент, у вас есть время для проверки кода?» . Таким образом, ваша команда не будет тратить дни на поиск проблемы, если она есть, и вы можете быть спокойны, зная, что вы И ваши коллеги уверены в изменениях. Некоторые команды разработчиков устраивают ежедневные стендапы, рассказывая о том, над чем они работают; это помогает команде быть более осведомленной о том, над чем вы работаете, и есть ли риск конфликта ваших изменений с чьими-либо еще.

Вы будете учиться, делая. Если вы хорошо разбираетесь в таких языках, как C#, вы можете освоить Java быстрее, чем вы думаете!

Это было вызвано строковой ссылкой на API в этом «файле рабочего процесса BPMN», поэтому ничто не устарело, и извлечение последних изменений не помогло бы.
@DavidConrad, вы правы на 100%, но это меньше о прошлом и о том, почему это произошло, поскольку я знаю и понимаю, как это дошло до этого. Этот ответ предлагает то, что, по моему мнению, является лучшим советом в этом случае - больше использовать свой голос и вовлекать других. Если бы я был громче и больше озвучивал другим разработчикам то, что я делал, было бы более вероятно, что кто-то мог бы указать, что это использовалось в рабочих процессах BPMN.
А, старый, "работает на моей машине". :П

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

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

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

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

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

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

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

Редактировать: обзоры кода — еще одна хорошая практика программирования, которая может свести к минимуму подобные ошибки, а также довольно проста в использовании.

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

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

Проблема возникает из-за того, что API упоминается в файле рабочего процесса BPMN, который не отображался, когда я искал ссылки или имя API в виде текста в среде IDE.

Что команды ретроспективно узнали об этом инциденте? Какие ведомственные процедуры можно было бы внедрить, чтобы там это не повторилось? Что, по мнению команды, необходимо при адаптации новых разработчиков? И какие новые процедуры адаптации необходимо разработать?

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

Могу я спросить, почему люди всегда предлагают улучшения на процедурном уровне или уровне управления? Очень сомнительно, что новый парень придет и скажет: «Измените все это, чтобы мои вещи могли работать!» Когда до этого момента все/вещи работали «хорошо»? Сломать что-то, а затем не знать, почему это сломалось, занять почти неделю рабочего времени, а затем в конце сказать, что их процесс воняет и его нужно улучшить, — это не лучший способ начать свою карьеру там.
Потому что, если вопрос звучит так: «Какое автоматическое тестирование мы можем добавить в процесс выпуска, чтобы выявлять такого рода проблемы при следующем внесении изменений», вы должны получить лучший процесс, который не требует, чтобы кто-то вручную проверял. каждое изменение.
Часто ветераны игнорируют процедурные и управленческие проблемы, поскольку привыкают их обходить. Они забывают, что так быть не должно, поэтому для них все работает «хорошо». Нужен свежий взгляд, чтобы увидеть недостатки. Тем не менее, я согласен, что новый парень не должен предъявлять требований, но это большая разница между словами «Измени все это, чтобы мои вещи могли работать!» и «Почему мы поступаем так, а не иначе?»
@Dan Ваш сценарий можно изменить: «... затем в конце скажите, что их процесс воняет и его нужно улучшить», чтобы избежать подобных проблем в будущем. Как человек, который сделал именно это, немного упорной решимости привел к изменениям процесса, которые сделали жизнь каждого проще. Я убедил своих коллег за 3 месяца работы в компании в качестве младшего разработчика, сделав это, а затем показав результаты . Если они не проводят ретроспективы/посмертные анализы, это легкое место для внесения позитивных изменений, которые определенно принесут пользу команде.
Если возникает проблема, то это либо из-за некомпетентности, либо из-за ошибки процесса - ясно, что ОП не некомпетентен, а совершил ошибку, которую можно избежать с помощью какого-то механизма. Компании может не понравиться слышать это от «постороннего», однако это проблема, которую можно устранить с помощью надлежащих процессов. В идеале руководство команды должно быть в состоянии идентифицировать это и применять новые процессы — если новичок инициирует этот мыслительный процесс, то это их более серьезные проблемы. Я думаю, что совет «проактивности» действителен, хотя я признаю, что если ОП активен, что-то большее неправильно.
@Dan Потому что их процесс явно нарушен. Не существует тестов на соответствие файла рабочего процесса BPMN API, и они, безусловно, должны быть.
@Dan, чтобы этого не повторилось в следующий раз, когда в команду добавится новый разработчик.

Где хранились файлы BPMN, которые не были видны при поиске других потребителей API?

Проблема звучит так, будто вы не знали обо всех потребителях API и не имели доступа к ним.

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

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

Я думаю, что одна из проблем заключается в том, что IDE для таких языков, как java (я предполагаю, что C# аналогичен, но у меня нет личного опыта) могут убаюкать вас ложным чувством безопасности. Они имеют встроенные функции для поиска пользователей классов, методов, полей и т. д., что позволяет избежать ложных срабатываний, обнаруживаемых при простом текстовом поиске, но эти методы надежны только в том случае, если весь код включен в проект IDE И вызовы выполняются напрямую. из java-кода, а не через отражение.

Вы должны изменить свое мышление.

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

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

Чтобы ответить на ваш вопрос:

  1. Вы лично не можете избежать таких вещей, в общем. Техническая ошибка была полностью вне вашей компетенции. Если бы вы хотели быть уверены на 100%, вы бы зашли в тупик. Вы не можете проверять части системы, о которых ничего не знаете.
  2. Системы (включая компьютеры и людей) также не могут быть построены таким образом, чтобы избежать таких вещей, как только они станут достаточно сложными.
  3. Один из способов приблизиться к этому — это подход DevOps/Agile, который предполагает отказ от неудачи и отказ от нее быстро и жестко. Это то, о чем все CI и особенно CD. Вы развертываете так часто и быстро, что очень часто терпите неудачу; и каждый раз с максимальным приоритетом устраняете конкретную причину (используя обычные приемы - автоматические и ручные тесты, безболезненный откат небольших коммитов, сине-зеленый-деплой с переключением отката по щелчку пальца и т.д.). Это логически приводит к тому, что весь процесс становится более надежным очень быстро. В идеале вы делаете это с нулевого дня. Легко? Нет. Можно ли улучшать по частям? Да.

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

Есть, конечно, технические «лучшие практики», которые помогут, и да, есть все банальности об обучении на своих ошибках. Но у тебя все это, кажется. Тем не менее, вы все еще чувствуете себя настолько плохо из-за инцидента, что нашли время, чтобы написать об этом на work.stackexchange.com?

Я думаю, что вы можете сделать что-то ощутимое, что поможет вам и другим почувствовать себя лучше во всем этом.

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

Вместо того, чтобы еще громче извиняться и давать скоро забытые обещания «никогда больше», найдите время, чтобы лично ПОБЛАГОДАРИТЬ людей, которые помогли решить проблему, и тех, кому вы доставили неудобства. Если это уместно, принесите коробку пончиков (например) в офис и дополните своих коллег.

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

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

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

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

Как избежать критических ошибок в новой среде кода?
СпросиСетьПолитика конфиденциальности1y, 0v