Pozłacanie

Oryginalny post: Gold Plating

Autor: Jeff Atwood

Jednym z 36 klasycznych błędów projektów programistycznych według McConnell'a jest pozłacanie. Powtarza się nawet dwa razy na liście, tak więc myślę, iż ryzyko złapania się w tę pułapkę jest dwa razy większe:

#28: Pozłacanie wymagań. Niektóre projekty mają zbyt wiele wymagań na początek. Kwestia wydajności jest stawiana jako wymaganie częściej, niż jest to potrzebne, a to może wydłużać harmonogram prac. Użytkownicy zdają się być mniej zainteresowani złożonymi funkcjonalnościami niż marketing i programiści, a złożone funkcjonalności nieproporcjonalnie przekładają się na harmonogram.

#30: Programistyczne pozłacanie. Programiści są zafascynowani nowymi technologiami i czasem pragną wypróbować nowe funkcjonalności ich języka bądź środowiska, albo stworzyć własną implementację schludnej funkcjonalności, którą widzieli gdzieś indziej -- bez względu na to, czy jest ona potrzebna w ich produkcie. Nakład pracy potrzebny na zaprojektowanie, implementację i utrzymanie niepotrzebnych funkcjonalności wydłuża harmonogram.

Według definicji McConnella, pozłacanie oznacza dodawanie niepotrzebnych, frywolnych funkcjonalności bądź wymagań. Jest to opisane w książce Rapid Development. Pozłacanie to doskonała metafora na dodawanie sztucznej wartości, tak jak tanio wyprodukowana biżuteria.

Jednakże, jeśli chodzi o pisanie kodu, nie jestem pewien, czy pozłacanie zasługuje na przezwisko "klasyczny błąd". W najczystszej formie, to refaktoryzacja jest pozłacaniem. Mianowicie, zużywa dodatkowy czas projektu i nie daje w rezultacie materialnych korzyści użytkownikom. Ale bez okresowych i agresywnych refaktoryzacji, nie jesteśmy w stanie wyprodukować rozsądnego i łatwego w utrzymaniu kodu. Gdzie kończy się refaktoryzacja, a zaczyna pozłacanie? Może jestem wypaczony, ale nie mogę sobie przypomnieć ostatniego czasu, kiedy to przesadnie pozłacałem oprogramowanie, poprzez uczynienie go prostszym i łatwiejszym w utrzymaniu.

Mam również trudności z krytykowaniem kliku programistów, którzy na pierwszym miejscu troszczą się o pozłacanie swojego kodu. Jak to zostało zasugerowane we wpisie Dana Applemana -- w stylu Joela Spolsky'ego -- wielu nawet nie próbuje:

Z jednej strony mamy osobę, która rozwiązuje problemy. Kiedy ma ona zadanie bądź cel i napotka na przeszkody, rozwiąże je, pokona, ominie, opracuje obejście, nawet jeśli oznaczałoby to przedefiniowanie problemu na coś równie dobrego bądź lepszego niż oryginalne zadanie bądź cel. Moim zdaniem, taka osoba byłaby tym, kogo Joel nazywa "rosh gadol".

Po drugiej stronie mamy osobę, która zatrzymuje się na pierwszej wymówce. Innymi słowy, jeśli taka osoba ma wytłumaczalny powód na zaprzestanie poszukiwań rozwiązania, to na tym kończy. Mimo iż może to być zamierzone (tutaj ma miejsce sytuacja z przykładu Joel'a - niewykazywania inicjatywy), to zazwyczaj jest to częścią ich natury. Taka osoba byłaby określona mianem "rosh katan".

Z przykrością stwierdzam, iż tych drugich jest o wiele więcej niż tych pierwszych.

Jako iż z pewnością istnieje wiele przekombinowanego i pozłoconego oprogramowania, znacznie bardziej powszechne jest posiadanie.. czystego ołowiu. Jeśli masz programistę, który jest w stanie dać z siebie więcej i popozłacać trochę, zalicz siebie do szczęśliwców. W końcu, z odpowiednim ukierunkowaniem i skupieniem, mógłbyś mieć programistę produkującego prawdziwe złoto. A to, w rzeczy samej, jest rzadkie.

Data publikacji oryginału: 7 grudnia, 2004

6 komentarze:

Anonimowy pisze...

Po polsku to będzie odpowiednio "robię za frajer" i "pierdole nie robie". :-)
Zależy od projektu chyba. Jak dla siebie, czy firmy, to pewnie, że będę pozłacał, ale dla kogoś na krótkoterminowe zlecenie? Oczywiście, że się szuka wymówek, bo powodują koszty, których często zleceniobiorca nie chce ponosić :)

Anonimowy pisze...

Tylko że wciskanie na siłę nowych funkcjonalności i technologii raczej nijak się ma do refaktoryzacji w celu uczynienia prostszym i łatwiejszym w utrzymaniu...

Tomasz Kowalczyk pisze...

Nie "robię za frajer", tylko "robię porządnie, bo wierzę w lepsze oprogramowanie" - niezależnie od tego jakie są inne warunki zadania. Ja np. nie potrafię napisać nawet kilku linijek "na odwal się", od razu muszę zrobić to porządnie bo odchodzi mi cała ochota na dalsze rozwijanie. Pomijam oczywiście sprawy, które mają być "na wczoraj", albo kiedy przerabiam kod niskiej jakości - trzeba oczywiście zachować umiar.

batman pisze...

Jeśli trafiam na kod śmietnik, to nie widzę powodu, bym miał poświęcać dodatkowy czas na sprzątanie po kimś (chyba, że jest to kod, który będę musiał utrzymywać).

Pozłacanie programistyczne - zdarza mi się stosować i nie widzę w tym nic złego. W końcu gdzie jak nie w produkcyjnym środowisku można poznać wady i zalety danego rozwiązania?

Konradzik pisze...

A na czym ja mam ćwiczyć nowe technologie i umiejętności jak nie na aktualnych projektach? Studia się skończyły, nie ma sensu pisanie 'do szuflady'. Oczywiście trzeba cały czas mieć przed oczami harmonogram, ale spróbowanie czegoś nowego, ciekawego, efektownego pozwala nie wpaść w rutynę i czerpać przyjemność z pracy.

Całe szczęście nie mam styczności z śmietnikiem opisywanym przez Tomka i batmana - znając siebie nie mógłbym na to patrzeć a pod koniec dnia miałbym fatalny humor. Pracuję przy projekcie który trzeba utrzymywać i rozwijać stale - refaktoryzacja starych kawałków kodu to po prostu fakt którego nie-programiści mogą nie rozumieć i nazywać (mylnie) pozłacaniem. Bez tego, projekt to przysłowiowy golem na glinianych nogach.

Moim zdaniem, to co łączy wszystkich dobrych programistów to właśnie balansowanie na linii pozłacania. Ach, ten dreszczyk emocji kiedy zobaczymy, że coś działa szybciej / prościej / kod lepiej wygląda / zmniejszyła się ilość kodu / wyeliminowaliśmy wszystkie warning'i :)

godlark pisze...

Ja także lubię patrzeć jak moje oprogramowanie dojrzewa, kod staje się bardziej przenośny, ładniejszy, wydajniejszy. Wprowadzenie nowej funkcjonalności staje się wtedy proste.

Prześlij komentarz

Related Posts with Thumbnails