Как сделать свой код чистым и красивым

0
3824
views

«А это ЕДИНСТВЕННЫЙ способ ПРОДВИГАТЬСЯ БЫСТРО и успеть к ДЕДЛАЙНУ»

Представляем перевод статьи Рави Райана, опубликованной на hackernoon.com.

Чистый кодОб этом прекрасно сказал Роберт Мартин:

“Единственная точная единица измерения качества кода – «какого хрена»/мин.»

Я немного поясню.

Когда бы я ни просматривал код, мой мозг синтезирует эмоции трех разных видов.

  • Какого хрена (раздраженно) – Этот код не нужен.
  • Какого хрена (восхищенно) – Этот чувак умен.
  • Какого хрена (озлобленно) – Не могу понять эту тарабарщину.

Итак, что прежде всего производит на нас впечатление, когда мы видим какой-нибудь код?

Это чистота и красота его написания.

А написание чистого и красивого кода – признак ОТЛИЧНОГО спеца по программному обеспечению.

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

Короче говоря, учиться писать чистый код это тяжелая работа. Вам придется над этим попотеть. Вы должны практиковаться, ошибаться, терпеть неудачи, преодолевать трудности и повторять эти шаги снова и снова, пока не получится правильно. Более простого пути нет.

А вот несколько способов, с помощью которых можно достичь вершин мастерства в написании чистого и красивого кода.

«Что значит ИМЯ»*

Хорошо выразился об этом Кендрик Ламар:

«Собираясь рассказать реальную историю, я начну со своего имени».

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

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

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

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

«Функции должны ДЕЛАТЬ ТОЛЬКО ЧТО-ТО ОДНО»

На эту тему отлично высказался Луис Салливан:

«Форма следует за функцией».

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

Есть всего два золотых правила написания чистых функций:

  • Они должны быть маленькими
  • Они должны выполнять одно действие, но выполнять его хорошо.

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

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

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

«Комментарии придуманы не для плохого кода»

Винус Уильямс попала в точку, сказав:

«Каждый оставляет собственные комментарии. Так рождаются слухи».

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

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

Код движется и развивается. Куски кода перемещаются туда-сюда, а комментарии – нет, и это становится проблемой!

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

«Форматирование кода всегда в приоритете»

Роберт С. Мартин сказал чистую правду:

«Форматирование кода относится к общению. А общение имеет первостепенное значение для профессионального разработчика».

Это утверждение нельзя недооценивать, это одна из главных характеристик действительно ОТЛИЧНОГО разработчика.

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

Если вы думаете, что в деле профессионального разработчика главное сделать так, «чтобы это работало», вы очень далеки от истины. Функционал, создаваемый вами сегодня, имеет все шансы измениться в следующем релизе, но читабельность вашего кода останется неизменной.

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

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

Пишите ваши try-catch-finally сразу

Жорж Кангильем верно заметил:

«Ошибки свойственны людям, упорство в ошибке – дьяволу».

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

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

А один из способов делать это – правильные вложения и захват всех ошибок в try-catch блоках. Эти блоки являются способом определения границ вашего кода. Когда вы исполняете код из части try вашего try-catch-finally предложения, вы заявляете, что выполнение может быть прервано в любой момент времени, а затем возобновлено в catch.

Поэтому начинать с предложения try-catch-finally является хорошей практикой при написании кода. Это помогает вам определить, чего может ожидать пользователь кода, независимо от того, что пошло не так при исполнении кода из try.

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

Обобщаем все вышесказанное

Итак, что является главным во всем, описанном здесь?

Это чувство кода – программистский эквивалент здравого смысла.

Согласно Роберту Мартину, «написание чистого кода требует дисциплинированного использования множества маленьких приемов, применяемых в соответствии с рожденным в муках ощущением «чистоты». Эти небольшие приемы обобщенно можно назвать чувством кода».

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

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

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

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

Как верно подытожил Гарольд Абельсон,

«Программы должны писаться для чтения их людьми и только попутно – для исполнения машинами».


При написании статьи использованы книги: “A handbook of Agile Software Craftsmanship” Роберта Мартина и “A handbook of Agile estimation” Майка Кона.

*Отсылка к цитате из пьесы «Ромео и Джульетта» В. Шекспира: «Что значит имя? Роза пахнет розой, хоть розой назови ее, хоть нет».



ОСТАВЬТЕ ОТВЕТ

Please enter your comment!
Please enter your name here