что такое хороший код

Главные характеристики качественного кода

Как часто вы поражаетесь, читая чужой код, и думаете «господи, ну и каша. ». Скорее всего, достаточно часто. И можете ли вы быть уверенным, что никто не думал также когда читал ваш код? Другими словами, насколько вы уверены в чистоте своего кода? Можно быть уверенным только если полностью понимаешь, что значит чистый код.

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

1.Плохой код делает слишком много, чистый код сфокусирован

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

Но я бы не ограничивал определение классами. В свой последней статье Ральф Вестфал (Ralf Westphal) представил более широкое определение принципа единственной обязанности:

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

Если хотите узнать больше, то советую прочитать его статью.

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

Не язык делает программу простой, а программист, который делает так, что язык выглядит просто.

(цитата Роберта C. Мартина)

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

3. Не нужно избыточности

Код должен подчиняться правилу DRY (Don’t repeat yourself — не повторяйся). Если это так, то модификация любого элемента системы не требует изменения других, логически не связанных элементов.

4. Читать ваш код должно быть приятно

Когда читаешь ваш код, должно быть ощущение, что читаешь «Гарри Поттера» (да, знаю, я немного переборщил). Должно быть ощущение, что его написали, чтобы любой разработчик мог с легкостью прочитать, не проводя часы в попытках разобраться.

Для этого нужно стараться подчиняться принципам KISS (Keep It Simple, Stupid!) и YAGNI (You Ain’t Gonna Need It — Вам это не понадобится). Принцип KISS гласит, что большинство систем работают лучше всего если сохранять их простоту, а не развивать сложность.

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

5. Другой разработчик может легко расширить ваш код

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

6. Нужно минимизировать зависимости

7. Меньше — лучше

Код должен быть минимальным. Классы и модули должны быть короткими, в идеале — всего несколько строк кода. Код должен быть хорошо разделен (в том числе внутри класса). Чем лучше вы делите код, тем легче его читать. Этот принцип хорошо влияет на пункт 4 — другим программистам будет проще понять его.

8. Необходимы юнит- и приемочные тесты

Как можно узнать, удовлетворяет ли наш код требованиям, если не писать тесты? Как можно поддерживать и расширять его, не боясь, что все сломается? Код без тестов — просто не чист. Если хотите узнать больше о принципах юнит-тестирования, то советую прочитать очень хорошую статью Three Pillars of Unit Tests, написанную одним из моих коллег.

9. Код должен быть выразительным

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

Так что же такое чистый код?

В целом, одно последнее качестве можно назвать итогом всего вышесказанного:

Чистый код написан тем, кому не плевать.

цитата Майкла Фетерса (Michael Feathers).

Он написан тем, кто относится к коду как к искусству, и кто обращает внимание на все детали.

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

Источник

Как важно писать хороший код

Мне приходится очень много читать код. Это и open source, и всяческие фреймворки, и код enterprise приложений. Именно о последних я хотел бы сегодня поговорить.

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

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

Теория разбитых окон

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

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

Есть также и обратный эффект. Поддержание порядка приводит к тому, что окружающие также поддерживают порядок.

Как это влияет на код

В enterprise разработке прессинг сроков и неопределенности требований бывает настолько высок, что кажется сделать “быстро и грязно” – гораздо лучший вариант, чем сделать правильно. Моментально подход “быстро и грязно” начинает распространяться по всему приложению, как путем clipboard inheritance (aka copy-paste), так и за счет эффекта разбитых окон.

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

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

В open source и продуктовой разработке такое встречается реже. Там больше следят за качеством и меньше прессинг сроков.

Код пишется для людей

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

Хороший код должен, в первую очередь, очень ясно выражать намерения. К сожалению “быстрые и грязные” способы разработки бьют в первую очередь по понимаемости кода. Улучшение кода осознанно откладывается до лучших времен, когда будет пауза чтобы провести рефакторинг. Те самые лучшие времена никогда не наступают, а код начинают читать и дорабатывать сразу же после попадания в source control.

Даже если вы полностью довольны свои кодом (в большинстве случаев программисты свои кодом довольны), то подумайте о том как будет ваш код читать другой человек (в большинстве случаев программисты недовольны чужим кодом).

Приверженность качеству

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

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

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

Если вам приходится править код, то не создавайте хаков. Потратьте немного времени, напишите нормально. Сэкономите на поддержке. Если же код совсем плохой, был сделан “быстро и грязно” и оброс хаками, то просто выкиньте его и перепишите. Только не надо пытаться переписать все. Учитывайте продуктивность: программист пишет 40-60 отлаженных строк кода в день в нормальном темпе и 120-200 в ускоренном (высокая концентрация, четкая цель, понятно что делать).

Если вы сами пишете “быстро и грязно”, например прототип для уточнения требований, то выкиньте код и перепишите нормально сразу после того, как ваш код сделает свое дело.

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

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

Перечитывайте свой код. Проводите рефакторинг постоянно в процессе написания. Помните, что рефакторинг “потом” никогда не наступает.

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

Экономика качества кода

Все знакомы с кривой стоимости ошибки:

Ошибка найденная и устраненная на этапе кодирования в 10 раз дешевле, чем ошибка найденная при тестировании и в 100 раз дешевле ошибки, найденной в production. В истории есть реальные примеры ошибок, исправление которых обошлось в десятки тысяч долларов.

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

Источник

Главный принцип хорошего кода

За двадцать лет разнообразного программирования я сформулировал, убежден, главнейший принцип хорошего кода. Опираясь на него, мне и моим коллегам удавалось приводить в порядок самый страшный код, объединять в команде малосовместимых программистов и годами поддерживать системы без лишнего нытья.

Прочтение этой статьи: 15 минут
Осмысление методики: 10 минут
Ощутимые результаты: 30 минут

Зачем?

Что можно сказать о плохом коде?

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

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

Я убежден, что понятность кода в большей степени зависит от названий. От названий классов, методов, переменных. Чем четче сформулированы имена, и чем их больше — тем легче читается код.

Например, есть вот такой код для отсылки уведомления на мобильное устройство:

Вроде кажется, что это более-менее чистый код. Но это только так кажется.

Следовательно, нам нужен простой способ писать легкочитаемый код. Желательно — механический. Некая методика, которую может применить и профессиональный и юный программист; пригодная для утра и для вечера, для существующего и для нового кода. Методика, дающая гарантированный результат.

Такая методика существует.

Все, что можно отделить и назвать — должно быть отделено и названо.

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

В начале этого метода идет отдельный кусочек кода, который решает отдельную задачу, дает ответ на отдельный вопрос: “можно ли найти девайс?”

Этот код можно отделить и назвать:

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

Идем дальше. Давай посмотрим внутрь isLocatable(). В начале видим тоже самое: в этом методе есть два алгоритма, которые отвечают на совершенно разные вопросы:

Этот код уже похож на нормальную английскую речь. Его когнитивная нагрузка очень низкая: читая метод isLocatable() ты видишь, какое он принимает решение и фокусируешь свое внимание только на высоком уровне. Читая isDeviceExpired(), ты понимаешь, как это решение принимается и твое внимание сосредоточено на конкретных данных.

Этот код уже не требует анализа — его достаточно лишь только прочитать.

Заодно, кстати, ты узнал что означает, когда token пустой. Обрати внимание, каким элегантным и надежным способом это знание закреплено в проекте: названием метода.

Ах да, заметь: этому коду уже не нужны комментарии. Instant win!

Почему?

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

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

* 300ms — средняя скорость переключения контекста мышления по разным оценкам и исследованиям.

Примеры

Два алгоритма: один читает конфигурацию в одном из двух вариантов (множественный и единичный), второй находит корневой каталог проекта. Разделяем и даем имена:

