Как факапить веб-разработчику

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

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

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

Я очень расстроился и начал готовить свое резюме, смирившись с тем, что меня уволят. Я даже гуглил, можно ли на меня подать в суд за то, что я сделал.

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

К счастью, технический менеджер спас меня, рассказав о еженощной резервной копии базы данных компании, и мы быстро устранили большую часть проблемы. Но до этого момента я был весь на нервах. Будучи веб-разработчиком,  вы будете ошибаться — часто, а иногда и очень сильно — независимо от того, новичок вы или ветеран (например, посмотрите на факап с сервисом веб-хостинга Amazon S3, в котором опечатка привела к остановке таких огромных сервисов, как Trello и Quora).

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

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

Момент факапа: OMG AKS & A1LSKD !!!!
Вы облажались, причем конкретно. Код, над которым вы корпели неделями, а может, и месяцами, пройдя через бесчисленные пиццы и эспрессо, внезапно сыпет ошибками. И не только не работает этот кусок, но и вместе с ним приличный кусок вашего веб-сайта, проекта и т. д. Хреново.

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

Погружаемся в проблему — разбираемся в сломанном коде

Прежде всего: проанализируйте и диагностируйте проблему. К сожалению, это самая сложная часть. В телесериале «Мистер Робот» есть отличная фраза, персонажа Рами Малека Эллиот Алдерсона, инженера по кибербезопасности: «Большинство программистов думают, что отладка программного обеспечения — это исправление ошибок, но это чушь собачья. На самом деле отладка — это поиск ошибки, это про понимание того, почему она возникла, и про то, что ее появление не было случайностью».

В моем случае я знал, почему я сломал сайт: я загрузил код, который сперва не протестировал. Но чаще всего вы понятия не имеете, кто или что вызвало поломку. Ваш инстинкт будет подсказывать продебажить код и различные файлы, переходя от файла к файлу, чтобы выяснить: «Хорошо, здесь вызвана эта функцию. Где эта функция?» Этот процесс может быть утомительным, трудоемким и хаотичным, в то время как ошибка может состоять из всего двух пропущенных букв.

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

 

Проговорите это.

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

Когда вы нафакапили, поговорите со своей командой и начинайте брать ситуацию под контроль. Возможно, кто-то может легко решить проблему или признается в том, что является виновником, или, как в моем случае, успокоит вас, сказав: «О, не переживай, это поправимо». Открытые беседы могут излечить бесчисленные офисные недуги — даже такие проблемы, как факапы в кодинге, которые вы, возможно, инстинктивно захотите оставить при себе. Одна из компаний, оказывающих наибольшую поддержку, в вопросах факапов — это сайт электронной коммерции Etsy. Команда инженеров компании ведет блог Code as Craft, в котором регулярно делится опытом, полученным в этой области, а также регулярно проводит серию выступлений, посвященных тенденциям в технологиях и программировании. Я думаю, что наряду с, возможно, Google, они одни из самых ярых приверженцев написания высококачественного кода. Несмотря на стремления к большим высотам или, возможно, из-за них, разработчики Etsy время от времени совершают ошибки. Но вместо того, чтобы расстраиваться, члены команды открыто говорят о том, где они облажались, в блоге или в электронном письме, адресованном всей компании. Это не публичное осуждение друг друга, а, скорее, возможность исследовать факапы, которые случаются, в надежде, что это поможет другим не допустить их. Разработчики должны стремиться к такому образу мышления. Следовать примеру Etsy и думать о программировании как о ремесле означает подходить к нему с той же осторожностью и вдумчивостью, как и любой другой ремесленник — смотреть на более широкую картину и обсуждать со своими коллегами инструменты, методы и способы стать лучше. 

Открытые беседы могут излечить бесчисленные офисные недуги — даже такие проблемы, как факапы в кодинге, которые вы, возможно, инстинктивно захотите оставить при себе.

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

 

Большой фикс: открой своего внутреннего разработчика

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

«Баг никогда не бывает просто ошибкойОн представляет собой нечто большее. Ошибка мышления. Это делает вас тем, кто вы есть
Андрей Козюля, СТО DAN.IT education


Найдите ошибку в своем мышлении. Узнайте себя.

Как СТО учебного центра DAN. IT education, я помогаю студентам понять, что они за разработчики: какие ошибки они совершат, к каким типам ошибок они склонны и где они совершат ошибки, думая о процессе. Программисты обычно делятся на тех, кто делает глупые опечатки, и тех, кто допускает логические ошибки, но нюансы невероятно сложны. Один из способов начать понимать свой стиль программирования — задать себе такие вопросы, как: склонны ли вы забывать знак равенства или неправильно оценивать истинность переменных? Вы путаете порядок, в котором вызываются ваши функции? Вас сбивает с толку асинхронный характер JavaScript? Или, может быть, вы отлично решаете все проблемы, но часто делаете опечатки. У всех свой подход, и поэтому все совершают ошибки совершенно по-разному. В DAN. IT  мы даем студентам домашние задания и проекты, разработанные специально так, чтобы стать для них вызовом. Для того, чтобы каждый знал о разных типах проблем и находил закономерности в своих работах, мы часто выводим ошибки на экран, чтобы весь класс мог их увидеть и проанализировать.

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

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

Андрей Козюля, СТО DAN. IT education

Все статьи
Контакты