среда, 24 мая 2017 г.

Как срезать углы и оставаться в порядке

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

Существует, однако, альтернативный подход, который обеспечивает профессиональный выход из этой ситуации. Вот несколько советов, которые я рекомендую своим сверстникам, которые пишут со мной в проектах teamed.io. Короче говоря, я собираюсь объяснить, как можно срезать углы и оставаться профессионалом, 1) защищая свои нервы, 2) оптимизируя расходы вашего проекта и 3) повышая качество исходного кода.

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


Создать зависимости, и ждать пока они решатся

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

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

Не пытайтесь есть спагетти код; Пожалуйтесь шеф-повару и попросите его приготовить что-нибудь лучше (кстати, я люблю спагетти).

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

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

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

Другим хорошим примером может быть вопрос, например, на StackOverflow или людям в списке пользователей сторонней библиотеки. Если вы не можете найти решение самостоятельно, и проблема выходит за рамки вашего проекта, отправьте вопрос SO и поместите его ссылку на исходный код (например, в блоке JavaDoc).


Требуется улучшенная документация и терпение

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

Опять же, думайте позитивно и не вините себя. Если программное обеспечение недостаточно понятно для совершенно незнакомого человека, это «их» вина, а не ваша. Они создали программное обеспечение таким образом, что его трудно переварить и изменить. Но код чист; Это уже не спагетти. Это великолепно приготовленный омар, но вы не знаете, как есть омара! Вы никогда не ели его раньше.

Шеф-повар хорошо поработал; Он хорошо его приготовил, но в ресторане не давали никаких инструкций о том, как есть такое сложное блюдо.

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

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


Воспроизведение ошибки и вызов

Теперь код чист, документация достаточно хороша, но вы все равно застряли. Что делать? Ну, я большой фанат разработки на основе тестов, поэтому мое следующее предложение было бы создать тест, который воспроизводит ошибку. По сути, это то, с чего вы должны начинать каждый tiket, будь то ошибка или функция. Поймайте ошибку с юнит-тестом! Докажите, что ошибка существует из-за сбоя сборки с помощью нового теста.

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

Ловля ошибки с модульным тестом в большинстве случаев составляет более 80% успеха

Когда вам удастся воспроизвести ошибку, а сборка не удастся, остановитесь прямо там. Этого более чем достаточно для одной части работы. Пропустите тест (например, используя аннотацию @Ignore в JUnit 4) и зафиксируйте свои изменения. Затем добавьте документацию в только что созданный модульный тест, предпочтительно в виде @todo. Объясните, что вам удалось воспроизвести проблему, но не успели ее исправить. Или возможно вы просто не знаете, как это исправить. Будьте честны и дайте все возможные детали.

Я считаю, что ловить ошибку с модульным тестом, в большинстве случаев, более 80% успеха. Остальное проще: просто исправьте код и пройдите тест. Оставьте эту работу кому-то еще.


Доказательство отсутствия ошибки

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

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

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

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

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

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

Ошибки производства не являются ошибками программистов, хотя это отсроченные тикеты

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

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

Производственные ошибки не являются ошибками программистов, хотя это и отложеные задачи (tickets). Если вы держите задачу в руках слишком долго, вы становитесь неуправляемой единицей работы. Они просто не могут управлять вами больше. Вы что-то делаете, пытаясь исправить ошибку, говоря: «Я пытаюсь, я пытаюсь ...» Как они могут управлять таким парнем? Вместо этого вы должны быстро решать вопрос, даже если это происходит за счет временно отключенной функции.


Скажи "нет

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

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

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

Быть профессиональным разработчиком не означает быть в состоянии исправить любую проблему

Ваше «Нет!» Будет очень ценной обратной связью для него. Это поможет ему принять следующие важные управленческие решения.

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


Комментариев нет:

Отправить комментарий