Równoległy rozwój Aplikacji Webowych | Codesushi
0 likes71 views
Code & Pizza - Równoległy rozwój Aplikacji Webowych - czyli jak stworzyć pełnowartościowy produkt przynajmniej 2x szybciej - Codesushi CTO Chris Ozog
![Narzędzia których używamy: Symfony + bundle
● Symfony + FOSRestBundle + NelmioAPIDocBundle
○ Używamy gdy FrontEnd startuje z opóźnieniem
○ Backend zwraca na sztywno dane [czasem przydaje się: Faker]
● Zalety
○ Dokumentacja i kod w jednym miejscu
○ Autogeneracja Swaggera + Webowy klient to testowania Api
○ Brak konieczności podmiany Endpointa
● Wady
○ Konieczne jest zaangażowanie developera
○ Dłuższy start projektu
○ Zmiana w Mock Api wymaga zaangażowania BackEndowca](https://image.slidesharecdn.com/prezentacjacodesushi-codepizzagliwice1-170512130251/85/Rownolegly-rozwoj-Aplikacji-Webowych-Codesushi-8-320.jpg)
![Równoległy rozwój Aplikacji
Webowych - Podsumowanie:
● Umożliwia atak na wielu frontach
● Developerzy działają w oparciu o kontrakt - co daje większą
swobodę w planowaniu
● FrontEnd nie jest blokowany przez BackEnd
● Zastosowanie jedynie wtedy gdy możemy całkowicie odseparować
FrontEnd od BackEndu (Angular, Ember, Backbone, React)
● Doskonale nadaje się do tworzenia Minimum Viable Product [MVP]](https://image.slidesharecdn.com/prezentacjacodesushi-codepizzagliwice1-170512130251/85/Rownolegly-rozwoj-Aplikacji-Webowych-Codesushi-11-320.jpg)
Równoległy rozwój Aplikacji Webowych | Codesushi
- 1. Równoległy rozwój Aplikacji Webowych czyli jak stworzyć pełnowartościowy produkt przynajmniej 2x szybciej Chris Ozog - Codesushi CTO
- 2. Agenda: ● Coś o mnie… ● Podejście standardowe - czyli jak to robiliśmy kiedyś ● Podejście zrównoleglone - czyli jak to robimy teraz ● Narzędzia które nam w tym pomagają ● Case study ● Podsumowanie
- 3. Coś o mnie... ● Od ponad dekady twórca aplikacji webowych ● Uzależniony od czystego kodu ● Lider techniczny w Codesushi ● CodeReviewer z zamiłowania ● Filozof i Developer w jednym… i co gorsza jest to udokumentowane dwoma dyplomami
- 4. Podejście standardowe: 1. User stories 2. Rozpisanie Endpointów 3. Implementacja Endpointów 4. Przekazanie udokumentowanych Endpointów do FrontEndu 5. Prace Frontowe 6. … 7. Profit
- 5. Podejście zrównoleglone: 1. User stories 2. FrontEnd i BackEnd wspólnie ustalają Endpointy - powstaje kontrakt 3. Tworzymy Mock Api 4. FrontEnd i BackEnd zaczynają pracę równocześnie 5. W miarę postępu w Api, FrontEnd przepinia Endpointy z Mock Api na “żywe” Api 6. … 7. Profit
- 6. Narzędzia których używamy: Apiary ● Używamy gdy FrontEnd i BackEnd mogą wystartować równocześnie, lub BackEnd ma opóźniony start ● Zalety ○ Bogate możliwości dokumentowania ○ Dokumentacja i Mock Api w jednym ○ Mock Api nie wymaga dodatkowego setupu ● Wady ○ Konieczność nauczenia się nowego narzędzia ○ Konieczność przepinania frontu
- 8. Narzędzia których używamy: Symfony + bundle ● Symfony + FOSRestBundle + NelmioAPIDocBundle ○ Używamy gdy FrontEnd startuje z opóźnieniem ○ Backend zwraca na sztywno dane [czasem przydaje się: Faker] ● Zalety ○ Dokumentacja i kod w jednym miejscu ○ Autogeneracja Swaggera + Webowy klient to testowania Api ○ Brak konieczności podmiany Endpointa ● Wady ○ Konieczne jest zaangażowanie developera ○ Dłuższy start projektu ○ Zmiana w Mock Api wymaga zaangażowania BackEndowca
- 9. Narzędzia których używamy: Json-server ● Json-server (https://github.com/typicode/json-server) ○ Używamy w momencie gdy FrontEnd rozpoczyna pracę jako pierwszy ○ Prosty server który zwraca pliki json ● Zalety ○ Prostota ○ Mock Api może być wersjonowane wraz z projektem ○ Każdy developer może dokonać poprawek ● Wady ○ Wymaga zaangażowania developera do zmiany Mock Api ○ Oferuje tylko Mock Api, o dokumentację trzeba zadbać osobno ○ Zmiany w kontrakcie mogą pozostać niezauważone
- 10. Case study: ● Projekt dotyczył zbudowania od nowa mechanizmu zamawiania obozów sportowych ● Zespół ○ 1x BackEnd od klienta ○ 1.5x BackEnd Codesushi ○ 1x FrontEnd Codesushi ● Poprzednia wersja z mniejszą ilością funkcjonalności powstała w 12 miesięcy, a wersja przy której pracowaliśmy powstała w 3 miesiące ● FrontEnd: Angular 1.5.11 ● BackEnd: Symfony 2.8 ● Apiary zostało wykorzystane w pierwszym etapie projektu ● W późniejszym etapie wykorzystaliśmy: Symfony + bundle
- 11. Równoległy rozwój Aplikacji Webowych - Podsumowanie: ● Umożliwia atak na wielu frontach ● Developerzy działają w oparciu o kontrakt - co daje większą swobodę w planowaniu ● FrontEnd nie jest blokowany przez BackEnd ● Zastosowanie jedynie wtedy gdy możemy całkowicie odseparować FrontEnd od BackEndu (Angular, Ember, Backbone, React) ● Doskonale nadaje się do tworzenia Minimum Viable Product [MVP]
- 12. Dziękuję za uwagę :) e-mail: hello@codesushi.co www: codesushi.coKrzysztof Ożóg Codesushi CTO