Разработчик Лоренцо Паскуалис рассказал об ошибках, которых инженеры должны избегать любой ценой.
Инженеры-программисты могут пропустить массу возможностей карьерного роста, не понимая, что они делают что-то неправильно. Многие ошибки в разработке программного обеспечения проявляются в способах, которые не переходят непосредственно в очевидные возможности для обучения. Они замедляют карьеру людей и не позволяют им достичь своего наивысшего потенциала.
- Не тестировать свою работу
Когда вы пишете код, вы должны протестировать его. Прежде чем продолжить, позвольте мне определить некоторые термины, связанные с тестированием; это поможет с остальной частью этой темы.
Happy-path: серия операций, потоков данных и действий пользователя, которые выполняют задуманную логику кода.
Unhappy-path: любое отклонение от happy-path, вызванное такими факторами, как: ошибочные условия, неожиданные входные данные, плохая настройка системы, аппаратные сбои.
Формальное тестирование: исчерпывающее тестирование, выполненное кем-то, кто не писал код. Это может быть тестер, QA-инженер, другой разработчик или поставщик.
Тестирование разработки: это тестирование, которое разработчик проводит при подготовке к формальному тестированию. Оно должно включать:
- Ручное тестирование — проведение операций в качестве конечного пользователя.
- Юнит-тестирование — создание воспроизводимых тестов для модулей кода.
- Автоматическое тестирование — код, который полностью проверяет систему или её часть.
Имейте в виду: если ваш код компилируется без ошибок или просто если все happy path работают, это не значит, что работа готова к формальному тестированию.
Чтобы избежать этой ошибки, вы должны:
- Выполнить тесты для всех happy path.
- Выполнить тесты для всех легко тестируемых unhappy path.
- Задокументируйте все сложные для тестирования unhappy path, о которых вы можете вспомнить. Оцените и обсудите с группой формального тестирования, как это сделать.
2. Скрывать свои ошибки
В большинстве ситуаций сокрытие ошибки хуже, чем любая ошибка, которую вы пытаетесь скрыть. Вы всегда должны быть честными в отношении того, что пошло не так, как это произошло, что вы делаете, чтобы исправить это и что вы собираетесь делать, чтобы предотвратить подобные вещи в будущем.
Я никогда не видел, чтобы кого-то увольняли за ошибку, которую они совершили и признали. Тем не менее, я видел, как людей увольняли за ошибки, которые они пытались скрыть.
3. Чувствовать, что код принадлежит только вам
Иногда индивидуальное владение кодом является частью инженерной культуры организации, в которой вы работаете. В других случаях это ошибка, которую вы допускаете из-за гордости.
Избегайте этого, если сможете. Для этого не нужно защищать свой код от любых исправлений или замечаний. Посмотрите на него как на тротуар, который вы построили для других.
4. Документировать код только для себя, а не для других
Когда вы документируете свой код, вы должны сделать это для разработчиков, которые будут работать над ним через несколько месяцев или даже лет. Поскольку у вас нет собственного кода, документация должна быть направлена на то, чтобы объяснить другим, что вы сделали и почему.
Если ваша документация понятна только вам, никто не сможет эффективно работать с кодом, и вы станете его фактическим владельцем. Это ведет вас к пути индивидуального владения кодом и собственноручно построенной карьерной тюрьме.
Кроме того, плохая документация является одним из наиболее заметных признаков плохого кода. Может быть сложно сказать, насколько плохим является фрагмент кода, но легко сказать, насколько плоха его документация. Когда на протяжении всей своей работы вы оставляете плохую документацию, вас начнут ассоциировать с плохим кодом.
Эта ошибка типична для прототипов систем, созданных в спешке, особенно на ранних стадиях стартапа. Такой код не должен служить долгое время. Но, к сожалению, часто код прототипа остается на неопределенно большой срок. Поэтому я советую сразу писать код, который может оставаться нетронутым долгие годы. В большинстве случаев так и происходит.
Чтобы избежать этой ошибки, пишите все комментарии к коду, представляя конкретного разработчика, который будет изменять этот код в будущем.
5. Сопротивляться процессам разработки
Процессы разработки, такие как скрам и канбан, предназначены для того, чтобы команды могли масштабироваться. Они способствуют сотрудничеству и совместному владению проектами, обеспечивая достаточное планирование и координированное выполнение плана.
Разработчики, которые борются с формальными процессами, создают трение, которое сжигает энергию и замедляет масштабируемость команд. Эта тенденция приводит к изоляции, которая может стать карьерным убийцей для инженера-программиста. Он или она будут рассматриваться как неспособные сотрудничать и работать в команде.
Чтобы избежать этой ошибки, усвойте необходимость и преимущества процессов развития. Если что-то не работает для вас, помогите исправить это. Возможно, вы захотите устроиться в меньшую организацию, в которой нет таких формальных процессов, нацеленных на масштабирование.
6. Выполнить 90% работы и идти дальше
Если вы нанимаете художника, чтобы разрисовать внутренние стены вашего дома, вы ожидаете законченной работы. Если вы получаете комнату, которая все еще находится в состоянии ремонта, вы не будете удовлетворены.
Код, который сделан на 90%, не закончен. Некоторым разработчикам нравится создавать прототипы, и они хороши в этом. Однако это может стать плохой привычкой. Незаконченная работа не может быть выпущена. Если человек, выполнивший большую часть работы, не завершает её, значит это должен будет сделать кто-то другой. Решение: всегда завершайте вашу работу.
7. Не проводить контроль версий
Некоторые разработчики не проводят контроль версий для кода, над которым они работают. Это особенно распространено в следующих ситуациях:
- Экспериментальные или ранние проекты
- Скрипты сборки
- Инфраструктурный код
- Код для тестов
- Конфигурации
- Скрипты развертывания
- Скрипты для разового применения
Все правки нужно вносить как можно скорее и как можно чаще. Если вы используете git, это должно быть просто.
8. Не понимать значения оценок
Любые организации подчиняются законам экономики. В частности, организации должны иметь возможность решить, должны ли они или не должны вкладывать средства в разработку продукта, функции или улучшения. Чтобы принять это решение, им необходимо оценить стоимость и ценность результата. Без таких оценок невозможно сделать такую оценку, и решения в конечном итоге будут сделаны в вакууме.
Разработчики иногда убеждаются, что невозможно оценить усилия, необходимые для завершения проекта. Я согласен, что это может быть сложно, но с практикой и опытом оценки становятся все более и более точными. Разработчики, которые хотят улучшить свои навыки оценки более успешны в карьере, чем разработчики, которые этого не делают.
9. Не делиться знаниями с другими
Хранить знания при себе — это саморазрушительная привычка. Вы можете думать, что обеспечиваете безопасность работы, но так вы не приобретаете новых обязанностей.
Повышение связано с расширением поля влияния. Если вы скрываете свои знания, вас будут видеть как человека, которые не может делегировать, влиять на других людей в команде и двигаться дальше. Как только ваш стаж в компании перестанет соотноситься с ценностью, которую вы приносите организации, вы заметите изменение в том, как вас воспринимают. Ваши знания постепенно устареют, более динамичные инженеры переделают то, что вы защищали, и вы уже не будете таким ценным сотрудником.
Решение простое, но не легкое. Делитесь тем, что вы знаете. Вы можете написать документацию, обучать других, делегировать часть работы и так далее. Старайтесь никогда не удерживать в течение длительного времени один ключ к большому хранилищу знаний.