The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
У вас есть задача, которую вам поручили, и вам она не нравится. Вы просто не в настроении. Вы не знаете, как исправить эту чертову ошибку. Вы не имеете понятия, как был разработан этот кровавый модуль, и не знаете, как он работает. Но вам нужно исправить проблему, о которой сообщил человек, который не имеет понятия, как работает это программное обеспечение. Вы раздражаетесь и обвиняете того глупого менеджера проекта и программистов, которые были уволены два года назад. Вы тратите часы, чтобы понять, как работает код. Затем еще несколько часов, пытаясь исправить его. В конце концов, вы не успеваете к сроку и все вас обвиняют. Было такое?
Однако есть альтернативный подход, который предлагает профессиональный выход из этой ситуации. Вот несколько советов, которые я рекомендую своим коллегам, которые кодируют со мной в проектах Zerocracy. Вкратце, я собираюсь объяснить, как можно сокращать углы и оставаться профессионалом, 1) защищая свои нервы, 2) оптимизируя расходы вашего проекта и 3) повышая качество исходного кода.
Вот список вариантов, которыми вы располагаете, в порядке предпочтения. Я рекомендую вам начать с первого в списке и продолжать к следующим, когда это необходимо.
Это первый и наиболее предпочтительный вариант. Если вы не можете разобраться, как исправить проблему или реализовать новую функцию, это ошибка проекта, а не ваша. Даже если вы не можете разобраться из-за того, что ничего не знаете о Ruby и вас наняли для исправления ошибок в кодовой базе Ruby on Rails - это их ошибка. Почему они наняли вас, если вы ничего не знаете о Ruby?
Так что будьте позитивны; не вините себя. Если вы не знаете, как работает этот чертов код, это ошибка кода, а не ваша. Хороший код легко понять и поддерживать.
Не пытайтесь есть спагетти-код; пожалуйтесь повару и попросите его приготовить что-то лучшее (кстати, я люблю спагетти).
Как вы можете это сделать? Создавайте зависимости - новые ошибки, жалуясь на неясный дизайн, отсутствие модульных тестов, отсутствие необходимых классов или что угодно еще. Будьте креативны и агрессивны - конструктивным и профессиональным образом, конечно. Не переходите на личности. Независимо от того, кто приготовил этот спагетти, у вас ничего против него или нее лично. Вам просто нужно другое блюдо, вот и все.
После того как вы сообщите о таких зависимостях, объясните в основной задаче, что вы не можете продолжать работу, пока все они не будут решены. Вы официально прекратите работу, и кто-то другой улучшит вам нужный код. Позже, когда все зависимости будут разрешены и код будет выглядеть лучше, попробуйте вернуться к нему снова. Если вы все еще видите проблемы, создавайте новые зависимости. Продолжайте делать это, пока код перед вами не станет чистым и легким для исправления.
Не будьте героем - не бросайтесь исправлять плохой код, который вы унаследовали. Думайте, как разработчик, а не хакер. Помните, что ваша первая и наиболее важная обязанность, как дисциплинированного инженера, - помочь проекту выявить проблемы поддержки. Кто и как их исправит - ответственность менеджера проекта. Ваша работа - выявлять, а не скрывать. Будучи героем и пытаясь исправить все в рамках одной задачи, вы не делаете проекту одолжение - вы скрываете проблемы.
Изменение: Еще одним хорошим примером зависимости может быть вопрос, заданный, например, на Stack Overflow или списке пользователей сторонней библиотеки. Если вы не можете найти решение самостоятельно, и проблема выходит за рамки вашего проекта, задайте вопрос на SO и добавьте ссылку на него в исходный код (например, в блоке JavaDoc).
Все зависимости разрешены, код выглядит чистым, но вы все равно не понимаете, как исправить проблему или реализовать новую функцию. Это слишком сложно. Или, может быть, вы просто не знаете, как работает эта библиотека. Или вы никогда раньше не делали ничего подобного. В любом случае, вы не можете продолжать, потому что не понимаете. И чтобы понять, вам понадобится много времени - гораздо больше, чем вы имеете от вашего менеджера проекта или доски Scrum. Что вы делаете?
Опять же, думайте позитивно и не вините себя. Если программное обеспечение недостаточно понятно для полного незнакомца, это “их” вина, а не ваша. Они создали программное обеспечение таким образом, что его трудно воспринять и изменить. Но код чистый, он уже не клубок спагетти. Это идеально приготовленный омар, но вы не знаете, как его есть! Вы никогда не ели его раньше.
Повар сделал свою работу хорошо, он хорошо приготовил его, но ресторан не дал вам инструкций о том, как есть такое изысканное блюдо. Что вы делаете?
Вы просите инструкцию. Вы просите документацию. Хорошо разработанный и написанный исходный код должен быть должным образом задокументирован. Как только вы видите, что что-то для вас неясно, создавайте новые зависимости, которые требуют лучшей документации определенных аспектов кода.
Опять же, не пытайтесь все понять самостоятельно. Конечно, вы умный парень, но проекту не нужен один умный парень. Проекту нужен поддерживаемый код, который легко модифицировать, даже тем, кто не такой умный, как вы. Поэтому сделайте одолжение своему проекту: выявите проблему с документацией и попросите кого-то исправить ее за вас. Не только для вас, для всех. Вся команда извлечет пользу из такой просьбы. Как только документация будет исправлена, вы продолжите свою задачу, и все получат исходный код, который немного лучше, чем был раньше. Выигрыш для всех, не так ли?
Теперь код чист, документация достаточно хороша, но вы все равно застряли. Что делать? Что ж, я являюсь большим поклонником разработки через тестирование, поэтому мое следующее предложение будет заключаться в создании теста, который воспроизводит ошибку. В основном, это то, с чем вы должны начинать каждую задачу, будь то ошибка или функциональность. Поймайте ошибку с помощью модульного теста! Докажите, что ошибка существует, заставив сборку не проходить новый тест.
Это может быть довольно сложно достичь, особенно когда программное обеспечение, которое вы пытаетесь исправить или изменить, было написано идиотами кем-то, кто не имел представления о модульном тестировании. Существует множество техник, которые могут помочь вам найти способ сделать такое программное обеспечение более тестируемым. Я очень рекомендую вам прочитать книгу Working Effectively with Legacy Code Майкла Фезерса. Существуют множество различных паттернов, и большинство из них работают.
Как только вам удастся воспроизвести ошибку и сборка не пройдет, остановитесь. Этого достаточно для одной задачи. Пропустите тест (например, используя аннотацию @Ignore в JUnit 4) и зафиксируйте свои изменения. Затем добавьте документацию к модульному тесту, который вы только что создали, предпочтительно в форме @todo. Объясните там, что вам удалось воспроизвести проблему, но у вас не было достаточно времени для ее исправления. Или, возможно, вы просто не знаете, как ее исправить. Будьте честны и предоставьте все возможные подробности.
Я считаю, что поймать ошибку с помощью модульного теста в большинстве случаев является более чем 80% успеха. Остальное намного проще: просто исправьте код и пройдите тест. Оставьте эту работу кому-то другому.
Очень часто баг невозможно воспроизвести. Это не потому, что код невозможно протестировать и использовать в модульном тесте, а потому что вы не можете воспроизвести ситуацию с ошибкой. Вы знаете, что код аварийно завершается в производстве, но не можете вызвать его аварийное завершение в тесте. Стек вызовов ошибки, который сообщает конечный пользователь или ваша система журналирования производства, не воспроизводится. Это очень распространенная ситуация. Что делать?
Я считаю, что лучшим вариантом здесь будет создание теста, который докажет, что код работает, как задумано. Тест не провалится, и сборка останется чистой. Вы закоммитите его в репозиторий и … сообщите, что проблема решена. Скажете, что сообщенная ошибка на самом деле не существует в реальной жизни. Заявите, что нет ошибки - “наше программное обеспечение работает правильно; вот доказательство: посмотрите на мой новый модульный тест”.
Поверят ли вам? Я не думаю, но у них нет выбора. Они не могут заставить вас идти дальше. Вы уже что-то сделали - создали новый тест, который доказывает, что все в порядке. Заявка будет закрыта, и проект продолжит свою работу.
Если позже в производстве возникнет та же проблема, будет сообщена новая ошибка. Она будет связана с вашей заявкой. Ваш опыт поможет кому-то более детально исследовать проблему. Возможно, этому человеку тоже не удастся поймать ошибку с помощью теста, и он также создаст новый успешный и “бесполезный” тест. И это может происходить снова и снова. В конечном итоге, этот накопленный групповой опыт поможет последнему человеку поймать ошибку и исправить ее.
Таким образом, новый проходящий тест - это хороший ответ на баг, который вы не можете поймать с помощью модульного теста.
Иногда метод тестирования модулей не работает, в основном потому что ошибки могут быть слишком важными, чтобы их игнорировать. Они не согласятся с вами, когда вы покажете им модульный тест, который доказывает, что ошибки не существует. Они скажут вам: “когда наши пользователи пытаются скачать PDF, у них открывается пустая страница”. И они также скажут, что им безразличны ваши чертовы модульные тесты. Им важен только тот PDF-документ, который должен быть загружаемым. Так что трюк с модульным тестом не сработает. Что же делать?
Это зависит от многих факторов, и большинство из них не технические. Это политические, организационные, управленческие, социальные, как вы только назовите. Однако, в большинстве случаев, я рекомендую вам отключить эту токсичную функцию, выпустить новую версию и закрыть заявку.
Вы снимете проблему с себя, и все будут довольны. Ну, кроме бедного конечного пользователя. Но это не ваша проблема. Это вина руководства, которое неправильно организовало предпроизводственное тестирование. Опять же, не берите эту вину на себя. Ваша задача - поддерживать чистый код и заканчивать свои задачи в разумные сроки. Их задача - убедиться, что разработчики, тестировщики, DevOps, маркетологи, менеджеры продукта и дизайнеры работают вместе, чтобы предоставить продукт с приемлемым количеством ошибок.
Ошибки в производстве - это не ошибки программистов, хотя просроченные заявки - да. Если вы держите заявку в своих руках слишком долго, вы становитесь неуправляемой единицей работы. Их просто невозможно управлять вами. Вы что-то делаете, пытаетесь исправить ошибку, говорите “Я пытаюсь, я пытаюсь…” Как они могут управлять таким человеком? Вместо этого вы должны быстро доставлять, даже если это приведет к временному отключению функции.
Хорошо, предположим, ничто из вышеперечисленного не сработало. Код чистый, документация приемлема, но вы не можете найти ошибку, и они не принимают от вас юнит-тест в качестве доказательства отсутствия ошибки. Они также не разрешают отключить функцию, поскольку она критична для пользовательского опыта. Какие у вас есть варианты? Всего один.
Будьте профессионалом и скажите: “Нет, я не могу это сделать; найдите кого-то другого”. Быть профессиональным разработчиком не означает уметь исправить любую проблему. Это, вместо этого, означает честность. Если вы видите, что не можете исправить проблему, скажите об этом как можно скорее. Позвольте им решить, что делать. Если в конечном итоге они решат уволить вас из-за этого, вы останетесь профессионалом. Они будут помнить вас как человека, который был честным и относился к своей репутации серьезно. В конце концов, вы победите.
Не удерживайте задачу в своих руках. В тот момент, когда вы понимаете, что не являетесь лучшим человеком для этого или просто не можете исправить ее, сообщите своему менеджеру. Сделайте это его проблемой. Фактически, это его проблема в первую очередь. Он нанял вас. Он интервьюировал вас. Он решил дать вам эту задачу. Он оценил ваши способности и навыки. Так что пришло время отплатить ему.
Ваш “Нет!” будет очень ценной обратной связью для него. Это поможет ему принять следующие важные управленческие решения.
С другой стороны, если вы лжете, чтобы произвести впечатление, что вы человек, который может исправить все, но в конце провалитесь, вы нанесете ущерб не только своей репутации, но и результатам и целям проекта.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-27 at 05:07
