Концепции и парадигмы

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

 

Я перечитал всю ветку несколько раз, т.к. в увлекательном обсуждении готовых систем отошел от главного вопроса, ради чего открывал тему :-/

Кто-нибудь занимался вопросом теории проектирования информационных систем (в частности, управления контентом)?

 

Нет, не совсем. Наверное, просто немного неточно выразился.
Я имею в виду, рассматривал ли кто-нибудь сам процесс с точки зрения теории, кто-нибудь изучал механизмы проектирования? Грубо говоря не КАК ИМЕННО написать ЧТО-ТО, а из чего состоит сам процесс проектирования, его зависимости, словно, если бы мы рассматривали сам процесс проектирования как конечную систему, то какие виды она могла бы приобрести?

Для того и поднял тему

Я прекрасно понимаю, что вы, будучи разработчиком, стакивались с этим вопросом лоб в лоб на практике, когда нужно было решать поставленные перед собой задачи, но выше речь шла только о конечной реализации по большому счету и об идее, на основе которой реализовалась структура. Лично мне в данный момент это крайне интересно, отсюда, собственно, все эти дебаты, т.к. разработка, как слоеный пирог - разница только в том, что мы заведомо огромный пласт знаний окутываем в обертку уже готовой технологии, а это не совсем правильно.

Для наглядности приведу пример:
Допустим, перед инженером стоит задача - создать двигатель для комбайна (по аналогии с движком сайта или платформой для реализации проектов какого-то типа), он начинает проектировать его, на основе каких-то критериев, будь то ограничения по бюджету, по потреблению топлива, весу и т.д. Какие именно узлы конечного агрегата проектируются - очевидно, технические тонкости реализации узлов - уже интереснее с точки зрения проектирования, ощущаете аналогию? Мы с вами обсуждали структуру системы, но мы от самого начала темы ни разу не подняли вопроса о том, как именно происходит сам процесс проектирования? Например, за основу вы взяли симфони2:

То есть само это решение уже подразумевает тот факт, что мы опускаем огромную часть проектирования (уровня FW), используя заложенные в его основе принципы как должное. В вашем случае, насколько я понимаю, как наиболее подходящее. Если вернуться к примеру выше, то ни у кого не возникнет вопроса, почему инженер начал проектировать блок цилиндров для ДВС, всем это покажется совершенно нормальным. Я же хотел бы понять почему именно так, почему не иначе в самом широком смысле?

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

Мне кажется я повторяюсь, но есть два подхода имхо:
1) Пишем код так, как считаем нужным и понимаем в процессе, что где-то что-то требует изменений, перерабатываем код и снова подвергаем его критике и т.д. - короче говоря, бесконечная переработка кода.
2) Сначала думаем как подходить к проектированию (создаем модель принципа проектирования), затем непосредственно проектируем сущности системы и их взаимосвязи, и лишь потом реализуем, с минимумом переработок.

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

 

Я думаю что концепция разработки настолько близка к особенностям самого процесса моделирования, что обе эти темы можно и нужно раскрывать в этой ветке. Вы все верно подумали, посудите сами, насколько близко граничит концепт (идея) создания любой системы с самим процессом разработки.

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

Я немного расписал то как вижу (понимаю) процесс моделирования, немного позже напишу. Обсудим. Я выделил 4-5 аспектов проектирования, которые можно рассматривать независимо друг от друга при построении системы, как говорится, с чистого листа.

 

Я попробую изложить свое вИдение, я буду определять термины именно так, как я их понимаю, какое значение я в них вкладываю (оно не всегда может быть точным, относительно общепринятых значений, поэтому не судите строго):

Раз уж форум о программировании на PHP, то в контексте его прикладного применения и будет идти далее речь: Что такое все эти "движки", FW, CMF, CMS, CRM и т.д. по своей сути?

Очевидно, что это информационные системы (ИС) в самом общем понятии.
ИС - автоматизированные программные средства для обработки данных. При этом не имеет значения какого рода данные, откуда они берутся, и что с ними происходит. Например, <?php echo 'Hello World'; ?> - тоже полноценная ИС в рамках терминологии.

