Проходил я значит тестовое задание, которое дают кандидатам на должность php-программиста. Спойлер: Вот задание(выкладываю как дали) Тестовое задание: спроектировать модуль для доставок. Две службы доставок: Птичка: base_url: string @var kladr string //кладр куда везем @var code string //код товара @return json { "price": float //стоимость "period": int //количество дней начиная с сегодняшнего, но после 18.00 заявки не принимаются. "error": string } Черепашка: имеет базовую стоимость 150р base_url: string @var kladr string //кладр куда везем @var name string //название товара @return json { "coefficient": float //коэффициент (конечная цена есть произведение базовой стоимости и коэффициента) "date": //дата доставки в формате 2017-10-20 "error": string } Нужна возможность получить для товара (стоимость 100.00 и дату 20.10.2017) как в списке всех доставок так и конкретной службы. Подразумевается что есть доступ к хранилищу, возможно получить по имени - код товара и по коду - название товара. В результате должен получиться модуль, фрагмент программы, или набор классов и интерфейсов, или вообще файл с портянкой несвязного кода. Т.е. результат зависит полностью от исполнителя. Задача поставлена максимально широко, чтобы понять на каком уровне разработчики готовы выполнять задачи и какие требования к себе предъявляют и/или какие требования к ним предъявляют лиды. Качество выполнения задания должно быть таким, чтобы заказчик понимал качество кода который он получит, и исполнитель понимал качество кода который ждет заказчик. Тестовое задание призвано достичь понимания в этом вопросе. Ожидаемый минимум это легко расширяемый модуль, с интерфейсами, покрытый доками, спроектированный с использованием классических шаблонов и классических принципов ООП, таких как solid, dry, kiss и оформление по psr. Готовый взлететь на php7. Мысли и причины реализации приветсвуются. Результат записывать ни куда не нужно, все данные которые понадобятся при работе, обращение к службам доставок и чтение из хранилища, необходимо с эмулировать (можно забить жестко в коде). Я сначала час тупо пытался понять что от меня хотят. Потом чёто накатал и отослал им. Они мне сказали, что я им не подхожу. Вот git-репозиторий с тем что я сделал. https://bitbucket.org/machetero/shipping-module Прошу советов уважаемых форумчам, что сделано не так и как надо было сделать. PS: Кстати, до сих пор не уверен в том, что правильно понял тз.
А как этим пользоваться то? PHP: /** * Public method, that application will be working with. * * @param $serviceID * @param $kladr * @return mixed * @throws InvalidServiceID */ public function getShippingPrice ($serviceID, $kladr) {} Куда код / название товара передавать? Как впилить новую службу доставки? Куда вообще слать данные товара, что бы потом получить итоговый расчет? Как получить сразу несколько?
Отличное тестовое задание. Всерьёз. Парни просто показали, что им не нужен кодер, для которого надо писать талмуды тз. Кстати, не лишним спрашивать в чем базово не устривает реализация всегда.
Мне не предвзято судить сложно: работал над логистическим сервисом интегрированном с сотнями служб доставки в большинстве часовых поясов, поэтому претензии к каждой строке кода, как и к структуре проекта в целом. Базовые вопросы @romach задал уже, прямо указанные в тестовом. Твой код задачи названные не решает просто. Об остальном без этого нет смысла говорить
@romach Я не понял зачем слать имя или код товара в "Птичку" или "Черепашку", чтобы рассчитать стоимость доставки. Мой модуль только рассчитывает стоимость доставки по кладру. А новые службы доставки добавляются через конфиг модуля(это предусмотрено).
В тз же у тебя написано что ты передаешь службе доставки и что получаешь в ответ. Расширяемость сервиса это не значит что в конфиг нужно все выносить. Это предполагает что реализована, например, некая базовая сущность службы доставки от которую можно наследовать/реализовывать и расширять (как раз тебе по этой причине дали отличительное свойство у одной службы доставки - коэфициент стоимости). Вот это про ООП-реализацию как раз, которую тимлид предположительно хотел к тебя увидеть. --- Добавлено --- Если ты спрашиваешь зачем с поактической точки зрения передать в службу доставки название товара для стоимости, то это совершенно конкретный бизнес-кейс, идентификаторы или коды товаров туда могут передаваться для получения стоимости. Зачем? Например товары с их размерами были добавлены ранее в базу службы доставки по их апи
Тогда надо было уточнять, не стеснятся. Плохо не не понять, плохо потратить ресурсы и сделать не то, что нужно. * Иногда пишу с телефона и ошибки не успеваю исправить в тексте, прошу прощение
1) Каждый подбирает команду под себя - это нормально. Поэтому не напрягайся, - может им твоя аватарка не понравилась. 2) "чёто накатал" - это первая ошибка. 3) У тебя нет файла, что-то вроде "index.php", чтобы "запустил и посмотрел". Это вторая ошибка (IMHO). 4) Стиль кода хромает. Это третья ошибка. 4) И четвёртая, главная, ошибка - проектирование. Тоже имхо, - ты слишком упростил. Насколько я понял, они хотят 100%-й ООП. Точнее, максимальное приближение к нему. Попробуй обратиться к ним с просьбой повторить тест, типа "я сначала не понял, чего вы хотите, а теперь дошло". п.с. А зачем комментарии на английском? Ты же пишешь для российской конторы. Это нельзя считать ошибкой, но всё же показатель.
я слабо разбираюсь в ООП)) но мне кажется они хотели что бы был или интерфейс или абстрактный класс от которого надо было уже создавать класс для разных служб доставки.. но я если что не очень шарю в проектировании чего то такого с нуля)) 99 процентов моих работ это работа с готовой архитектурой приложения)
Там собеседование только после прохождения тестового задания. Я писал на англ., чтобы они знали, что я его хоть сколько то знаю. --- Добавлено --- В том то и дело: обратиться можно только к HR'у(общаешься только с ним) , а задание давал тимлид, к которому тебя не пустят пока не пройдёшь это тестовое задание.
Все можно если заранее попросить чтобы передали развернутый фидбек. в любом случае, основные причины тут уже назвали