Код поиска картинки в мобильном приложении на iOS:

Если картинки нет, то нужно взять общую картинку. Результат положить в кэш. Разделяем:

Распиливаем данные из SQL в память. Я этот код писал сам год назад, а сейчас, когда искал примеры для статьи, долго пытался понять, что вся эта каша делает.

Собираем XML для беседы с Amazon S3. Поскольку мы точно знаем, какие данные мы туда кладем, то XML создается вручную:

Теоретически это довольно понятный код, но давай его упростим:

Альтернативное мнение

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

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

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

Как внедрить

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

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

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

Update: убрал конструкции вида «if (true) return true» из примеров, т.к. суть статьи не в этом, но каждый считает своим долгом прокомментировать этот момент.

Источник

Что такое хороший код? Считаем звёзды

Никогда такого не было, и вот опять! Опять на прошлой неделе на Хабре появился (и был очень активно комментирован) пост, ныне удалённый, о том, что такое хороший код и чем он отличается от плохого. Яндекс подсказывает, что публикаций о хорошем (вариант: отличном, идеальном, правильном, чистом, грязном, плохом и т.д.) коде здесь уже десятки и сотни, появляются они стабильно на протяжении многих лет, всегда активно обсуждаются, но к единому мнению на этот счёт так и не пришли.

Этот код тянет как минимум на одну звезду 🙂

Такой код в настоящее время распространён повсеместно. Причин этому несколько, вот наиболее заметные:

Массовая цифровизация, из-за которой техзадания программистам ставят люди, далёкие от IT (например, руководители заводов) и они в принципе не могут оценить качество кода.

Высокие зарплаты в IT активно привлекают всех-всех-всех, которые трудоустраиваются, пройдя курсы «вайти-вайти за месяц» и имея соответствующие навыки.

Справедливости ради: не всегда это плохо. Если разработка маломасштабная, то её и оптимизировать особо незачем (и так летать будет, ну ведь правда же!). Так или иначе, такой код обычно пишут начинающие программисты и по мере обретения опыта переходят на уровень выше.

Код, который не просто работает, но ещё и работает достаточно быстро. Можно сказать, что этот код оптимизирован по процессорной вычислительной мощности. Одно из формальных определений:

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

На практике эффективность по времени иногда определяется не по этому учебно-тренировочному критерию, а по объективным целям и задачам проекта, и может быть задана как относительно («на каждый N не больше k»), так и абсолютно («открывать окно не дольше 0,5 секунды») или даже субъективно («не менее 80% опрошенных согласились, что программа открывается мгновенно»).

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

Код, который сам имеет минимальный объём. Можно сказать, что он оптимизирован и по процессору, и по оперативке, и по накопителю.

Обычный программист может при желании слегка усечь объём кода: заменив повторяющиеся куски на функции, используя однобуквенные переменные или даже через #define заблаговременно переименовать все команды языка в более краткие, если это оказывается выгодно. Однако всё это, конечно, баловство, которое приносит минимальный результат и в целом скорее вредит. Для того, чтобы принципиально сократить код путём его полной переработки, требуется очень высокая квалификация.

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

Выводы

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

Источник

Как писать чистый код?

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

Брэм Коэн, автор BitTorrent, писал: «То, что мог бы написать любой идиот, обычно имеет качество написанного идиотом». И действительно, несмотря на постоянное пополнение рядов программистов, качеством кода могут похвастаться не все.

Отличительные признаки хорошего кода:

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

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

Источник: Cyanide and Happiness

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

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

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

Иногда перенос блоков кода в комментарии объясняется благими намерениями программистов: мало ли, кому он может понадобиться в будущем. Например, это происходит, когда часть программы полностью переписывается, но перечеркивать проделанную работу жалко – вот она и пылится в комментариях месяцами. Если часть кода можно убрать, то это нужно сделать.

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

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

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

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

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

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

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

Источник