Coś mnie wzięło i będzie chyba o tym prawie cały tydzień, z różnych punktów widzenia i z różnymi obserwacjami. Ciekawe jak to wyjdzie. Zacznę od dążenie do perfekcji w programowaniu. Czyli o tym, że naszym celem jest pisanie coraz to lepszego, czytelniejszego kodu, który wraz z architekturą stworzy arcydzieło o którym każdy będzie chciał opowiadać. Szczerze, kto nie miał takiego marzenia? Piękny kod, ciekawa, ładna i schludna architektura bazująca na wzorcach i konwencji, umożliwiająca wszystko co jest potrzebne i nie na zasadzie hackowania/wymuszania, ale na zasadzie prostego i przyjemnego wykorzystania. Nigdy o czymś takim nie myśleliście? U mnie przeważnie myśl nie idzie z czynem, dokładna relacja jest taka:
W głowie mam, że śliczne, piękne, ale w rzeczywistości jest to bagno. Nawet jeżeli nie w dosłownym tego słowa znaczeniu, to po napisaniu, wiem, że już mogę to poprawić. Zresztą ktoś mądry już to powiedział:
Legacy is the stuff I wrote yesterday.
źródło
A kod legacy to kod, który już nie jest tym czym mógłby być, gdybyśmy posiadali tę wiedzę, którą zdobyliśmy przy pisaniu pierwszej wersji. Tutaj można by było kod poprawić, tam zmienić, tam z refaktoryzować itd. I jak tylko to zrobimy to znów znajdziemy coś nowego do poprawy. Co gorsza, jak w którymś momencie stwierdzimy, że pora przepisać rozwiązanie, bo już wiemy jak, to też to nie wyjdzie tak jakbyśmy tego chcieli.
Dlaczego tak jest? Bo to my dążymy do perfekcji, która zmienia się w czasie. Co innego nam się w podoba przed rozpoczęciem projektu a co innego podoba się nam w chwili ukończenia pisania kodu. I to jest ok, my się zmieniamy, nasza wiedze, nasze spostrzeganie problemu, nasze zrozumienie problemu, wszystko się zmienia. A jak się zmienia to co innego jest dla nas perfekcyjnym rozwiązaniem.
Dlatego też, najlepszym wyjściem jakie możemy zastosować to zaakceptować fakt, że dane rozwiązanie w danej chwili jest najlepszą rzeczą jaką mogliśmy zrobić. Koniec. Najlepiej też odciąć się od tego projektu, by nie było chęci zmiany tego co tam się napisało. Perfekcjonizmu nigdy nie osiągniemy, możemy do niego się zbliżyć, ale im bliżej będziemy tym więcej rzeczy zauważymy, że nam przeszkadzają.
Ja już dawno temu zrezygnowałem z perfekcjonizmu w trakcie pisania kodu. To był przegrany wyścig, co doganiałem to co chciałem osiągnąć to albo projekt się kończył, budżet się kończył, albo zmieniała mi się percepcja tego co jest piękne. Rezygnacja z tego wyścigu też daje to, jak ja czuję się z kodem który wypuściłem. Zrobiłem wszystko by był on ładny i solidny. Wiem, że dużo mógłbym zmienić. Ale to jest coś co jest najlepsze co mogło wyjść z pod mych rąk w danej chwili. Jakbym podążał za perfekcją, kod nie ujrzałby światła dnia.
A wy jak macie?
Celny wpis! Nie raz łapię się na tym, że spędzam zbyt dużo czasu nad jakimś fragmentem kodu tylko po to, żeby go “dopieścić”. A to nie zawsze ma sens, bo jak wiadomo “Done is better than perfect” :)
prawda, trzeba w którymś momencie się odciąć :)
Ja staram się pisać kod tak, aby był spójny. Nie musi być doskonały. Gdy natrafiam na problem z jakimś ficzerem i kombinuję na różne sposoby, aby w końcu zadziałał, to rozwiązanie typu obejście, łatka czy inna jakaś nietypowa kombinacja, nie daje mi satysfakcji, nie zaznam spokoju, dopóki nie oprogramuję tego w sposób zgodny z istniejącą już architekturą projektu. Tak więc w moim przypadku dążenie do perfekcji objawia się w taki właśnie sposób.
a co jeżeli aktualna architektura projektu nie pozwala na naprawę?
Poszerzam architekturę.
nawet jak wymaga przepisania całości?
Nie, jedynie o tą brakującą funkcjonalność.
IMO w samym dążeniu do perfekcji nie ma nic złego – nie mniej jednak ja staram się pisać najlepszy kod jaki jestem w stanie wyprodukować w danym momencie. Rzeczą normalną jest, że kiedy staramy się ciągle uczyć i rozwijać, to bardzo szybko ten kod robi się “blahhh”. Ja generalnie z zasady raczej nie poprawiam już napisanego i działającego kodu. Nawet jeżeli robimy jakiś maitenance czy drobną rozbudowę starszego produktu to stosuję zasadę: “jeżeli coś działa – nie ruszać i nie psuć”, bo jak się ruszy jedną rzecz, to nagle się okazuje że przydało by się 90% napisać od nowa, a na to nie ma nigdy ani czasu ani budżetu.
problem z dążeniem do perfekcji jest taki, że dla każdego co innego jest tą perfekcją i co innego jest tym dążeniem :)
rozwijanie nie jest złe. Ale nie publikowanie czegoś bo nie jest perfekcyjne, jest złe :) albo tak mi się wydaje ;) a Tobie?
Dobre podsumowanie tematu! Ile to razy w mieliśmy uczucie w pracy, że coś jest nie tak z kodem. Niestety w rzeczywistości gonią nas nieubłagane terminy, klienci itd. Mi dążenie do perfekcji już dawno przeszło, kod musi działać, być sprawnie napisany, łatwy w utrzymaniu, ale nie musi być perfekcyjny ważne żeby był prosty i czytelny. Często później dochodzi do zabawnych sytuacji jak patrzymy w historię “kto napisał to #$%#$%#$%” i okazuje się, że byliśmy to my ale jakieś 6 miesięcy wcześniej :).
Sam nie raz tak się naciąłem ;) Patrzę w historii – myślę sobie “pewnie jakiś student napisał, bo kod fatalny” i zdziwko – jestem autorem tego wpisu :)
Ale uważam, że to dobrze, że tak jest. Jeśli ktoś jest zadowolony z kodu, który popełnił np. pół roku temu i nic by w nim nie zmienił – znaczy, że się nie rozwija ;)
[…] Dążenie do perfekcji w programowaniu […]
Comments are closed.