Ответ
Конструктивное разрешение разногласий — ключевой навык для здоровой команды. Мой подход основан на аргументации, данных и поиске консенсуса.
1. Фокусировка на цели, а не на позициях Вместо спора "чей подход лучше" переводим дискуссию в плоскость: "Какая из предложенных архитектур лучше решает конкретные бизнес-задачи и соответствует нашим ограничениям (сроки, поддержка, производительность)?"
2. Использование объективных критериев Предлагаю оценивать варианты по заранее согласованным метрикам:
- Поддерживаемость: Насколько легко будет читать и изменять код новичку?
- Производительность: Есть ли объективные замеры (профилирование в Instruments)?
- Масштабируемость: Как решение поведет себя при росте кодовой базы?
- Риски: Зависимость от новых/нестабильных технологий?
3. Практические инструменты для принятия решений
- Proof of Concept (PoC): Если спор принципиальный, предлагаю быстро реализовать прототипы обоих подходов для сравнения «в бою». Это снимает большинство споров.
- Архитектурные записи (ADR): Документируем принятое решение, его контекст и последствия. Это создает shared understanding и справочник для будущих дискуссий.
Пример из опыта:
Спор: Внедрять SwiftUI в существующий UIKit-проект сразу или постепенно? Разные мнения: Часть команды — за быстрый переход, другие — за осторожный. Решение через PoC и критерии:
- Сделали PoC для одного экрана в SwiftUI, интегрировав его в UIKit-навигацию.
- Оценили по критериям: Время разработки (быстрее), Стабильность (есть баги в
List), Поддержка (iOS 13+).- Приняли компромиссное решение: Новые, относительно простые экраны — на SwiftUI. Сложные и ключевые — пока оставляем на UIKit. Параллельно обучаем команду.
4. Культура уважения и готовности изменить мнение Важно создать среду, где можно не соглашаться, но где окончательное решение, подкрепленное аргументами, поддерживается всеми. Если мои аргументы оказываются слабее, я готов поддержать решение коллеги.
Ответ 18+ 🔞
Да ты послушай, что эти умники понаписали! Конструктивное разрешение, блядь... Как будто мы в детском саду, а не на работе, где каждый второй считает себя гением, а остальные — идиотами. Ну ладно, слушай сюда, я тебе сейчас на пальцах объясню, как не перерезать друг другу глотки из-за архитектуры.
1. Не упёрся рогом, как бык на мосту Вместо того чтобы орать «Мой фреймворк — бог, а твой — говно!», задай один простой вопрос: «А нахуя?». Серьёзно. «Нахуя нам эта ваша новая блестящая штука, если задача — сделать кнопку, которая мигает?». Переводи с языка фанатизма на язык дела. Какая бизнес-хуйня за этим стоит? Уложимся в сроки или опять будем ночевать на работе?
2. Циферки, блядь, а не мнения Слова — это хорошо, но они дешёвые. Начинается спор — достаём измерительные приборы.
- Поддерживаемость: Дашь этот код стажёру — он через неделю сбежит или разберётся?
- Производительность: Instruments показывают, что всё летает, или анимация тормозит, как муха в сиропе?
- Масштабируемость: Когда проект вырастет в три раза, эта архитектура не превратится в спагетти-монстра, которого все будут бояться трогать?
- Риски: Мы тут не в научной лаборатории, блядь. Завязываемся на библиотеку, которую один чувак в гараже написал? Ну, пиздец тогда.
3. Меньше болтовни, больше дела
- Proof of Concept (PoC): Спорите, что лучше — RxSwift или Combine? Да сделайте, блядь, по одному экрану на каждом! И посмотрите, что проще, что быстрее, где больше костылей. Обычно после такого PoC спор сам собой затухает, потому что всем становится всё похуй, кроме рабочего варианта.
- Архитектурные записи (ADR): Приняли решение — запишите, ёпта! Почему приняли, что рассмотрели, от чего отказались. Чтобы через полгода не пришёл новый тимлид и не начал с того же места: «А давайте на React Native перепишем!». Ты ему эту записку — раз, и в ебальник. Всё, вопрос закрыт.
Живой пример, чтобы не быть голословным:
Спор: Впихивать SwiftUI в старый проект на UIKit или нет? Расклад: Одни кричат «Будущее!», другие — «Нестабильное говно!». Как рубились:
- Сделали PoC: За день наваяли один экран на SwiftUI и впихнули его в общую навигацию. Не идеально, но работает.
- Приложили циферки: Скорость написания — овердохуища. Геморройность — есть, особенно с этим ёбаным
List. Поддержка — iOS 13+, значит, прощай часть аудитории.- Приняли решение, от которого ни у кого не встал: Новые, простые экраны — можно на SwiftUI, тренируемся. Всё сложное и критичное — оставляем на UIKit, не надо тут экспериментов. И всем спокойно, и прогресс есть.
4. И главное — не будь упёртым мудаком Создай атмосферу, где можно сказать «Твоя идея — пиздец», но при этом не переходить на личности. Если твои аргументы разбивают в хлам, а у коллеги железобетонные доводы — будь человеком, скажи «Ок, я был не прав, давай его вариант». Упёртость до конца — удел идиотов. Цель — сделать продукт, а не доказать, что ты самый умный в песочнице. Хотя иногда это охуенно сложно, блядь.