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

Обзор

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

Что такое рефакторинг

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

Ремонтопригодность

Gitviwr - довольно сложное приложение, которое работает путем связывания и взаимодействия с несколькими службами: расширением chrome, сервером сокетов и Github SDK. Чтобы над ним работал другой инженер, его необходимо поддерживать в актуальном состоянии.

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

Читаемость и понятность

Если другой разработчик будет искать или работать над Gitviwr, он должен уметь читать кодовую базу на высоком уровне, даже если она написана на незнакомом языке или на незнакомом фреймворке. Я могу разделить это на категории: Читаемость и Понятность.

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

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

В информатике есть только две сложные вещи: инвалидация кеша и именование вещей.

- Фил Карлтон

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

Простота

Одна из замечательных особенностей разработки программного обеспечения - это сообщество с открытым исходным кодом. Написан ли ваш проект на Javascript, Swift или C #; вы всегда можете найти библиотеки и фреймворки, которые сделают или упростят вашу работу. Например, если служба вашего приложения занимается хранением конфиденциальных данных и манипулированием ими, вы можете использовать библиотеку, такую ​​как KeychainSwift или JWT, вместо разработки своей собственной.

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

Тестируемость

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

Функция queryUser нарушит проверку компонента, поскольку она тесно связана с 3 другими функциями. Это означает, что для успешного тестирования этой функции мы также должны протестировать updateViewerCount, emailUser и updateCountOnClient. Чтобы исправить это, мы должны убедиться, что каждая функция выполняет только одно действие и возвращает значение, если это применимо. Приведенный ниже фрагмент кода показывает, насколько улучшена функция queryUser() для тестирования.

Заключение

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

Об авторе :

Меди Ассумани в настоящее время изучает информатику в Make School и разработчик iOS в Сан-Франциско, Калифорния. Вы можете связаться с ним через его электронную почту, LinkedIn или Портфолио.