Gdy pracuję z innymi programistami nad tematami związanymi z jakością kodu bardzo często uderza mnie fakt, że pod względem technicznym żadnego z nich nie jestem w stanie nic, ale to nic nowego nauczyć!
Programiści zazwyczaj wiedzą:
- jakie są słabe punkty ich kodu
- jak powinien wyglądać ich kod
- co dokładnie należy zrobić, aby ich kod wyglądał tak jak
Wiedzą to wszystko i...nic się nie dzieje! Nic się nie zmienia. Ciekawe jak to jest możliwe, że mimo tej ogromnej wiedzy, świadomości dobrych rozwiązań, znajomości wzorców projektowych, umiejętności tworzenia czytelnego kodu wciąż jest jak jest - czyli kod woła o pomstę do nieba, a my narzekamy.
Przeprowadziłem małe śledztwo, polegające głownie na zadawaniu pytań i nakłanianiu ludzi do wypełniania ankiet.
Podsumowując: nic się nie dzieje, ponieważ:
- za działający kod płaci każdy, za dobry nikt
- nacisk na jakość kodu powinien iść z góry, od menadżerów; programiści-idealiści w końcu zniechęcają
- długotrwała praca ze kodem o złej jakości, skutkuje tendencją do dopasowywania się do otoczenia; równamy w dół i tworzymy kod, którego jakość jest nie lepsza niż jego otoczenie
- obawiamy się, że radykalne decyzje projektowe okażą się niesłuszne w przyszłości
To wszystko jest nieco bardziej skomplikowane (przynajmniej moim zdaniem).
ReplyDeleteKlient płaci za działający kod... więc lepiej, żeby był dobry, bo wtedy jego późniejsze utrzymanie będzie tańsze dla wykonawcy... ale... jeśli klient jest słaby (np. uwikłany w kontrakt z duża firmą IT i system, który nie tak łatwo zmienić) to de facto on płaci za zły kod, bo za każdą zmianę zostanie skrupulatnie podliczony (a czym gorszy kod tym zmiany będę więcej kosztowały).
Taki np. freelancer... (albo developer prowadzący własną firmę) zwykle musi płacić za zły kod, bo zwykle poprawki robi na swój koszt. Więc czym kod lepszy, tym mniej ich ma do zrobienia i nie przejada zarobionych pieniędzy. Dodatkowo jeśli kod jest dobry to taki człowiek/firma osiąga większe marże na drobnych zmianach, bo kod pozwala na szybkie ruchy. Jeśli kod byłby zły to jest granica w którą jest w stanie uwierzyć klient i zwykle faktycznie trzeba się narobić tyle a nawet więcej niż się wynegocjowało.
Takich kontekstów można by mnożyć wiele. Co z tego wynika... zły kod zawsze kogoś kosztuje. Od rodzaju relacji zależy kogo. I świadomość tego faktu musi istnieć po obu stronach (wykonawca/klient). Bez tego zawsze pozostanie pole do nadużyć. Sama świadomość developerów nie wystarczy.
@Marcin
ReplyDelete"Klient płaci za działający kod... więc lepiej, żeby był dobry, bo wtedy jego późniejsze utrzymanie będzie tańsze dla wykonawcy.."
Jak najbardziej się zgadzam. Jednak sposób twojej argumentacji jest bliski stronie programistów (czy dobrze zgaduję, że jesteś programistą albo liderem, ale raczej na pewno bardzo blisko kodu i problemów z tym związanych?). Gdyby jednak na naszą sprawę spojrzeć oczami kogoś, kto jest absolutnie biznesowy, kto ma na celu 2 rzeczy: harmonogram i budżet (wszystko w kontekście jednego projektu). To okazuje się, że ma działać, ma być zrobione. Jak? - to już sprawa drugorzędna.
Czasem niestety okazuje się, że celem projektu jest wystawienie faktury.
Po pierwsze "Biznes" tez występuje po obu stronach, a projekt nigdy nie kończy się jakąś jedną fakturą. Jest wdrożenie, jest naprawa jakiś bugów tuż po wdrożeniu (oby jak najkrótsza), jest wreszcie utrzymanie.
ReplyDeleteJakość kodu nie ma wpływu na harmonogram tylko wtedy, kiedy mamy więcej czasu niż nam potrzeba.
Zwykle jest odwrotnie i wtedy mamy do wyboru dwie drogi: albo totalnie tniemy jakość czyli pojawią się hack'i, atrapy i szkielet z zapałek podtrzymywany taśmą klejącą, szpachla i jeszcze raz szpachla, albo też w zdyscyplinowany sposób dostarczamy kod wysokiej jakość (czyli zwięzły, bez powtórzeń, z przemyślaną architekturą itp. itd).
W pierwszym wypadku przerzucamy tak faktycznie cześć kosztu na fazę utrzymania, licząc, że będzie to osobna faktura(y).
Dodatkowo zły kod powoduje, że w każdym tygodniu koszt napisania nowego kawałka systemu kosztuje więcej, a kontrakt raczej nie zakłada rosnącej dniówki. Więc tak czy siak osoba reprezentująca biznes powinna być zainteresowana dobrym kodem, bo ma to bezpośredni wpływ na jej marżę i budżet jakim dysponuje.
Dobra strasznie się rozpisałem, ale kluczowe znaczenie ma tutaj co rozumiem jako "projekt", bo dla mnie nie kończy się on na pierwszym oddaniu kodu, akceptacji i fakturze. Właściwie to takie postrzeganie projektu wydaje mi się bliższe programistom (byle do deadline'u, a potem to już inna bajka). Biznes powinien patrzeć na to szerzej.
Przy sztywnym deadline i karach liczy się tylko dostarczenie czegokolwiek ale w terminie. A biznes lubi sztywne deadline bo dają mu poczucie kontroli. Jaaaazdddaaaaa.
ReplyDeleteA moim zdaniem problem z jakością jest przede wszystkim taki, że jej konsekwencje są trudne do mierzenia. No dobrze, uwierzą mi, że lepszy kod to mniej kosztów przy utrzymaniu i łatwiejszy rozwój. Ale o ile? I ile problemów i tak by wystąpiło?
Na takie pytania niestety nie umiem ściśle odpowiadać.
Zresztą są i przypadki, gdy podejście byle-jak byle-szybko jest słuszne (np. robimy jakąś mało komu potrzebną atrapę uwarunkowaną formalnie albo dorabiamy tymczasowy kawałek, który za parę miesięcy wyleci albo robimy coś co de facto jest tylko prototypem).
Tylko ... tylko droga do gorszego kodu wygląda na jednokierunkową. Programistę, który przywyknie pisać byle jak, bardzo trudno zawrócić.
Nawet gdy system się totalnie rozsypuje i trzeba go przepisać, nie jest dobrze wiadomo gdzie była ta granica, którą przekroczono i łatwiej jest obwiniać tego czy tamtego konkretnego człowieka niż myśleć systemowo.
@Mekk: "Przy sztywnym deadline i karach liczy się tylko dostarczenie czegokolwiek ale w terminie. A biznes lubi sztywne deadline bo dają mu poczucie kontroli. Jaaaazdddaaaaa."
ReplyDeleteŚwięte słowa. Ostatnio to przerabiam, ale mam na tyle mocne "plecy", że mogę powiedzieć "to tylko działa, ale nie jest dobre" i zaliczyć 2 tygodnie opóźnienia :)
Często tak nie można robić i produkuje się byle co.
@autor: Nie poruszyłeś najważniejszej kwestii. Na jakość można sobie pozwolić z kodem nowym. Jeżeli trafisz na kod zastany lub co gorsza automatycznie migrowany (bo taniej/szybciej) z np. COBOLa do Javy i zawierający całą masę "smaczków" typu grupy i paragrafy COBOLowe, ramki LINCa czy "matematykę wg. ALGOLa" to okazuje się, że jakość... jest jakość działa jakość się nie wywala.
Poza tym jakość to rzecz umowna. Oczywiście działa to na zasadzie "poprawnej polszczyzny", czyli umowy pomiędzy programistami, że pewne formy są dobre inne nie za bardzo. Hm... chyba mam wieczór z głowy. Akurat wujka Boba przeczytałem i muszę oddać się swojej grafomańskiej pasji blogowania o czystym kodzie...
This comment has been removed by the author.
ReplyDelete"Dlaczego tak jest że narzędzia idą cały czas do przodu, a sama technologia wytwarzania oprogramowania stoi w miejscu"
ReplyDeleteSprawa jest skomplikowana:)
* łatwiej napisać narzędzie niż zmienić mentalność ludzi
* parafrazując Autorów "Peopleware" - wszyscy mówią o jakości, ale gdy przychodzi do podejmowania decyzji szybko okazuje się co liczy się najbardziej
* organizacje zmieniają się baaardzo wolno (czytaj: latami)
* żeby ktoś się czegoś nauczył, musi osobiście doświadczyć konsekwencji swojego działania; w organizacji jest to trudne, bo jeśli ja coś napsuję, to gdy pojawią się konsekwencje ja już będę w innej firmie, a beknie mój następca
* z działaniem na rzecz dobrego kodu jest jak z laniem wody do wiklinowego koszyka - wprawdzie cała woda wycieknie, ale koszyk będzie już nieco mokry i zawsze bardziej czysty :)
* i ostatnie najważniejsze: dobry kod, wzorce, tdd, ddd itd to pewne modele do naśladowania, ale tylko modele, rzeczywistość jest o wiele bardziej bogata i nigdy nie będzie w 100% zgodna modelem; zawsze będziemy musieli iść na jakieś ustępstwa: zawsze będziemy mieli "błędy studentów", God Classes, trudności w dogadaniu się, zawsze; pogodzenie się z tym faktem oszczędzi nam wiele niepotrzebnych stresów, a doskonała znajomość w/w modeli pozwoli nam nie zwariować:)
Z najlepszymi pozdrowieniami,
mb
A ja powiem inaczej z perspektywy tych trzech lat... na jakość w procesie produkcji oprogramowania bardzo często patrzymy w podobny sposób jak na problem jakości w produkcji przemysłowej. Jednocześnie ignorując główną różnicę:
ReplyDeleteW produkcji przemysłowej w celu wyeliminowania błędów stosuje się automatykę.
Jak na razie nie wynaleziono dobrego generatora kodu, a i korzystanie z bibliotek jest średnie (nie wiemy że istnieją, nie mają porządnej funkcjonalności, wymyślamy bardziej okrągłe koło). Nadal duża część kodu jest tworzona przez człowieka, a ten jest omylny.
Można co prawda powiedzieć, że np. w fabryce samochodów dużo czynności wykonują ludzie, ale i tu należy zauważyć, że poziom komplikacji takiej czynności jest wielokrotnie niższy niż pisania kodu.