В детстве у меня конструкторов "LEGO" не было - в тогдашнем СССР они были завозившейся единицами редкостью (то есть, может быть, я ошибаюсь, и они были у всех, кроме меня, но у меня не было). Решил окунуться в детство, но не в свое, а в современное.
Мне доводилось читать, слышать и даже фрагментарно применять многие методологии разработки ПО, но про методологию "LEGO" мне слышать не приходилось, а жаль.
И мне все равно, что мне уже давно не 14 лет.
Чем дольше возился, тем больше поражался - процесс строительства замка из кубиков теперь прочно ассоциируется у меня с хорошей системной архитектурой. Вот 10 причин моего искреннего восторга:
- Задача сборки грамотно разделена, причем на разных уровнях: детали разделены по пакетам с номерами 1-5 (в моем случае), самые мелкие детальки дополнительно упакованы в маленький пакетик внутри большого, простые дополнения в виде нескольких однотипных деталей сразу лепятся на главную конструкцию, а более сложные собираются отдельно и прикрепляются целиком.
- Каждая деталь произведена с допусками в десятые доли миллиметра (если не с меньшими) в части габаритов, размеров отверстий, углублений и расстояний между ними.
- Конструкция в целом становится тем устойчивее, чем больше деталей на нее прикрепляется - это достигается за счет того, что следующие детали часто крепятся на несколько предыдущих, а не на одну. Хотя, справедливости ради, нужно отметить, что если на каком-то их шагов обнаруживается ошибка (а у меня они были), то и возвращаться приходится не на один шаг назад - иногда приходится демонтировать и пересобирать весьма значительные части конструкции.
- Даже при большом числе деталей не становится скучно - порядок сборки определен так, что повторяющихся действий мало (хотя количество типов деталей по определению ограничено), или они разнесены, разбавлены какими-то другими действиями.
- Далее несколько пунктов об инструкции по сборке. Для начала скажу, что я бы боготворил производителей мебели, если бы хотя бы одна из их инструкций, с которыми мне приходилось сталкиваться, хоть в чем-то напоминала материалы "LEGO". Ну вы знаете эти жуткие, плохо отпечатанные мятые бумажки с чертежами, ни дать, ни взять, межгалактических кораблей, почему-то называемых столами и креслами. Видимо, у составителей таких схем тоже в детстве не было "LEGO", или им "отстегивают" профессиональные сборщики предметов меблировки.
- Полиграфия справочников, в целом, лучше, чем многие наши и не наши книги. При выборе из кучи пластика именно тех деталей, которые нужны для очередного шага сборки, не возникает никаких проблем - детали в книжке отлично нарисованы, цветовое кодирование на высоте.
- Справочник добавляет еще один уровень декомпозиции задачи: по шагам сборки конструкции или отдельных крупных блоков. Один шаг - одна иллюстрация.
- ... и еще один уровень декомпозиции: сначала картинка с нужными для шага деталями и их количеством, затем местоположение этих деталей в цельном произведении или его блоке.
- Отлично выверено, сколько и чего должно быть на каждой странице: по количеству шагов сборки или действий в процессе одного шага, то есть по количеству иллюстраций и по площади этих иллюстраций.
- Переходы между отдельными иллюстрациями, шагами сборки, страницами грамотно обозначены стрелками. Это верно даже в тех случаях, когда переход выполняется между разворотами справочника.
Мне доводилось читать, слышать и даже фрагментарно применять многие методологии разработки ПО, но про методологию "LEGO" мне слышать не приходилось, а жаль.
И мне все равно, что мне уже давно не 14 лет.
Я бы сказал, Валера, что вся методология "LEGO" в индустрии разработки ПО давно и успешно сведена к одному нажатию кнопки - либо Build для построения приложения, либо Install для установки/деплоймента.
ОтветитьУдалитьЕсли же проводить какую-то аналогию, то процесс разработки ПО отображается на LEGO как мучительные раздумья инженеров и дизайнеров - "а что мы хотим получить в результате?", подбор тех самых цветных составных частей, их комбинирование, если не получилось - разобрать и снова собрать (отладка). Наконец - получилось задуманное! Фиксируем последовательность действий в инструкции (фиксируем отлаженный исходный код в VCS). Нет?
Можно и так сказать, если брать уровнем ниже. Я, собственно, об этом и не об этом одновременно. С одной стороны - да разработчик ПО Х будет согласно методологии Лего мучаться и думать, как бы подобрать и сделать кубики "правильными", и в этом случае есть польза, потому что есть ряд постулатов (допуски, сочетаемость и т.д.), на которые нужно обращать внимание (это в Лего так, я понимаю, что при разработке ПО все сложнее).
ОтветитьУдалитьНо теперь представим, что в предыдущем абзаце я говорю о разработчиках библиотек, инструментов, языков и сред программирования, API ОС... тогда в качестве пользователей мы можем рассматривать и программистов-прикладников или, в случае языков, просто программистов, их использующих.
Если первые озаботились совершенно конкретными постулатами, то вторые вправе ждать совершенно конкретных плюшек. Это философия, конечно, но философия ИМХО правильная.
А этого-то как раз и нет сейчас, причем ни на каких уровнях. Вот пример со вчерашнего дня - если я вставляю веб-браузер в качестве (и в виде) элемента управления на форму Аксцесс (я многопрофильный - я то на C#, то на С++, то на Аксцесс, ибо я "научный наемник" :) ), и на экране все смотрится чудесно, согласись, я вправе ожидать, что и на печать все будет выводиться чудесно или хотя бы как-то. Так нет же - элемент веб-браузера на печать не выводится вместе с формой. А как его напечатать? А нужно извлечь из него картинку, для чего у контрола тоже нет интерфейса. Это нужно эту же картинку скачать вторично по урлу вручную или достать из кэша через всякие HTTP-классы, потом засунуть в элемент управления "Картинка", скрыть браузер, отобразить эту картинку и тогда вот печатать.
Раздражает тот факт, что, казалось бы, ПРОСТОЕ, ОЖИДАЕМОЕ поведение компоненты не наблюдается, и то, что, казалось бы, должно занять 2 минуты занимает целый день или полдня. :) Ну неужели никому не приходило в голову (сочетаемость кубиков), что программисту могут понадобиться картинки из уже отображенного контрола? Ведь в браузере (полновесном, любом) есть такая функция, то есть я вправе рассчитывать на то, что разработчики контрола подумали об этом, а они вправе считать, что мне это понадобится - нередкая ситуация-то. :) В Лего ожидания этих двух категорий людей - разработчиков и пользователей совпадают. В Андроиде, кстати, ожидания разработчиков и пользователей, как ни странно, тоже совпадают, думаешь: "Эээээ ну где же это может быть, здесь?" и таки ДА - оно ТАМ! ВСЕГДА ТАМ! :)
И конструкция не только укрепляет себя по мере сборки... обнаружил, что последовательность действий и крепления определены таким образом, чтобы противостоять глупым ошибкам, например, приложению силы при креплении следующей детали в каком-нибудь слабом месте. Так вот там просто нет этих слабых мест: если нужно прикрепить деталь в каком-нибудь месте, значит все предыдущие действия укрепляли это место, чтобы все не свернулось по ошибке, не вышло из пазов, не развалилось, если великовозрастный дядька, вроде меня, захочет посильнее надавить. :)
ОтветитьУдалить