Большой-большой проект
Часто слышу — Кложа не подходит для больших проектов. Даже цитируют Алекса Миллера из твиттера: “мы считаем Кложу прекрасным решением для небольших команд в быстро меняющихся условиях рынка”. Цитату пишу по памяти, видел когда-то давно.
Что ж, кому-то не подходит и ладно. Мне лично все подходит, и фирме, где я работаю, тоже. Всегда найдется тот, кому не подойдет — это не важно. На самом деле я хотел бы поговорить о “больших” проектах — что это такое и чего от них ожидать.
Откровение: за весь период работы я не помню именно больших проектов. Они всегда были малыми и средними, а если логика росла, проект делили на несколько. Так поступали все команды, где я работал. Любому адекватному человеку ясно, что если проект усложняется, а сущности громоздятся друг на друга, надо разнести их, и все станет ясно.
Когда-то давно я работал в Wargaming. Наша команда занималась кланами и Глобальной картой. Это был жирный проект на Django, который управлял событиями на карте и кланами. Со временем стало ясно, что карты и кланы — самостоятельные сущности, которым трудно ужиться в одном проекте. Поэтому их разделили. Получилось два проекта — карты и кланы. Для взаимодействия они сначала лазили в общую базу, потом каждый обрел свой API.
Было много других случаев, когда одна из фич оттягивала на себя внимание и мешала другим. Ее просто выносили в отдельный сервис. Уточню, не микро-, а обычный сервис. Например, единая авторизация, рассылка писем, служба статистики. Не можешь ужиться со всеми — будь добр живи отдельно. Как в жизни.
Не понимаю, почему проект обязательно должен быть большим. Откуда эти аргументы, что, мол, твой язык подходит только для средних проектов, а для больших — нет? У меня встречный вопрос — почему проект должен быть большим? Откуда эта гигантомания? Разве лишний вес и размер — не признак инженерного провала?
Из истории мы знаем примеры того, как стремление к размерам оборачивалось трагедией. Самый большой корабль — Титаник. Самый большой дирижабль — Гинденбург. Самый большой ядерный реактор — Чернобыльская АЭС. Люди искренне верили, что большой значит надежный. Как может потонуть такой большой корабль? Да вот так, за три часа.
С Чернобылем, кстати, особая ситуация. По воспоминаниям инженеров, в его размере не было никакого смысла. Это была чистейшей воды советская гигантомания. Погоня за показателями, а не качеством и дизайном системы. Инженерам приходилось управлять реактором как четырьмя отдельными. Из-за колоссальных размеров температура и другие показатели менялись в зависимости от места замера. К чему это привело, всем известно.
Еще в античные времена умные люди поняли, что правильный дизайн означает соразмерность человеку. Никому не нужен стакан размером с кувшин. Люди не хотят жить на 151 этаже — их должно быть не более десяти-двенадцати. Код должен быть кратким — без геттеров, сеттеров и public final static void бла-бла. Он должен точно описывать задачу. И уж тем более, если, чтобы понять код, нужна платная IDE с подсказками, то здесь что-то не так.
Большой проект — это неуловимый Джо. Можно прожить всю жизнь в ожидании Большого проекта, который никак не настанет. Тешить себя мыслью, что пусть сейчас неудобно, но когда-то настанет Большой проект, и там-то я развернуть. А те умники с Кложей будут страдать. Допускаю, будем. Но скорей всего, это никогда не наступит.
Вот и сейчас, дорогая редакция: пишу плагин к Kafka на Кложе. Сравниваю с чужими плагинами на Java. У меня 8 .clj-файлов, у них 20 .java-файлов. У меня 478 строк, у них 1920 строк. Одна и та же задача — отправить сообщеньки в сеть. А разница по всем показателям в три-пять раз.
Мне возразят: а как бы ты писал IDE или какую-то другую жирную штуку, которая вот прямо никак не делится. Ответ в том, что все на свете делится. Не бывает неделимых вещей. Человек внутри не сплошной, как картошка, а состоит из органов и системы обращения веществ. Большой проект — это всегда система из ядра и модулей, которые как-то общаются друг с другом. Поэтому первое, что надо сделать в большом проекте — нащупать систему. Далее выделить компоненты и решить, как им общаться. Потом спокойно работать над каждым компонентом в отдельности.
Но увы, разработчики мечтают о Больших, Сложных проектах. Средние — для ламеров, это не про нас! Так и получается Большой проект. Вот только он большой не потому, что является таким, просто его так спроектировали. Поэтому лучше умерить влажные мечты о больших проектах и подумать, как больше сделать маленьким. Таким, чтобы оно умещалось в одну голову без насилия над собой.
Нашли ошибку? Выделите мышкой и нажмите Ctrl/⌘+Enter
Yury Antonov, 28th Jan 2021, link
По поводу больших проектов. Есть вполне видимые проблемы в следующем (помимо мечтания о большом):
1. Отстуствие выделение изолированных частей в отдельные библиотеки, или хотя бы четко проведенные границы между семантически изолированными частями кода (чтобы при первом желании выделить просто было).
Зачастую под девизом так быстрее, хотя в реальности это как раз и дольше на средней и длинной дистанции, т.к. начинается перерешивание одних проблем даже соседними командами\проектами, в реальности от недостатка квалификации.
2. Разрастание проекта до невероятных размеров (когда во временем в проект включается функциональность соседних\иных продуктов проектов), что со временем приводит к тому, что очередной потребитель смотрит на это, думает мне нужен 1-5% от этого и начинает заново (переходит к использованию иного продукта).
Так что с композируемостью ситуация просто ужасная, даже в рамках одного (любого) языка.
Ivan Grishaev, 28th Jan 2021, link , parent
Согласен. Менеджмент я намеренно упустил, потому что это другая история.