Front end pierwszy lub back end pierwszy. Z tych dwóch, które są dobrą praktyką projektowania systemu?

Mam teraz klienta, który wymaga ode mnie opracowania szkolnego systemu rekrutacji. Teraz po raz pierwszy mam tego rodzaju wyzwanie. Większość wcześniejszego oprogramowania, które stworzyłem, nie jest tak skomplikowane.

Wiem, że większość z was stworzyła skomplikowane oprogramowanie, chcę tylko Waszej porady w tej sprawie. Czy powinienem zaprojektować najpierw przód czy tył?

dzięki!

Oto konkluzja artykułu, który jakiś czas temu znalazłem w Internecie. Po prostu chcę się podzielić

http://www.skitoy.com/p/front-end-vs-back-end-developers-my-take/157

Front-end vs. back-end developers (moja opinia)

Moje osobiste podejście

Znów jest to kwestia treningu, kilka ogólnych uogólnień:

Programiści front-end

• Zazwyczaj nie masz dyplomu CS ani dyplomu CS ze szkoły trzeciego poziomu.
• Pracuj w językach podobnych do podstawowego (patrz PHP is Basic)
• Posiadaj umiejętności wizualne w konwertowaniu dokumentów z Photoshopa do CSS / HTML / itp.
• Mają wysoką tolerancję dla programowania iteracyjnego, ze względu na języki wolne od typów

Programiści zaplecza

• Mają stopień CS lub duże doświadczenie
• Mają bardziej systematyczne podejście do rozwiązywania problemów
• Nie przejmuj się spędzaniem dni na znajdowaniu jedynego przeciekającego obiektu
• Spróbuj zbudować narzędzia do rozwiązywania problemów

Jeśli zaczniesz od tyłu i pójdziesz naprzód, ryzykujesz niezrozumienie klienta. Ponieważ będziesz tworzyć rzeczy, których nie mogą łatwo zobaczyć i zrozumieć, nie mogą oni bardzo łatwo uczestniczyć w sprawdzaniu, czy spełniasz wymagania. Oznacza to, że możesz zmarnować dużo pracy.

Jeśli zaczniesz od przodu i cofniesz się, ryzykujesz, że klient pomyśli, że jest prawie gotowy, gdy tylko narysujesz prosty formularz na ekranie. Mogą wtedy zapytać, dlaczego to trwa tak długo, skoro przeważnie skończyłeś w ciągu kilku dni. Ryzykujesz także zamalowaniem się w kącie, kiedy zdajesz sobie sprawę, że musisz wykonać skomplikowaną pracę, aby łączyć przód z tyłem, kiedy bardziej odpowiedni front byłby prostszy.

IMO, powinieneś najpierw nad tym pracować. Napisz razem przód i tył dla każdej funkcji w systemie. Daje to klientowi lepszą widoczność postępu i daje mu możliwość powiedzenia „nie, nie o to mi chodziło”, bez powodowania zbyt dużego stresu.

To powiedziawszy, jeśli jest to bardzo duży projekt, w którym musisz wziąć pod uwagę sprzęt serwera lub możliwości dowolnego oprogramowania, na którym się opierasz (np. Jakiej bazy danych używasz), prawdopodobnie powinieneś najpierw dobrze przemyśleć tę część.

Oprogramowanie ma wiele wymiarów, dlatego nadmiernie uproszczony front-back-back jest złym pytaniem i bardzo, bardzo trudno jest podać rozsądną, przydatną odpowiedź.

Jeden widok to statyczna struktura danych. W tym widoku istnieją co najmniej trzy wymiary: warstwy architektoniczne („od przodu do tyłu”), przypadki użycia i podmioty, a także koszty lub ryzyko wdrożenia.

Jednym z widoków jest dynamiczna struktura przetwarzania. Istnieją również co najmniej trzy wymiary tego widoku.

Trzeci widok to komponenty architektoniczne, które naturalnie dzielą się na warstwy, obsługują przypadki użycia oraz wiążą się z kosztami i ryzykiem.

Mógłbym kontynuować, ale o to chodzi.

Front-end vs. back-end developers (moja opinia)

To w przybliżeniu najmniej przydatny sposób spojrzenia na problem. Faktyczni programiści - i wasze opinie na ich temat - mają tutaj bardzo, bardzo małe znaczenie. Co się liczy

• Używaj skrzynek i aktorów

• Logiczny model danych do obsługi tych przypadków użycia

• Proces wykonywany jako część przypadku użycia

• Komponenty, których użyjesz do zbudowania logicznych i przetwarzających elementów przypadku użycia.

Dlatego większość ludzi mówi, że musisz rozłożyć system według historii użytkownika lub przypadku użycia.

Nie dokonuj ogólnych uogólnień na temat ludzi, którzy będą się rozwijać.

