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

Почему постоянство важно?

Согласованность имеет решающее значение, когда речь идет о качестве кода, потому что согласованность ведет к предсказуемости. Решение с высокой степенью качества будет предсказуемо в своем функционировании. Вы сможете просматривать код, и без каких-либо знаний предметной области вы должны иметь довольно хорошее представление о том, что происходит. Цитируя Роберта С. Мартина, автора превосходной книги «Чистый код», «вы понимаете, что работаете над чистым кодом, когда каждая процедура оказывается почти такой, как вы ожидали».

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

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

Как можно улучшить согласованность?

Есть несколько жизненно важных факторов, на которых вы можете сосредоточиться, когда дело доходит до улучшения качества кода за счет согласованности.

Интервалы и отступы

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

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

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

Именование переменных и регистр

Существует множество различных способов именования переменных. От сложных для понимания однобуквенных переменных до переменных с семантически именованными именами есть над чем подумать.

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

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

Архитектура

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

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

Согласованная архитектура — это то, что нужно планировать. Если вы попытаетесь сделать это в произвольном стиле, вы, скорее всего, получите непоследовательное объединение различных шаблонов, которые не обязательно смешиваются. Чтобы избежать этого неприятного состояния, вы должны иметь довольно четкое представление о том, какую архитектуру приложения вы собираетесь использовать, прежде чем начинать писать код. В этом случае также не помешает записывать архитектурные решения, используя что-то вроде метко названного Записи архитектурных решений (ADR). Это действует как своего рода документация по архитектуре и может помочь объяснить другим в дальнейшем, почему были приняты те или иные решения, какие альтернативы были рассмотрены, и другие полезные фрагменты информации, подобные этой.

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