Pull to refresh
14
0
Александр Мозговой @velvetcat

User

Send message

Реалии такие, что для описанных вами типов деятельности уже есть подходящие определения. А вы придумали свои. Кстати, поищите статьи "программист" vs "кодер".

А откуда в банке такие крутые, сознательные, узкие и в то же время все умеющие специалисты, и уже готовые к любым изменениям проекты?


Похоже на очередную фантазию.

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

Правильнее сказать, что там контекст не спутать (особенно в диалектах с LET). А так это три разные операции: императивное присваивание, декларативное утверждение равенства, и сравнение.

Тоже думаю, что проблема преувеличена, и иммутабельность здесь не при чем.

Не смог понять, в чем цель поста… Ну да ладно, допустим, я тупой.


Но вот конкретный вопрос (иду с конца).


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

Серьезно? 99,9% разработчиков ужаснутся при мысли о том, что им надо серьезно переделать код, намертво (если код плохой) или более-менее приемлемо (если код ок) склееный юнит- и интеграционными тестами.


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

Нет, речь о раздельных доменных событиях, а не об одном-единственном update. А это очень разные вещи. MVC — это об определенном направлении зависимостей и контроля, когда модель прямо говорит, что в ней изменилось и когда. Метод render же, грубо говоря, вообще по таймеру можно вызывать.


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


Впрочем, мы уже видели такую массовую подмену понятий — толстые контроллеры, выдаваемые за MVC, или целая экосистема Rails, тоже выдаваемая за MVC.

Не уверен. В них (и в примере в статье) нет доменных событий,
зато есть метод render, относящийся не пойми к чему, и якобы "декларативный" подход.

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


Что мешает сделать каноничный MVC (например, с Active Model)?


Заводим:


  1. Модель со стейтом и событиями (в данном случае — NewAddress, DeleteAddress), реализующая шаблон Observer.
  2. Вью, подписанную на изменения модели (в данном случае — добавление некоторого html на NewAddress и удаление на DeleteAddress).

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


?

> А в случае спортпита молодежь, начитавшись качковских статей для стероидных мутантов

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

Наркотики, гепатит и спортпит, ага…
> спортивное питание

а между тем спецпитание вовсю используется в медицине, и в нефрологии в частности. Например, www.bbraun.ru/cps/rde/xchg/cw-bbraun-ru-ru/hs.xsl/products.html?id=00020742600000000565&prid=PRID00002983

В том и дело, что надо проектировать под неопределенность — делать слабосвязанные взаимозаменяемые части.

Полная лажа. Выделение и переиспользование знаний, технологий, решений, деталей, чего угодно — основа прогресса.


Стройте все изначально из правильных частей и не будет проблем с выделением.

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

Прочитайте, пожалуйста, мой коммент внимательнее. Сам код, а не что он делает, плох.

Посмотрите на такой простой кусочек кода:

Если это продакшен-код (или создан из такового), тогда он очень, очень плох… И дело не в неправильной работе с кешом, а в самом коде. Да даже и пример можно было сделать, используя нормальные практики программирования, заодно выиграв в читаемости.

Огромное количество проблем в работе, совместимости и эксплуатации уязвимостей на моей памяти были связаны со словом «автоматически». А если не подгрузит «автоматически»? С инклудом хоть сразу видно будет.

Вы гораздо больше наделаете ошибок, если будете загружать файлы руками.


А если не подгрузит «автоматически»? С инклудом хоть сразу видно будет.

Просто надо знать, как работает твой инструмент. И тоже все будет сразу видно.

Где в Symfony сильная связанность

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

микрофреймворк — задачу и смежные с ней

Нет, смысл совсем не в размере, охвате и пр.


Суть в направлении контроля. Фреймворк вызывает Вас. Вы вызываете библиотеки.


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

Почему это он неуклюжий? Зачем мне шаблонизация, если у меня строго JSON API? Суть — с введением PSR можно самому собрать собственный фреймворк, делающий ровно то, что нужно и ничего больше, из кода разных производителей.

которые и не библиотеки на самом деле а микро-фреймворки

Нет, это именно библиотеки. А Вы не понимаете разницу между библиотекой и фреймворком.


Статья — норм, заголовок — вполне точен.


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

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity