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

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

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

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

Я определил 3 основные ошибки, которые делает разработчик программного обеспечения при написании кода —

1. Перестаньте слепо копировать код

Google помогает нам всем по-своему. Разработчики программного обеспечения часто сталкиваются с проблемами в своем коде или ищут решения в Интернете из различных источников, таких как — StackOverflow, официальная документация библиотеки/пакета, документы npm и т. д.

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

  1. Скопированный код требует всех необходимых правок, чтобы заставить его работать. Если пропустить это, это может привести к ужасному сбою процесса при запуске кода.
  2. Многие разработчики даже не осознают риск нарушения авторских прав. Копируемый код может иметь авторские права, и владельцы могут легко потребовать роялти или даже подать в суд.
  3. Последний результат, который может случиться, это то, что скопированный код может работать в одной среде и не работать в другой. Поскольку он скопирован, будет трудно найти правильное решение.

Вот что я предлагаю вам следовать при получении любого фрагмента кода из онлайн-источников —

Всегда ищите текст копирайта/лицензии. Существуют типы лицензий, которые позволят вам использовать код, но с некоторыми ограничениями, поэтому действуйте соответственно.

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

2. Прекратите повсеместно использовать обработку исключений

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

  1. Когда фрагмент кода вызывает внешний вызов API, используйте универсальное исключение или исключение, задокументированное в документации по API.
  2. Используйте общее исключение только тогда, когда оно может вызвать серьезные проблемы, такие как завершение сценария/процесса.
  3. Используйте обработку исключений при отладке кода.

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

3. Тестируйте свой код в несколько этапов

Я много раз видел, как сбой в коде происходил главным образом из-за того, что он был протестирован в одной среде, а не в целевой среде. Например, разработчик программного обеспечения пишет код и тестирует его в среде разработки, а не тестирует в производственной/непроизводственной среде.

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

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

  1. Разработка — разработчики программного обеспечения будут кодировать и тестировать программное обеспечение.
  2. Непроизводственная/тестовая среда — команда тестировщиков будет выполнять тесты на основе критериев приемки, определенных реальными пользователями.
  3. Производство — команда со стороны пользователя будет проводить тесты и предоставлять отзывы.

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

Подробнее об авторе😄

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

Зарегистрируйтесь здесь для получения моего информационного бюллетеня Coders Weekly, где я делюсь интересными учебниками, библиотеками Python, инструментами и т. д.

Гитхаб | ЛинкедИн | Твиттер | Фейсбук | Куора | Еженедельник кодеров