From 266f39e34d01a311bb70b83c0ee8ea2f719a96dc Mon Sep 17 00:00:00 2001 From: Eldar Mustafin Date: Wed, 21 Feb 2024 10:49:44 +0300 Subject: [PATCH] =?UTF-8?q?=D0=97=D0=B0=D0=BC=D0=B5=D1=82=D0=BA=D0=B0=20?= =?UTF-8?q?=D0=BF=D1=80=D0=BE=20=D0=BF=D1=80=D0=BE=D0=B5=D0=BA=D1=82=D0=B8?= =?UTF-8?q?=D1=80=D0=BE=D0=B2=D0=B0=D0=BD=D0=B8=D0=B5?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../technical-lead/architecture/design/ru.md | 71 ++++++++++++++++++- 1 file changed, 68 insertions(+), 3 deletions(-) diff --git a/tlroadmap/roles/technical-lead/architecture/design/ru.md b/tlroadmap/roles/technical-lead/architecture/design/ru.md index 6a01e059..50cb66a3 100644 --- a/tlroadmap/roles/technical-lead/architecture/design/ru.md +++ b/tlroadmap/roles/technical-lead/architecture/design/ru.md @@ -1,3 +1,68 @@ ---- -title: Проектирование ---- +# Проектирование +## Описание +Проектирование — процесс определения архитектуры, компонентов, интерфейсов и других характеристик системы или её части (ISO 24765). Данный процесс необходим для определения наилучшего решения поставленной задачи и декомпозиции этой задачи на понятные команде составные части. + +Процесс проектированя раскладывается на подпроцессы в соответствии с назначением: +1. Функциональное проектирование (что хотим?) +2. Проектирование пользовательского опыта (как этим будем пользоваться?) +3. Техническое проектирование (какими средствами реализуем?) + +Работа техлида предполагает в основном техническое проектирование: выбор языка, библиотек, подходов, шаблонов и т.п. для реализации конкретной информационной системы. + +## Почему ветка важна +- Помогает выбрать оптимальные решения до начала реализации +- Вынуждает думать об ограничениях, допущениях и возможных рисках при реализации +- Позволяет оценить и предусмотреть возможные изменения системы в будущем +- Команда получает ориентиры и рамки, которые позволяют сфокусироваться +- Работа приоретизируется и разбивается на логически завершенные части +- Обеспечивает более эффективное управление процессом разработки, что позволяет сэкономить время и ресурсы + +## Что будет, если её не делать? +- Риск сделать ненужную работу +- Риск выбора неоптимальных решений и технологий +- Возможные проблемы при развитии и росте в части функциональности или нагрузки +- Возможные проблемы с совместимостью решений на проектах с большими командами +- Многократное переделывание функционала из-за ошибок и несоответствия требованиям + +## На кого может быть делегирована? +- Технический архитектор +- Тимлид ниже уровнем +- Senior-разработчик + +## Примеры хорошего поведения +- Любая функциональность предварительно продумывается и встраивается в решение на этапе проектирования +- В команде закреплены высокоуровневые паттерны, стандарты и парадигмы разработки, как стандарты для реализуемой системы +- Для больших команд организован архитектурный комитет, на котором утверждаются новые решения +- Участники команды имеют четкое представление о системе в целом и своей роли в ней, что способствует более эффективному взаимодействию и синхронизации работ + +## Примеры плохого поведения +- Команды и/или разработчики самостоятельно определяют, как расширять функциональность +- Нет единой архитектурной схемы системы, информация разрознена +- Взаимодействие между компонентами системы не стандартизировано +- Отсутствует четкий план этапности разработки и релизов + +## Способы прокачки +Хорошее проектирование сводится к двум аспектам: +1. Знание стандартов и решений +2. Умение применять на практике + +Рекомендуются к изучению стандарты: +1. Парадигмы программирования (объектно-ориентированное, функциональное, логическое…) +2. Принципы разработки (DDD, SOLID, KISS, DRY…) +3. Паттерны проектирования (MVC, MVVM, Clean Architecture…) + +Умение применять стандарты нарабатывается проектами и обменом опытом с другими техлидами и разработчиками. Хорошо помогает развиваться заимствование решений из других сфер. Наглядным сравнением для процесса проектирования цифровых решений является архитектурное проектирование, которое явно показывает достоинства и недостатки, а также задает стандарты в проектировании. + +### Книги +1. "Clean Code: A Handbook of Agile Software Craftsmanship" Роберта Мартина (Robert C. Martin) - классическое руководство по написанию чистого и качественного кода. +2. "Design Patterns: Elements of Reusable Object-Oriented Software" Эриха Гаммы, Ричарда Хелма, Ральфа Джонсона и Джона Влиссидеса - обязательная книга о шаблонах проектирования и их применении в разработке ПО. +3. "Domain-Driven Design: Tackling Complexity in the Heart of Software" Эрика Эванса (Eric Evans) - описание методики DDD, которая помогает организовать и структурировать сложные проекты. +4. "Code Complete: A Practical Handbook of Software Construction" Стива Макконнела (Steve McConnell) - практическое руководство по конструированию программного обеспечения и разработке эффективного кода. +5. "The Pragmatic Programmer: Your Journey to Mastery" Эндрю Ханта и Дэйвом Томаса (Andrew Hunt, Dave Thomas) - советы и практики от опытных разработчиков для повышения навыков программирования и проектирования ПО. + +### Практика +- [Сайт Рефакторинг.Гуру](https://refactoring.guru/) + +### Консультации +- [Telegram-чат TL Bootcamp](https://tlinks.run/tlbootcamp). +- Технические архитекторы, Senior-разработчики и другие техлиды. \ No newline at end of file