четверг, 16 мая 2013 г.

Банальное об UML и моделях вообще

Первое что хочу озвучить - НИЧТО НЕ ДОГМА. Ни TDD, ни UML, ни вообще "хорошие практики программирования". Всё - ЭВОЛЮЦИОНИРУЕТ. Это надо ПОНЯТЬ. То что считалось хорошим - завтра может быть уже "устаревшей практикой" и наоборот.

Хочу рассказать СВОЙ взгляд на проектирование проектов на "модели".

Так как я для СЕБЯ это понимаю. И так - как я это пытаюсь презентовать это вновь прибывшим коллегам устно.

Я не буду пытаться рассказать о "космических технологиях" или <<стереотипах>> или устройстве нашей кодогенерации. Тем боле, что ПОКА - что-то не получается.

Хочется сказать БАНАЛЬНЫЕ вещи, которые на самом деле - являются основой и из которых вытекает всё остальное.

"САМЫЙ НАУЧНЫЙ СПОР - это СПОР О ТЕРМИНАХ"...

Повторю ещё раз:

"САМЫЙ НАУЧНЫЙ СПОР - это СПОР О ТЕРМИНАХ"...

Очень много копий ломается именно в спорах, дискуссиях, раздумьях - "как нам организовать процесс и как навести порядок".

Например:
Эта библиотека может зависеть от этой? А эта от этой? А циклические зависимости тут возможны?

В какую папку поместить компонент X - в common\rtl или в rtl\common?

Инструкция программирования? Как оформлять входные параметры? А выходные? А члены класса? А приватные? А методы доступа к свойствам?

Где граница между подсистемами? Это ещё данные? Или УЖЕ бизнес-объект? Или КОНТРОЛЛЕР? Или может ПРЕДСТАВЛЕНИЕ? Как они должны зависеть друг от друга?

Как проекты могут зависеть друг от друга?

Фабрики? Dependency Injection? Как? Зачем и почему?

Шаблоны GoF? Где и как?

И пишутся ИНСТРУКЦИИ. И ведутся СПОРЫ. И все "друг друга пинают" за несоблюдение инструкций. Аппелируют к регламенту. Шучу конечно. Но в каждой шутке... Но - "тыкать в инструкцию" - это ведь некоструктив. И это - НИКАК не улучшает производительность труда.  А что иначе делать? Или забить на инструкцию?

И главное - ВСЕ МЫ ЛЮДИ. Мы НЕ УМЕЕМ тупо соблюдать инструкции. Особенно многостраничные. Даже ЕСЛИ ЗАХОТИМ. А мы ведь - ХОТИМ. Но не МОЖЕМ.

А как требования трассируются на код? Какой участок кода выполняет это требование? А это требование протестировано? Как?

Вопросы.. Вопросы..

А как вообще должны называться проектные папки? "Самый научный спор - это спор о терминах".

Рут проекта где должен находится? В стандартизованном месте или как захочется разработчику?

А вот этот код это уже реализация прецедента? Или ещё представление? Или что-то ещё? И где вообще собственно реализация прецедента?

И через ВСЁ это - я прошёл. И не раз.

И могу сказать, что модель - это конечно не "серебряная пуля". Но это ОТВЕТ на МНОГИЕ вопросы.

Модель - снимает многое из этой "пены на волне". Она - ВЕДЁТ разработчика в ПРАВИЛЬНОМ направлении. Она де даст поставить циклические зависимости - ТАМ ГДЕ ЭТО НЕВОЗМОЖНО. И даст - там где возможно.

Она не даст нарисовать бизнес-объект на уровне данных. Просто физически. И она не даст нарисовать зависимость от данных к представлению. Что компилятор Delphi - НИКАК не контролирует.

Повторюсь - "модель и её шаблоны - не ДОГМА". Но они служат "ремнями безопасности" или даже скорее "тьюторами" для тех раз разработчиков, которые ХОТЯТ СОБЛЮДАТЬ ПРАВИЛА, но которым тяжко каждый раз сверяться с инструкцией.

Вот как-то так. Это - вершина айсберга. Далее конечно есть "шаблоны проектирования" или "параметризация классов" или "устойчивые проектные решения", но это - ДАЛЬНЕ. Но в первую очередь - это то, что проектирование на модели умеет вести разработчика нужной колеёй.

Например (опять же - это не догма) - модель не даст провести связь к данным миную контроллер или бизнес-объект. Просто ФИЗИЧЕСКИ не даст. Ну если правила игры (шаблоны) такие.

Да! модель (на первый взгляд) - "бьёт по рукам" разработчикам (Embarcadero кстати тоже не прочь "дать по рукам" - http://18delphi.blogspot.com/2013/04/delphi-language.html, и это кстати, на мой взгляд - "правильно"). Она ограждает их от "неверных" решений ( в данной конкретной среде). Но! Надо не забывать только одну вещь - среда тоже - НАСТРАИВАЕМА. Ничто - не догма. Всё МЕНЯЕТСЯ.

Нужны циклические зависимости? На этом уровне? Окей - давайте - введём. Если они ОБОСНОВАННЫ. Но! Das Ordnung muss sein. Если решили так - то - решили. До следующего ревью мета-модели. Которое конечно надо "делать на лету, но всё же дискретно и ВСЕМИ заинтересованными участниками процесса. А не "тихо гундеть в углу". И "в минуты передышки".

НО! При этом. В каждый конкретный момент времени есть - "ощущение порядка и автоматического соблюдения договорённостей". Мне лично - это нравится. Не нравятся договорённости - давайте их менять. Но они - ДОЛЖНЫ БЫТЬ! Какие-то. Должны быть "общие правила игры". В общем - не суть важно - какие. Хотим "стоять на голове" - давайте стоять на голове. Но - ВСЕ вместе, а не КАЖДЫЙ в свою сторону. Дурацкие договорённости? Дурацкие! Но - должны быть. Хотя бы какие-то. И АВТОМАТИЧЕСКИ валидируемые. Чтобы не углубляться "в самый научный спор" на этапе разработки.

Вот как-то так я всё это вижу. Рассказывать дальше про UML и модели? Или я не найду отклика?

P.S. UML тут кстати не совсем причём. Даже может "совсем не причём". Он лишь одна из реализаций. А вообще говоря - надо бы иметь средства мета-мета-программирования (проектирования).

Комментариев нет:

Отправить комментарий