Изучите быстрые советы по рефакторингу программного обеспечения, чтобы избежать технических долгов.
Обзор
Как инженеры-программисты; или начинающих программистов, мы постоянно пишем новый код, который улучшает или вводит новые функции в приложение. Это может быть сторонний проект или программное обеспечение корпоративного уровня. По мере того, как приложение растет и в команду вводятся новые инженеры, кодовая база может стать очень беспорядочной и сложной в обслуживании, что приводит к техническим долгам, которые могут привести к потере сотен рабочих часов и тысячам корпоративных долларов. В этом сообщении блога я остановлюсь на четырех ключевых методах рефакторинга: ремонтопригодность, удобочитаемость и понятность, простота и тестируемость.
Что такое рефакторинг
В программной инженерии рефакторинг - это процесс написания в электронном виде некоторых частей приложения с целью улучшения его текущего состояния. Это обычно вызвано ошибками или несоблюдением определенных руководящих принципов и соглашений. к крайнему сроку. Давайте теперь углубимся в четыре фактора, на которых я сосредоточился при рефакторинге своего приложения 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 или Портфолио.