Что такое грязный код
Рефакторинг
Рефакторинг — это контролируемый процесс улучшения кода, без написания новой функциональности. Результат рефакторинга — это чистый код и простой дизайн.
Грязный код является не только результатом лени и невежества, но и побочным продуктом частых изменений в процессе разработки.
Чистый код — это код, который просто читать, понимать и поддерживать. Чистый код улучшает предсказуемость разработки и повышает качество продукта.
Пошаговые изменения, сопровождаемые частыми запусками тестов — это то, что делает процесс рефакторинга эффективным и безопасным.
Запахи кода — это индикаторы проблем, на которые нужно обращать внимание при рефакторинге. Часто их легко найти и исправить, но иногда они предвещают о глубинных проблемах с кодом.
Техники рефакторинга описывают конкретные методы борьбы с грязным кодом. Большинство рефакторингов имеет как достоинства, так и недостатки. Поэтому любой рефакторинг должен быть мотивирован и обдуман.
21 запах кода, 66 рефакторингов
Живые примеры на Java/C#/PHP
Никаких лимитов по времени
Что такое плохой код и что с этим делать
Что такое качество кода, как его улучшить, и почему иногда хороший код — это плохо. Статья подготовлена на основе нашего вебинара с Глебом Михеевым.
Плохой код — как плохой ремонт. Работать может и даже работает, но плохо и недолго, выглядит так себе и исправить в нём что-то непросто. Он хаотичен, имеет непонятную структуру, и вообще не сразу поймёшь, что же хотел сказать автор.
В бэкграунде — программирование, французский язык, академическое рисование, капоэйра. Сейчас учит финский. Любит путешествия и Балтийское море.
Признаки некачественного кода:
Вот такой логикой, как на картинке, всё-таки лучше не пользоваться: если программа работает, это ещё не значит, что с ней всё в порядке.
Чем грозит проекту плохой код
На первый взгляд, плохой код — не катастрофа. Программа же работает, разве это не главное? На самом деле он приносит много проблем, особенно в долгосрочной перспективе. И вот почему:
В итоге скорость разработки снижается, сроки удлиняются, стоимость изменений растёт. Если это критично для потребителя или заказчика, то плохой код может похоронить проект.
Как писать хороший код
Чтобы писать качественный код, надо знать, что он из себя представляет. Вот его основные качества:
Комментарии действительно очень важны, чтобы код легко читался. Это поможет не только другим программистам, когда они будут работать с вашим кодом, но и вам в будущем.
Подробнее почитать об этом можно здесь: Как писать техническую документацию для программ на C#
Вот пять действий, которые улучшают код.
Почему конструкторы сайтов выдают плохой код?
Пишу эту статью, потому что верстальщикам и программистам приходится все чаще и чаще сталкиваться с результатом работы подобных сервисов. Также приходится испытывать конкуренцию с их стороны – как минимум в сегменте недорогих сайтов. И нет более-менее фундаментальной статьи, в которой конструкторы сайтов рассматриваются под этим ракурсом. Будет полезно знать, что является причиной плохого кода и есть ли перспективы у конструкторов заменить массовую ручную верстку, или все это игрушки, не имеющие никаких перспектив.
Для того чтобы классифицировать причины, по которым код получается плохим, нужно привести небольшую классификацию самих конструкторов по возможности кастомизации. Их условно можно разделить на 2 группы: шаблонные и со свободным редактированием. В этой статье я буду рассматривать только сервисы со свободным редактированием, так как в шаблонных конструкторах сайты разрабатываются вручную с определенной спецификой, которая позволяет эти сайты потом редактировать в конструкторе. Но несмотря на это практика показывает, что в большинстве случаев он тоже испорчен.
Мы будем рассматривать причины плохого кода как в HTML, так и в CSS. Но фундаментом плохого кода является CSS, поэтому начнем с него.
Причины, делающие CSS плохим:
1) Position:absolute. Это когда все элементы на странице имеют свойство position в значении absolute. Эта причина является фундаментом, на котором основываются все остальные. При значении absolute нет возможности получить качественный код, что бы не делали разработчики такого сервиса. До недавнего времени (до необходимости создания responsive-дизайна), несмотря на грязный код, такой подход был немного оправдан, потому что он позволял пользователю сервиса свободно перемещать элементы по странице. Сейчас же, когда необходимо, чтобы сайт создавался с responsive-дизайном, использование position:absolute не оправдано ни с какой стороны, потому что при absolute нет возможности создать сайт с responsive-дизайном.
В последние 3 года появляются сервисы, которые, с одной стороны, позволяют кастомизировать сайт без ограничения, но при этом на странице элементы находятся в position:static, что позволяет получать чистый код и хороший responsive-дизайн; но обратной стороной является сложность работы в таких сервисах, потому что нельзя свободно передвигать элементы по странице. Получается у нас выбор: либо absolute – пользователю легко работать, но грязный код, либо responsive – тяжело работать, но при этом чистый код. Сейчас использование absolute не оправдано, поэтому нужно у элементов использовать static.
2) id вместо class. Если у элементов используются id вместо class, то код тоже не будет чистым. Причиной этому является то, что он будет дублироваться в CSS, и с таким кодом будет работать сложно. Эта ситуация характерна, когда у элементов position:absolute, но при position:static тоже иногда встречается. Когда у absolute не используются class, то это необходимость, когда у static – это ошибка разработчиков, потому что static позволяет заменить id классами, что в свою очередь дает более чистый код, с которым можно работать вручную.
Это 2 основные причины, из-за которых конструкторы сайтов выдают грязный CSS. Но есть и другие.
3) Не очищаются лишние стили. Например, во всех селекторах одни и те же стили, которые не имеют смысла: border:none, posiiton:static и т.д. Если эти стили и нужны, то они должны быть прописаны для всех, а не для каждого элемента.
4) Дублирование стилей на разных экранах. Например, на компьютере стоит margin: 45px auto 0 auto, а на мобильном – margin: 25px auto 0 auto. Можно на мобильном просто написать margin-top: 25px.
5) Запись стилей в не сокращенном формате. Такие стили margin, padding, background, font должны записываться в сокращенном виде. Например, вместо margin-top: 10px, margin-left: auto, margin-right: auto можно просто написать margin: 10px auto 0 auto.
Это причины, которые делают грязным CSS. Теперь мы разберем причины, делающие HTML плохим:
1) Стили в атрибуте style. У тегов стили прописаны в атрибуте style, а не вынесены в файл CSS. Если разработчики конструктора прописывают стили в атрибуте style, то помимо грязного кода есть и другие последствия:
— нельзя будет использовать классы – только id;
— нормального responsive-дизайна точно не получится: возможно только с использованием костыля в виде JS.
2) Class или id генерируются автоматически и их нельзя изменить. Они не несут смысловой нагрузки, имея следующий вид Только этого одного пункта достаточно, чтобы испортить весь код.
3) Большая вложенность. Лишние обертки тегов, которых при ручной разработке не должно быть, потому что они не имеют никакого смысла.
4) Нет форматирования кода.
5) Лишние атрибуты и классы. В коде есть много классов и атрибутов, которые не нужны для стилей CSS или работы JS.
Мы перечислили причины в HTML и CSS, которые экспортируемый код конструктора сайтов делают плохим. Теоретически если избежать все ошибки, которые были описаны выше, то можно получить достаточно чистый код на твердую четверку, с которым потом можно будет работать без каких-либо проблем верстальщику или программисту. Конечно, этот код будет немного хуже, чем сверстанный «гуру» верстки, но он будет как минимум не хуже, а порой и лучше, чем сайты, сверстанные в низкой ценовой категории (особенно если они с заявкой на responsive-дизайн).
Что такое «чистый код» в 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 (об этом мы его уже расспрашивали отдельно). Его вариант оказался таким:
«Чистый код — это код, который можно легко разделить на маленькие атомарные составляющие.
«Атом кода» — это наименьший возможный набор инструкций, обладающий самостоятельным смыслом, не зависящие излишне от окружающего контекста: имена переменных и операций достаточно описательные, чтобы читающему их не требовалось выделять в голове дополнительную память для хранения их значений и возможных модификаций, а также не требовалось смотреть ещё куда-то в коде, чтобы понять, что означает результат этого «атома». Чем меньше атомы, тем проще понять, что делает код.
Код может быть чистым вне зависимости от языка программирования или парадигмы: атомы можно реализовать как маленькие объекты, функции, или даже как маленькие фрагменты кода, не изолированные синтаксически».
Заключение
Наконец, когда мнения были собраны, мы показали их самому Дядюшке Бобу и спросили, хочется ли ему что-то сказать. Ответ оказался таким:
«Я полностью поддерживаю комментаторов выше. Я бы добавил только одну вещь, которую когда-то сказал Майкл Фезерс: “Чистый код всегда выглядит так, будто его писал человек, которому не всё равно”».
Его заключение звучит очень дружелюбно. Но чистый код — такая дискуссионная тема, что пока кто-то из вас согласно кивает, кто-то другой наверняка горит, ощущая что-то такое: