Go to file
2024-04-14 22:59:22 +02:00
bin chore: Add instructions 2024-04-14 22:59:22 +02:00
config TASK-35: Send orders to CRM 2024-04-14 20:17:21 +02:00
docker/nginx chore: Initial commit 2024-04-14 15:47:41 +02:00
features 36: Add order validation 2024-04-14 22:42:40 +02:00
migrations chore: Initial commit 2024-04-14 15:47:41 +02:00
public chore: Initial commit 2024-04-14 15:47:41 +02:00
src 36: Add order validation 2024-04-14 22:42:40 +02:00
tests 36: Add order validation 2024-04-14 22:42:40 +02:00
translations chore: Add Behat and PHP Unit dependencies 2024-04-14 18:22:28 +02:00
.env TASK-35: Send orders to CRM 2024-04-14 20:17:21 +02:00
.env.test chore: Add Behat and PHP Unit dependencies 2024-04-14 18:22:28 +02:00
.gitignore chore: Add Behat and PHP Unit dependencies 2024-04-14 18:22:28 +02:00
behat.yml.dist TASK-35: Send orders to CRM 2024-04-14 20:17:21 +02:00
composer.json TASK-35: Send orders to CRM 2024-04-14 20:17:21 +02:00
composer.lock TASK-35: Send orders to CRM 2024-04-14 20:17:21 +02:00
docker-compose.yaml chore: Add instructions 2024-04-14 22:59:22 +02:00
Dockerfile chore: Initial commit 2024-04-14 15:47:41 +02:00
phpunit.xml.dist chore: Add Behat and PHP Unit dependencies 2024-04-14 18:22:28 +02:00
README.md chore: Add instructions 2024-04-14 22:59:22 +02:00
symfony.lock TASK-35: Send orders to CRM 2024-04-14 20:17:21 +02:00

Zadanie Rekrutacyjne

Projekt jest w całości zdockeryzowany - wymagany docker compose. Projekt testowałem jedynie na linuksie, ale powinien działać także na innych systemach.

Uuchomienie

# Skrypt, który odpali composera w tymczasowym kontenerze, zainstaluje zależności a następnie uruchomi projekt
$ ./bin/start.sh

Testy

Testy są napisane w phpunicie (tam gdzie testowanie jednostkowe miało sens) oraz w behacie (tam, gdzie chciałem przetestować integracyjnie). Oba zestawy testów można uruchomić jednym poleceniem:

$ ./bin/test.sh

Uwagi

  1. Robiłem jedynie to, co jest opisane w zadaniach - przykładowo dla zadania z saldem klienta zapewniłem jedynie, że jest ono zapisywane w sposób trwały - nie tworzyłem żadnych endpointów pozwlających na odpytanie o to saldo.
  2. W zadaniu 35 z przesyłaniem informacji do CRM pozwoliłem sobię na zmianę kodu HTTP z 400 na 422, który semantycznie zdaje mi się być bardziej poprawny. Ponieważ jest to styk z frontendem to taka zmiana powinna być możliwa do wdrożenia, gdyby to była końcówka wywoływana przez CRM takiej zmiany bym pewnie nie wdrażał.
  3. Założyłem, że walutą jest złotówka (lub inna waluta "dziesiętna"). Tam gdzie kwoty były podawane jako int uznałem, że mamy styczność z groszami (bo tak byłoby najbardziej poprawnie) tam, gdzie były to liczby zmienno-przecinkowe założyłem złotówki.
  4. Waga założyłem, że jest podawana w kg.
  5. Założyłem, że "co najmniej 5 produktów" oznacza "Co najmniej 5 różnych produktów".
  6. Nie robiłem żadnej autoryzacji - zakładam, że odpowiednie mechanizmy są już w aplikacji dostępne i gotowe do użycia.
  7. Architekturę starałem się trzymać jak najprostszą, jednak sugerując się kontekstem zadania uważam, że w przypadku rzeczywistym należałoby ją trochę zmienić - całość wygląda jakby fajnie się implementowała jako jakaś architektura eventowa.
  8. Zadania robiłem w kolejności takiej, jaka zdawała mi się najbardziej odpowiednia - zakładam, ze w rzeczywistości też miałbym wgląd do backlogu i możliwość pewnej dowolności.
  9. W walidacji zamówienia jest wyraźnie mowa o saldzie dodatnim - a nie wystarczającym. Oprogramowałem to zgodnie ze spisanymi wymaganiami, jednak w rzeczywistości upewniłbym się, czy na pewno chcemy pozwalać wchodzić na dowolny debet. Wszak zamówienie może być warte milion, a klient może mieć saldo wynoszące 1 grosz.
  10. Zadania 39, 40 zrobiłem przy okazji dla dopełnienia zestawu testowego ;)
  11. Nie celowałem w pokrycie testami 100% ani nic, pisałem testy, gdzie uznałem za słuszne.
  12. Pewnie przydaloby się jakieś logowanie w aplikacji ale z doświadczenia logi najlepiej dodawać na podstawie konkretnych sytuacji aby nie spamić