32 lines
2.8 KiB
Markdown
32 lines
2.8 KiB
Markdown
# 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
|
|
```bash
|
|
# 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:
|
|
|
|
```bash
|
|
$ ./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ć
|