Обоснование выбора технического решения
опубликовано: ⏰ 8
Небольшая статья о том, как можно описывать выбор технических решений в рамках проекта или каких-либо других активностей, которые требуют принятия решений с их обоснованием.
Введение
Зачастую, при в рамках процесса проектной работы или при определении сторонних решений для внедрения, нельзя просто выбрать то, что нравится по личным ощущениям. Необходимо обосновать свой выбор, чтобы другие участники проекта или целевые заказчики, для которых выполняется работа, понимали мотивацию и причину этого выбора.
В зависимости от размера проекта и сложности задачи, можно использовать разные подходы обоснования выбора. Более сложные случаи требуют детального анализа всех зависимостей и оценки последствий выбора, полноценного документа с составлением технико-экономического обоснования, этапов согласования, защиты и т.д.
В данной статье будет пример простого обоснования выбора решения, более приближенного к каждодневной проектной работе или для этапов экспресс-пресейлов. Наверное, это чем-то схоже с тем, что описывается в ADR.
Общий подход
Думаю, здесь всё довольно банально и очевидно, но всё же шаги следующие:
- Определить проблему, которую нужно решить. Или преследуемые цели.
- Описать возможные варианты решения.
- Оценить каждый вариант по заданным критериям.
- Сделать выводы и выбрать лучший вариант.
- Оформить документ.
Цели
При определении проблемы важно учитывать различные факторы, как технические, так и организационные. Важно учитывать контекст, в котором возникает потребность. Например, проблема может быть в том, что команда не может эффективно работать с определённым сервисом/языком разработки, или в том, что у компании нет четкого понимания, какие технологии используются в проектах и куда она движется.
Пример упрощённой постановки по выбору языка разработки
Выбор языка разработки
Основная бизнес-потребность заключается в разработке надежной, масштабируемой и сопровождаемой программной платформы для поддержки основных функций платформы NovaPlay, обеспечивающей бесперебойную интеграцию с существующими системами и поддержку будущего роста. Платформа должна быть построена с использованием современного языка программирования, который удовлетворяет этим требованиям.
1.1. Цели
1.1.1. Кроссплатформенная совместимость
Система должна быть способна работать на нескольких платформах (Windows, macOS, Linux) без значительных изменений и поддерживать стабильную производительность. Эта кроссплатформенная совместимость является ключевой для обеспечения доступности на различных платформах и простоты сопровождения. Выбранный язык должен поддерживать возможности кроссплатформенной разработки, позволяя использовать один код для развертывания в различных средах. Такой подход минимизирует затраты на разработку и максимизирует переиспользование кода.
1.1.2. Зрелость экосистемы
Язык программирования должен иметь зрелую экосистему с обширными библиотеками и инструментами для поддержки быстрой разработки и повышения продуктивности. Зрелая экосистема предоставляет доступ к широкому набору готовых решений, что сокращает время разработки и гарантирует соблюдение лучших практик. Кроме того, она обеспечивает проверку языка в реальных условиях, что важно для долгосрочного успеха и стабильности проекта.
Варианты
Поняв потребность и определив цели с возможными ограничениями сверху, можно переходить к описанию вариантов решения. Собственно, за счёт первого этапа, спектр вариантов сузится до более или менее приемлемого списка.
Здесь обычно сравнение выполняется в виде таблицы, где по горизонтали перечислены варианты, а по вертикали - критерии.
| Criteria | Java SE/EE | Go | Scala |
|---|---|---|---|
| Overview | |||
| Website | www.oracle.com | golang.org | scala-lang.org |
| License | GPLv2+CPE | BSD 3-Clause | Apache 2.0 |
| Release Date | 1995 | 2009 | 2003 |
| Developer | Sun / Oracle | EPFL / Lightbend | |
| Community Size | + + + + Very Large | + + + Large | + + Medium |
| Ecosystem Maturity | + + + + Mature | + + + + Mature | + + + + Mature |
| Features | |||
| Primary Purpose | Enterprise, Android, Backend | Cloud, microservices, CLI | Functional + OOP, Big Data |
| Key Features | JVM, GC, OOP | Goroutines, channels, simplicity | Functional + OOP, Pattern Matching |
| Platform | Linux: ARM64, Unix: ARM64, Linux: PPC64LE, Linux: s390x, Windows: x86-64, Linux: x86-64, macOS: x86-64, Unix: x86-64, Windows: ARM64, macOS: ARM64, AIX: PPC64, Plan 9: x86-64, Plan 9: ARM64 [13] | Linux: ARM64, Unix: ARM64, Linux: PPC64LE, Linux: s390x, Windows: x86-64, Linux: x86-64, macOS: x86-64, Unix: x86-64, Windows: ARM64, macOS: ARM64, AIX: PPC64, Plan 9: x86-64, Plan 9: ARM64 [13] | macOS: x86-64, Unix: x86-64, Linux: ARM64, Windows: ARM64, Unix: ARM64, Linux: PPC64LE, Linux: s390x, macOS: ARM64, Plan 9: x86-64, Windows: x86-64, Plan 9: ARM64, Linux: x86-64 [12] |
| Integration Capabilities | + + + Extensive (JARs, Maven) | + + gRPC, HTTP, CLI | + + + Akka, Spark |
| Extensibility | + + + + High (libraries) | + + Moderate | + + + + Very High (implicits) |
| Realtime Capabilities | + Fair (GC pauses) | + + + Good | + Fair |
| Scalability Support | + + + + High | + + + + High (goroutines) | + + + + High |
| Technical Evaluation | |||
| Architecture Style | OOP, modular | Concurrent, procedural | OOP, Functional |
| Performance | + + + Medium-High | + + + + High | + + Medium |
| Memory Usage | + Med-High (JVM) | + + + + Low-Med | + + High (JVM) |
| Concurrency Support | Threads, Executors | Goroutines, CSP | Akka, Futures |
| Security Features | + + + Good (sandbox) | + + Moderate | + + + Good |
| Debugging & Tooling | IntelliJ, Eclipse | Delve, VS Code | IntelliJ |
| Learning & Development Experience | |||
| Learning Curve | + + Moderate | + + + + Gentle | + Steep |
| Documentation Quality | + + + + + Excellent | + + + + + Excellent | + + + Good |
| Tutorials & Examples | + + + Abundant | + + + Abundant | + + + Abundant |
| Community Support | + + + + Very Large | + + + Large | + + Medium |
| IDE/Editor Support | + + + + + Excellent | + + + Strong | + + + Good |
| Development Speed | + + Medium | + + + + Fast | + Slow |
| Score | 10.3 | 10.6 | 8.5 |
| Consequences score | 1.5 | 1 | 1.4 |
Пример определения дополнительных условий.
1.2.1. Переписывание устаревших систем на Java Этот подход позволяет использовать единую экосистему и подходы к разработке на Java. Основным недостатком такого подхода является высокая стоимость переписывания всей системы.
Оценка: -1
1.2.2. Оставить устаревшие системы как есть
Этот подход не требует дополнительных затрат на переписывание старых систем. Однако он требует организации миграции между старыми и новыми системами. Это сложная задача, требующая много времени и ресурсов.
Оценка: 0
По такой таблице можно оценить, насколько решение подходит для конкретной задачи. Например, если решение имеет высокую оценку по всем критериям, то оно может быть хорошим выбором. Если оно имеет низкую оценку по одному из критериев, то это может быть проблемой.
При этом важно учитывать, что оценка всё-таки зависит от конкретной ситуации, проекта, заказчика и
так далее. Нельзя просто в абсолюте сравнивать оценки. Например, в таблице строка Score это абстрактная суммарная
оценка по критериям, а Consequences score это оценка последствий внедрения (детали ниже) и она приоритетнее.
Оценка
После определения списка вариантов можно выполнить их оценку с учётом ограничений и требований.
Чаще всего это описывается в виде текста Вариант 1 vs Вариант 2 с обоснованиями. Либо это может быть в виде таблицы с плюсами и минусами, сумма которых и даст оценку.
| Вариант | Плюсы | Минусы |
|---|---|---|
| Java SE/EE | +2 Совместимость с несколькими ОС +1 Зрелость экосистемы | -1 Низкая производительность системы -0,5 Высокое потребление памяти |
| Go | +1 Совместимость с несколькими ОС +0,5 Зрелость экосистемы | -0,5 Требуется ручное управление памятью |
| Scala | +2 Совместимость с несколькими ОС +0,7 Зрелость экосистемы | -0,8 Низкая производительность системы -0,5 Высокое потребление памяти |
| Переписывание устаревших систем на Java | +2 Единая экосистема и подходы к разработке | -3 Очень высокие затраты на переписывание |
| Оставить устаревшие системы как есть | +1 Никаких дополнительных затрат на переписывание старых систем | -1 Необходимо организовать миграцию между старыми и новыми системами |
Выбор и последствия
На данном этапе уже подводятся итоги и описывается финальный выбор с последующими действиями. Формат зависит от ситуации и может включать план внедрения, описание рисков и т.д.
1.4. Результаты Выбрано: Java SE/EE Решения: Оставить устаревшие системы как есть
Решение использовать Java в качестве основного языка разработки основано на следующих факторах:
- Java — зрелый и стабильный язык с большим сообществом и обширной документацией.
- Java — хороший выбор для разработки крупномасштабных приложений.
- Java — хороший выбор для разработки веб-приложений с использованием Spring Boot.
1.4.1. Кроссплатформенная совместимость
Java обеспечивает отличную кроссплатформенную совместимость благодаря своей виртуальной машине (JVM). Она является хорошим выбором для разработки NovaPlay, поскольку позволяет запускать приложение на любой платформе, поддерживающей JVM.
Цель: Кроссплатформенная совместимость
1.4.2. Зрелость экосистемы
Java имеет зрелую экосистему с множеством библиотек и фреймворков, которые можно использовать для разработки NovaPlay. Spring Boot, в частности, обеспечивает отличную основу для создания веб-приложений.
Цель: Зрелость экосистемы
1.5. Заключение
Java — лучший выбор для NovaPlay благодаря кроссплатформенной совместимости, обширной экосистеме и сильной поддержке сообщества.
Заключение
Подобные документы могут быть использованы как основа для принятия решений о выборе технологий и как историческая документация к проекту (аналог ADR).
В tekBlueprint.specs (Архитектурные решения) составление подобных документов возможно с использованием шаблонов, автоматическим сравнением по параметрам и расчётом общих оценок, что позволяет ускорить процесс.
Дополнительно, для предварительного сравнения компонентов возможно использование tekBlueprint.kbase.