если именно против, то первое это очень сильно мешает тестированию, нельзя замокать или как-то изменить этот контракт.
мы "прибиваем" зависимость гвоздями, если что-то изменится, версия к примеру, или добавиться провайдер данных, или любое другое поведение изменится, то будет очень неудобно с этим работать, как я показал выше, в одних случаях нам нужен один провайдер, в других - другой, а сама логика формирования сообщения остается одной и той же, нужно будет лезть и менять код и все равно приходить к внедрению зависимости
если каждый раз вызывать new то это и по perfomance такое себе, выделение памяти, процесорное время, если это делать часто то есть определенный оверхед (тут конечно надо смотреть на ситуацию, DTO предположим вполне себе нужно создавать каждый раз на разные данные)
в целом можно и через new но тут надо учитывать то: что описано выше и думать - а надо ли, плодить много контрактов где вообще не предвидиться никаких изменений только усложнять кодовую базу.
И 90% разработчиков как частных так и в компаниях не умеют и не могут поправить входное ТЗ. Для этого в фирмах есть бизнес аналитики, которые вытаскивают клещами всю инфу из заказчика, чтобы это не было убыточным мероприятием.
Если вы способны сами провести бизнес анализ, поздравляю вас, но это отдельная профессия.
wukibuh Сайт посмотрите для начала, что-ли. Это не сайт визитка, а достаточно большой агрегатор и чёрт знает что там под копотом у него.
И то что вы в разработке с 1998 года ни о чём не говорит вообще.
Можно 20 лет Hello World писать, а можно после двух лет проектировать и реализовывать highload проекты.
И вы Техническое задание, с проектирование не путайте. Разработчику нужен бизнес функционал, чтобы обернуть его в техническую реализацию. Если разработчик начнёт лезть в бизнес, то он или офигено разбирается в этом бизнесе, доподлино знает всё организацию заказчика, как она работает, сколько человек и прочее, или дурак и в итоге будут:
а) Задержки
б) Переписывания потому что заказчик не знал чего хочет, а разработчик сделал на своё усмотрение
в) Нервы деньги время в минус
г) Больше никто не будет ни с кем работать.
Так что не несите бред. На этом закончу. Удачи вам в ваших начинаниях.
@wukibuh
ТЗ не сложная задача?)
Бизнес-аналитики негодуют)
Расписать схемы взаимодействия, функционал и прочее подогнав под рамки бизнеса, и бизнес процессов?
Вы видимо в серьёзной разработке не участвовали враз думаете что ТЗ пишется легко и самостоятельно.
Я видел только один раз реально хорошо подготовленное ТЗ на разработку проекта (проекта а не фичи) которое мне не пришлось перепиливать полностью, а только немного уточнить, это ТЗ было построено на прототипе который уже действовал, и там уже человек набив шишки, точно понял что ему нужно.
Всё, больше грамотных ТЗ я не видел. Все написаны или через Ж, или настолько минимально как указано в вопросе (запили мне что-то похожее на что-то)
Да. Всегда нужно фильтровать данные на сервере. По факту неизвестно откуда они приходят, а если не известно значит они не обработаны и их надо обработать.
Фильтрация по заголовкам на стороне клиента... тут от приложения зависит.
Вообще фильтруются данные. (Вы же имеет ввиду фильтрацию а не валидацию). Т.е. всё что можно отфильтровать в рамках разумного, можно делать на клиенте, не обязательно но можно.
Там хорошо написано.
Всё равно программирование это 50% времени чтения кода, так что сперва читать, потом писать.
А для начала надо прочесть мануал по выбранному языку. (PHP Python Ruby C# Java Go).
В принципе вполне можно уложиться в месяц чтобы написать что-то что будет вести себя вполне удобоваримо.
Лучше взять Java или C# там меньше гавнокода получится =)
А во всех "учебниках" жуткий шлак который надо помечать тэгом "как делать не надо".
Попробуйте запустить вот с таким вот конфигом.
Т.е. забэкапте текущий my.cnf и пропишите этот новый, если стартанёт значит надо разбираться с настройками конфига.
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1
# Disabling symbolic-links is recommended to prevent assorted security risks;
# to do so, uncomment this line:
# symbolic-links=0
грубо говоря индекс составляется последовательно:
сперва индекс по полю которое максимально уменьшит первую часть выборки, потом второе поле по которому будет что-то находится из того что осталось.
Ну вот у вас статус положим.
oldStatus 0 - новый 1 - отправленный - итого статуса всего два (новый и отправленный).
По сути email у нас не уникальный а значит предположим что записей с одним email может быть 100, а всего записей 10000.
Теперь используя знания по формировании индексов в MySQL мы понимаем что сперва нам нужно найти все записи с указанным email и уже в них искать подходящие статусы.
Mikhail Osher Да и пишется это всё на микросервисах (портал по факту большой, и монолитом его писать глупо). Так что тянуть на каждый микросервис Symphony который медленный как черепаха... Или взять раскидать всё на ноду, где есть асинхронность?)
мы "прибиваем" зависимость гвоздями, если что-то изменится, версия к примеру, или добавиться провайдер данных, или любое другое поведение изменится, то будет очень неудобно с этим работать, как я показал выше, в одних случаях нам нужен один провайдер, в других - другой, а сама логика формирования сообщения остается одной и той же, нужно будет лезть и менять код и все равно приходить к внедрению зависимости
если каждый раз вызывать new то это и по perfomance такое себе, выделение памяти, процесорное время, если это делать часто то есть определенный оверхед (тут конечно надо смотреть на ситуацию, DTO предположим вполне себе нужно создавать каждый раз на разные данные)
в целом можно и через new но тут надо учитывать то: что описано выше и думать - а надо ли, плодить много контрактов где вообще не предвидиться никаких изменений только усложнять кодовую базу.