Ani. Co musi zrobić Twoja aplikacja? Upewnij się, że gorący zawór dostarcza ciepłą wodę, zimny zawór dostarcza zimną wodę, że woda przepływa przede wszystkim, że możesz przedłużyć rury tam, gdzie jest to potrzebne, a następnie martwić się wprowadzeniem rzeczywistej hydrauliki do wszystkich pomieszczeń domu lub tego, co będzie w domu właściwie wyglądają dokładnie tak.

Przedni koniec to tylko maska ​​z kilkoma przełącznikami i dźwigniami. Zaplecze to tylko rzecz, która odbiera żądania pobierania i przetwarzania danych. Przejdź do punktu, w którym możesz szybko wdrożyć oba w dowolnej pożądanej kombinacji.

Ale cokolwiek zrobisz, nie pozwól, aby projekt jednego dyktował projekt drugiego. W ten sposób leży szaleństwo.

Przygotuj narzędzia, które pozwolą Twoim deweloperom zbudować wszystko, czego potrzebują dla Twojego klienta, niezależnie od tego, ile razy zmieniają zdanie. Następnie zbuduj go zgodnie ze specyfikacjami i uruchom ponownie, aż małe guziki będą w końcu szczęśliwe.

Porównywanie deweloperów front-end do deweloperów back-end w 2008 roku jest dawno temu w latach internetowych. Dla zabawy chciałbym poprawić / dodać kilka rzeczy do tego starego kasztana, ponieważ połączyliśmy go w pytaniu, ale także (mam nadzieję) umieść kilka wskazówek w:

Programiści front-end

Zazwyczaj nie masz dyplomu CS ani dyplomu CS ze szkoły trzeciego poziomu.

Podniesienie rąk. Ile osób z dyplomem CS zostało nauczonych najlepszych praktyk z zakresu obsługi? Lub jak nie robić bałaganu za pomocą JavaScript? Lub jak radzić sobie z problemami CSS z IE6-IE9? Przemysł podręczników, który prowadzi akademię, jest zbyt gruby, leniwy i wzdęty, aby poradzić sobie z ciągle zmieniającymi się technologiami, dlatego bardzo mało uwagi poświęcił kolegiom. To było doskonałe dla późno kwitnących jak ja.

Pracuj w językach podobnych do podstawowego (patrz PHP is Basic)

Ponieważ PHP to technologia po stronie klienta? A może JavaScript, który został zainspirowany przede wszystkim przez Scheme, ma więcej wspólnego z Basicem niż Visual Basicem, który nie jest już dłużej dostępny w interfejsie i nigdy tak naprawdę nie był, ale jest nadal dostępny dla aplikacji webowych .NET? Blog porównuje samouków programistów internetowych typu open source z programistami klasy CS używającymi popularnej technologii w tym momencie. Po obu stronach tej konkretnej walki natrafiłem na niezrównane i kompetentne udziały w równych częściach, ale wciąż jest tam OT.

Posiadaj umiejętności wizualne w konwertowaniu dokumentów z Photoshopa do CSS / HTML / itp.

Więcej uwagi na szczegóły niż „umiejętność wizualna”, która jest nieco szeroka. Nie każdy z nas ma jakiekolwiek umiejętności w zakresie estetyki. Ale tak, większość z nas musi się tego nauczyć na poziomie Jr. i jest to naprawdę bardzo ważne, aby napisać dobry interfejs użytkownika, który nie używa młotów JS, gdy skalpele CSS to zrobią.

Mają wysoką tolerancję dla programowania iteracyjnego, ze względu na języki wolne od typów

Właśnie dlatego chcesz, aby utwory, o których wcześniej wspomniałem, były na pierwszym miejscu. Przekazujemy wciśnięte przyciski, a Ty produkujesz / odzyskujesz towary. Pakujemy je i dostarczamy. Nie ma powodu, aby te rzeczy były ściśle związane ze sobą. Również naprawdę ścisłe pisanie na klawiaturze nie powinno zakłócać iteracyjnego procesu, jeśli nie jest do bani w OOP, co większość ludzi, którzy lubią wyśmiewać się z języka, który technicznie nie ma zajęć, zazwyczaj tak robi. Ale nawet jeśli śmierdzą, interfejs potrzebuje tylko przewidywalnego punktu dostępu i możesz robić, co chcesz, na zapleczu, o ile nie robisz czegoś głupiego, jak dynamiczne pisanie JavaScript, który nie jest JSON lub ściśle powiązać udane zachowanie zaplecza ze strukturą HTML, która jest „po prostu”. * kaszel * java devs * / kaszel *

Nie ma jednej właściwej odpowiedzi na to pytanie. Każde podejście może być dobre (i złe) w niektórych sytuacjach.

Zalecam rozważenie podejścia TDD, w którym prowadzi się przez testy (akceptacyjne i jednostkowe).

