Комментарии 14
Побуду занудой.
Опытный разработчик увидит полное совпадение с MVC
Мне кажется опытный разработчик увидит что в оригинальном MVC пользователь взаимодействует с View а не с Controller, а View в свою очередь зависит от Model(т.к. является активным и сам обновляет себя при обновлении модели), и возможно ещё от контроллера, поэтому ключевая аналогия в статье выглядит весьма неудачно )
View не должна зависеть от Model и получает данные от Controller. Тут я являюсь поклонникам Cocoa MVC от Apple.
Согласно википедии
Согласно Википедии — "Представление (View) отвечает за отображение данных модели пользователю, реагируя на изменения модели[1]."
Тут я являюсь поклонникам Cocoa MVC от Apple.
У MVC есть оригинальное определение которое сформировал Трюгве в 1979.
Более того, ни о каких искаженных определений MVC от Apple я не слышал и Гугл мне в этом не помог.
developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-CocoaCore/MVC.html
Ну молодцы ребята, придумали Model-View-Adapter и обозвали это MVC, что ещё сказать?
Надеюсь что статья отправлена в архив благодаря тому что они получше разобрались в теме.
Могу дать ссылку от себя на «дефолтное» определение — MVC-originals
Или вот тут набор ссылок — mvc-index
Согласен, что нужны приемочные тесты. В которые вовлечён заказчик
П- программист. М- менеджер.
П:-Надо критерии приёмки.
М:-Не критерии приёмки. Техническое задание, да.
П:-Нет. Критерии приёмки.
М:-Слу-шай. Критерий приёмки нет. Нет. Совсем нет. Нет критериев. Техническое задание — создали люди-аналитики. Оно описывает всё. Твоя понял?
П:-НЕТ! НАДО КРИТЕРИИ ПРИЁМКИ!
М:-НЕТ НИКАКИХ КРИТЕРИЕВ ПРИЕМКИ НА ИСПРАВЛЕНИЕ БАГА, ДУБИНА СТОЕРОСОВАЯ! НЕТ КРИТЕРИЕВ! НЕ СОЗДАВАЛИ! НИКОГДА! НЕТ!
[КОНЕЦ]
Ну, а теперь серьёзно. У нас есть аналитики и время им на разработку критериев приёма в виде документации не выделяют от слова «Agile разработка». Так что у нас всё идёт как описано выше. Менеджеры же покрывают «непокрываемое» тестами и работают над тем, что если какой баг появился на боевом — удерживаем клиента в состоянии «Дзен».
Не согласен. Иногда очень полезно программисту поучаствовать в процессе сдачи результатов его работы Заказчику.
Очень часто программист воспринимает крайне негативно любую критику со стороны клиента. И это может выбить его из колеи на полдня. Возможно я один такой.
По мне, вопрос насколько неоднозначный. С одной стороны — такое взаимодействие даёт крайне положительный эффект. Когда клиент пару раз выскажет программисту своё "фи" по результатам его работы, эти результаты в дальнейшем часто становятся заметно лучше. С другой стороны — такая ситуация говорит, вроде бы, про некачественную работу менеджера, который недостаточно проконтролировал результат. Истина же, как водится, где-то посередине — т.к. никакие ТЗ, критерии приемки, методики испытаний не покроют абсолютно всех деталей задачи, и место оголтелому креативу или циничному пофигизму всегда найдется.
В-общем, я — за такие общение, хотя бы иногда.
Программист, менеджер, MVC и критерии приемки