// codeart.ru / Офтопик / MVC ориентированное мышление Форум

MVC ориентированное мышление rss подписка

Автор: Evgeniy Sergeev

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

  1. Искренне не понимаю в чем стеб. Да, возможно, — это болезнь. Но я думаю, что пост слишком сумбурно написан.

    > Где мне разместить код моего нового метода?
    Это что-то. Смотря какую задачу должен выполнять метод. А разместить можно много где — хотите — в lib, хотите — в модуле хелпера, хотите — в модели. А может код достоин того, чтобы сделать из него gem-пакет? Тогда он будет в vendor.

    Так что реально, я не понимаю, что автор хотел сказать этим постом.

  2. Andy, если сказать совсем просто, то я имел в виду, что когда программисту ставят задачу «Напиши программу Hello Word», а он начинает думать, о том где тут модель, где контроллер, а где вьюшка и что записать в базу данных — это уже патология какая-то.

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

  3. Часто сталкиваюсь с MVC-ориентированными вопросами — «Ааа, куда положить этот функционал, модель, контроллер иль еще куда?», так мало того — на этом фоне разгораются холивары, которые занимают времени больше, чем написание самого функционала.

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

    И… да, применительно к PHP.

  4. А ты теперь не пишешь на PHP?

  5. Тормоз, почему не пишу? Только на нем и пишу

  6. «Andy, если сказать совсем просто, то я имел в виду, что когда программисту ставят задачу “Напиши программу Hello Word”, а он начинает думать, о том где тут модель, где контроллер, а где вьюшка и что записать в базу данных — это уже патология какая-то.

    Постепенная популяризация RoR-а породила кучу программистов-зомби, которые искренне считают, что им дали некий “филосовский камень”, и единственное, что им осталось — это правильно поделить задачу на контроллеры, модели, хелперы и т.д.»

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

    И да, для примера тот же «hello world» пишется прекрасно и вообще без контроллеров, моделей и вьюх. Чудеса, да?

  7. Просто предпоследний абзац навёл на такие мысли :)

  8. Блин, вечно забываю про смайлики.

  9. По-моему, у автора просто развилась зависть по поводу того, что на PHP ничего сравнимого по удобству с Rails в обозримом будушем не появится. :)

  10. По-моему, претензии должны быть исключительно к людям, а не к MVC или фреймворкам.

    MVC — паттерн, предложенный для решения конкретных задач, а «фреймворк» дословно переводится как «каркас» и никто не обещал, что он идеально подойдет именно к вашему зданию :)

    К тому же большинство фреймворков не накладывают жестких ограничений. Никто не мешает выводить разметку с помощью echo прямо в контроллере. И AR использовать не обязательно.

    А вот долго сидеть на форумах и обсуждать где должна быть эта строчка кода — вредно для здоровья. Лучше пойти воздухом свежим подышать :)

  11. Alex, а вы про какую часть Африки говорите? Местами там действительно полная жопа, нам, например, чтобы дойти от бара до дома (около 800 метров) давали двух охранников. А слышали, что обезьяны в Африке являются переносчиками ВИЧ инфекции? И в случае укуса можно очень легко заразиться. А вот в Голандии, если не считать депрессивной погоды, очень даже хорошо. Я около двух месяцев жил в Gendringen-е — это недалеко от границы с Германией. Так, что могу Вам совершенно ответственно заявить — в Европе жить лучше!

    А мучают меня не вопросы, а программисты на RoR-е. :-)

  12. fxposter, лучшее враг хорошего. А удобства RoR-а — это вообще дорога ведущая в никуда.

  13. Владимир, согласен с Вами на все 100%. :-)

  14. А куда ведет дорога PHP? :)

    Среднестатистические PHP-шники как-раз таки не знают, что такое CI, TDD, BDD, ant и phing. :) Также они обычно не знают, что такое паттерны проектирование, архитектура приложений и выработка требований. :)

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

    Rails community вкладывает огромные усилия в то, чтобы обеспечить удобство и скорость разработки приложений. Да, естественно, рельсы накладывают свои ограничения, но то, о чем пишешь ты — это просто бред, не имеющий никакого отношения к реальности. :)

    я имел в виду, что когда программисту ставят задачу “Напиши программу Hello Word”, а он начинает думать, о том где тут модель, где контроллер, а где вьюшка и что записать в базу данных — это уже патология какая-то.
    Нормальный программист при таком «задании» явно начнет думать не о том, какую часть кода куда поместить, а о том, какую пользу заказчику принесет решение подобной задачи. 😉

  15. fxposter,
    «А куда ведет дорога PHP?»

    Дорога PHP — это планомерное развитие, смысл которого в том, что нужно учиться, а не искать легких путей.
    А мир Рельсов — это религия, основанная на веру в какие-то чудесные свойства фреймворка. Хотя нет, это скорее сектантство, чем религия.
    Фанатики Рельсов искренне верят, что фреймворк просто не даст им ошибиться.

    «Человек осознано выбравший руби и рельсы, а таких, уж поверь, большинство, узнает о всем, что написано выше значительно раньше, чем пхп-шник, который будет читать мануал по пхп, юзать смарти и какой-нибудь CodeIgniter.»

    Я уже писал, единственная причина почему новички выбирают рельсы заключается в фразе — «Рельсы — это хорошо, потому что php гавно». Большинство RoR-ев даже не понимаю, что RoR нельзя сравнивать с PHP, потому что язык и фреймворк разные вещи. А те кто понимают не могут сказать чем Ruby лучше PHP.

    Конечно, Рельсоманы слышали про CI, TDD, BDD, паттерны проектирования и т.д. Но что толку? Если на практике они не могут обосновать даже простейшие архитектурные решения? Они просто не понимают что такое ООП, у них в голове MVC — это идеальное решение для любого типа проекта.

    «Rails community вкладывает огромные усилия в то, чтобы обеспечить удобство и скорость разработки приложений. Да, естественно, рельсы накладывают свои ограничения, но то, о чем пишешь ты — это просто бред, не имеющий никакого отношения к реальности.»

    Rails community занимается тем, что засирает мозги начинающим программистам. Соглашения рельсов новички воспринимают как часть языка Ruby, от них ускользает механизм реализации этих соглашений, а так же причины по которым эти соглашения возникли.

    «Нормальный программист при таком “задании” явно начнет думать не о том, какую часть кода куда поместить, а о том, какую пользу заказчику принесет решение подобной задачи.»

    Ага — уважаемый заказчик Вы не должны этого хотеть. :-)

    Все кричат о том, что RoR — это типа супер пупер среда для быстрой разработки. И что? У нас ребята из клуба «Вышиби мозг» пропагандируют RoR, а когда понадобилось быстро сделать сайт клуба, они взяли, и за ночь собрали его на WordPress. По-моему — это лучший показатель «эффективности» RoR-а.

    Я считаю что, PHP, за счет своей зрелости, позволяет для заказчика делать гораздо больше, чем RoR который «типа» нереально крут.

    И еще один момент — я не против Ruby или RoR-а, я против того сдвига в мозгах, которые возникли вокруг этих решений.

  16. «А мучают меня не вопросы, а программисты на RoR-е.»

    помойму вы ответили на все свои вопросы этим предложением. во-первых вы отошли от обсирания RoR/MVC и показали, что вы сталкивались с работой только ror-кодеров весьма не высокого качества, а выводы пытаетесь делать за все rails community. Чтобы вам не выглядеть и дальше глупо советую либо для начала написать хоть пару сложных сайтов на ror и запустить их в продакшн либо просто прекратить это бесмыленное необоснованное кидание какашками. Третий вариат — пообщаться таки с нормальными ror-кодерами не предлагаю по одной простой причине — в Красноярске это сделать очень сложно, за все время в rails community я и десятка таких в Красноярске не насчитал, к сожалению.

  17. Alex, а я предлагаю нормальным RoR кодерам перестать нести чушь о том, что Рельсы — это статусный фреймворк и кто пишет на Ruby те классные ребята, а все остальные недалекие тупицы. Давайте наконец признаем, что программирование — это труд, и коротких путей здесь не бывает. Независимо от языка!

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

    Выглядеть глупо я не боюсь.В ноябре буду в Москве, давайте пообщаемся?

  18. Это почему коротких путей не бывает? ) Они бывают везде и не только в программировании, и это никак не противоречит тому, что программирование — труд. Однако, заметь, труд интеллектуальный, это важный нюанс.

  19. Тормоз, есть замечательная фраза — «Короткий путь откроется лишь тому, кто уже прошел длинный». Ну или как-то так :-)

  20. > Фанатики Рельсов искренне верят, что фреймворк просто не даст им ошибиться.

    Не так, сам фреймворк просто позволяет совершать меньше ошибок.

    > А удобства RoR-а — это вообще дорога ведущая в никуда.

    Удобство фреймворка, это именно то свойство, которое повышает продуктивность. Путь в никуда — это «программирование» на PHP. Я просто поражаюсь, когда защищают PHP, что, другого ничего не видели, не щупали, сравнить не получается? И дело тут не во фреймворках. Дело в ЯП.

    И могу сказать про тех, кто знает только PHP (ну, может еще JS и Делфи) — у этих ребят в основной массе очень низкий уровень. Тут недавно был на одном собеседовании, по вакансии Ruby/Rails программер, так вот, туда шли ребята в основном пхпшники (контора помогает обучаться, тем, кто не знает руби/рельсу), ну и после собеседования мне сказали, что ни один человек не ответил до меня на все вопросы. А их было 6 человек до меня. Я не говорю что, вот, посмотрите как я крут. Нет, тут дело в другом, что вопросы то были на уровне «что происходит когда мы вводим адрес сайта в браузер и жмем enter». Это заслуга php — люди даже не могут объяснить базовых вещей.

  21. >Не так, сам фреймворк просто позволяет совершать меньше ошибок.

    Цифры можете привести? Или это очередной рекламный лозунг RoR-а?

    >Удобство фреймворка, это именно то свойство, которое повышает продуктивность. Путь в никуда — это “программирование” на PHP. Я просто поражаюсь, когда защищают PHP, что, другого ничего не видели, не щупали, сравнить не получается? И дело тут не во фреймворках. Дело в ЯП.

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

    Вот мне интересно, Вы когда нибудь заглядывали внутрь RoR-а? Видели как там реализован код? Если заглядывали, то какие можете предложить улучшения (имеется в виду рефакторинг)? Или с чем несогласны в реализации? У Вас свое мнение на код RoR-а сформировано? Вы можете его отстаивать? Если хотя бы на один вопрос ответили полжительно, то это уже большой прогесс, потому что типовой член комьюнити RoR-а ни разу не залез и не посмотрел — как же там все устроено! Нет желания, нет мнения, нет мышления… Одна вера, в то, что RoR — это офигенно круто.

  22. > Цифры можете привести? Или это очередной рекламный лозунг RoR-а?

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

    Конечно заглядывал, в свое время ActiveRecord излазил вдоль и поперек, т.к. хотел перенести на другой язык его. Другие пакеты смотрел, но не так сильно. Просто было интересно как реализованы некоторые вещи, еще когда с метапрограммированием разбирался. Внутренности gem’ов смотрю постоянно, с теми, с которыми приходится работать. Просто для того, чтобы почерпнуть идеи.

    Вот когда на ZF писал, вот-там по я изрядно изучил все внутренности! И даже обнаружил пару багов, которые оформил как issues в системе ZF.

    Честно говоря, в реализации RoR до сих пор не приходилось ни с чем таким сталкиваться, что бы мне очень не понравилось или бы я был не согласен с этим. Вот в реализации gem’ов, которые использую, такое бывает и, в таких случаях, я обычно предлагаю автору пакета improvements. Сам пока не являюсь контрибутором, но в будущем, обязательно им стану.

  23. Andy, а отсутствие статической типизации — это тоже одно из средств позволяющих меньше ошибаться? Если не ошибаюсь Ruby может так же модифицировать классы и во время исполнения (или это пайтон?)? Да и bang-методы не совсем прозрачная и ясная сущность. Так что мне кажется насчет «не позволяет делать ошибок» — это сильно преувеличено. Уверен, что возможность делать ошибки определяется не свойствами языка, а фантазией разработчиков.

  24. > Так что мне кажется насчет “не позволяет делать ошибок” — это сильно преувеличено.

    Я говорил позволяет делать меньше ошибок, благодаря некоторым конструкциям языка.

    > Да и bang-методы не совсем прозрачная и ясная сущность.

    Чего тут непонятного или неясного, Все просто, bang-методы модифицируют объект, а не возвращают новое значение:
    str = «Hello, Vassily!»
    str.sub /Vassily/, ‘Piotr’
    str # => Hello, Piotr!

    > Ruby может так же модифицировать классы и во время исполнения

    Да, позволяет. Это одна из сильных сторон. Дает просто невероятные возможности.

    > Andy, а отсутствие статической типизации — это тоже одно из средств позволяющих меньше ошибаться?

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

  25. Andy,
    >Чего тут непонятного или неясного, Все просто, bang-методы модифицируют объект, а не возвращают новое значение:
    str = “Hello, Vassily!”
    str.sub /Vassily/, ‘Piotr’
    str # => Hello, Piotr!

    Если верить вот этой статье — http://railsbuilder.blogspot.com/2009/04/bang-methods-in-ruby-ruby-classes.html Вы не правы. Приведу цитату:

    «The ! does not mean “This method changes its receiver.” A lot of “dangerous” methods do change their receivers. But some don’t. I repeat: ! does not mean that the method changes its receiver.»

    Поэтому неясности все же есть.

    >> Ruby может так же модифицировать классы и во время исполнения

    >Да, позволяет. Это одна из сильных сторон. Дает просто невероятные возможности.

    Я имел в виду, что эта возможность позволяет вносить больше ошибок и усложняет их устранение. Хотя, безусловно, позволяет значительно ускорить разработку.

    >Ну, насколько я знаю, все основные языки под веб используют динамическую типизацию. Не скажу, плохо это или хорошо — но это удобно. Конечно, нужно следить за типами переменных. Вот у многих php-программистов с этим проблемы. Я уважаю тех программеров, которые принудительно приводят к нужному типу переменные, возвращаемяе из методов, и проверяют аргументы методов на принадлежность к типу/классу.

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

    Самый главный недостаток перечисленных возможностей (изменение методов на лету и нестрогая типизация) — это нарушение изоляции модуля. Т.е. фактический каждый разработчик может внести изменения которы нарушат контракт накладываемый на класс при его разработке.

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

  26. Перечитал некоторые выводы, один из них привлёк особое внимание. Из последнего комментария: «Самый главный недостаток перечисленных возможностей (изменение методов на лету и нестрогая типизация) — это нарушение изоляции модуля. Т.е. фактический каждый разработчик может внести изменения которы нарушат контракт накладываемый на класс при его разработке.»

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

    Только что-то мне всё больше кажется, что обсуждение тут в комментариях уже далеко убежало от темы. У всего есть плюсы и минусы, любые возможности можно использовать во благо и во вред. И зачастую, чем круче выгода, тем круче могут быть проблемы. Ну и что? Прогресс не остановить.

Leave a Reply

« »