[button color=4d61d7 icon=arrow-left-2 url=https://apptractor.ru/develop/grigoriy-petrov-formirovanie-navyikov.html] Предыдущая статья [/button]
В предыдущей колонке я рассказал о том, как тренировка навыков может расширить возможности разработчика в борьбе со сложностью. И большинство разработчиков, даже не зная о проблеме сложности, инстинктивно стараются выделять хорошо знакомый им общий код и делить программу на небольшие части.
В большинстве случаев выделение общего код и абстракции — хорошая, годная штука. Если умеренно и без фанатизма. Увы, умеренно получается не всегда. Во время частных консультаций по организации разработки, я не раз видел внутренние “фреймворки” такой сложности, что на прикладном уровне большая часть функциональности описывалась одной-двумя строчками “сверхвысокоуровневого” кода. С одной стороны — это хорошо. Меньше строчек — проще прочесть и понять что происходит. С другой стороны, код ведь надо не только читать, но и менять. И если эта одна “волшебная” строчка недостаточно гибка (а она никогда не будет достаточно гибка), то для изменений необходимо лезть в сложнейший внутренний фреймворк, разбираться в его архитектуре и добавлять необходимую гибкость.
Мне очень нравится высказывания писателя-фантаста и футуролога Артура Кларка: “Любая достаточно развитая технология неотличима от магии”. Это фраза точно описывает то, что происходит с программами, в которых основной упор в борьбе со сложностью делается на декомпозицию и максимально высокоуровневый фреймворк, чтобы код “бизнес-логики” был как можно проще.
Плюсы и минусы магии
Я не могу сказать, что магия в коде — это однозначно плохо. Уровни абстракции борются со сложностью, с помощью нескольких строчек высокоуровневого кода можно решить задачу, требующую многих тысяч строчек обычного кода. С другой стороны, шаг влево или вправо сразу же натыкается на ограничения абстракций и вынуждает разработчика работать с подводной частью этого айсберга, которая обычно содержит многолетние наработки поколений программистов компании.
Решения лучше всего принимать, владея информацией. Какие плюсы есть у магии?
- Магия переводит количественную сложность в качественную: огромные массивы кода разделяются на несколько простых строчек “верхушки айсберга”, а большое количество слоев абстракции в “подводной части” обеспечивает его работу. Равномерно распределенная по проекту сложность позволяет разработчикам относительно легко добавлять новый код. Конечно, при условии, что они хорошо знакомы с подводной частью айсберга.
- Вся сложность знаний предметной области естественным образом переносится на один, верхний уровень и сосредоточена только там. Такое разделение позволяет разработчикам быстро отвечать на вопрос “как это работает” и не тратить время на поиск размазанной по коду функциональности.
- Изменения, не противоречащие архитектуре фреймворка, вносятся легко и просто. Опять же, при условии, что разработчик знаком с фреймворком, обеспечивающим магию.
- Новые разработчики, знакомые с фреймворком, могут сразу приступать к работе.
Минусы магии, как это обычно бывает в жизни, являются обратной стороной ее плюсов:
- На практике, количественная сложность редко переводится в качественную без увеличения сложности — своеобразный “КПД”, который обычно сильно меньше 100%. Каждый добавляемый слой абстракции имеет стыки и интерфейсы для взаимодействия с предыдущими слоями, дополнительный код для обеспечения логической целостности, дополнительный контроль ошибок и много других интересных штук. Все это увеличивает суммарную сложность программы. Несмотря на то, что после разделения кода на слои абстракции каждый слой по отдельности будет намного проще исходного кода, их суммарная сложность будет выше. Иногда — намного выше. Простота верхушки айсберга компенсируется суммарной сложностью его подводной части.
- Простота внесения изменений в надводную часть айсберга компенсируется сложностью внесения изменений, которые противоречат архитектуре созданного или использованного фреймворка. Сложность подводной части айсберга зачастую возрастает настолько, что при неудачном стечении обстоятельств будет проще переписать все с нуля, чем кардинально поменять архитектуру системы. Магия и гибкость архитектуры зачастую антонимы: возможность на высоком уровне написать одну строчку и “сделать круто” компенсируется огромными скрытыми от глаза конструкциями, обеспечивающими собственно «делание круто».
- Новые разработчики, не знакомые с фреймворком, будут вынуждены изучить его, прежде чем делать хоть что-нибудь. И хорошо, если используется популярный фреймворк с хорошей документацией. Часто магические системы — внутренняя, слабо документированная разработка компании. Изучение такой системы не только займет время, но и будет отвлекать от работы “старожил”, знающих недокументированные нюансы.
Нужна ли в проекте магия?
Как и многие вещи в этом мире, магия в исходном коде программного обеспечения не является добром или злом сама по себе. У нее есть сильные и слабые стороны, часть из которых я описал выше. В зависимости от проекта и процессов, магия может как принести огромную пользу, так и полностью парализовать разработку. На мой взгляд, для большинства проектов хорошо себя зарекомендовал отказ от предварительной оптимизации.
Не стоит в начале разработки сразу создавать множество слоев абстракции, увенчанных сверху DSL как торт вишенкой. Первое время новые проекты развиваются стремительно, часто вся архитектура меняется несколько раз, адаптируясь по мере того, как разработчики лучше понимают рынок, клиентов и задачи. После стабилизации проекта у команды разработки будет возможность оценить характер изменений. Если изменения по большей части количественные, при этом архитектура проекта не меняется — то имеет смысл вытягивать на верхний уровень магию, что сэкономит огромное количество времени, позволит собрать все знания предметной области в одном месте и вообще благотворно отразится на проекте. Если же архитектура проекта часто меняется, адаптируясь под новые варианты использования и платформы, то магия будет только мешать этим изменениям, заставляя разработчиков раз за разом переписывать “поддерживающие” слои.
Магия в реальном мире
Многие популярные фреймворки придерживаются “магической концепции”. К примеру, возможность писать одну-две строчки легко читающегося кода для решения большинства задач было одной из сильных сторон фреймворка Ruby on Rail. Эта возможность, совместно с удобным для создания DSL синтаксисом языка Ruby, позволили фреймворку стать серьезным игроком в экосистеме веб-разработки. Несмотря на то, что за прошедшие годы удачная концепция была адаптирована другими фреймворками, «рельсы» все еще остаются одним из лучших способов быстро делать типовые веб—приложения.
Выбирая популярный фреймворк, компания получает не только высокоуровневую магию, но и возможность быстро включать в разработку новых программистов. Программист, имеющий опыт работы с Ruby on Rails или Django, легко приступит к работе над проектом, который адекватно написан с использованием одного из этих фреймворков. Если же компания использует фреймворк собственного изготовления — то каждому новому программисту придется тратить время на его изучение — не только свое, но и команды.
Оценка существующих фреймворков и выбор правильного стека технологий — одна из задач тимлида. Выбирая фреймворк, мы платим временем изучения за возможность решать какой-то круг популярных задач в несколько магических строчек кода. И платим увеличивающимся временем разработки за решение тех задач, которые не являются с точки зрения фреймворка “популярными”. Балансируя оплату и получаемые блага, хороший тимлид управляет рисками, сроками и ценой разработки. Задача непростая — но интересная. Общаясь с кандидатом на эту важную роль, нелишне будет поспрашивать, что он думает о фреймворках, магии, и всем вышеперечисленным.
Кстати, именно о тимлидах мы поговорим в следующей колонке. Оставайтесь с нами!