Ответ
Процесс основан на анализе требований, оценке ограничений и сравнении альтернатив.
Типичные шаги:
- Анализ проблемы и контекста. Уточняю бизнес-требования, технические ограничения (deadline, инфраструктура, legacy-код) и критерии успеха.
- Поиск и оценка альтернатив. Рассматриваю несколько подходов, их плюсы и минусы.
- Производительность и масштабируемость.
- Сопровождаемость и читаемость кода.
- Риски и сложность реализации.
- Согласованность с архитектурой и стандартами команды.
- Принятие решения. Выбираю вариант, оптимально балансирующий между перечисленными критериями. В сложных случаях обсуждаю с командой.
- Документирование и коммуникация. Фиксирую rationale (обоснование) решения, чтобы оно было понятно команде сейчас и в будущем.
Пример на псевдокоде:
TechnicalDecision makeDecision(Problem problem, Context context) {
List<Option> options = researchOptions(problem);
return options.stream()
.filter(opt -> isFeasible(opt, context.teamSkills, context.deadline))
.max(Comparator.comparing(Option::getMaintainability)
.thenComparing(Option::getPerformance))
.orElseThrow(() -> new CompromiseNeededException("Требуется обсуждение/уточнение"));
}Ключевой принцип: решение должно быть практичным, обоснованным и понятным для команды.
Ответ 18+ 🔞
Да ты посмотри, какой процесс, ёпта! Как будто мы тут в космос ракету собираем, а не код пишем. Ну ладно, разложу по полочкам, как это у нас в реальности происходит, без этих ваших заумных словечек.
Первым делом, конечно, надо понять, в какую жопу мы вообще лезем. Сидишь, смотришь на задачу, а там такое... Бизнес говорит: «Нам надо, чтобы оно летало, пело и кофе варило, а вчера уже должно было быть готово». Технические долги, как слон на груди, лежат, а инфраструктура — хуй с горы, собранная на соплях и изоленте. Без этого понимания — пиши пропало, можно сразу впендюрить себе в проект такое, что потом год откатывать.
Дальше начинается самое интересное — поиск вариантов. Тут включается внутренний голос, который орет: «Э, бошка, думай!». Рассматриваешь кучу подходов, и у каждого свой подводный булыжник размером с дом.
- Скорость и масштаб. Один вариант быстрый, как угорелый, но если пользователей станет больше десяти — он накроется медным тазом и будет лежать, сука, пузом кверху.
- Читаемость и поддержка. Другой — красивый, модульный, весь такой из себя элегантный. Писать его — одно удовольствие, но работает он со скоростью пьяного слизняка в январе.
- Риски. А третий вообще от лукавого: библиотека непонятная, документация на птичьем языке, и чуешь ты подозрительное волнение ебать — вдруг завтра её автор смоется в запой, и всё, пизда твоей фиче.
В общем, сидишь и взвешиваешь: что важнее — чтобы через полгода не пришлось всё переписывать с нуля, или чтобы завтра тикет в Jira закрылся? Обычно ищешь золотую середину, а она, зараза, всегда где-то в стороне.
Ну и кульминация — выбор. Берёшь тот вариант, который меньше всего, блядь, всех заебёт в перспективе. Если совсем туго — орешь на всю опенспейс: «Народ, а давайте сюда, ёпта! Посмотрите на эту хуйню!». И начинается мозговой штурм, где рождаются гениальные идеи и ебанавты.
И вот тут, внимание, самый важный шаг, который все просрать любят! Надо записать, блядь, почему так решили. Не «сделали так-то», а «сделали так-то, потому что Вася был пьян, сроки горят, а библиотека Х — пидарас шерстяной, который в прошлый раз всё сломал». Через месяц ты сам забудешь, а новый чувак посмотрит в код и скажет: «Какой мудак это писал?». А там будет ссылка на решение, и он поймёт, что мудак — это обстоятельства, а не ты. Ну, почти.
Вот как это выглядит в коде, если бы его писал не робот, а живой человек, которому уже овердохуища этих задач:
TechnicalDecision makeDecision(Problem problem, Context context) {
// Находим все теоретически возможные варианты
List<Option> options = researchOptions(problem);
// Отфильтровываем откровенную пургу, на которую у команды нет времени/мозгов
// И выбираем то, что и работать будет, и поддерживать не застрелишься
return options.stream()
.filter(opt -> isFeasible(opt, context.teamSkills, context.deadline))
.max(Comparator.comparing(Option::getMaintainability)
.thenComparing(Option::getPerformance))
.orElseThrow(() -> new CompromiseNeededException("Пацаны, идите сюда, хуйня какая-то!"));
}А главный принцип, внатуре, простой: решение должно быть не просто умным, а практичным. Чтобы и работало, и через полгода тебе за него по ебалу не дали. Всё, чих-пых, пошёл делать.