понедельник, 21 февраля 2011 г.

Размышления об идеальной архитектуре приложения. Часть 2: Развеиваем мифы?

Содержание

Часть 2

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

И в конец пролога - угадайте, что же это за такой талантливый инженер изображен на фотке справа :)

Я не пытаюсь создать универсальное средство решения задач
Это коренное заблуждение, которое я увидел в комментариях к моему посту. Универсальное средство решение - есть наш мозг. Но самый занятный момент здесь в том, что он не предназначен напрямую решать задачи. Схему его работы скорее можно представить как: "научится решать" -> "решить". А в нашее время еще и создать средство для того, чтобы задачу, которую мы научились решать - решал кто-то другой. Например, арифметические операции прекрасно выполняет калькулятор.

К чему я веду?
Я веду к тому, что я хочу создать не фреймворк, который решает все задачи (то есть это не универсальная нейросеть, и никакой другой универсальный апарат решения задач), - это уже не будет фреймворк, а "кнопка" "Сделать зашибись". Я хочу создать фреймворк реализующий архитектуру (подход, методологию) приложения, которую можно применить для всех задач.
Привожу пример
практически все боьшие коммерческие компьютерные игры создаются на объектно-ориентированных языках (в основном это С++). Попытка сделать игру пользуясь только структурным подходом приведет сами понимаете к чему.
Но какой занимательный факт. Ведь имея, например, в своем распоряжении, грубо говоря, функцию main (рассмотрим вариант на С), мы можем написать любое приложение:
int main() {
// Do any task in the world
return 0;
}
То есть, по сути, вот оно! =) Отсутствие фреймворка, каких-либо архитектурных правил и ограничений и привело нас к цели. Пользуясь таким "фреймворком" можно сделать все.

Смешно, да?
Действительно, понаписывал про терминаторов, про всякую фигню и дошел до того, что фреймворки нафиг не нужны. Не совсем так.

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

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

Заключение
Дела с покорением мира обстоят немножко плохо, но, благодаря уверености Андрея Светлова в том, что задача более легкая и обозримая, как-нибудь к ней вернусь, может даже напишу о прогрессе здесь.

Надеюсь, что внес некоторую ясность в идею, изложенную в предыдущей публикации, если не запутал вас еще больше :)

19 комментариев:

  1. Подразумевается ли наличие некоего стандартного функционала(если да, то что именно) или же фреймворк только должен предоставлять возможность использования архитектуры

    ОтветитьУдалить
  2. Отличный вопрос! (он мне показал, что этот пост я написал не зря :) ).
    Эта тема очень болезненная. Как показывает история и опыт использования, большинство предпочитает batteries included (Django), а не делай как хочешь, и чем хочешь (Pylons).

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

    Суть проблемы в том, что в разных областях "стандартный функционал" будет СОВЕРШЕННО разным и даже не пересекатся.

    То есть внедрение такового в код, и даже больше, - ОПРЕДЕЛЕНИЕ данного ПОНЯТИЯ еще будет формироваться и пока у меня нет ответа на этот вопрос.

    ОтветитьУдалить
  3. По поводу вопроса в прологе:

    Майлз Беннетт Дайсон - ведущий программист «Кибердайн Системс» в паралельной/вымышленной вселенной фильмов про Терминатора. :)

    ОтветитьУдалить
  4. Таки да! А на мониторе позади него мы видим призрачные строчки кода будущего фреймврока :)

    ОтветитьУдалить
  5. Я так понял, что идеальный универсальный фреймворк на данный момент состоит из пустого модуля.
    Думаю теперь стоит произвести небольшой анализ существующих фреймворков и архитектур и вывести из них начальный набор аксиом.

    ОтветитьУдалить
  6. >>> Я так понял, что идеальный универсальный фреймворк на данный момент состоит из пустого модуля.

    Совершенно верно :)

    >>> Думаю теперь стоит произвести небольшой анализ существующих фреймворков и архитектур и вывести из них начальный набор аксиом.

    Не совем так. Это то, о чем я писал в первой главе, - никакой жизни не хватит выучить все фреймворки, средства и категории задач", а при такой задачи обязательно знать все :). Задача превращается в полный перебор... =(

    Как я описал в первой главе, подход будет более теоретический, то есть: пишем код и смотрим, применим ли он (удобен ли он) для всего класса задач. Если нет - так не пишем, думаем как сделать по-другому.

    ОтветитьУдалить
  7. >>> никакой жизни не хватит выучить все фреймворки, средства и категории задач
    >>> пишем код и смотрим, применим ли он (удобен ли он) для всего класса задач.

    Здесь начинается путаница... Нужно разобраться со всем самому либо пустить в мир на растерзание.

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

    В данном случае это особенно актуально в связи с полной неясностью задачи

    ОтветитьУдалить
  9. а вообще я люблю написать, посмотреть шевелится ли "оно" и если что кувалдой по голове. Первая итерация. А дальше повторяем :)

    ОтветитьУдалить
  10. Так придумали шаблоны проектирования. На базе опыта реализации многих задач выделили общие приемы и подходы

    ОтветитьУдалить
  11. @theod
    >>> сначала вы должны начинать развивать алгоритмы, и только в конце этой работы приходите к тому, что вы в состоянии сформулировать четкие и непротиворечивые интерфейсы.

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

    ОтветитьУдалить
  12. мне больше нравится первый путь решения.
    обьясню почему:
    как ты будеш смотреть\оценивать применима ли "строчка" для всех классов задач? особенно учитывая что отрицаеш необходимость наличия опыта в различных классах задач

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

    такую задачу нужно решать сообща, и решать её должны люди набившие руку в большом круге задач

    это не значит, что ты должен остановится, твой путь и опыт который ты получиш в поисках решения тоже важен, и возможно он приведёт кого-то к какой то правильной мысли

    ОтветитьУдалить
  13. >>> мне больше нравится первый путь решения.

    Мне тоже. И я полностью принимаю и понимаю все аргументы.

    >>> как ты будеш смотреть\оценивать применима ли "строчка" для всех классов задач?

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

    ОтветитьУдалить
  14. Назар
    >>На базе опыта реализации многих задач выделили >>общие приемы и подходы

    В том то и дело, что сначала были попытки, а потом появились шаблоны :)

    ОтветитьУдалить
  15. Блин, как я себе сейчас напоминаю этого товарища - http://python.su/forum/viewtopic.php?id=3996

    ОтветитьУдалить
  16. Я правильно понял, что вы собираетесь выработать общую методологию разработки как под создание игр, так и под создание веб приложений? Попахивает поповщиной...

    ОтветитьУдалить
  17. >>> Я правильно понял, что вы собираетесь выработать общую методологию разработки как под создание игр, так и под создание веб приложений?

    Примерно "в десятку".

    >>> Попахивает поповщиной...

    Главное правильно приготовить :) А чем оно там попахивает - разберемся.

    ОтветитьУдалить
  18. >>> Блин, как я себе сейчас напоминаю этого товарища -
    >>> http://python.su/forum/viewtopic.php?id=3996
    Ууу... Мега чувак. До сих пор не оставил своей идеи. :-)

    А вообще да, я считаю, что в итоге ты придёшь к пустому питоньему модулю, набору стандартных библиотек и pypi. Ведь по сути это и есть твой универсальный фреймвок для решения любых задач.
    Ну да, собаку выгулять пока нельзя, но это, думаю, в разработке. :-)

    ОтветитьУдалить
  19. @ZZZ
    Как сказал мне @theod, разница между мной и тем чуваком в том, что в моем случае нельзя оценить объем работ...

    ОтветитьУдалить

В этом гаджете обнаружена ошибка