Методология пятифакторной разработки для создания современных программных систем
Программисты обычно работают с настольными, мобильными, веб-приложениями и встроенными приложениями, используя различные инструменты разработки и зависимости. Между тем, некоторые программисты разрабатывают фреймворки, программные библиотеки, операционные системы и инструменты разработчика для поддержки программистов, разрабатывающих приложения. Каждый программист стремится улучшить качество своих программных систем, чтобы добиться успеха в своих проектах. Если программный продукт поставляется с качественными и стабильными функциями, пользователи будут рекомендовать конкретный продукт другим пользователям — в противном случае они могут найти альтернативы.
Команды разработчиков программного обеспечения используют различные процессы и методы для создания высококачественных программных систем. Все мы знаем о методологии Twelve-Factor App, которая предлагает хорошо структурированную концепцию создания высококачественных продуктов типа программное обеспечение как услуга (SAAS).
В этой статье я объясню пятифакторную методологию разработки для улучшения качества любой программной системы. Вы можете применить эту методологию для создания настольных приложений, мобильных приложений, веб-приложений, фреймворков, библиотек или любого другого программного проекта. Я также использую тот же подход для разработки своих программных проектов.
1. Стабильная и оптимальная архитектура проекта
Программный проект обычно содержит несколько подмодулей или компонентов, и эти модули могут быть внутренними компонентами или сторонними зависимостями. Архитектура программного обеспечения относится к расположению и подключению этих подмодулей. Например, в многоуровневом архитектурном шаблоне мы обычно размещаем подкомпоненты поверх каждого подобного слоя в луковице, чтобы построить всю систему. Посмотрите, как слой движка Flutter использует слой рендеринга Skia для обработки родной прорисовки виджетов:
Архитектура программного обеспечения изначально закладывает основу для программного проекта и позволяет программистам работать над конкретным проектом в течение многих лет. От этого фундамента зависит срок службы всей программной системы, ее ремонтопригодность и успех на рынке. Поздние архитектурные изменения обычно отнимают много времени и средств для любой команды разработчиков программного обеспечения. Другими словами, буквально невозможно изменить фундамент, когда на нем построен дом. Поэтому всегда нужно стремиться выбрать оптимальный архитектурный паттерн с первой попытки реализации.
Действительно, лучше потратить больше времени на ранние архитектурные решения, чем тратить время на исправление побочных эффектов мгновенных неоптимальных архитектурных решений.
Во-первых, работа над основным функционалом программной системы и ее стабилизация — на этом этапе архитектурные изменения не требуют много времени. Затем поработайте над функциями, используя функциональность программного ядра. Даже если вы используете монолитный шаблон, вы можете отделить основную логику от функций на уровне исходного кода, а не на уровне архитектуры. Несколько лет назад мы создавали бессерверную платформу и разделили основную логику на каталог core, как показано ниже:
Кроме того, несомненно важны технические решения, такие как выбор языков программирования и зависимостей — выбирайте их, тщательно обдумав свои требования — не только из-за современной шумихи.
2. Чистая, простая и поддерживаемая кодовая база
Когда у нас будет четкое представление о дизайне архитектуры программного обеспечения, мы сможем приступить к разработке кодовой базы, но есть и другой способ. Мы можем сначала создать работающий программный проект (он же POC), а затем подумать об улучшении архитектурных аспектов. Многие популярные проекты с открытым исходным кодом начинались с этого подхода на основе POC, а затем дорабатывали архитектуру для производственных нужд. Однако нам необходимо разработать чистые, простые и удобные в сопровождении кодовые базы, чтобы в результате получить программное обеспечение хорошего качества.
Над программными проектами обычно работает несколько разработчиков, и им часто требуется обновлять кодовую базу проекта, добавляя функции, исправления ошибок и улучшения производительности. Наличие поддерживаемой кодовой базы повышает производительность каждого и мотивирует всех снова вносить свой вклад в проект. Принципы программирования YAGNI, KISS и DRY учат нас создавать хорошую кодовую базу. Следующая история объясняет эти концепции программирования дальше:
Перед разработкой кодовой базы планируйте с самого начала. Во-первых, подумайте о предпочтительной парадигме программирования — модное ООП не является единственно подходящей парадигмой для современной разработки программного обеспечения. Затем мы можем использовать правильные структуры данных, предпочтительные языковые функции, подходящие программные библиотеки, хороший стиль кода и шаблоны проектирования для написания чистого понятного кода. Сохранение простой кодовой базы с использованием только необходимых шаблонов проектирования и языковых функций устраняет эффект чрезмерной инженерии и мотивирует всех вносить свой вклад в проект.
3. Рабочий процесс DevOps для разработчиков и серверов CI/CD
Раньше программисты использовали ручные процессы для обработки облачных развертываний, создания пакетов выпусков и понимания функций, которые ожидают пользователи. Позже движение DevOps представило автоматические выпуски программного обеспечения, стратегии автоматизированного тестирования и концепции мониторинга приложений, чтобы предоставлять функции программного обеспечения быстрее и качественнее. Следующая история объясняет преимущества DevOps:
Концепции DevOps действительно делают весь процесс разработки программного обеспечения продуктивным за счет автоматизации. Например, разработчикам пришлось скомпилировать одну из наших платформ с открытым исходным кодом, чтобы поэкспериментировать с последними невыпущенными функциями. Но теперь наши автоматизированные рабочие процессы DevOps генерируют ночные сборки каждую полночь с экспериментальными функциями, как показано ниже:
DevOps предназначен не только для улучшения цикла выпуска — он также побуждает нас автоматизировать каждую трудоемкую ручную задачу на протяжении всего жизненного цикла разработки программного обеспечения (SDLC). Например, мы можем использовать принципы DevOps для повышения удовлетворенности клиентов за счет автоматического создания невыполненных задач спринта на основе событий мониторинга приложений.
В некоторых сценариях мы можем повторно использовать сценарии DevOps, ориентированные на CI/CD, в локальных средах разработки, а также повысить производительность разработчиков. В рабочих процессах DevOps часто может происходить чрезмерное проектирование, поэтому нам необходимо внедрять автоматизацию, когда нам требуется автоматизация, а не только из-за современной тенденции DevOps.
4. Набор тестов для разработчиков и серверов CI
Стратегии тестирования программного обеспечения помогают нам выявлять дефекты в программных системах раньше, чем конечные пользователи. Программисты часто изменяют исходные файлы для добавления новых функций, исправления ошибок и рефакторинга. Даже изменение одного символа может незаметно вызвать критическую ошибку в программных системах, даже если у нас есть ручная проверка кода. Обзоры кода обычно выполняют статический анализ конкретного снимка кода. Нам, несомненно, необходимо выполнить динамический анализ, выполнив код в реальной вычислительной среде, чтобы выявить возможные проблемы во время выполнения и во время компиляции.
Набор тестов обычно представляет собой набор модульных тестов, интеграционных тестов или других тестов для динамической проверки правильности конкретного снимка кода. Набор автоматизированных тестов на основе DevOps повышает качество продукта, выявляя дефекты сразу после модификации исходного кода. Например, посмотрите, как рабочие процессы DevOps кодовой базы Node.js проверяют каждый запрос на вытягивание участников:
Набор тестов предназначен не только для серверов CI — разработчики также должны запускать его локально во время разработки перед отправкой кода в удаленные репозитории. Поэтому большинство программных проектов обычно предлагают разработчикам возможность локального запуска всего набора тестов или его части.
Как и программные ошибки, наборы тестов также могут содержать ошибки и могут скрывать проблемы с пограничными случаями в алгоритмических модулях, поэтому доверяйте тому, что вы пишете, а не статусу прохождения/непрохождения набора тестов.
5. Понятная документация и руководство
Существует несколько типов документации — давайте сначала обсудим документацию кода. Простой исходный код без комментариев действительно является источником документации для несгибаемых программистов. Но каждый программист стремится сэкономить время и не хочет проверять каждую строку кода, чтобы отправить простой патч. Например, если вы создаете продукт SAAS, новым разработчикам не нужно читать каждую существующую строку кода перед тем, как они внесут свой первый код.
Документация по коду содержит обзор исходного кода и объясняет обязанности каждого модуля исходного кода. Комментарий к коду может быть более ценной документацией, чем документация с большим количеством абзацев. Например, посмотрите на следующие комментарии в исходном коде ядра Linux:
Между тем, некоторые разработчики создают отдельные страницы веб-документации из комментариев к коду. Но тогда они могут столкнуться с некоторыми проблемами при работе с исходными файлами, поскольку эти файлы выглядят немного перегруженными со встроенной документацией. Выберите стратегию документирования кода в зависимости от вашего удобства.
Другой тип документации — это руководство по проекту, которое читают конечные пользователи. Этот документ может быть и техническим, если вы решаете задачу для разработчиков. Некоторые проекты могут содержать другие типы документации, такие как пояснения по архитектуре и пояснения по безопасности приложений. Удобство использования и актуальность каждой документации делает всех счастливыми и продуктивными.
Спасибо за прочтение.