Zacznij od złożenia szkieletu systemu: podstawowej infrastruktury z absolutnie minimalną funkcjonalnością. To tylko po to, aby pokazać, że twoja koncepcja działa, a różne komponenty mogą ze sobą współpracować. Obejmuje to również interfejs użytkownika z odkrytymi kośćmi (jeśli dotyczy), wystarczający do zrobienia i / lub pokazania czegoś minimalnego.

Następnie dopracowujesz szczegóły, funkcja po funkcji : napisz test akceptacji dla konkretnej cechy / scenariusza, spraw, by się nie powiódł, a następnie napisz kod, aby go spełnić. To sprawia, że pracujesz do wewnątrz z zewnątrz : system odbiera komunikat wejściowy, więc musisz obsłużyć / przekonwertować ten komunikat, zrobić coś z nim, a następnie propagować wyniki z powrotem do interfejsu użytkownika. Po drodze odkryjesz koncepcje domen i reprezentujesz je za pomocą nowych klas, od interfejsu użytkownika do warstwy domeny iz powrotem.

W przypadku tego podejścia zalecaną lekturą jest Rosnące oprogramowanie obiektowe, kierowane testami .

API pierwszy

Inżynierowie z obu zespołów powinni współpracować nad interfejsem API między front-endem a back-endem. Następnie oba zespoły mogą rozpocząć pracę w oparciu o zaprojektowany interfejs API. Ma to tę zaletę, że inny zespół front-end może również rozpocząć pracę (być może mobilny, po kliencie WWW), poza oczywistą zaletą, że zespoły mogą rozpocząć pracę równoległą.

Połącz z iteracyjnym podejściem i powinno to wyglądać tak:

1. Zaprojektuj prosty interfejs API
2. Oba zespoły opracowują i testują w oparciu o interfejs API
3. Test integracyjny
4. Pokaż klientowi i otrzymaj informację zwrotną.
5. Ulepsz API i powtórz.

Zacznij od interfejsu, ale po pierwsze, dlaczego nie mogą znaleźć aplikacji, która już istnieje? Dałoby to więcej wglądu w ten projekt. Czy mają jakieś unikalne wymagania, czy uważają, że możesz budować taniej?

Dowiedz się, jakie są ich oczekiwania w zakresie bezpieczeństwa i jakie jest prawo. Nie jestem pewien, jaki to typ szkoły, ale informacje o uczniach zwykle wymagają pewnej poufności.

Jeśli potencjalni studenci wprowadzają dane na stronie internetowej, projekt graficzny będzie bardziej problemem.

Na podstawie ich wniosków narysuj makiety interfejsu. Jeśli uważasz, że gui nie jest proste, być może będziesz musiał stworzyć coś funkcjonalnego, aby mogli zobaczyć to w akcji. Mogą postrzegać rejestrację jako pewnego rodzaju „kreatora”, który rozgałęzia się w różnych kierunkach w oparciu o wprowadzanie danych.

Następnie możesz zacząć uzyskiwać informacje utrwalone w bazie danych.

Tak, zdałem sobie sprawę, że OP poprosił jakiś czas temu. Zacznij od zaplecza, ale ZABLOKUJ interfejs, aby użytkownik mógł zobaczyć, co sobie wyobrażasz. Front, mimo wszystko, co warte jest, to tylko dzwony i gwizdy. Na zapleczu znajdują się pieniądze, a gdy masz już to proste, FE jest po prostu sosem nad mięsem.

Rozszerzając mój komentarz:

Najpierw zbierz wymagania, a następnie zmień je w Przypadki użycia i projekt.

Najpierw pojawia się szczegółowa definicja bazy danych. Nie dbam o to, czy klient nie do końca się zdziwi, zmuszam ich, aby usiedli i popatrzyli na to - i podpisali się na nim (być może wtedy zmuszali mnie, by zdać sobie sprawę, że kiedyś bardziej zaawansowani technicznie faceci powinni to zrobić ), przed kontynuowaniem.

Jak zacząć od FE bez BE? FE za co ??? Zdefiniuj swoją bazę danych !! To właśnie manipuluje FE.

Ok, nie będzie problemów i późniejszych poprawek, a ja zrobić zgadzają się, że jest dobry, aby uzyskać prosty, próbki GUI przed klientem ASAP, ponieważ szczególności wierzchołek góry lodowej tego, co jest najbardziej najbardziej zrozumieć.

Jednak 1) podkreślam, że jest to tylko makabryczna makieta do dyskusji morświnów, oraz 2) celowo czynię ją brzydką, ale funkcjonalną , aby ci, którzy nie rozumieją, mogli ją poderwać i kazać mi zrobić pole wprowadzania dokładnie 400px szerokie i jasnoniebieskie tło.

Doszedłem do wniosku, że większość odpowiedzi tutaj (i śledziłem je) ma tendencję do zbytniego skupiania się na kliencie, ale z czysto białego punktu widzenia twierdzę, że nie można zaprojektować FE do manipulowania BE bez wcześniejszego projektowanie tego BE.