Только мне одному кажется сегодня чем-то диким заморачиваться на тему MVC и какой архитектуре/паттерну соответствует код?
+1
Да и в повседневной разработке не нужно заново создавать MVC-каркас или использовать паттерны.
Пользуемся готовым функционалом, меняем в случае необходимости. Но не ради моды или галочки.
Только в жизни выходит наоборот.
Команда была самоуправляема до внедрения модных методологий, а чем больше внедряют методологию, тем больше выходит наоборот.
Под аутсорсом понимается веб с кучей клиентов (сайтов).
Посмею заметить, что это не правильно. Люди от бизнеса должны быть РО, а проектные менеджеры должны играть роль скрам мастера. Но если люди не адекватные, то тут печаль-беда.
А, тогда у нас 25 разрабов, они, конечно поделены на команды.
И 13 скрам-мастеров. :)
Т.е. по сути в течении спринта, sprint backlog принадлежит только команде разработки и никто туда соваться не имеет права.
Если PO вносит кардинальные изменения, то нужно ли команде продолжать делать старое неактуальное задание или делать новое? Как на это смотрит скрам?
А потянет ли 1 СМ команду из 25 разрабов и 13 менеджеров? :)
Коммуникация вместо разраб <-> менеджер будет разраб <-> СМ <->менеджер? :)
(менеджеры не из бизнеса, а менеджеры проектов, бизнес-аналитики)
работая параллельно над тремя-пятью проектами каждый
Разве скрам подходит для аутсорса? :)
Т.е. когда много реквестов с многих проектов, то это уже попахивает support'ом и тут лучше уходить от SCRUM'а.
А если много запросов с одного проекта? :)
Я повторюсь если скажу, что PO нет и SM мудак и это основная проблема?
Короче, все зависит от людей.
Дебилы могут испоганить что угодно. :)
Т.е. PO — первый сдерживающий барьер от всего стада менеджерья обитающего на просторах вашего офиса.
Хм.
А у нас не так.
Менеджеры из бизнеса называются просто бизнес.
А менеджеры проектов являются и PO.
Вот эти PO и неадекватные. :) Вообще не фильтруют бред от бизнеса.
А не кажется ли посетителям сайта, что скрам — это попытка непрограммистов управлять программистами без понимания их запросов? :) Если бы скрам внедряли адекватные люди, то возможно и проблем бы не было. Да проблем не было при любой методологии.
Скрам — это гибкая методология?
Как часто допускается вносит изменения в ТЗ?
Большинство фреймворщиков (писунов в интернетах) именно так неправильно и понимают M.
Типо, M — это наследник базового класса по работе с базой и этот M расширяют всяким мусором. :)
А что плохого, если простая логика будет в контроллере?
Если M ограничится ORM? :)
В коробочной поставке симфони огрызок ещё тот, по-этому каждый проект потом превращается в фарш из JMS, Knp, Fos и прочей лабуды с вермишельками сонаты.
Мне жаль, что у меня, как симфониста есть подобные коллеги как вы.
На Simfony получается вермишельный код?
Его удобно поддерживать?
Почему вам тогда нравится Simfony? :)
+1
Да и в повседневной разработке не нужно заново создавать MVC-каркас или использовать паттерны.
Пользуемся готовым функционалом, меняем в случае необходимости. Но не ради моды или галочки.
Хм, я постоянно говорю, что большие компании используют самопись, а не фреймворки.
Но получаю минусов. :)
Только некоторые уже сейчас пытаются следовать моде, создавая новые проекты.
Команда была самоуправляема до внедрения модных методологий, а чем больше внедряют методологию, тем больше выходит наоборот.
Нету менеджеров. А под менеджерами я понимал то, что тут называют СМ:
линк
Нету ТЗ.
Та плевать как вы это назовете.
Судя по всему это 5-ое колесо в телеге. :)
Под аутсорсом понимается веб с кучей клиентов (сайтов).
А, тогда у нас 25 разрабов, они, конечно поделены на команды.
И 13 скрам-мастеров. :)
Если PO вносит кардинальные изменения, то нужно ли команде продолжать делать старое неактуальное задание или делать новое? Как на это смотрит скрам?
API битрикса — более менее норм. А также его плюс в том, что оно обратно совместимо.
А вот когда куча говнокода на якобы нормальном фреймворке — вот это печально.
Методы CMS или фреймворка не так и часто нужно использовать.
Хм, но какая разница, что внутри CMS или фреймворка? :)
С этим кодом разработчику работать не приходится.
А вот на якобы нормальных CMS или фреймворках программисты создают свой говнокод, с которым приходится работать другим. :)
Ок, пусть нету.
Потянет ли 1 СМ команду из 25 разрабов? :)
Он будет ТЗ писать? :)
А потянет ли 1 СМ команду из 25 разрабов и 13 менеджеров? :)
Коммуникация вместо разраб <-> менеджер будет разраб <-> СМ <->менеджер? :)
(менеджеры не из бизнеса, а менеджеры проектов, бизнес-аналитики)
Разве скрам подходит для аутсорса? :)
А если много запросов с одного проекта? :)
Короче, все зависит от людей.
Дебилы могут испоганить что угодно. :)
Хм.
А у нас не так.
Менеджеры из бизнеса называются просто бизнес.
А менеджеры проектов являются и PO.
Вот эти PO и неадекватные. :) Вообще не фильтруют бред от бизнеса.
А не кажется ли посетителям сайта, что скрам — это попытка непрограммистов управлять программистами без понимания их запросов? :) Если бы скрам внедряли адекватные люди, то возможно и проблем бы не было. Да проблем не было при любой методологии.
Скрам — это гибкая методология?
Как часто допускается вносит изменения в ТЗ?
Типо, M — это наследник базового класса по работе с базой и этот M расширяют всяким мусором. :)
А что плохого, если простая логика будет в контроллере?
Если M ограничится ORM? :)
На Simfony получается вермишельный код?
Его удобно поддерживать?
Почему вам тогда нравится Simfony? :)
У домена-донора и домена-получателя не было мусора.
Откуда он потом может взяться? :)
4:
Что это такое и где это смотреть (бесплатно)? :)
А если строить региональность / язык не по разделам, а по поддоменам?
У сайтов, которые автоматом редиректят с главной на раздел страны на главной что-то есть? :)
Как быть с поисковиками?
Они же будут получать редирект на страну поисковика.
Или в природе не появляются ссылки на главную? :)
А что Вы используете? :)
Можно примеры, почему за и против? :)
Спасибо.
Это ж цифровой товар.
Его можно продать 100500 раз по 1К. :)