Реалии такие, что для описанных вами типов деятельности уже есть подходящие определения. А вы придумали свои. Кстати, поищите статьи "программист" vs "кодер".
А элементы из этого острова стабильности могут оказаться полезными в материальном мире? Иными словами, может ли быть открыт какой-нибудь вибраниум или типа того?
Правильнее сказать, что там контекст не спутать (особенно в диалектах с LET). А так это три разные операции: императивное присваивание, декларативное утверждение равенства, и сравнение.
Не смог понять, в чем цель поста… Ну да ладно, допустим, я тупой.
Но вот конкретный вопрос (иду с конца).
После того, как у нас работают все тесты, мы можем позаботиться о том, чтобы наш код читается, как хорошо написанная проза, и удалить ненужное дублирование.
Серьезно? 99,9% разработчиков ужаснутся при мысли о том, что им надо серьезно переделать код, намертво (если код плохой) или более-менее приемлемо (если код ок) склееный юнит- и интеграционными тестами.
Весь смысл в том, чтобы оптимизировать код еще при написании тестов, когда видно, что тест не складывается (например, слишком много дублирования в самих тестах).
Нет, речь о раздельных доменных событиях, а не об одном-единственном update. А это очень разные вещи. MVC — это об определенном направлении зависимостей и контроля, когда модель прямо говорит, что в ней изменилось и когда. Метод render же, грубо говоря, вообще по таймеру можно вызывать.
Почему-то JavaScript фреймворки пошли по этому пути (и соответственно, необходимости делать кучу дополнительной работы с вытекающими тормозами). Плохо то, что они называют его MVC.
Впрочем, мы уже видели такую массовую подмену понятий — толстые контроллеры, выдаваемые за MVC, или целая экосистема Rails, тоже выдаваемая за MVC.
Боюсь задать глупый вопрос (весьма далек от всего этого), но все же.
Что мешает сделать каноничный MVC (например, с Active Model)?
Заводим:
Модель со стейтом и событиями (в данном случае — NewAddress, DeleteAddress), реализующая шаблон Observer.
Вью, подписанную на изменения модели (в данном случае — добавление некоторого html на NewAddress и удаление на DeleteAddress).
Это будет очень быстро (максимально быстро, я бы сказал), можно менять модель командами с сервера, модель ничего не знает про вьюшки (меняй их как хочешь, заводи сколько угодно и пр.), все события рядом, и вообще это правильно же.
> А в случае спортпита молодежь, начитавшись качковских статей для стероидных мутантов
Я правильно понимаю, что спортпит излучает некое поле, которое заставляет попавших в зону его действия людей определенного возраста искать и читать особые статьи от весьма специфических авторов?
Имхо у Вас в самом изначальном примере дублирование знаний (действие можно привязать к типу лица, а можно — к типу договора), и отсюда все проблемы. Атрибуты по-возможности должны быть ортогональны.
Если это продакшен-код (или создан из такового), тогда он очень, очень плох… И дело не в неправильной работе с кешом, а в самом коде. Да даже и пример можно было сделать, используя нормальные практики программирования, заодно выиграв в читаемости.
Огромное количество проблем в работе, совместимости и эксплуатации уязвимостей на моей памяти были связаны со словом «автоматически». А если не подгрузит «автоматически»? С инклудом хоть сразу видно будет.
Вы гораздо больше наделаете ошибок, если будете загружать файлы руками.
А если не подгрузит «автоматически»? С инклудом хоть сразу видно будет.
Просто надо знать, как работает твой инструмент. И тоже все будет сразу видно.
Ну на самом деле куча бандлов, идущие как стандартные, представляют собой месиво, гвоздями приколоченное к некоторым основным компонентам (типа Доктрины). Как будто сделано все, чтобы показать, что наличие интерфейсов еще не означает слабую связанность :).
Суть в направлении контроля. Фреймворк вызывает Вас. Вы вызываете библиотеки.
А на самом деле он слепил свой собственный неуклюжий фреймворк, за бортом осталась шаблонизация… не протестированных на четкую работу вместе
Почему это он неуклюжий? Зачем мне шаблонизация, если у меня строго JSON API? Суть — с введением PSR можно самому собрать собственный фреймворк, делающий ровно то, что нужно и ничего больше, из кода разных производителей.
которые и не библиотеки на самом деле а микро-фреймворки
Нет, это именно библиотеки. А Вы не понимаете разницу между библиотекой и фреймворком.
Статья — норм, заголовок — вполне точен.
И хотя по сути автор описывает, как создать свой микрофреймворк из стандартных библиотек, это нормально, так как любое более-менее структурированное приложение держится на некоем каркасе, готовом или самописном.
Реалии такие, что для описанных вами типов деятельности уже есть подходящие определения. А вы придумали свои. Кстати, поищите статьи "программист" vs "кодер".
А откуда в банке такие крутые, сознательные, узкие и в то же время все умеющие специалисты, и уже готовые к любым изменениям проекты?
Похоже на очередную фантазию.
Правильнее сказать, что там контекст не спутать (особенно в диалектах с LET). А так это три разные операции: императивное присваивание, декларативное утверждение равенства, и сравнение.
Тоже думаю, что проблема преувеличена, и иммутабельность здесь не при чем.
Не смог понять, в чем цель поста… Ну да ладно, допустим, я тупой.
Но вот конкретный вопрос (иду с конца).
Серьезно? 99,9% разработчиков ужаснутся при мысли о том, что им надо серьезно переделать код, намертво (если код плохой) или более-менее приемлемо (если код ок) склееный юнит- и интеграционными тестами.
Весь смысл в том, чтобы оптимизировать код еще при написании тестов, когда видно, что тест не складывается (например, слишком много дублирования в самих тестах).
Нет, речь о раздельных доменных событиях, а не об одном-единственном update. А это очень разные вещи. MVC — это об определенном направлении зависимостей и контроля, когда модель прямо говорит, что в ней изменилось и когда. Метод render же, грубо говоря, вообще по таймеру можно вызывать.
Почему-то JavaScript фреймворки пошли по этому пути (и соответственно, необходимости делать кучу дополнительной работы с вытекающими тормозами). Плохо то, что они называют его MVC.
Впрочем, мы уже видели такую массовую подмену понятий — толстые контроллеры, выдаваемые за MVC, или целая экосистема Rails, тоже выдаваемая за MVC.
Не уверен. В них (и в примере в статье) нет доменных событий,
зато есть метод render, относящийся не пойми к чему, и якобы "декларативный" подход.
Боюсь задать глупый вопрос (весьма далек от всего этого), но все же.
Что мешает сделать каноничный MVC (например, с Active Model)?
Заводим:
Это будет очень быстро (максимально быстро, я бы сказал), можно менять модель командами с сервера, модель ничего не знает про вьюшки (меняй их как хочешь, заводи сколько угодно и пр.), все события рядом, и вообще это правильно же.
?
Я правильно понимаю, что спортпит излучает некое поле, которое заставляет попавших в зону его действия людей определенного возраста искать и читать особые статьи от весьма специфических авторов?
Наркотики, гепатит и спортпит, ага…
а между тем спецпитание вовсю используется в медицине, и в нефрологии в частности. Например, www.bbraun.ru/cps/rde/xchg/cw-bbraun-ru-ru/hs.xsl/products.html?id=00020742600000000565&prid=PRID00002983
В том и дело, что надо проектировать под неопределенность — делать слабосвязанные взаимозаменяемые части.
Полная лажа. Выделение и переиспользование знаний, технологий, решений, деталей, чего угодно — основа прогресса.
Стройте все изначально из правильных частей и не будет проблем с выделением.
Имхо у Вас в самом изначальном примере дублирование знаний (действие можно привязать к типу лица, а можно — к типу договора), и отсюда все проблемы. Атрибуты по-возможности должны быть ортогональны.
Прочитайте, пожалуйста, мой коммент внимательнее. Сам код, а не что он делает, плох.
Если это продакшен-код (или создан из такового), тогда он очень, очень плох… И дело не в неправильной работе с кешом, а в самом коде. Да даже и пример можно было сделать, используя нормальные практики программирования, заодно выиграв в читаемости.
Вы гораздо больше наделаете ошибок, если будете загружать файлы руками.
Просто надо знать, как работает твой инструмент. И тоже все будет сразу видно.
Ну на самом деле куча бандлов, идущие как стандартные, представляют собой месиво, гвоздями приколоченное к некоторым основным компонентам (типа Доктрины). Как будто сделано все, чтобы показать, что наличие интерфейсов еще не означает слабую связанность :).
Нет, смысл совсем не в размере, охвате и пр.
Суть в направлении контроля. Фреймворк вызывает Вас. Вы вызываете библиотеки.
Почему это он неуклюжий? Зачем мне шаблонизация, если у меня строго JSON API? Суть — с введением PSR можно самому собрать собственный фреймворк, делающий ровно то, что нужно и ничего больше, из кода разных производителей.
Нет, это именно библиотеки. А Вы не понимаете разницу между библиотекой и фреймворком.
Статья — норм, заголовок — вполне точен.
И хотя по сути автор описывает, как создать свой микрофреймворк из стандартных библиотек, это нормально, так как любое более-менее структурированное приложение держится на некоем каркасе, готовом или самописном.