Полезно для проверки качества кода

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

S означает масштабируемость

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

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

Если архитектура программного обеспечения является масштабируемой, остается лишь создать еще одно наследование от базового класса файла доставки и повторно использовать существующие методы экспорта. В противном случае, если масштабируемость не будет соблюдена, придется добавить несколько условных структур (If, Case), как это часто происходит сегодня.

C для сложности

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

Многие профессионалы рекомендуют отличную практику, чтобы выработать привычку программировать «для людей», а не для машин. Это предполагает изменение мышления.

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

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

R для устойчивости

Вы знаете, что означает «отказоустойчивость»? Это синоним «выздоровления». Устойчивый боец ​​принимает удар и быстро встает, чтобы продолжить бой. Буква «R» в SCRAP означает, что программное обеспечение также должно вести себя таким же образом.

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

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

A для API

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

Имея это в виду, мы можем сказать, что когда мы делаем API доступным, наши клиенты сами являются разработчиками, вы согласны?

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

У меня были проблемы с реализацией некоторых интерфейсов из-за избытка методов (многие из них с похожими именами) и неточности документации. Эти интерфейсы похожи на плохо изготовленные продукты.

P для производительности

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

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

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

Больше контента на plainenglish.io