Przysięga programisty

Dla zachowania i obrony honoru profesji programistów komputerów,

Wykorzystując moje najlepsze zdolności i wiedzę, przyrzekam:

1. Nie napisać kodu, który powoduje szkody.

2. Pisać kod, który będzie efektem moich najlepszych starań. Nie dopuścić świadomie do kumulowania się uszkodzeń w działaniu i w budowie kodu.

3. Dostarczyć z każdą wersją aplikacji szybki, pewny i powtarzalny dowód, że każda część kodu działa tak jak powinna.

4. Robić częste, małe wersje aplikacji, które nie przeszkadzają w pracy innych.

5. Poprawiać bez strachu i bez ustanku owoce mojej pracy przy każdej okazji. Nie sprawić nigdy, że staną sie gorsze.

6. Zrobić, co w mojej mocy, aby zachować produktywność swoją i innych na najwyższym możliwym poziomie. Nie robić niczego, co obniża tę produktywność.

7. Upewniać się ciągle, że inni mogą wykonywać moją pracę i ja mogę wykonywać pracę innych.

8. Określać uczciwe przybliżone czasy wykonania zadań tak w liczbie jak i w dokładności. Nie złożę obietnicy bez pewności.

9. Nie przestawać się uczyć i poprawiać mojego rzemiosła.

Poniższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :
http://blog.cleancoder.com/uncle-bob/2015/11/18/TheProgrammersOath.html
Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.

Bicie piany

Czy słyszałeś o tym gościu, który powiedział, że Object Oriented to przeżytek?

No nie. Następny. Co powiedział?
Opisał wszystkie obietnice OO, i jak żadna z nich tak naprawdę nigdy nie została spełniona i o tych wszystkich możliwościach OO, które kosztują więcej, niż są warte i że funkcjonalne programowanie jest lepsze i ...
Phi. Tak słyszałem już to wcześniej.
No, więc OO jest martwe, leży i kwiczy i możemy przejść dalej.

Przejść dalej do czego?

Co? No do NASTĘPNEJ WIELKIEJ RZECZY oczywiście.

Aaaa, do tego. Czy wiesz już co to jest?

Nie bałdzo, ale jestem podekscytowany na myśl o mikroserwisach; jaram się Elixirem; i słyszałem, że React jest fantastyczny; i ...

Tak, tak. Bicie piany. Dałeś się nabrać na bicie piany.

Co? Co masz na myśli. Przecież mamy takie wspaniałe czasy.

Tak naprawdę postrzegam te czasy jako depresyjne.

Ale dlaczego? Przecież co kilka dni wyskakują nowe wspaniałe technologie! Wspinamy się na coraz wyższe szczyty.

Phi. To, co tak naprawdę robimy, to wymyślanie koła od nowa. Wciąż i wciąż od nowa. I tracimy ogromne ilości czasu i zasobów, aby to robić.

Ej, no weź, no. Przecież to jest właśnie POSTĘP.

Postęp? Naprawdę? Nie widzę tego w ten sposób.

No dobra, to w takim razie co widzisz?

Widzę marnotrawstwo. Ogromne, niepoliczalne marnotrawstwo. Marnotrawstwo na marnotrawstwie, marnotrawstwem pogania.

Jak możesz tak mówić?

No więc, rozważmy ten przypadek Programowania Zorientowanego Obiektowo. To nie jest tak, że OO jest martwe. OO nigdy nie było żywe. OO to jest technika i to dobra. Twierdzić, że OO jest martwe, to jak twierdzić, że doskonale sprawny śrubokręt jest martwy. Mówienie nara do OO jest jak mówienia nara do doskonale działającego śrubokręta. Co za marnotrawstwo!

Ale Programowanie Funkcyjne jest lepsze!

No sorry, ale to jak mówienie, że młotek jest lepszy od śrubokręta. Programowanie funkcyjne nie jest lepsze od programowania zorientowanego obiektowo. Programowanie Funkcyjne jest techniką i to dobrą i może być użyte obok Programowania Zorientowanego Obiektowo.

Nie jest to to, co słyszałem. To, co słyszałem, to to, że te techniki są rozłączne.

Oczywiście, że nie są. Adresują problemy, które wzajemnie się przenikają. Takie problemy występują we wszystkich projektach informatycznych.
Słuchaj, są ludzie, którzy uważają, że oprogramowanie naturalnie podąża za postępem, że bez przerwy wchodzi po drabinie w górę. Każda "nowa" rzecz jest lepsza niż poprzednia "starsza" rzecz. Tak to nie działa.


No więc jak to działa - według Ciebie?

