Kiedy zacząłem uczyć się PHP (około 5 lub 6 lat temu), dowiedziałem się o Ajaxie i przeszedłem „fazy”:
- Serwer zwraca dane w formacie HTML i umieścić go wewnątrz Doma innerHTML
- Dowiesz się o formatach przesyłania danych, takich jak XML (i powiesz „oooh, więc to jest to, do czego służy), a następnie JSON.
- Zwracasz JSON i budujesz swój interfejs użytkownika za pomocą waniliowego kodu JavaScript
- Przechodzisz do jQuery
- Dowiesz się o interfejsach API, nagłówkach, kodach stanu HTTP, REST , CORS i Bootstrap
- Uczysz się SPA i frameworków frontendowych ( React , Vue.js i AngularJS ) oraz standardu JSON API.
- Otrzymujesz trochę starszego kodu przedsiębiorstwa i po jego sprawdzeniu okazuje się, że robi to, co opisano w kroku 1.
Ponieważ pracowałem z tą starszą bazą kodu, nawet nie pomyślałem, że może ona zwrócić HTML (to znaczy, jesteśmy teraz profesjonalistami, prawda?), Więc trudno mi było znaleźć punkt końcowy JSON, który zwraca dane, które wywołania Ajax wypełniają się. Dopiero zapytałem „programistę”, że powiedział mi, że zwraca HTML i jest dołączany bezpośrednio do DOM za pomocą innerHTML.
Oczywiście trudno było to zaakceptować. Zacząłem myśleć o sposobach przefaktoryzowania tego do punktów końcowych JSON, zastanawiając się nad jednostkowym testowaniem punktów końcowych i tak dalej. Jednak ta baza kodu nie ma żadnych testów. Ani jednego. I to ponad 200 000 linii. Oczywiście jednym z moich zadań jest zaproponowanie podejścia do przetestowania całości, ale w tej chwili jeszcze się tym nie zajmujemy.
Więc nigdzie się nie zastanawiam: jeśli nie mamy żadnych testów, więc nie mamy szczególnego powodu, aby utworzyć ten punkt końcowy JSON (ponieważ nie jest to „wielokrotnego użytku”: dosłownie zwraca dane, które pasują tylko w tej części aplikacji, ale myślę, że to już sugerowano, ponieważ ... zwraca dane HTML).
Co dokładnie jest złego w robieniu tego?