Алексей > с группой альпинистов на сложном маршруте, то позиция партнера по связке
Вы привели очень неудачную аналогию. Безусловно, будь проблема на продакшне из серии "ничего не работает" - ее нужно исправлять в кратчайшие сроки. Я не спорю, чужие косяки можно исправлять, но только когда на это есть и время и желание. Чаще всего эти самые косяки на оборот не стоит исправлять, вместо этого указать автору на них и рассказать, как не делать подобных оплошностей впредь.
"командный игрок" и тому подобные фразы - это не более чем маркетинговый булшит. Для вполне комфортной работы в команде достаточно выполнять свою работу качественно, согласно техническому процессу, конструктивно критиковать чужие косяки (иногда исправлять) и трезво воспринимать критику из вне, тут уже исправлять обязательно.
> А IT - это тоже наша реальная жизнь, может не столь экстремальна, как альпинизм, но "правила игры" (лучше даже сказать "правила жизни") - те же...
Пример, что вы привели имеет право на жизнь для маленьких команд, где каждый является соучредителем, или с опционом. Однако не стоит забывать, что все люди по разному мотивированы, как результат помощь может перерасти из разовой - в обязательную и в один прекрасный момент это может вылиться в конфликт. В отличии от вашего примера с альпинистами - чем раньше он произойдет - тем лучше.
memba
> Да, фикстуры это решение, но оно очень затратное.
еще и единственное
> У меня БД на 10гб, там 100+ таблиц, представлений и т.п.
Какая разница сколько там весит прод БД?)
> Она изменяется чуть ли не каждый день, что я миграции не успеваю накатывать.
Собственно и чо?)) Вы несете ответственность за все таблицы?
> С фикстурами моя работа сведется на постоянную их правку.
Если меняется структура БД, или код ее обрабатывающий - то меняются и тесты с тестовыми данными, это ж очевидно.
if (!is_string($path)) {
throw new \InvalidArgumentException('Argument "$path" must be string');
} elseif (!empty($path)) {
throw new \InvalidArgumentException('Argument "$path" must be not empty');
}
> От сюда увиличение срока разработки, перерасход бюджета. . .
Вы видимо никогда не сталкивались с разработкой ПО. Не бывает систем без ошибок, не бывает систем без проблем. Самые дорогое с точки зрения бизнеса, как правило - архитектурные и человеческий фактор, в полной мере они не всегда решабельны в принципе.
> Какую рекомендуете CMS и СУБД?
Можете посмотреть в сторону Magento+MySQL.
Артур Черешнюк
> "На достаточном для решения это задачи." вот я и спрашиваю какой достаточный уровень?
Смысл моего утверждения был в том, что задача определяет уровень, а не желание.
Вернемся к примеру: вы хотите построить шалаш с выгребной ямой: тут знаний о трубопроводе особо не нужно. Пример 2 вы хотите построить жилой небоскреб на 100 этажей. Тут нужны реальные знания.
> Не было бы phpmyadmin мне бы пришлось учить больше что бы прописывать все это в консоль.
Если вы хотите сделать cms, которая будет использовать phpmyadmin - в этом был бы хоть какой то смысла, но объективно в этом смысла нет.
Игорь
> Но, в целом, я могу только повторить - хороший специалист сделает хорошо, плохой - плохо.
Любой программист, попав в экстремальные условия будет писать что бы работало. Хороший - с большой вероятностью за собой уберет, если на это будет выделено время.
> Если кто-то пишет на самописном, но код стройный и аккуратный - какие будут проблемы?
В том, что людей знающих как работает этот код на нашей планете - всего ничего. Я говорю не о бизнес логике, а об окружающем ее коде, грубо говоря том, что обычно называют фреймворком. Чем больше проект - тем серьезней эта проблема. Раскрученные фреймворки ценны именно сообществом.
Игорь
В целом действительно не всегда, но как правило. Писать на самописном движке имеет смысл, если ваш самописный движок и так популярный, например тот же Symfony и вы Фабьен, либо для решения очень узкоспециализированых задач, для которых впринципе движков нет.
Если исполнитель использует только свои наработки, просто потому что - скорее всего он хочет сделать то, что я написал в ответе автору вопроса.
Никита
> При грамотно организованной разработке (версионный контроль, трекер задач с правильно оформленными тикетами, документация) все без супер проблема переносится между командами.
Согласен, правда я бы сюда еще добавил покрытие тестами, соответствие стандартам оформления и правильность выбранной архитектуры. Но. Вы часто встречаете проекты, как описал автор вопроса но с реализацией, что вы привели в пример?
nepster09
Смотрите, ваш подход имеет право на жизнь. В случае сложных форма он будет даже удобен. Но для маленьких форм - это будет избыточным.
Однако добавив этот уровень абстракции над контроллером вы должны быть готовы к увеличению сложности вашего приложения, соответственно - количеству ошибок. Я не знаю как конфигурация подобного происходит в laravel. Если она не явная (только на основании тайпхинтинга) - это потенциальный источник ошибок.
> кстате руководством нашей команды он был выбран, только из-за популярности
Если только из-за популярности - вы уж извините, ваше руководство слепо.
> Когда данные доходят до экшина, я получаю массив k-v $request->all();
Если уж на то пошло, что вам мешает собирать dto в том же сервисе, что и проверять request? Превратить TestRequest в некую фабрику.
На моем текущем проекте есть в планах использовать подстановку аргумента UserInterface с выходом Symfony 3.2. С одной стороны это приводит к тем же проблемам, что и с внешней обработкой Request. С другой стороны - это очень упростит unit тесты (с этим строго, покрытие 98%). Так что это вынужденная мера.
> Я не просил мне указывать на composer
Я указал вам на composer с той целью, что есть принятые стандартные практики, которые стоит принимать, или по крайней мере знать о них.
> я спрашивал про принцип единой ответственности
Понятие SRP намного больше, чем раскидывать что-то по классам, или не раскидывать. Его стоит применять и для методов тоже. Каждый класс должен решать конкретную отдельную задачу. Ваш пример с загрузчиком плох для демонстрации как раз потому, что задача автозагрузки не должна иметь множества реализаций, иначе получите хаос.
На счет переменных (которые оказыватся константы) - это неявная зависимость. Каждый класс должен быть независим на сколько это возможно, но без противоречия здравому смыслу.
> Если core.php настраивает приложение при работе, нарушится ли принцип единой ответственности если в него так же записывать функции загрузчики
Да, нарушает. Вы же сами пишете: "настраивает" и "функции загрузчики". Какая может быть единая ответственность?
> Как тогда учиться программированию, если у всех один аргумент "Не учись, все уже сделано"
Так, что бы не учиться хреновым практикам, о которых вам написали 2 человека. Вот вам пример SRP: сервис регистрации пользователей, он на вход принимает данные в DTO, запихивает их в Entity и сохраняет в БД. Более ничего не делает.