Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Заметка про проектирование #425

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
71 changes: 68 additions & 3 deletions tlroadmap/roles/technical-lead/architecture/design/ru.md
Original file line number Diff line number Diff line change
@@ -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-разработчики и другие техлиды.