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

Программисты тратят большую часть своего времени на чтение кода, написанного кем-то другим. Чтобы сделать правильную интерпретацию такого кода, им нужно убедиться, что они понимают, что хотел передать автор. Обычно гораздо сложнее, если то, что вы сделали, не читается. Вот почему в Accesto мы придерживаемся принципов ЧИСТОГО КОДА.

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

Грэди Буч, редактор журнала Software Development, однажды сказал, что чистый код читается как хорошо написанная проза. А, как известно, любая письменная форма должна иметь определенную, удобочитаемую и понятную структуру, чтобы ее можно было хорошо прочитать. В противном случае читатели могут сделать вывод, что произведение было написано кем-то, кто не знает предмета, или кем-то, кому все равно. То же самое и с программированием. Если мы хотим, чтобы наша аудитория, то есть другие программисты, могла читать наш код, мы должны следовать определенным правилам. Эти правила, конечно же, называются CLEAN CODE.

Так что же такое ЧИСТЫЙ КОД? Самое известное определение принадлежит Роберту С. Мартину (он же дядя Боб), который написал:

«Чистый код — это код, который легко понять и легко изменить»

Но что это означает? Короче говоря, это означает, что ваш код должен быть читабельным, простым для понимания и позволять легко вносить изменения. Вы можете достичь этого результата, если будете придерживаться нескольких правил и общих хороших практик. Среди прочих (а их много) есть два толковых и простых:

  • СУХОЙ = не повторяйся
  • KISS = Не усложняй глупость

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

Почему важно писать чистый код?

  1. Как только мы поймем структуру кода, в будущем будет легче исправить любые ошибки.
  2. Читаемый код значительно сокращает время, необходимое для написания чего-либо нового.
  3. Создание читаемого кода отражает ваше отношение к нему, потому что вы можете гордиться своей работой.
  4. Включение чистого кода в ваши существующие проекты позволит вам увидеть разницу в качестве вашей работы.
  5. Избегание кода, который заставляет людей чувствовать себя запутанными, создает меньше технического долга в проектах.
  6. Если вы не сделаете свой код чистым, у вас не будет много времени, чтобы исправить его позже, и это определенно приведет к неприятным последствиям.
  7. Ваш код представляет вас, поэтому в будущем, когда вы снова встретитесь со своими коллегами в другом проекте, качество вашей работы может повлиять на то, будут ли ваши коллеги открыты для работы с вами и вашим кодом.

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

Пишем чистый код — 7 полезных идей для читаемого кода

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

1. Подумайте о других людях в вашей команде

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

2. Создавайте многоразовый код и избегайте копирования и вставки

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

Повторное использование функций вместо копирования блоков кода

В 1999 году Энди Хант и Дэйв Томас написали книгу под названием «Прагматичный программист», в которой они описали принцип DRY («Не повторяйся»). Это очень известная концепция, согласно которой программисты должны избегать повторяющихся шаблонов и строить код таким образом, чтобы он был прозрачен для других.

3. Оставьте свой код немного лучше, чем вы его нашли

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

4. Старайтесь, чтобы ваши модули, классы и функции были небольшими

Вы когда-нибудь слышали, что маленькое красиво? Это особенно верно, когда дело доходит до… кода 😉 Размер может быть чем-то, что отличает хороший код от плохого. Некоторые люди склонны создавать большие фрагменты кода, которые являются общими, надежными, гибкими и… нечитаемыми. Между тем гораздо проще тестировать, анализировать и поддерживать небольшие фрагменты кода. Короче говоря, чтобы писать хороший код, вы должны следить за его усвоением. Поэтому хорошей идеей будет разбивать части проекта на более мелкие компоненты, классы и модули, что повышает читабельность и способствует тому, что другим людям просто проще работать с нашим кодом. Чтение сотен строк сложного логического кода может стать настоящим кошмаром. Вот почему хороший мастер программного обеспечения пишет функции, которые являются небольшими и легко читаемыми одновременно. Обычно много маленьких функций лучше, чем несколько, но больших — вы можете использовать это как эмпирическое правило.

Источник: pragprog.com

5. Поддерживайте единый стиль кода

Здесь хорошая аналогия — написание книги. Авторы мировых бестселлеров являются мастерами создания и использования своего стиля, который не только позволяет им выделиться среди других авторов, но и позволяет им привлечь и удержать внимание читателя. Если автор несколько раз менял свой стиль в своей книге, он мог внести диссонанс в читателя. То же самое и с написанием кода. Для написания чистого кода очень важно форматировать код согласованным образом. Отсутствие определенного стиля для форматирования кода может привести к тому, что кто-то, кто использует то, что вы создали, должен будет догадаться, для чего нужны изменения. Это, в свою очередь, может удлинить процесс. Последовательность в стиле позволяет другим избежать путаницы.

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

Подробнее на editorconfig.org

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

6. Доверяйте своим чувствам по поводу кода

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

7. Используйте вторую пару глаз

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

100% чистый код?

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

Устали от плохо написанного кода?

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

Присоединяйтесь к нам: https://accesto.com/career/

Первоначально опубликовано на https://accesto.com.