Postęp w oprogramowaniu podąża za krzywą logarytmiczną. We wczesnych latach postęp był ostry i dramatyczny. W późniejszych latach postęp stał się bardziej przyrostowy. Teraz postęp praktycznie nie istnieje.

Zobacz, asembler był o niebo lepszy od binarnego kodu maszynowego. Fortran był dużo lepszy od asemblera. C był lepszy niż Fortran. C++ był prawdopodobnie lepszy od C. Java to ulepszenie w stosunku do C++, a Ruby jest tylko troszkę lepszy od Javy.

Waterfall był o niebo lepszy niż nic. Agile był lepszy niż waterfall. Lean był trochę lepszy niż Agile, a Kanban to tylko usprawnienie.

Każdego roku, mimo, że dokonujemy ogromnego wysiłku, robimy mniejsze postępy niż rok wcześniej, ponieważ zbliżamy się coraz bliżej i bliżej do asymptoty.

Asymptoty! Czy uważasz, że jest górna granica technologii oprogramowania i postępu?

Absolutnie, tak właśnie uważam. Co więcej uważam, że jesteśmy tak blisko tej asymptoty, że dalsze staranie się nie ma sensu. Myślę, że przekroczyliśmy punkt, który opisuje prawo malejących przychodów.

Co takiego? To brzmi śmiesznie! To brzmi deprymująco!

Rozumiem to. To wszystko przez to, że przywykliśmy do tych początkowych etapów szybkiego wzrostu. To były ekscytujące czasy i bardzo chcemy żeby powróciły. Ale one odeszły i musimy stanąć przed faktem, że marnujemy czas i wysiłki na masową skalę, aby poczuć się tak, jak wtedy.

No, ale jeżeli nie będziemy pchać do przodu, nie stworzymy świetlnej przyszłości.

Uwierz mi, ja bardzo chcę abyśmy pchali do przodu, ku przyszłości. Nie robimy jednak tego. To co robimy, to trzymanie się kurczowo czasów minionych.

No więc jak wygląda przyszłość, do której powinniśmy dążyć?

Produktywnie. Niech to będzie przyszłość, która nie jest zdominowana przez te marnotrawne bicie piany.

O co chodzi z tą marnotrawnością.

Czy używałeś kiedyś IntelliJ Idea lub Eclipse do programowania w Javie?

No pewnie.

To są niesamowicie użyteczne narzędzia. Doświadczony profesjonalista może być dzięki nim bardzo efektywny. Te refaktoringi! Te ułatwienia! Mój Boże, te narzędzia są spektakularne.

Każdorazowo, kiedy wyjdzie nowy język programowania uciekamy od tych mocarnych narzędzi, żeby używać NOWEJ WSPANIAŁEJ RZECZY. Tymczasem narzędzia do tego nowego języka pozostawiają wiele do życzenia. Wielkie nieba, tam zwykle nie ma nawet dobrze działającego narzędzia do automatycznej zmiany nazwy!

Mijają wieki zanim ten język doczeka się sensownego zestawu narzędzi. Jeżeli będziemy ciągle zmieniać języki nigdy nie będziemy w stanie zbudować im odpowiednio dobrych narzędzi.

Ale te nowe języki są lepsze.

Byzydura. One są różne, ale nie są lepsze. Lub przynajmniej nie lepsze na tyle byśmy mogli usprawiedliwić wysłanie naszego całego zestawu narzędzi spowrotem do epoki kamienia łupanego.

I pomyśl o kosztach szkolenia, potrzebnego do adaptacji do nowego języka. Pomyśl o kosztach organizacyjnych konieczności używania 84 różnych języków tylko dlatego, że programiści są podjarani błyszczącym nowością świecidełkiem raz na dwa tygodnie.

Błyszczące nowością świecidełka? To trochę obraźliwe, nieprawdaż.

A i owszem, ale do tego to się sprowadza. Nowe języki nie są lepsze. One są po prostu błyszczące. Co więcej poszukiwanie złotego runa nowego języka, nowego frameworka, nowego paradygmatu, czy nowego procesu jest podejściem nieprofesjonalnym.

Jak to nieprofesjonalnym?

Tak! Nieprofesjonalnym! Potrzebujemy uświadomić sobie, że osiągnęliśmy asymptotę.

Czas skończyć z pezproduktywnym biciem piany o językach, frameworkach, paradygmatach czy procesach.

To jest czas, aby po prostu zabrać się do roboty.

Potrzebujemy wybrać język, dwa czy trzy. Mały zbiór prostych frameworków. Zbudować nasze narzędzia. Utwierdzić nasze procesy. I stać się w końcu cholerną profesją.

Poniższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :
http://blog.cleancoder.com/uncle-bob/2016/07/27/TheChurn.html
Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.