Пишем чистый и читаемый код: руководство для начинающих разработчиков
Перевод статьи «The junior developer’s guide to writing super clean and readable code».
Уметь писать код это одно, а уметь писать чистый код – совсем другое. Но что такое «чистый код»? Я создал это короткое руководство как раз для того, чтобы помочь вам разобраться в этом вопросе и овладеть искусством написания чистого кода.
Представьте, что вы читаете статью. Просмотрев вступление, вы можете понять, о чем вообще в ней говорится. Также в ней есть заголовки, за каждым из которых следует по нескольку абзацев. Сами абзацы при этом представляют собой логические смысловые блоки, сгруппированные особым образом: так, чтобы повествование текло плавно и хорошо читалось.
А теперь представьте, что в этой статье нет заголовков. Есть разбивка на абзацы, но они слишком длинные, да к тому же еще расположены как-то странно. Вы не можете бегло просмотреть эту статью. Чтобы понять, о чем она, вам придется очень глубоко погрузиться в ее содержимое. А это может очень раздражать!
Ваш код должен читаться, как хорошая статья. Можете считать свои классы/файлы заголовками, методы – абзацами, а строки – предложениями. Вот несколько характеристик чистого кода:
Переходим к главному вопросу: как же разработчику-джуниору научиться писать такой код? Предлагаю воспользоваться следующими советами.
Используйте последовательное форматирование и отступы
Если бы в книгах постоянно менялись межстрочные интервалы и размер шрифта, а строки переносились, как автору в голову взбрело, такие книги было бы очень тяжело читать. То же касается и вашего кода.
Чтобы сделать код понятным и легким для чтения, следите за тем, чтобы отступы, переносы строк и форматирование были последовательными (одинаковыми в рамках одного файла/проекта). Вот примеры хорошего и плохого кода:
Хорошо
Плохо
Вах! А вот здесь много неправильных вещей.
Конечно, в нашем примере все преувеличено, зато хорошо демонстрирует преимущества последовательности в отступах и форматировании. Не знаю, как вам, а мне первый пример читать гораздо легче!
К счастью, есть множество доступных IDE-плагинов, которые могут автоматически форматировать ваш код. Аллилуйя!
Используйте понятные имена для переменных и методов
В самом начале я говорил о том, насколько важна для кода легкость чтения. И одной из вещей, играющих в этом большую роль, является нейминг. Давайте рассмотрим пример хорошего нейминга:
Этот отрывок кода хорош по многим причинам:
Начинающим разработчикам выбирать хорошие имена для своего кода гораздо сложнее, чем кажется. Когда ваше приложение начинает расти, используйте следующие соглашения, чтобы обеспечить легкость чтения вашего кода:
Бонусный совет: если вы не можете придумать имя для своей функции или метода, есть вероятность, что эта функция делает слишком много всего. Разбейте ее на более мелкие! Например, если ваша функция (исходя из того, что она делает) должна называться updateCarAndSave(), создайте два разных метода: updateCar() и saveCar().
При необходимости используйте комментарии
Есть такое мнение, что код должен быть самодокументированным. Это означает, что вместо использования комментариев нужно писать код таким образом, чтобы он и без них хорошо читался. Это разумный подход, и я думаю, он имел бы смысл в идеальном мире. Но поскольку мир программирования далек от идеала, порой комментарии нам необходимы.
Документирующие комментарии это комментарии, которые описывают, что делает определенная функция или класс. Если вы пишете библиотеку, такие комментарии пригодятся разработчикам, которые будут ее использовать. Вот пример из useJSDoc:
Поясняющие комментарии делаются для всех (в том числе и для самого автора в будущем), кому придется заниматься поддержкой, рефакторингом или расширением кода. Часто такие комментарии опускаются в угоду «самодокументированному коду». Вот пример поясняющего комментария:
Ниже приведены примеры комментариев, от которых стоит воздерживаться. Они не имеют большой ценности, могут запутать читателя, да и просто засоряют код.
Просто лишние и бесполезные комментарии:
Забавные или обидные комментарии:
Помните о принципе DRY (Don’t Repeat Yourself – «Не повторяйтесь»)
«Каждая часть знания должна иметь единственное, непротиворечивое и авторитетное представление в рамках системы».
На самом простом уровне это означает, что следует уменьшать количество дубликатов в коде. (Заметьте, я сказал «уменьшать», а не «полностью исключать», потому что в некоторых случаях дублирующийся код это не конец света!).
Дублирующийся код может стать кошмаром в плане поддержки и внесения изменений. Рассмотрим пример.
Допустим, вы на заказ создаете веб-приложение для отдела кадров. Это приложение позволяет админам через API добавлять в базу данных пользователей с указанием их ролей. Есть три вида ролей: сотрудник, менеджер и админ. Давайте рассмотрим несколько функций, которые могут быть при этом:
[javascript]function addEmployee() <
// create the user object and give the role
const user = <
firstName: ‘Rory’,
lastName: ‘Millar’,
role: ‘Admin’
>
// add the new user to the database — and log out the response or error
axios.post(‘/user’, user)
.then(function (response) <
console.log(response);
>)
.catch(function (error) <
console.log(error);
>);
>
function addManager() <
// create the user object and give the role
const user = <
firstName: ‘James’,
lastName: ‘Marley’,
role: ‘Admin’
>
// add the new user to the database — and log out the response or error
axios.post(‘/user’, user)
.then(function (response) <
console.log(response);
>)
.catch(function (error) <
console.log(error);
>);
>
function addAdmin() <
// create the user object and give the role
const user = <
firstName: ‘Gary’,
lastName: ‘Judge’,
role: ‘Admin’
>
// add the new user to the database — and log out the response or error
axios.post(‘/user’, user)
.then(function (response) <
console.log(response);
>)
.catch(function (error) <
console.log(error);
>);
>
[/javascript]
Класс! Все работает и жизнь прекрасна. Но спустя некоторое время клиент возвращается и говорит: «Здравствуйте! Мы бы хотели, чтобы сообщение об ошибке содержало фразу «Произошла ошибка». А также, чтобы вам жизнь сахаром не казалась, мы хотим изменить конечную точку API с /user на /users. Спасибо!»
Итак, прежде чем бросаться писать код, давайте сделаем шаг назад. Помните, в самом начале я сказал, что чистый код должен быть сфокусированным, т. е., делать одно дело, но хорошо? Вот в этом и кроется небольшая проблемка нашего теперешнего кода. Код, делающий вызов API и обрабатывающий ошибку, повторяется. А это означает, что для удовлетворения поменявшихся требований нам придется внести правки в трех местах. Это раздражает.
Итак, что если нам изменить этот код, чтобы он стал более сфокусированным? Посмотрите на следующий вариант:
[javascript]function addEmployee() <
// create the user object and give the role
const user = <
firstName: ‘Rory’,
lastName: ‘Millar’,
role: ‘Admin’
>
// add the new user to the database — and log out the response or error
saveUserToDatabase(user);
>
function addManager() <
// create the user object and give the role
const user = <
firstName: ‘James’,
lastName: ‘Marley’,
role: ‘Admin’
>
// add the new user to the database — and log out the response or error
saveUserToDatabase(user);
>
function addAdmin() <
// create the user object and give the role
const user = <
firstName: ‘Gary’,
lastName: ‘Judge’,
role: ‘Admin’
>
// add the new user to the database — and log out the response or error
saveUserToDatabase(user);
>
function saveUserToDatabase(user) <
axios.post(‘/users’, user)
.then(function (response) <
console.log(response);
>)
.catch(function (error) <
console.log(«there was an error » + error);
>);
>
[/javascript]
Мы перенесли логику, создающую вызов API, в ее собственный метод saveUserToDatabase(user) (хорошее ли это имя? Вам решать!). Этот метод будут вызывать другие методы, чтобы сохранить пользователя. Теперь, если нам снова нужно будет изменить логику API, нам придется внести правки лишь в один метод. Более того, если нам нужно будет добавить другой метод, создающий пользователей, у нас уже будет готовый метод для сохранения пользователя в базе данных через API. Ура!
Пример рефакторинга с применением полученных знаний
Давайте закроем глаза и представим, что мы делаем приложение «Калькулятор». В нем есть функции, позволяющие соответствующим образом складывать, вычитать, умножать и делить. Результат выводится в консоли.
Вот, что у нас есть на данный момент. Давайте посмотрим, сумеете ли вы самостоятельно выявить проблемы в этом коде.
[javascript]function addNumbers(number1, number2)
<
const result = number1 + number2;
const output = ‘The result is ‘ + result;
console.log(output);
>
// this function substracts 2 numbers
function substractNumbers(number1, number2)<
//store the result in a variable called result
const result = number1 — number2;
const output = ‘The result is ‘ + result;
console.log(output);
>
function doStuffWithNumbers(number1, number2) <
const result = number1 * number2;
const output = ‘The result is ‘ + result;
console.log(output);
>
function divideNumbers(x, y) <
const result = number1 / number2;
const output = ‘The result is ‘ + result;
console.log(output);
>
[/javascript]
А теперь мы используем то, о чем узнали из этой статьи, чтобы сделать рефакторинг нашего кода. Новый код выглядит так:
[javascript]function addNumbers(number1, number2) <
const result = number1 + number2;
displayOutput(result)
>
function substractNumbers(number1, number2) <
const result = number1 — number2;
displayOutput(result)
>
function multiplyNumbers(number1, number2) <
const result = number1 * number2;
displayOutput(result)
>
function divideNumbers(number1, number2) <
const result = number1 * number2;
displayOutput(result)
>
function displayOutput(result) <
const output = ‘The result is ‘ + result;
console.log(output);
>
[/javascript]
Поздравляю! Теперь вы можете гордо заявлять на собеседованиях и в своем резюме, что знакомы с принципами написания чистого кода!
Не перестарайтесь с «чисткой» кода
Я часто вижу, что разработчики уж слишком усердствуют в том, что касается чистоты кода. Будьте осторожны и не увлекайтесь чистотой кода чрезмерно, чтобы не получить обратный эффект, когда из-за ваших действий ваш код становится тяжелее читать и поддерживать.
Помните о чистоте кода, но не слишком сосредотачивайтесь на ней на ранних стадиях ваших проектов. Сначала убедитесь, что ваш код работает и хорошо проходит тесты. О чистке кода в соответствии с принципом DRY стоит задумываться уже на стадии рефакторинга.
Чистый код: причины и следствия
Автор: Виктор Свирский, Senior Python Developer / Team Lead, DataArt
Сколько программистов, столько и определений, что такое чистый код. Часто, проводя собеседование, я слышу, что хороший код — это такой, который легко читается. Согласен, но как подсказывает мой личный опыт, это только вершина айсберга.
Первый звоночек, который нам сообщает, что код перестает быть чистым — это рост времени разработки новой функциональности и увеличение регрессионного скоупа при малейшем изменении в системе. Это следствие того, что технический долг накапливается, компоненты в системе очень тесно связаны, автотесты отсутствуют. Причины этого могут быть:
Что такое чистый код?
Получается, чтобы сказать, что код чистый и система спроектирована грамотно, легкого чтения кода недостаточно. Он должен обладать и другими качествами:
Стоит ли писать чистый код?
Однозначно стоит! Но не всегда и не везде стоит уделять чистоте слишком много внимания.
Не стоит забывать о целесообразности и сроке жизни вашего кода. Например, если перед вами стоит задача разработки концепции — PoC (Proof of concept), и вы доказываете, что выбранный стек технологий выполняет поставленную задачу, ваш код станет неактуален уже через неделю или две. Не стоит тратить силы на совершенствование этого функционала.
Бытует мнение, что не нужно следить за качеством кода или части системы, которые в скором времени будут заменены. И это неверно по нескольким причинам. Высокое качество исполнения сделает переход или интеграцию с новыми частями более простыми, бесшовными и быстрыми. Оно наверняка упростит жизнь в тех случаях, когда несколько версий кода придется поддерживать одновременно. Количество регрессионных ошибок с чистым кодом будет в разы меньше. Также не стоит забывать, что нет ничего более постоянного, чем временное. Возможно, задачи по улучшению этой части кода еще несколько месяцев будут лежать в бэклоге.
Что поможет улучшить ваш код?
Большинство программистов мечтают писать код быстро и максимально красиво, причем так, чтобы все идеально работало с первого раза. Но далеко не каждому удается сделать код не просто работающим, но и понятным. Как же добиться успеха в написании чистого кода? Есть два пути — самоорганизация и командная работа.
Самоорганизация
Рассмотрим несколько возможных способов улучшить индивидуальное качество кода. Эти рекомендации подойдут разработчику любого уровня.
Не спешите решать задачи в лоб. Задавайте вопросы старшим разработчикам и самому себе. Всегда важно понимать причинно-следственную связь тех или иных решений. Хорошо понимая проблему, вы сможете эффективно ее решить.
Любой опыт лучше, чем его отсутствие.
Командная работа
Большинство задач решается в команде. Очень важно разделять ответственность за качество между ее участниками. Чем больше команда, тем сложнее поддерживать продукт в хорошем состоянии. Рассмотрим несколько подходов удержания кода в вышеуказанных условиях.
Во время проверки кода необходимо учитывать несколько вещей:
Суть непрерывной интеграции в том, что она позволяет быстро получить множество отзывов о текущем состоянии кода.
Непрерывная интеграция работает, когда вы следуете двум простым правилам:
Важно иметь список соглашений о кодировании. Но прежде чем вы начнете составлять список, все в команде должны понимать значимость этого соглашения. Не рассчитывайте, что такое соглашение будет принято с первого раза, вас ожидает множество дискуссий.
Составьте список соглашений о кодировании, в которых вы обозначаете то, как переменные должны объявляться, соглашения об именах и т. д. Количество правил, которые вы можете добавить в этот список, не ограничено и может варьироваться. Просто делайте то, что работает для вас и вашей команды. Не стесняйтесь добавлять новые правила в список соглашений, если команде это подходит. Это же касается и удаления соглашений из списка.
После того, как вы получили свой список соглашений о кодировании, крайне важно придерживаться их. Наиболее предпочтительный способ — проверить соглашения о кодировании с помощью статических анализаторов и непрерывной интеграции, поскольку он не требует каких-либо ручных действий.
Чем меньше ошибок в коде, тем выше его качество. Тщательное тестирование отфильтровывает критические ошибки и гарантирует, что код работает так, как задумано.
Наличие четкой стратегии тестирования важно, когда дело доходит до улучшения качества кода. Как минимум, ваш код должен быть модульным. Еще лучше, если вы хотите использовать и другие способы, например интеграционное или регрессионное тестирование.
Наличие ошибок в вашем коде, вероятно, неизбежно. Поэтому анализ и способ обработки этих ошибок очень важны. Если вы хотите улучшить свои навыки, важно учиться на собственных ошибках.
Когда возникает ошибка, проанализируйте ее с помощью нескольких вопросов:
Есть несколько метрик, которые вы можете использовать для количественной оценки качества вашего кода. С такой задачей легко справляется SonarQube. Он с легкостью поможет вам собрать все необходимо важные метрики:
Используется при тестировании программного обеспечения. Она показывает процент исходного кода программы, который был выполнен в процессе тестирования. Задайте планку, ниже которой процентное соотношение ваших тестов не опускается.
Ошибки в коде чем-то сродни углеродному следу. Избежать совсем невозможно, а лишний выхлоп сам по себе не убьет ни человечества, ни окружающей его природы. Тем не менее, снизить негативный эффект от своего пребывания на планете сегодня кажется естественной потребностью. Примерно так же и написание чистого кода оказывается ответственностью каждого разработчика. Независимо от того, какой именно путь вы выберете, необходимо стремиться писать работающий и понятный код.
Хорошо, если удастся не превращать чистоту в фетиш, учитывая срок жизни нашего кода и оценивая целесообразность дальнейших улучшений. Главное помнить о людях: пользователях, которых может подвести внезапный отказ даже небольшой части разработанной нами системы, и инженерах, которым предстоит эту систему поддерживать.
Что такое «чистый код» в 2020-м?
«Чистый код» и чистый кот
Разработчиков хлебом не корми, дай поспорить о чистоте кода: например, недавно шумиху навёл пост Дэна Абрамова «Goodbye, Clean Code».
Но при этом у самого понятия «чистый код» нет чёткого определения. Главная книга по этому вопросу — «Clean Code», где Роберт «Дядюшка Боб» Мартин сразу заявляет: «сколько программистов, столько и определений». Впрочем, из этого он делает не вывод «говорить об этом бесполезно», а вывод «стоит сравнить разные определения». Поэтому в книге он привёл мнения нескольких выдающихся программистов о том, что такое чистый код.
Нам стало интересно: в 2020-м представления человечества о чистом коде остались теми же, или с выхода книги как-то изменились? Различаются ли мнения у разных айтишников: может, бэкендеры видят всё с одного ракурса, а тестировщики с другого?
А поскольку тема холиварная, наверняка кто-то из вас окажется не согласен с какими-то из мнений. В таком случае айда спорить в комментариях, это тоже весело!
UPD: Когда мы писали эту статью, Роберт планировал приехать на наши конференции. К сожалению, ситуация изменилась. Также из-за запрета на проведение массовых мероприятий мы перенесли конференции на другие даты. Следите за обновлениями на сайте конференции. 13 марта мы обновили этот пост, чтобы он не содержал некорректную информацию.
DotNext
Джон Скит
Джон — легенда Stack Overflow, автор книги «C# in Depth» и один из самых известных дотнетчиков планеты. Он дал нам такое определение:
«Для меня чистый код — это скучный код, с точки зрения имплементации. Единственный сюрприз в нём — это то, насколько он лишён сюрпризов. Я должен чувствовать „Да, я бы мог такое написать”, даже если бы на самом деле я и не мог — по тому, насколько хорошо он спроектирован.
Когда абстракция выбрана верно, имплементация выводится естественным образом. В идеале эта абстракция также должна ощущаться простой и очевидной — хотя на самом деле доведение её до такого состояния могло занять часы, недели, месяцы размышления и экспериментов.
Упомянутое отсутствие сюрпризов позже переносится и на использование: когда я пишу код, используя хорошо спроектированный API, мой код тоже становится очевидным и скучным».
Андрей Акиньшин
Когда мы спросили, что он думает про чистый код, Андрей сослался на два своих старых хабрапоста: «Совершенный код и реальные проекты» и «Комментировать или не комментировать». И мы выбрали для вас пару абзацев оттуда, с которыми кто-то наверняка захочет поспорить:
«Я люблю совершенный код. Ведь это не только правильный подход к написанию программ, но и настоящее искусство. От чтения хорошего листинга я получаю не меньше удовольствия, чем от чтения хорошей книги. Проектировать архитектуру большого проекта ничуть не легче, чем проектировать архитектуру большого здания, а в случае хорошей работы — результат не менее прекрасен. Порой меня завораживает то, как изящно переплелись паттерны проектирования в создании совершенной программной системы. Меня восхищает внимание к деталям, когда абсолютно каждый метод настолько прост и понятен, что претендует на место классического примера совершенного кода.
Но, увы, всё это великолепие разбивается о суровую действительность и реальные проекты. Если мы говорим о продакшн-проекте, то пользователей не волнует, насколько красив ваш код и насколько хороша архитектура, их волнует, чтобы проект хорошо работал. Но я всё равно считаю, что в любом случае нужно стремиться писать правильно, просто при этом фанатизма быть не должно».
Дилан Битти
Хабрачитатели могут помнить Дилана по его вдумчивому и яркому докладу про работу с легаси-кодом: для Хабра мы делали его расшифровку. И когда мы обратились к Дилану по поводу чистого кода, он написал такой развёрнутый и продуманный текст, что его хоть отдельным постом публикуй:
«Для меня интересно, что понятие «чистый код» распространилось далеко за пределы круга людей, читавших книгу Роберта Мартина. Я общался с многими, многими разработчиками, которые слышали слова «clean code», но не читали книгу. Я даже встречал их в кодревью: «Тут всё довольно хорошо, но можешь немного почистить?» — и такая просьба может быть раздражающе неточной, если неочевидно, что «чистый» означает в данном конкретном контексте.
В английском есть слова, которые часто встречаются вместе — «clean», «tidy», «organised», «neat» — и для меня как носителя английского они все означают немного разные вещи. Я думаю, что полезно рассмотреть некоторые коннотации этих слов применительно к разработке софта.
Представим, например, кухню ресторана. У слова «clean» в этом контексте будут очень конкретные коннотации. Всё вымыто, стерилизовано, нет никакой угрозы заражения из-за сырых продуктов, и тому подобное.
Но это не означает автоматически, что здесь всё хорошо организовано. Если вы когда-нибудь пытались приготовить еду у друга или в квартире, снятой на Airbnb, вы знаете, как раздражает, когда вещи не на своих местах. Средство для мытья посуды стоит в буфете, в котором рассчитываешь увидеть кастрюли, а чеснокодавилка вообще непонятно где. Да, всё чистое — нет угрозы, что кто-то отравится едой, приготовленной на этой кухне — но работать в таких условиях раздражает.
А теперь представим деревообрабатывающий цех. В этом месте грязь тоже может вызывать проблемы, но здесь у вас совсем не такое определение «чистоты», как на кухне. Вы можете начищать зубило, пока оно не начнёт сверкать, но вы всё равно вряд ли стали бы резать им сосиски. Так что слово «clean» может быть очень субъективным.
Но для меня слова вроде «tidy» и «organised» работают и таких контекстах, где «clean» не очень хорошо подходит. «Organised» означает, что кто-то как следует подумал, как расположить элементы конкретного рабочего места, а «tidy» означает, что эти элементы действительно находятся на отведённых им местах. Как говорится в старой поговорке, «всему есть своё место и всё на своём месте».
Возможно, в случае с кодом нам стоит думать о словах «clean», «tidy» и «organised» как о трёх разных понятиях. «Clean» означает, что вы смотрите на составные части кодовой базы — методы, функции, интерфейсы — и не видите никаких причин для беспокойства. В именовании придерживаются конвенций; названия переменных и методов написаны без ошибок; в деталях вроде отступов и скобок придерживаются единого стиля; куда ни посмотри, видишь подтверждения того, что на базовом уровне этим заправляют люди, подходящие к делу серьёзно. Это противоположность «грязного кода» — такого, где в названиях куча опечаток, фигурные скобки и отступы захотичны, несоответствующие названия файлов. Это те вещи, которые магически оказываются исправлены, когда вызываешь инструмент «code cleanup» в чём-то вроде ReSharper.
«Organised» — это про архитектуру. Это о том, что можно нырнуть в незнакомую кодовую базу и найти вещи там, где ожидаешь их увидеть. Интерфейсы и доменные границы помогают, а не мешают; методы и переменные названы не просто корректно названы с точки зрения языка, но и отражают единый язык бизнеса, с которым работаешь.
А «tidy» — это про уважение локальных конвенций… кодовая база, в которой можешь найти нужные вещи в соответствующих им местах, даже если конкретная организационная модель вам в этот момент не слишком понятна.
Я думаю, что когда говорят о борьбе за «чистый код», этим обычно подразумевают все три эти вещи. Но ставить целью полностью «чистый код», особенно когда работаешь со сложным легаси-проектом, может быть довольно устрашающей перспективой. Возможно, нам всем было бы полезно задуматься немного глубже и разобраться, что именно из составляющих «чистого кода» по-настоящему принесёт пользу проекту, над которым мы в данный момент работаем».
Heisenbug
Это «конференция по тестированию не только для тестировщиков»: она на стыке тестирования и разработки. Поэтому многие её спикеры понимают специфику обоих этих миров сразу.
Иван Крутов и Анна Чернышева
Иван и Анна работают в разных компаниях, но кое-что их объединяет: оба много знают про Selenium. Мы общались с ними одновременно, так что получилось совместное определение:
Иван: «Для меня самое простое определение чистого кода — это код, который понятен без комментариев, «самодокументирующийся». Код, который завален комментариями, которые пытаются объяснить, что он делает — это не чистый код».
Анна: «У меня похоже: это код, в котором можно быстро разобраться, исправить баг, легко расширить его, дополнить».
Иван: «Ещё можно сказать, что это «код, за который не стыдно». Вообще говорят, что если ты смотришь код, который написал полгода назад, и не ужасаешься, то ты не развиваешься. Получается, что с каждым годом твой код должен становиться всё чище».
Себастиан Дашнер
Себастиан — Lead Java Developer Advocate в IBM, и его часто можно увидеть на Java-конференциях. Но поскольку сейчас он прилетает на Heisenbug, мы спросили его о чистом коде именно в контексте тестирования, и он ответил:
«По моему опыту, качество кода важно не только в случае продакшн-кода, но и для наших тестов. В тестах чистым кодом, правильными абстракциями и делегацией часто пренебрегают, что приводит к такому коду тестов, который не поддержишь. Когда мы рефакторим продакшн-код и меняем его поведение, становится видно, хорошую работу ли мы проделали над моделированием и имплементацией наших тестов».
Андрей Лушников
Андрей работает над инструментом для браузерной автоматизации Playwright, о котором мы недавно писали. Его определение оказалось самым лаконичным:
«Чистый код — это тупой, очень понятный код. И чем тупее, тем лучше».
Александра Сватикова
Александра — эксперт по информационной безопасности в Одноклассниках, которая «начинала в IT как Java-разработчик, но свернула не туда». Её определение оказалось таким:
«Чистый код обладает тремя свойствами: другой разработчик может легко прочесть и понять его, незначительные доработки требуют соразмерных усилий, и эффект от конкретного изменения может быть предсказан.
На деле это означает, что код структурирован, лаконичен, следует общепринятым практикам для того языка на котором написан, не содержит неявных зависимостей или побочных эффектов и покрыт тестами».
HolyJS
Андрей Мелихов
Андрей известен многим по проекту «Девшахта». Неудивительно, что человек, постоянно формулирующий свои мысли в «Девшахта-подкасте», и свою позицию сформулировал чётко:
«Роберт «Дядя» Мартин тремя своими главными книгами («Clean Code», «The Clean Coder» и «Clean Architecture»), как мне кажется, пытается для себя ответить на вопросы: кто, что и как должен писать. Можно поспорить о корректности некоторых его выводов, но вот что, неоспоримо — эти книги построены на богатом личном опыте и здравом смысле. И в рамках этой идеи я могу сказать, что для меня чистый код — это код, который написал бы человек, споткнувшийся о немалое количество подводных камней в своей жизни и в этом болезненном процессе научившийся идти осторожной походкой, позволяющей этих камней избегать.
Вам может быть неудобен стиль этого человека, но если вы будете ему следовать, вы точно останетесь целы. Вы можете взять этот стиль и переработать его, сделать удобным для себя. Или вы можете отчаянно нырнуть в реку набивать собственные шишки, вырабатывать свой собственный стиль, пока остальные будут смотреть на вас с недоумением, двигаясь под присмотром старших товарищей.
Чистый код — это код, который легко читается, легко поддерживается и легко расширяется. Именно эти три аспекта закладывают прочный фундамент под приложениями, которым предстоит жить годами в условиях изменчивости внешних требований. А именно такие приложения мы пишем в крупных компаниях»
Александра Калинина
Александра состоит в программном комитете HolyJS, у неё большой опыт в программировании — и, хотя она не с Heisenbug, с тестами она тоже знакома не понаслышке (unit, integration, E2E, B2B). Вот её текст:
«Clean code — сейчас это простое понятие, но понять его довольно трудно. Мне кажется, что чистый код может получиться при соблюдении следующих правил:
— каждый отдельный кусочек кода должен иметь возможность масштабироваться или расти/улучшаться независимо от других кусочков, но при этом сохранять изначальную идею/интеграцию с другими кусочками (в этом очень помогает SOLID, а также правило «все решения, которые могут быть приняты позже, должны приниматься позже»).
— код должен читаться как увлекательная книга, с понятными типичными названиями и обозначениями. К примеру, если вы задумаете писать рассказ, то у него, вероятнее всего будет типичная структура вроде вступления, завязки, кульминации и развязки. Даже если только вы один работаете на проекте, код должен читаться легко вами же спустя любое время, независимо от выбранной архитектуры, языка, фреймворков.
— код должен иметь понятную структуру. Т.е. должна быть понятна причина, по которой тот или иной кусочек кода находится в проекте.
— каждая строчка кода должна быть обоснована с точки зрения бизнеса»
Nicolò Ribaudo
Николо, будучи ещё студентом, стал одним из ключевых разработчиков компилятора Babel (об этом мы его уже расспрашивали отдельно). Его вариант оказался таким:
«Чистый код — это код, который можно легко разделить на маленькие атомарные составляющие.
«Атом кода» — это наименьший возможный набор инструкций, обладающий самостоятельным смыслом, не зависящие излишне от окружающего контекста: имена переменных и операций достаточно описательные, чтобы читающему их не требовалось выделять в голове дополнительную память для хранения их значений и возможных модификаций, а также не требовалось смотреть ещё куда-то в коде, чтобы понять, что означает результат этого «атома». Чем меньше атомы, тем проще понять, что делает код.
Код может быть чистым вне зависимости от языка программирования или парадигмы: атомы можно реализовать как маленькие объекты, функции, или даже как маленькие фрагменты кода, не изолированные синтаксически».
Заключение
Наконец, когда мнения были собраны, мы показали их самому Дядюшке Бобу и спросили, хочется ли ему что-то сказать. Ответ оказался таким:
«Я полностью поддерживаю комментаторов выше. Я бы добавил только одну вещь, которую когда-то сказал Майкл Фезерс: “Чистый код всегда выглядит так, будто его писал человек, которому не всё равно”».
Его заключение звучит очень дружелюбно. Но чистый код — такая дискуссионная тема, что пока кто-то из вас согласно кивает, кто-то другой наверняка горит, ощущая что-то такое: