От переводчика: сегодня публикуем для вас статью разработчика из Индии Рави Шанкара Рахана. Он рассказывает о том, что стоит делать, если вы хотите научиться писать простой и понятный код. Статья рекомендуется всем начинающим программистам.
Написать простой код несложно. Но если речь о том, чтобы он был готов к будущему использованию кем-либо, то все сразу усложняется. Дело в том, что такой код должен быть еще более чистым и понятным.
Разработчику необходимо создавать код, который может использовать любой его коллега из любой страны мира. Так он становится чем-то вроде его «наследия». Все это хорошо и складно звучит, но реальность несколько иная…
Skillbox рекомендует: Двухлетний практический курс «Я — веб-разработчик PRO».
Напоминаем: для всех читателей «Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».
Дело в том, что в начале своего пути, даже принимая изложенную выше догму, я создавал такой монструозный код, что «хорошим» его было назвать никак нельзя. Его было практически невозможно понять и интерпретировать. Чуть позже я начал проводить дни и месяцы над «исправлением» и «оживлением» чудовищ, которых создал.
Программировать сложно. Когда вы пишете программу, в которой дофигалионы строк, вы делаете ошибки. Иногда они значительные, иногда — не очень. Но вне зависимости от размера для их поиска и исправления необходимо время. Иногда вам нужна помощь, чтобы выбраться из воронки отчаяния и безысходности, в которую вы попадаете, работая над своим кодом.
Порой вам нужна… резиновая уточка
Концепция резиновой уточки впервые была предложена Дином Паркером в его посте об ораторском искусстве. Паркер говорит о том, что для того, чтобы стать хорошим оратором, нужно постоянно упражняться в произнесении речей. И лучший способ избавиться от страха перед слушателями, одновременно обучаясь выражать свои мысли складно и внятно, — это выступать во время «ораторских тренингов» перед резиновой уточкой. Она как раз и заменяет собой слушателей.
Будучи программистом, вам необходимо попробовать объяснить каждую строку своего кода резиновой уточке (неважно, реальной или воображаемой). Пытаясь сделать это, вы начинаете понимать достоинства и недостатки кода. Вы даете самому себе возможность взглянуть на него со стороны.
Вот несколько важных моментов, которые я понял, применяя эту практику. Они помогли мне начать писать заметно лучше.
Cоздание многократно используемых компонентов — не перманентная необходимость
Многие не согласятся со мной, утверждая, что многократно используемые компоненты нужны всегда, что их необходимо делать повторно используемыми так часто, как это возможно. Дескать, это помогает улучшать качество кода и работать над собственными ошибками. Все так, но только в том случае, если вы создаете лучший код в мире. А он-то как раз никому и не нужен.
Нет, конечно. Вам необходимо создавать программное обеспечение, соответствующее определенным условиям, включая бюджет. Вы также можете постоянно полировать свой проект, доводить его до блеска, теряя время, но чувствуя себя идеальным разработчиком. Но помните: ПО актуально в течение ограниченного времени, а значит, вам нужно работать быстро, иначе вы никогда не закончите.
You Aren’t Gonna Need It
Оригинальная английская аксиома звучит как “YouArentGonnaNeedIt (YAGNI)”. Понимать это следует следующим образом: «Используйте определенные инструменты лишь тогда, когда вы в них действительно нуждаетесь, а не просто думаете, что они вам могут пригодиться».
Для этого есть две причины:
- Вы экономите время, избегая лишней работы.
- Ваш код становится лучше, поскольку вы избавляете его от «предполагаемых» элементов, которые бы усложняли программу.
Упрощайте все до необходимого минимума
У «экстремального программирования» есть два золотых правила для создания простого кода.
Во-первых, самый простой способ ввести новую функцию — сделать так, чтобы она «просто работала». Не нужно создавать шикарные суперструктуры, нечто высокотехничное. Просто сделайте так, чтобы функция работала. Но не забудьте и того, что код должен пройти Unit Tests.
Во-вторых, проведите рефакторинг системы таким образом, чтобы код стал максимально простым, с включением всех текущих функций. Он должен быть чистым настолько, насколько это возможно.
В-третьих, стоит усвоить, что мы не ищем самый быстрый путь. Мы стремимся достичь самого простого результата (в плане кода). Например, можно разбить существующий метод на части, что оставит тестовые фрагменты работающими, а затем модифицировать каждый из методов обработки, шаг за шагом.
Когда вы застрянете в следующий раз, попробуйте уточку
Поиск багов, проблем, общая работа над кодом — главная часть программирования. Поэтому разработка собственных техник по поиску и ликвидации багов, поиск своего пути — критически важная задача.
Если вы где-то застряли и ничего не работает, попробуйте уточку.
Можно не представлять ее себе, а купить. И неважно, будет ли это обычная уточка для ванной или утка-пират, — главное, чтобы вам было комфортно с ней, чтобы она соответствовала вашей индивидуальности.
И после этого можно начать разговор с уточкой. Говорите с ней, задавайте вопросы, объясните вслух проблему, с которой вы работаете. Результат вас удивит.
Крис Пайн был прав, говоря: «Программирование — это не то, что вы знаете, это то, что вы можете узнать».
- Онлайн-курс «Профессия frontend-разработчик»
- Практический курс «Мобильный разработчик PRO».
- Практический годовой курс «PHP-разработчик с 0 до PRO».