Вам куском, или нарезать?

У одной монеты — две стороны. Любая палка — о двух концах. Все проблемы имеют как минимум два решения.

Если бы я задался целью классифицировать типы этих решений — мне бы хватило двух слов — по одному на каждый тип. Монолитный и модульный. Программистам наверняка известно, что ядро операционной системы Minix — имело модульную структуру, в то время, как ядро Linux — монолит. Роман с точки зрения издателя — монолитен, сборник рассказов — напротив — является модульным решением (в том, хотя бы, смысле, что неудачные тридцать страниц из середины романа могут привести к необходимости переписать роман целиком; неудачный же рассказ в тридцать страниц — можно просто заменить на другой, не притрагиваясь к содержимому остальных. В то же время, неудачные тридцать страниц романа — простительны автору, а неудачный рассказ может привести к полной потере читателя). Дубовый шкаф отличается по тем же признакамот конструкторов «Сделай Сам» производства IKEA. Плюсы и минусы обоих вариантов — очевидны и трехлетнему ребенку.

Монолитные решения, как правило, характеризуются внешней добротностью, фешенебельностью и производят впечатление отделки в стиле «ампир».Результат применения модульного дизайна — как правило, удобнее в быту, легче при перевозке и лучше приспособлен к обновлениям. Впрочем, такого типа приобретением не станешь хвастаться зажиточному соседу.

Наконец, килограмм колбасы куском — дольше сохранится свежим; однако нарезка гораздо удобнее во многих житейских ситуациях, право перечислить которые я предоставлю читателю.

Patch (англ.) — заплата, лоскут

Сразу оговорюсь, я являюсь адептом модульных решений. Поэтому мои слова могут быть во многом пристрастны и несправедливы.

Я убежден, что в мире нет программиста, способного написать работоспособный код сколь угодно малого объема без ошибок. Алгоритм Эвклида и сортировка пузырьком — подвержены проникновению багов не меньше, чем нелинейное восстановление Сэммона или даже интепретирование регулярных выражений. Дайте любому программисту месяц на решение какой-нибудь нерешаемой задачи, и на двадцать девятый день он принесет «вполне работоспособное» решение, оставив, впрочем, себе пару дней на то, чтобы «пофиксить баги», которые найдете вы. Дайте этому же персонажу десять минут на кодирование утилиты «Hello,World!» — и на девятой минуте дверь вашего кабинета распахнется, и радостный программист принесет исполнимый файл, который будет печатать эту хрестоматийную околесицу без завершающего перевода каретки, превращая приглашение командной строки в оптимистичное:

Hello, World![am@localhost /home/am]$

Попеняйте ему, и он умчится доделывать, недовольно бурча себе под нос всякую нецензурщину. И доделает, и уложится в одиннадцать с половиной минут, и никому не придет в голову ругать его за это ничтожное отклонение от графика.

Так вот. Принимая во внимание тот факт, что любое ПО создается такими вот разгильдяями — необходимо иметь возможность быстро починить что-то внезапно отказавшее. В модульном приложении это сделать несоизмеримо проще. Как минимум, есть гарантия, что результатом починки одного мини-бага не станет привнесение двадцати пяти новых.

И обработать напильником...

Мне однажды довелось разговаривать с человеком, который расписывалмне преимущества Internet Explorer'а перед остальными браузерами, в частности — перед Mozilla. Он пылко и со знанием дела говорил минут десять. Я не знал, что и возразить; от немедленного перехода на это чудо инженерной мысли меня спасло только отсутствие в пределах видимости подходящих операционных систем. Он меня убедил тогда, клянусь.

На следующий день меня разбудил телефонный звонок. Этот пламенный поклонник Explorer'а установил себе, таки, Mozilla — просто для ознакомления. А потом зашел на страничку плагинов... Всю ночь он развлекался установкой разных гуглебаров и таббедсорчей (траскрипция ориг.), а в начале девятого утра следующего дня — позвонил мне, чтобы обрадовать следующим известием: Mozilla — рулезз форева.

К чему я это? Да к тому, что заточка под свои вкусы и нужды модульного приложения — занятие гораздо менее утомительное, нежели чем конфигурация монолитного монстра. Кроме того, сами модули, конечно, при условии грамотно документированных интерфейсов, может писать человек, совершенно не разбирающийся в тонкостях функционирования всего приложения в целом.

Известный благодаря Лу Гринзоу «синдром небрежных DLL» — речь идет о упаковывании всего «плохого» кода в динамически связываемую библиотеку, — с призрачным намерением когда-нибудь, потом, переписать и отладить — этого же поля ягода. И если не принимать во внимание тот факт, что никто и никогда не переписывает небрежный код, «отложенный на время в DLL» — такое бизнес-решение — тоже пример превосходства модуляризации над монолитностью.

Тридцать три богатыря

Наконец, умение работать в команде — искусство гораздо менее распространенное среди программистов, чем принято полагать. По правде говоря, никто не умеет работать в команде в полной мере. На 99% — да, умеют,очень немногие, но умеют. Но стопроцентного растворения в коллективе, образования единого целого — лично мне повидать не удалось. Кроме того, уровень программистов не всегда одинаков. И разбиение проекта на модули, определение интерфейсов взаимодействия и перепоручение каждого отдельно взятого модуля — отдельно взятому персонажу, — позволит, вероятно, избежать множества ошибок, вызванных рассогласованностью действий, перетягиванием одеяла и различиями в основных концепциях кодирования.

В конце концов, даже стиль комментариев, положение закрывающих скобок и организация бесконечных циклов (for(;;) vs. while(true)) — будет единым хотя бы внутри модуля.

И, наконец, самое главное: ненужные модули можно отключать.

А нужные — подключать.

И работать с тем набором функциональности, который требуется пользователю, а не с тем, что был спроектирован полоумным разработчиком. Мне это важно.

Никто, кстати, не в курсе, что такое Xtreem Programming?!

Всем загрузить модуль выгрузки монолитного ядра!