Что такое данные? - это любая информация, выраженная для разработчика любым способом, явно (текст, изображения, звук, видео) или косвенно (бинарное представление в оперативной памяти) содержащая в себе определенное семантическое значение. Почему именно содержащая в себе семантическое значение? Потому что у ИС есть определенное назначение, даже если это назначение просто записывать любую поступающую извне информацию, то сама эта информация, какой бы она ни была, является объектом обработки (исследования), а значит автоматически приобретает для нас некоторое значение, которое может быть выражено не как определенное объектное представление (картинка, текст, наборы битов и т.д.), а как форма значимости / важности.

Сказал запутанно, но постараюсь объяснить: если направить радиотелескоп чувствительный даже к достаточно узкому диапазону радиочастот в звездное небо, то можно запечатлеть шумы, распространяющиеся повсеместно (аналогично и с простым настольным радиоприемником, работающем не на частоте передачи радиостанции - он будет шуметь в прямом смысле слова). Шумы не несут в себе семантическую информацию, если объектом исследования является, допустим, какой-то пульсар, даже более того, шумы в таком случае сильно вредят и мешают, искажая сигнал, поэтому от них стараются всячески избавиться. Но шумы не всегда являются бестолковым и портящим измерения фоном, потому что шумы на самом деле - это огромные потоки информации от огромного множества источников, которые в своем многообразии порождают такой эффект. Существуют проекты, объектом исследования которых являются шумы. Целью подобных проектов является нахождение зависимостей в хаосе электромагнитных волн с целью потенциально возможных открытий передачи периодических сигналов от естесственных объектов и (потенциально) искусственно созданных. Например, проект из сети распределенных радиотелескопов SETI. Таким образом, семантическое определение информации, которая будет рассматриваться в конечном счете как данные строго зависит от выбора объекта исследования / оперирования.

Но стоит отметить и тот факт, что вышеупомянутые информационные системы (CMF, CMS, ...) имеют ярко выраженную специфику, характеризующую такие системы по их прикладному назначению - обработка данных применительно к веб-технологиям. Эта специфика обусловлена языком программирования (ЯП), на котором создается весь спектр систем.

ЯП - представляет собой сложный программный комплекс, являющийся в классической многоуровневой модели представления архитектуры компьютера одним из уровней, представленным виртуальной машиной для языка программирования этой виртуальной машины, которая транслирует условные и понятные для человека языковые конструкции, либо на уровень ниже, например, на язык ассемблера, либо непосредственно компилируя (по сути трансляция на самый глубокий уровень) в наборы машинных инструкций.

Теперь нужно на минутку остановиться и представить себе масштаб того, хотя бы в рамках этих незначительных определений, что же такое обычное <?php echo 'Hello World'; ?> с точки зрения исполнения этого кода. Какие механизмы задейстуются для того, чтобы за время порядка 10^-4 сек. мы увидели на экране заветные слова. Какой массив преобразований на самом деле проходит наша "идея", воплощенная языковыми конструкциями языка программирования, чтобы получить желаемый результат.

Минутка воображариума =) А теперь продолжим: немного понимая процессы, хотя бы в самых общих чертах, давайте подумаем над процессом проектирования. Изначально нам доступны средства в виде некоторого множества языковых конструкций строго определенных возможностями интрерпретирующего механизма виртуальной машины ЯП. Моя главная мысль в том, что мы изначально полностью ограничены средствами ЯП. Мы не можем выйти за пределы языка, мы не можем писать скрипты на РНР, производя манипуляции с регистрами процессора. А это значит, что ограничения, наложенные разработчиками языка определяют уровень прикладного назначения ЯП. В связи с вышесказанным, далее речь будет идти полностью в контексте ограничений области прикладного назначения PHP.

Я уже говорил об ИС, я сказал и о том, что ИС оперирует данными, при этом только мы определяем семантическое значение той информации, которая будет являться данными для ИС (с учетом ограничений ЯП). Так в частности сами исходные коды какого-либо скрипта могут стать объектом оперирования (то есть данными) для исходного алгоритма (рефлексия).

