Pewnie lubisz pisać dobry kod? Zakładam, że skoro czytasz tego bloga, to temat jakości jest Ci bliski. Bardzo mnie to cieszy! Jakość projektu to nasza wspólna sprawa.  Tylko czy my zawsze mówimy o tym samym? Czy wysoka jakość dla programistów, testerów, managerów to to samo, co dla klienta? Jeśli tak myślisz, to trochę Cię rozczaruję.

Jako programistka lubię dbać o jakość kodu. Lubię kiedy mój kod jest czytelny, wykorzystuje wzorce projektowe, no i ma testy. Czuję się wtedy jak skaut, który powinien dostać order z ziemniaka za dobrze wykonaną pracę. A potem przychodzi ktoś i mi ten order depcze, bo niby mój kod nie robi tego co trzeba. Czy to ważne, co robi, skoro jest taki piękny i zoptymalizowany, i robi wszystko szybko? No ważne.

 

Jakość kodu a jakość projektu

Jako twórcy postrzegamy sprawy nieco inaczej niż odbiorcy. Skupiamy się na tym, aby proces był dopieszczony i aby wszystko powstawało w harmonii. Przeważnie takie warunki zapewniają też wyższą jakość. Ale nie zawsze. Byłam kiedyś świadkiem jak programiści przejęli władzę w firmie i robili co im się podobało. Na początku działało to całkiem nieźle, ale z czasem skupienie na jakości kodu zaczęło być najważniejsze. A to nie wpływało dobrze na jakość projektu. Wróć, co? Jak to jakość kodu nie szła w parze z jakością projektu?

Oczekiwaniem klienta było skupienie się na prędkości dostarczania nowych funkcjonalności i dużej elastyczności. To była dla nich jakość. Zastosowane wzorce projektowe, ani piękny proces CI ich nie interesowały. Wiem, że teraz Twoje serce krwawi, ale prawda jest taka, że to my pracujemy dla naszych klientów, a nie odwrotnie. Nikt się nie powinien wtrącać w pracę żadnego rzemieślnika, o tyle ten rzemieślnik też powinien się dostosować do wymagań.

Wyobraź sobie stolarza, który pracuje tylko na materiałach najwyższej jakości, zawsze kupuje drogie elementy i jego praca jest dopieszczona w każdym szczególe. O ile w dużym mieście zawsze znajdzie się zbyt na takie usługi, o tyle w małej miejscowości może się okazać, że nie ma chętnych. Ktoś potrzebuje półki do garażu, ktoś inny meblościanki do domku letniskowego, który idzie do rozbiórki za pół roku. To nie jest ujma na honorze, żeby czasem sklecić coś z płyty pilśniowej 😉

 

Programistyczne prowizorki

Pamiętasz ten dylemat: dobrze, szybko, tanio, wybierz max 2? Nie wszędzie dba się w równym stopniu o architekturę projektu i jakość kodu. Czasem ma być szybko i tanio, albo po prostu szybko. Nie jestem orędownikiem kodu niskiej jakości, ale muszę się przyznać, że nie korzystam z TDD na hackathonach…

Wiem, że prowizorki często trzymają się świetnie przez długie lata. Kiedy byłam mała mieliśmy taką szopę, która powstała przy budowie domu. Zniknęła dopiero kiedy byłam na studiach. W projektach często też skleca się coś na szybko, a potem korzystają z tego tysiące klientów. Jeśli projekt działa i zarabia pieniądze, to można go trochę podrasować, albo nawet przepisać. Kiedy jednak zabijemy projekt, bo chcemy żeby wszystko było perfekcyjnie, to nie będzie czego utrzymywać.