Nasza strona używa cookies. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Metoda 90-10, czyli jak rozłożyć etapy programowania

Lucas Majerowicz Software Architect
Przekonaj się, jak znaleźć równowagę pomiędzy różnymi aspektami tworzenia oprogramowania w metodzie 90-10.
Metoda 90-10, czyli jak rozłożyć etapy programowania

Zasada 90-10: nie spędzaj 90% czasu na martwieniu się o pozostałe 10%. Innymi słowy, nie poświęcaj swoich wysiłków na osiągnięcie 100% wyniku. Dlaczego tak? Z dwóch powodów. Pierwszy powód to prawo malejących przychodów, które odnosi się nie tylko do rozwoju oprogramowania, ale też praktycznie do wszystkiego innego.

Weźmy na przykład zespoły, które się tym zajmują. Powiększenie się zespołu programistów z jednego do pięciu prawdopodobnie zwiększy produktywność o 500%. A co stanie się, jeśli dalej będziemy dodawać programistów do zespołu? Po pewnym czasie produktywność wzrośnie nieznacznie (np. z 7 do 8 programistów) lub nawet zacznie spadać (np. posiadanie jednego zespołu składającego się z 20 programistów).

Drugi powód jest taki, że jeśli za bardzo skupisz się na jednym aspekcie tworzenia oprogramowania, prawdopodobnie skończysz na zaniedbywaniu innych aspektów. Weźmy na przykład wydajność, która zwykle przychodzi kosztem prostoty i/lub ceny. Im więcej testów piszesz, tym dłużej trwa rozwój.

Podam Ci kilka przykładów zastosowania zasady 90-10.


Wybór właściwej technologii

Powiedzmy, że każdy w naszej firmie ma duże doświadczenie w pracy z konkretną bazą danych. A teraz nadszedł czas, aby rozpocząć nowy projekt. Którą bazę danych byś wybrał? Tę, z którą wszyscy mają doświadczenie, czy nowszą, bogatszą w inne funkcje? Moim pierwszym wyborem zawsze będzie użycie bazy danych, z którą każdy ma doświadczenie, nawet jeśli istnieje inna, z większą ilością o wiele lepszych funkcji.

Potrzeba lat rzeczywistego doświadczenia i praktyki, aby stać się biegłym w bazach danych, frameworkach, językach programowania, itd. To właśnie dlatego Twoje pierwsze projekty prawdopodobnie były kiepskie, a nowe są już o niebo lepsze. Wielu architektów i menedżerów oprogramowania nie zdaje sobie z tego sprawy, ale wysiłek i koszty związane z przejściem ze znanej technologii na nową są niezwykle wysokie, a w większości przypadków dodatkowe korzyści są znikome.


Kod

Czy kod powinien być przejrzysty i łatwy w utrzymaniu? Zdecydowanie. Czy kod powinien być bezbłędny i nie powinno się w nim znaleźć miejsca na poprawki? Niekoniecznie.

Jeśli kod, nad którym obecnie pracujesz, jest trudny w utrzymaniu, to jego poprawa i ulepszenie na pewno opłaci się w przyszłości. Jeśli jednak kod jest już wystarczająco dobry lub prosty to rzeczywista korzyść, jaką uzyskasz z jego ulepszenia, będzie prawdopodobnie bardzo mała, nie mówiąc o tym, że możesz pogorszyć sytuację.


Wydajność

Mierzysz się z wąskim gardłem i potrzebujesz poprawić czas reakcji lub przepustowość? Zazwyczaj największe usprawnienia wynikają z najprostszych zmian. Wprowadzenie ich często pozwala uzyskać 200% lub nawet 500% poprawy. Dalsze usprawnienia będą zazwyczaj wymagały bardzo skomplikowanych zmian, a przyrost wydajności będzie marginalny. Dla większości aplikacji prawdopodobnie nie ma sensu poświęcać wielu miesięcy pracy, aby uzyskać, powiedzmy, kolejne 10% poprawy wydajności.


Testowanie

Pokrycie testami jest doskonałym przykładem prawa malejących przychodów w praktyce. Po pewnym czasie, gdy masz już wystarczająco dużą ilość testów i pokrycia, wysiłek, jaki musiałbyś włożyć w dodatkowe pokrycie, nie jest tego wart.


Nauka i samodoskonalenie

Na początku mojej kariery byłem tak żądny wiedzy, że potrafiłem godzinami oglądać wykłady, brałem udział w kursach lub czytałem książki na temat tworzenia oprogramowania. Jeśli działałeś podobnie, być może zauważyłeś, że po pewnym czasie trudno o znalezienie treści o trochę lepszej wartości. Trudno też o nauczenie się czegoś nowego tylko z konsumpcji cudzych treści.

Jeśli Twoim celem jest nauka, myślę, że najwięcej zyskasz, dosłownie brudząc sobie ręce i zdobywając doświadczenie w praktyce. Jeśli masz już ciekawą pracę, w której uczysz się nowych umiejętności i technik, powinieneś być w stanie ograniczyć liczbę kursów, książek i wykładów, które do tej pory pochłaniałeś.


Przemyślenia końcowe

Zauważyłem, że programiści mają tendencję do nadmiernego skupiania się na jakości kodu i najlepszych praktykach (zwłaszcza jeśli przeczytałeś „Czysty Kod!”), architekci na wydajności, a menedżerowie na metrykach i wdrażaniu najlepszych praktyk (TDD, zwinność, pokrycie testami, itp...).

Zasada 90-10 nie ma nic wspólnego z zadowoleniem się przeciętnością czy zachęcaniem do lenistwa. Chodzi o dokonanie logicznej analizy kosztów i korzyści, abyś mógł skupić się na tym, co naprawdę ważne. Nie uczyni cię to najlepszym programistą lub architektem, ale pomoże ci znaleźć właściwą równowagę pomiędzy wszystkimi różnymi a czasem sprzecznymi, aspektami tworzenia oprogramowania.

Oryginał tekstu w języku angielskim przeczytasz tutaj.

Rozpocznij dyskusję

Lubisz dzielić się wiedzą i chcesz zostać autorem?

Podziel się wiedzą z 160 tysiącami naszych czytelników

Dowiedz się więcej