По сути всё верно — на практике нет нужды добавлять интерфейсы на всё, так как код становится непоследовательным, слишком абстрактным и менее читаемым. Да, он станет гибче, но вспомнить потом по нему работу бизнеса окажется той ещё задачей.
Единственно, я бы добавил интерфейсы на то, что может часто меняться и что нужно будет протестировать в первую очередь, например: FeedbackReportInterface — чтобы сразу заложить структуру репорта независимо от его формата (XML, HTML, JSON) и потом не менять весь связанный код. Плюс разделил бы процесс на создание репорта в нужном формате и его отправку (считай, конвертацию FeedbackReportInterface в объект Email, который знает наш мейлер). Тогда сразу заложим гибкость в плане сочетания разных форматов и разных каналов распространения без добавления лишних слоёв абстракций.
То есть важно за интерфейсами скрывать то, что реально может поменяться в ближайшей перспективе, а не то, что краеугольное и базовое. Если оно и будет меняться, это в любом случае потребует большого рефакторинга и тестов. Так, никогда не понимал тех, кто пишет абстракции на классы, работающие с базой, когда и так есть ORM как слой абстракции. В данном примере это стоило бы сделать только в том случае, когда при обсуждении фичи с бизнесом, нам бы сказали, что да, в идеале в будущем можем перенести репорты в другое хранилище, но пока надо протестить фичу и всё будет в базе. Тогда можно задуматься об интерфейсе, или хотя бы просто о сервисе FeedbackStorage, в который инджектить репозиторий. Когда и если задача дорастёт до смены стораджа, Репозиторий можно будет заменить на другой класс, при этом не затронув выше стоящие слои, всё ограничится изменениями в FeedbackStorage и написанием тестов на него (если ещё нет).
Победитель — 41 минута. Серьезно? Кааак? Может быть телефон не попался?
Имхо, просто нереально пройти с первого раза все задания за 41 минуту. Реквестирую скорость выполнения победителями каждого из заданий.
p.s^ еще обещали вот что:
Победители
[...]
За лучшее время в каждой конкретной задачке — сертификат на облачный хостинг, на 1 месяц.
Уже додумались. Тоже была такая идея, изучил вопрос и решил не ввязываться. Есть пару проектов на западе и даже один у нас. Проблема в юридической стороне дела. Тут вроде как безвозмездное пожертвование (футболки и диски — лишь подарки), а когда вкладываются деньги, то нужны договора с каждым участником. Из-за расходов на это, нет интереса работать с мелкими инвесторами, в результате чего появляется порог вхождения, например 5000 рублей. Не так много, но большинство отсеется здесь. В то же время, такую сумму люди готовы вкладывать, но не готовы терять. Нужны гарантии, нужны рычаги управления того, во что вложился, нужен доступ к финансовой информации (а то вдруг прибыль зажилят). В общем, когда люди вкладываются для фана и мысленно готовы потерять вложенные деньги — это одно, но если к этому относится как к настоящему инвестированию — все входит в деловое русло и становится серьезным.
Не работаю с Joomla, но со стороны — большой бардак и маразм.
От Joomla Platform отказались, так как она нигде не использовалась, кроме своей CMS, так решили разработать фреймворк, который теперь вообще никто не использует, даже они сами.
Соглашусь, что слишком поверхностно. С одной стороны, такой подход тоже неплох — ссылки указаны, изучай каждую из технологий по мере появления в тексте статьи, потом возвращайся к статье и т.д. В конце получится, что знаком уже с несколькими технологиями сразу. Но с другой стороны, статья в этом случае должна называться не «Web-разработка на node.js и express. Изучаем node.js на практике», а «Основные вещи, которые должен знать каждый, кто хочет писать на node.js и express». Практики тут очень мало. Но в целом, даже за подборку ссылок стоит сказать спасибо.
Если бы вы не написали этот комент, его написал бы я. Подписываюсь под каждым словом. Плюс еще (обращаюсь уже к автору) обратите внимание на скорость анимации: как-то все замедленно движется. Постарайтесь приблизить физику вымышленного мира к физике реального.
Подпишусь под каждым словом. Главный минус не в том, что ФОС громоздкий, а в том, что он необъяснимо громоздкий. В том смысле, что документация мало освещает большую часть из используемой им магии. Особенно глухо ситуация выглядит для новичка. Кстати, тоже самое можно сказать и про формы, разве только там проблема менее острая.
Да дело не в том, что мало плюсующих, а в том, что относительно много молча минусующих:) В принципе, если помог двум людям, то этого достаточно для самоудовлетворения. Теперь вы должны перевести по одной статье, их прочитают 4 человека, которые переведут по одной статье, которые прочитают уже 8 человек, которые… ну, дальше вы поняли — symfony-сообщество захватывает Землю.
По сути всё верно — на практике нет нужды добавлять интерфейсы на всё, так как код становится непоследовательным, слишком абстрактным и менее читаемым. Да, он станет гибче, но вспомнить потом по нему работу бизнеса окажется той ещё задачей.
Единственно, я бы добавил интерфейсы на то, что может часто меняться и что нужно будет протестировать в первую очередь, например: FeedbackReportInterface — чтобы сразу заложить структуру репорта независимо от его формата (XML, HTML, JSON) и потом не менять весь связанный код. Плюс разделил бы процесс на создание репорта в нужном формате и его отправку (считай, конвертацию FeedbackReportInterface в объект Email, который знает наш мейлер). Тогда сразу заложим гибкость в плане сочетания разных форматов и разных каналов распространения без добавления лишних слоёв абстракций.
То есть важно за интерфейсами скрывать то, что реально может поменяться в ближайшей перспективе, а не то, что краеугольное и базовое. Если оно и будет меняться, это в любом случае потребует большого рефакторинга и тестов. Так, никогда не понимал тех, кто пишет абстракции на классы, работающие с базой, когда и так есть ORM как слой абстракции. В данном примере это стоило бы сделать только в том случае, когда при обсуждении фичи с бизнесом, нам бы сказали, что да, в идеале в будущем можем перенести репорты в другое хранилище, но пока надо протестить фичу и всё будет в базе. Тогда можно задуматься об интерфейсе, или хотя бы просто о сервисе FeedbackStorage, в который инджектить репозиторий. Когда и если задача дорастёт до смены стораджа, Репозиторий можно будет заменить на другой класс, при этом не затронув выше стоящие слои, всё ограничится изменениями в FeedbackStorage и написанием тестов на него (если ещё нет).
Имхо, просто нереально пройти с первого раза все задания за 41 минуту. Реквестирую скорость выполнения победителями каждого из заданий.
p.s^ еще обещали вот что:
От Joomla Platform отказались, так как она нигде не использовалась, кроме своей CMS, так решили разработать фреймворк, который теперь вообще никто не использует, даже они сами.
А между тем ведь идея и в правду интересная. Свежий взгяд на ММОРПГ.