Как известно подписчикам этого блога, в настоящее время я читаю Чистый код, классический метод написания читабельного профессионального кода. Написанный в основном дядей Бобом Мартином с участием ряда ведущих мыслителей в области разработки программного обеспечения AGILE, Clean Code не совсем пошаговое руководство по кодированию. Хотя я жажду еще одной украшенной животными книги О'Рейли так же, как и следующего наркомана кода, Чистый код не научит вас конкретному языку или фреймворку. Скорее, подзаголовок Clean Code - Руководство по созданию программного обеспечения - объясняет более широкую цель этой книги.

Для Боба Мартина и его соавторов Чистый код предоставляет способ позаботиться о своем коде. Подобно тому, как плотник ведет свой токарный станок по деревянной плите с лазерной точностью (сегодня буквально с лазерной точностью), так и программисты должны писать свой код с предельным вниманием к деталям. Чтобы более конкретно проиллюстрировать то, что предлагает эта фантастическая книга, я собираюсь продолжить с того места, на котором остановился на прошлой неделе, и более подробно расскажу, какие элементы компьютерной программы могут потребовать очистки.

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

Проект, который я буду рефакторировать для этой статьи, на самом деле является моим завершающим проектом для учебного курса по разработке программного обеспечения Flatiron School, Гнилостный картофель (прошу прощения за банальное название, я действительно ничего не могу с собой поделать). Клон веб-сайта обзоров фильмов Letterboxd, Гнилостный картофель позволяет вам регистрировать просмотренные фильмы, писать рецензии на эти фильмы и подписываться на других рецензентов на сайте. Как фанат Letterboxd и кино в целом, я получил огромное удовольствие от создания этого веб-сайта, и когда он был готов, я действительно почувствовал себя полноценным инженером-программистом.

При этом любой, кто посетил учебный курс по программированию, может сказать вам, что научиться создавать полнофункциональное веб-приложение всего за три недели может быть чрезвычайно напряженным. Я не горжусь этим, но уверен, что за это время написал не очень чистый код, и я рад брать уроки у дяди Боба и его компании. чтобы привести в порядок некоторые из моих работ. Напоминаем, что так важно писать чистый код, потому что время, потраченное на чтение кода, а не его написание, составляет 10: 1. Это особенно важно, потому что я все еще разрабатываю функции для Putrid Potatoes, и любой, у кого есть учетная запись GitHub, может внести свой вклад в мой код, как и любое другое программное обеспечение с открытым исходным кодом. Если мой код будет неясным, это замедлит процесс их разработки и, возможно, развитие сайта. Хуже того, если бы Гнилостный картофель получил значительное количество пользователей и что-то сломалось, исправить это было бы бесконечно труднее, чем если бы я просто написал чистый код! Итак, давайте посмотрим, что мы можем очистить в этой кодовой базе.

Функции

Даже если вы не следуете парадигме функционального программирования, функции, как говорит Чистый код, являются первой линией организации в любой программе. Функции позволяют нам передавать данные через нашу программу, манипулируя ими по нашему желанию и открывая реальную мощь программного обеспечения. Поскольку мы так часто полагаемся на функции в нашем коде, важно убедиться, что мы следуем некоторым передовым методикам. Давайте посмотрим на следующую функцию от Putrid Potatoes, которая следует за другим пользователем в приложении при нажатии правильной кнопки и отправляет этому пользователю электронное письмо с уведомлением об их новом подписчике (с использованием фантастической библиотеки EmailJS):

Хотя используемые здесь соглашения об именах относительно просты, в этом фрагменте кода есть одна серьезная проблема. Как говорит Чистый код, функции должны быть маленькими! Если быть более конкретным, Мартин говорит нам, что это первые два правила функций:

  1. Функции должны быть небольшими.
  2. Функции должны быть меньше этого.

Хотя handleFollowOtherUser может быть намного длиннее - я видел функции в диапазоне от 1000 строк (глоток!) - функции должны быть небольшими кусками, которые мы можем легко понять. Если написание кода похоже на любой другой вид написания, тогда мы хотим, чтобы наши функции служили предложениями, постепенно предоставляя подробности о том, что программа должна делать, как если бы это был роман. Вместо того, чтобы иметь этого 30-строчного бегемота, подобного приведенному выше, наш код был бы значительно более читабельным, если бы он был разбит на несколько более мелких функций:

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

Такой рефакторинг моего кода позволяет нам обсудить еще одну рекомендацию Боба Мартина для наших функций: функции должны делать одно. Раньше handleFollowOtherUser выполнял для нас довольно много операций, анализируя событие, собирая необходимую информацию для создания новых отношений последователь-подписчик, а затем отправляя эти данные в нашу базу данных. Легко редактировать. Хотя мы могли бы абстрагироваться postNewFollowerRelationshipToBackend на все меньшие и меньшие части, я думаю, что в этом случае предпочтительнее хранить всю нашу логику выборки в одном месте.

Хотя я не буду вдаваться в подробности здесь, рекомендации Clean Code по аргументам функций, использованию описательных имен, и сохраните код СУХИМ (Don’t Repeat Yourself) заслуживают внимания Google и, вероятно, станут предметом будущих публикаций в блоге. Несомненно, они уменьшат ваши функции и сделают их более доступными для вашей команды разработчиков.

Форматирование

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

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

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

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

Как видите, GenreFilter() занимает всего 25 строк кода (он также явно выполняет одну функцию и имеет описательные имена, если вы ведете счет). Но почему для наших программ важно Вертикальное форматирование? Давайте посмотрим на следующую диаграмму из Clean Code, которая показывает среднюю длину файла для ряда крупномасштабных производственных приложений:

Как сообщает Чистый код, «маленькие файлы легче понять, чем большие». Вместо того, чтобы прокручивать экран вверх и вниз, чтобы понять, что должен делать наш код, мы можем писать небольшие файлы и разбивать нашу логику на другие файлы, если она становится слишком длинной. Более того, очевидно, что можно создавать полезные приложения, написав ~ 100 строк кода / файла. Чтобы понять эту мысль, Мартин советует нам использовать Газетную метафору. Мы читаем газету вертикально, сначала смотрим на информативный заголовок, затем на синопсис истории в первом абзаце и собираем более подробную информацию по мере дальнейшего чтения ниже. Точно так же наши исходные файлы должны иметь простые, понятные имена, а более подробная информация о файле раскрывается при чтении вниз. Давайте посмотрим на еще один аспект форматирования, на который следует обратить пристальное внимание:

Хотя функциональные возможности allReviews достаточно ясны, здесь, очевидно, есть большая проблема: ширина линии, начинающейся с canLeaveReview, превышает длину экрана! Как и в случае с вертикальным форматированием, программисты также должны обращать внимание на горизонтальное форматирование. Чтобы лучше понять, что я имею в виду, давайте посмотрим на другую диаграмму из Clean Code, показывающую среднюю ширину линии:

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

Хотя отредактированный код по-прежнему довольно широк, самая длинная строка теперь составляет всего 160 символов, что примерно вдвое меньше, чем было раньше. Есть еще много уроков о форматировании, в которые я не буду здесь углубляться, включая Отступ, Горизонтальное выравнивание и Концептуальное сходство. Хотя может показаться, что с форматированием вы просто делаете свой код презентабельным, в написании кода есть серьезная сила, которую другие могут легко прочитать.

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

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