Сломанный код не должен ломать ваш дух. Узнайте, как правильно себя вести, когда что-то идет не так.
Проработав три месяца на моей первой работе после колледжа на должности веб-разработчика в компании, занимающейся финансовой отчетностью, я стер все записи клиента одной командой.
Я загрузил скрипт, предназначенный для удаления одного клиента, но быстро обнаружил, что он удалил их всех, и я не могу восстановить эти записи. (Это было в начале 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
