Jak dobrze podejść do wyboru architektury w projekcie

Swoją karierę jako inżynier oprogramowania zacząłem 15 lat temu. Pracowałem wtedy dla agencji reklamowej. Niektóre zlecenia musieliśmy wykonywać naprawdę szybko - czasem wręcz na wczoraj. Sprawiło to, że nie było czasu na dyskusję o tym, jakie podejście wybrać. Wszystko musiało po prostu wyglądać ładnie i być robione na czas. Nauczyło mnie to również pewnej istotnej rzeczy. Wielu z Was może się ze mną nie zgodzić, ale postaram się to jak najlepiej wyjaśnić.

Prawda jest taka, że nikogo nie obchodzą najlepsze praktyki, jeśli kod nie jest już nigdy później używany. Przenieśmy się więc 15 lat później. Od kilku lat pracuję jako Engineering Manager i ciągle widzę, jak ludzie przekombinowują jakieś rozwiązanie do takiego stopnia, że sami nie wiedzą, jak użyć tego kodu w kolejnym projekcie.

A to sprawia, że dotarliśmy do momentu, w którym musimy porozmawiać o przesadnie rozrośniętej architekturze. W ciągu lat zacząłem przywiązywać wagę nie tylko do strony technicznej, ale też biznesowej. Uświadomiło mi to pewne rzeczy, jeśli chodzi o oba te aspekty inżynierii oprogramowania.

Decyzje managementu nie mają żadnego sensu dla programistów, a prośby developerów wydają się niedorzeczne z punktu widzenia biznesowego. Oczywiście biznes chce, aby inżynierowie oprogramowania używali jak najwięcej kodu z poprzednich projektów, żeby nie trzeba było tworzyć za dużo nowych rzeczy.

Developerzy zawsze będą twierdzić, że obecne wymagania nie pasują do architektury, a więc trzeba dokonać zmian w podstawach projektu. I w taki sposób dotarliśmy do sedna problemu. Jeśli za każdym razem ponownie używamy kodu z jakiegoś projektu, to dlaczego musimy uaktualniać fundamenty naszej architektury? Odpowiedź jest tutaj dosyć prosta: nie jesteśmy w stanie przewidzieć przyszłości, a więc nie ma potrzeby tworzyć oprogramowania, które rozwiąże każdy możliwy problem.

Oto bardzo proste porównanie: kiedy stawiamy jakiś budynek, to architekt planuje budowę na podstawie specyfikacji żądania, czyli: x ilość mieszkań oraz y, czyli ilość przestrzeni komercyjnej itp. Jedna przestrzeń mieszkalna zostaje więc wynajęta na burgerownię, a ta modyfikuje ją sobie pod siebie, nie zważając na to, kto może zajmować tę przestrzeń w przyszłości. Dlaczego nie spróbować tego samego, gdy tworzymy oprogramowanie?

Architektura oprogramowania to fundament dla pewnego typu projektów - i tyle wystarczy. Nie musimy martwić się o wszystkie dodatki, które mogą się kiedyś pojawić, jeśli nasz obecny projekt ich nie wymaga. Moja rekomendacja brzmi następująco: używajcie architektury, która pasuje do projektu w obecnym stanie, a nie w przyszłym. 

Najlepsza decyzja dotycząca architektury, to taka, której nie trzeba podejmować - Robert C. Martin

Oczywiście są takie firmy, jak Facebook, Google, Amazon, które mają miliony użytkowników i scenariuszy do przewidzenia, a więc ich architektura siłą rzeczy będzie ogromna. Większość programistów pracuje jednak dla mniejszych firm, które mają jeden produkt lub usługę - w takich przypadkach im prościej, tym lepiej. 

Morał jest tutaj następujący: nikogo nie obchodzą najlepsze praktyki, jeśli kod nie jest jeszcze później ponownie używany.

Oryginał tekstu w języku angielskim możesz przeczytać tutaj.