Inżynieria oprogramowania

Jak rozumiec i jak implementowac? Routing dla Frontend, Backend, Client Side, Server Side za pomoca google translator!

Jak rozumiec i jak implementowac? Routing dla Frontend, Backend, Client Side, Server Side za pomoca google translator!

Temat wydaje sie jasny dla programisty, ale jak rozumieja to nie-programisci?

Teoria

Cytat z wikipedii

https://en.wikipedia.org/wiki/Front_and_back_ends

In software engineering, the terms front-end and back-end refer to the separation of concerns between the presentation layer (front end), and the data access layer (back end) of a piece of software, or the physical infrastructure or hardware.

In the client–server model, the client is usually considered the front end and the server is usually considered the back end, even when some presentation work is actually done on the server.

Praktyka

Doswiadczenie jednego projektu

Pracujac w sredniej firmie (ponad 120 pracownikow, 40 programistow) wytwarzajacej oprogramowanie i uslugi reklamowe.

Spotkalem sie ze zdefiniowaniem dwoch czesci systemu: jako frontend i backend.

  • frontend – jako czesc dostepna dla klienta koncowego i wspolpracujacego w ramach umow.
  • backend –  jako czesc dostepna dla administratorow i pracownikow firmy reklamowej

Jako nowa osoba w projekcie zwrocilem na te konwencje uwage, co ciekawe nikogo to niedziwilo i bylo traktowane jako historycznie naturalne

Wnioski

Moim zdaniem nie bylo to trafne okreslenie, zwlaszcza ze bylo uzywane bezposrednio w adresie url:

http://{domena}/frontend

http://{domena}/backend

Inne rozwiazanie

Mysle, ze uzywanie w nomenklaturze bardzo prostych i podstawowych pojec nie powinno miec miejsca.

Jestesmy ekspertami, specjalizujemy sie kazdego dnia i to co dla nas wydaje sie oczywiste nie musi byc oczywiste dla innej osoby, klienta, managera.

Proponuje stosowanie nazw w zaleznosci od uzycia, ktore okreslaja nie zbior rozwiazan czy miejsce a konkretny objekt na ktorym beda wykonywane dzialania.

Mam swiadomosc, ze to tylko wierzochlek gory lodowej, jednak proponuje uzycie bardziej trafnych nazw, zamiast dla okreslenia.

Nalezy pamietac, by tez dbac o wiedze w firmie, by dbac o nazewnictwo i operowac nazwami precyzyjnymi, aby w momencie implementacji bylo wszystko jasne, gdyz potem moze byc zbyt duzo kosztow przy zmianie.

http://{domena}/frontend/user

 

Zmiana nie od raru musi byc oczywista, mozna by rzec, ze chodzi o klienta koncowego wiec: customer

http://{domena}/customer/config

proponuje isc dalej i zapytac jaka role pelni w tej czesci systemu ten customer, jesli np kupuje to: buyer

Proponuje wiec

http://{domena}/customer/buyer/config

Co mozna przetlumaczyc

Ustawienia dotyczace uzytkownika, ktory kupuje

Aby potwierdzic, czy jest to zrozumiale, sprawdzam, jak to tlumaczy google:

„customer buyer config”

„konfiguracja klienta kupującego”

– brzmi klarownie?

Sens zmiany

Nie chcialbym forsowac rozwiazania, zdaje sobie sprawe, ze w kazdej firmie i spolecznosci jest pewna kultura u nomenklatura, nie ma sensu jej na sile zmieniac.

Proponuje te kwestie dla nowych modulow aplikacji.

Tom
Latest posts by Tom (see all)
Tagi: , ,