Хороший код, вне зависимости от используемого языка программирования, должен хорошо читаться, быть масштабируемым, понятным другим разработчикам. Но должен ли он быть актуальным? Если да, то какое время необходимо сохранять актуальность и как этого добиться? Большинство начинающих программистов не до конца понимают, что такое “хороший” код, поэтому постараемся в этом разобраться, а также узнаем, нужно ли заморачиваться с составлением кода, который не потребуется менять и через 10 лет.

Техническая база

Вообще, если код нормально работает, то его и не требуется менять, хоть через 10, хоть через 100 лет. Однако есть другая проблема, на которую невозможно повлиять – моральное устаревание как самого продукта, так и версий языков программирования, на которых он написан. Код, написанный 10 лет назад вполне может быть рабочим и масштабируемым, но вот на вызовы времени ему становится все сложнее отвечать, поэтому некоторая часть дописывается или заменяется. Исключением может быть какая-нибудь базовая структура, не претерпевшая серьезных изменений в течение времени, например, HTML.

HTML-каркас, созданный в конце 90-х будет нормально работать и масштабироваться даже сейчас. Однако тут другая проблема – каркас создавался под дизайн и расположение блоков, которое было актуально на конец 90-х годов. Да, тогда уже были базовые представления о дизайне веб-страниц, но тем не менее, натягивать на HTML-каркас, созданный в то время, современный дизайн страниц не всегда просто. Иногда проще его переработать или вовсе написать новый каркас.

“Вечный” код не нужен?

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

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

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

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

Как написать код, который не потеряет актуальность через 10 лет

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

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

Читаемость кода

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

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

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

Соблюдение иерархии с помощью табуляции и пробелов в HTML-каркасе

  • Не злоупотребляйте сокращениями. Некоторые команды можно записывать с помощью сокращений. Здесь нужно быть осторожным, так как сильно большое количество сокращений усложняет восприятие, а иногда может приводить к ошибкам. Правда, в некоторых языках программирования, например, JavaScript, принято использовать библиотеки с сокращениями (для того же JS это JQuery). В таком случае лучше наоборот использовать только сокращения. В других случаях используйте сокращения с умом, чтобы они не осложняли восприятие кода посторонним человеком.
  • Отделяйте блоки кода друг от друга. Обычно для этого используется пустая строка. В некоторых случаях используется иерархическая система разделения, например, отделение блоков кода внутри родительского блока одной строкой, отделение родительских блоков двумя пустыми строками.
  • Пишите понятные комментарии. Каждый блок и основные функции желательно прокомментировать. В комментариях нужно вкратце указать, за что они отвечают. Правда, не нужно вдаваться в крайности и комментировать все подряд и/или давать слишком развернутый комментарий – вполне будет достаточно пары слов.
  • Давайте корректные имена переменным. Из названия переменной должно быть примерно понятно, за что она отвечает.

Отделение блоков и дача комментариев к ним в CSS-документе

Оформление документации

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

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

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

Общие правила оформления кода

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

Избегайте двусмысленных наименований

Не давайте имена переменным, которые могут вызывать путаницу. Например, в объекте перечисляется список, но сам объект относится к другому классу. В этом случае лучше в названии объекта не употреблять “list” или другие подобные слова, так как они могут вызвать неясность. Это слово будет разумнее использовать в названии как раз списка, а не объекта, в котором он находится.

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

Имя удобно искать автоматическим поиском

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

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

Выбирайте правильную часть речи

Для классов и объектов рекомендуется использовать существительные или комбинацию из нескольких существительных. Пример: Sidebar, CSSParser, AccountPage. Методы и функции лучше записывать глаголами или их производными формами: replace, delete_folder.

Правила работы с функциями

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

Компактность функции

Она не должна занимать много места. Даже сложную функцию можно упростить. Их будет проще считывать и понимать предназначение, а также логику работы. Еще в 80-х годах среди разработчиков был принят негласный стандарт размера функций – она должна была помещаться на один экран. Экран компьютеров того времени вмещал примерно 20-30 строк. Конечно, это не значит, что вам нужно укладываться в эти значения, но желательно, делать так, чтобы функция была не больше 50 строк.

Пример экрана компьютера начала 80-х

Минимизация блоков с условиями

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

Одна функция – одна операция

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

Ограничение аргументов

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

Заключение

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