Как правило в качестве данных мы выбираем исключительно семантически явно определенную информацию - символьные представления, реже - бинарные преобразования данных (и то, исключительно стандартными функциями, т.к. работать вслепую не очень удобно). Данные, как правило, где-то храняться и для этого очевидно используются специализированные ИС - СУБД, кеширующие механизмы и средства ОС в виде файловой подсистемы хранения данных.

Теперь у нас в арсенале: информационные системы хранения и обработки данных и ограниченное многообразие языковых конструкций, из которых мы будем собирать, словно из молекул, будущие системы, будь то ERP, CRM, ORM, mapper'ы и т.п. Причем, я повторюсь, все это возможное многообразие систем любого уровня сложности заведомо ограниченно возможностями ЯП.

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

Если с точки зрения технологических ограничений ЯП мы определились, то в процессе моделирования и проектирования (под проектированием я понимаю этап предварительной реализации наиболее приближенной к возможностям языка, то есть это переход от схем с крайне абстрактными кружочками и стрелками, к схемам с конкретными объектами и связями между ними) мы имеем ряд совершенно других ограничений - физические ограничения нашего разума. Абсолютному большинству разработчиков сложно оперировать тысячами строк кода даже с точки зрения образного представления что к чему, а уж говорить о полном проектировании системы исключительно в воображении, проивзодя при этом на лету рефакторинг при каждом внесении изменения - на грани фантастики. Эта особенность ограниченности нашей концентрации внимания и памяти (хотя я уверен, эти качества тренируются и со временем разработчики адаптируются к тому, чтобы заведомо продумывать большую часть ситуаций) рождает необходимость дискретного представления процесса разработки: мы разделяем потенциальное воплощение будущей системы, которым невозможно эффективно оперировать в воображении, на ряд меньших сущностей, которые не просто легче представить, но и которые проще реализовать. От сплошной простыни кода к изящному объектному представлению... к выделению функциональных структур кода... к модульной, компонентной парадигме и т.д.

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

Все системы в контексте вышесказанного обладают тем или иным балансом между делением воплощения идеи на отдельные сущности и количеством взаимозависимостей между ними.

Благодаря различным свойствам языковых конструкций и их отношению к использованию сторонних ИС (например, использование объекта для работы с БД), влияющим на конечную логику, любую систему следует рассматривать как некое многоуровневое или многомерное образование, так в частности, можно выделить такие аспекты проектирования как:

1. Уровень определения структуры пространств имен
2. Уровень определения структуры в файловой системе
3. Уровень определение архитектуры системы (на этом уровне выделяются различные сущности из единого целого)
4. Уровень определения структур кодов системы (на этом уровне определяются API (интерфейсы) взаимодействия выделенных сущностей)
5. Уровень определения структуры данных (структура на уровне представления данных в ИС обработки и хранения данных: в основном СУБД)

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

Я примерно описал то, каким я вижу процесс проектирования с точки зрения теории проектирования ИС. Не принимайте близко к сердцу =)

 

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

Так, в частности, для систем имеющих прикладное назначение в области решения задач связанных с веб-технологиями отображения и управления контентом / данными, была применена (унаследована) парадигма MVC, которая применялась с языками постарше.

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

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

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

Недостаточно понимать, какие блоки необходимо выделять в системе для ее функционирования, необходимо понимать почему стоит структурировать блоки именно так, а не иначе, почему сам ход рассуждений и логика в системе должны быть именно такими, а не какими-либо другими, и отвечать на этот вопрос необходимо с позиции полного осознания процессов, а не слепо копируя опыт. Это моя основная мысль.

Я же просто призвал тех, кто задумывался когда-либо над чем-то подобным, да и просто тех, кто немало времени и сил потратил на проектирование в рамках решения собственных задач, открыто поделиться опытом и мыслями. Иногда 10 минут общения могут дать больше полезных и новых идей, чем неделя шаблонного программирования, поэтому я уделил внимание вопросам идеологии и принципам проектирования.

 

Благодарю. Я стараюсь выражать идеи как можно более выразительно, хотя, даже этого мне сейчас кажется недостаточно. Я бы хотел визуализировать принципы, даже не схемами, а компьютерной анимацией, так можно было бы объяснить все без слов.

 

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