Czynniki wpływające na wybór architektury. Moje doświadczenia

Wyobraź sobie: wchodzisz w nowy projekt, który jest dokładnie i dogłębnie przeanalizowany. W dodatku, masz czas na podjęcie decyzji dotyczącej architektury oprogramowania. Sytuacja idealna! Zadajesz sobie wtedy pytanie: na co zwrócić uwagę przy wyborze architektury? O tym w tym artykule.

Maciej Pachciarek. Programista Androida w firmie intive. Pierwsze aplikacje pisał już na Androida 1.6. Doświadczenie zdobywał w start-upach, dużych korporacjach oraz jako lektor w szkołach programowania. Na co dzień poza programowaniem zajmuje się estymacją projektów, projektowaniem nowych rozwiązań, wsparciem w projektach, rozmowami z klientami czy wygłaszaniem prezentacji na meetupach. Chętnie zasiada do beznadziejnych przypadków i błędów oraz rozwija swoje umiejętności eksperymentując w prywatnych projektach.

1. Zawsze najnowsze rozwiązania

Bardzo często jest to czynnik, który wpływa znacząco na naszą decyzję. Nie ma się czemu dziwić, nikt nie chce pracować ze starymi technologiami. Preferujemy raczej nowości, które mogą później podbić developerski świat. Poza standardowymi rozwiązaniami, w otchłani internetu możemy znaleźć przeróżne twory. Najnowsze architektury czy biblioteki często nie są sprawdzone przez milionów użytkowników, nie mają dobrego wsparcia lub po prostu mogą mieć błędy. Z pozoru fajne rozwiązania mogą okazać się tragiczne w skutkach. W projekcie komercyjnym nie ma miejsca na tak ogromne eksperymentowanie.

Daną architekturę czy biblioteki powinniśmy chociaż w części kojarzyć, rozumieć i potrafić z nimi pracować. Musimy również pamiętać, że w przypadku problemów to my będziemy ostatnią deską ratunku. Jeżeli chcemy wprowadzać nowości, starajmy się, aby w miarę możliwości robić to rozsądnie i małymi partiami. Warto mieć z tyłu głowy przekonanie, że to co złe, na pewno nam się przytrafi i z pewnością zdarzy się na produkcji.

2. Zespół

Oczywistym jest również, że zespół chętnie podchodzi do nowych rozwiązań. Trzeba jednak pamiętać, że nie każdy ma tyle zawzięcia w sobie i z gorliwością douczy się o architekturze poza aktualnym projektem. O ile zespół jest już mniej więcej skonstruowany, wrzucanie skomplikowanych i całkowicie nowych rzeczy może być strzałem w kolano. Może się zdarzyć, że pierwsze sprinty będą bardzo niewydajne, a my jako autorzy takiego rozwiązania spędzimy godziny tłumacząc naszą nową wizję i pokazując, co i jak należy rozwiązać. Może się to przydarzyć również bardziej doświadczonym developerom, którzy pracowali w innym setupie.

3. Generyczność

Niektóre rozwiązania narzucają korzystanie z generyczności, tyczy się ona również sposobu pisania kodu w późniejszym etapie projektu. Bardzo często chcemy rozwiązać coś niemal idealistycznie, przygotować dany kawałek kodu na apokalipsę. Później okazuje się jednak, że z pozoru prosta zmiana biznesowa psuje pierwotne założenie i albo musimy mocno kombinować, albo rozbijać generyczność. Z czasem staje się to nieczytelne i bardzo skomplikowane. Generyczność należy używać rozważnie, a w przypadku, gdy mamy podobną metodę czy kawałki kodu z pewnością lepiej zainwestować w kompozycję.

Oferty pracy z

4. Przygotowane na apokalipsę

Mając przed sobą wizję utrzymywania aplikacji oraz dodawania nowych funkcjonalności, często poświęcamy czas na rozwiązania, które nam to ułatwią. Dodajemy kolejne warstwy abstrakcji, aby tylko później było nam łatwiej. Zapewne klient coś wspomniał, gdzieś usłyszeliśmy plany, lub widzimy z grubsza plan projektu, a już chcemy się na to przygotować. Po jakimś czasie okazuje się, że plany ulegają zmianie, mamy opóźnienia lub jest to przekładane na później. Do czasu aż funkcjonalność zostanie wdrożona mijają lata, a aplikacja już dawno wygląda zupełnie inaczej.

Oczywiście róbmy wszystko tak, aby można było skalować projekt bez problemu oraz dodawać nowe funkcjonalności, jednak podobnie jak z generycznością można zauważyć, że czasami przygotowujemy architekturę na apokalipsę.

5. Deadline

Można się zastanowić, co deadline ma do architektury. Kiedy jesteśmy pod ścianą i musimy szybko pracować, wybór rozwiązań okaże się kluczowy. Dodając nową funkcjonalność chcemy zachować standardy. Gdy jednak czas goni, szukamy sposobu, aby zrobić to szybciej. Musimy zadać sobie pytanie czy przyjęte rozwiązania pozwolą na małe wyjątki. To nie muszą być rzeczy związane stricte z kodem, ale również z prowadzeniem projektu. Na przykład są projekty, w których pull requesty muszą zawierać mniej niż 500 linii kodu, a w momencie deadlinu sztuczne rozbijanie commitów zabiera cenny czas.

–

Musimy pamiętać, że każdy projekt jest inny, jest swego rodzaju specyficzny. Niektóre wymagają specjalnych rozwiązań, których i tak nie da się zmienić. Nigdy nie przewidzimy wszystkiego w 100%, jak rozwinie się projekt i co będzie tak naprawdę potrzebne. Nawet gdy prowadzimy go w metodologii waterfall, technicznie może się sporo zmienić. Starajmy się prowadzić projekt zgodnie z ogólnie przyjętymi dobrymi praktykami. Nie róbmy wszystkiego na zapas oraz miejmy wiedzę na temat wybranych przez nas rozwiązań.

Zdjęcie główne artykułu pochodzi z unsplash.com.