Pragmatyczne Programowanie Funkcyjne

uncle bob label image
Przechodzenie do programowania funkcyjnego rozpoczęło się na dobre jakąś dekadę temu. Widzieliśmy jak języki Scala, Clojure i F# zaczęły przyciągać uwagę. To przechodzenie było czymś więcej niż tylko zwykłym entuzjazmem w stylu: "O fajnie, nowy język!". Było w tym coś prawdziwego. Coś, co to napędzało - przynajmniej tak myśleliśmy.

Poniższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :


Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.

Prawo Moora mówiło, że prędkość komputerów będzie podwajać się każdorazowo co 18 miesięcy. To prawo sprawdzało się od lat 60-tych aż do roku 2000. I wtedy się zatrzymało. Na amen. Częstotliwości zegara osiągnęły 3ghz i krzywa wzrostu spłaszczyła się. Prędkość światła została osiągnięta. Sygnały nie mogły rozchodzić się po układzie elektronicznym z wystarczającą prędkością, aby zapewnić szybsze działanie.
Więc projektanci sprzętu zmienili swój plan działania. Aby zapewnić większą wydajność, dodali więcej procesorów (rdzeni). Żeby zrobić miejsce dla tych rdzeni usunęli wiele elementów pamięci podręcznej i potokowości z tych układów. Zatem procesory stały się odrobinę wolniejsze niż przedtem, ale za to było ich więcej. Wydajność zwiększyła się.
Miałem swoją pierwszą dwurdzeniową maszynę 8 lat temu. Dwa lata później miałem czterordzeniową maszynę. I tak zaczęło się rozmnażanie rdzeni. I wszyscy zrozumieliśmy, że to wpłynie na tworzenie oprogramowania w sposób, którego nie mogliśmy przewidzieć.
Jedną z naszych reakcji na to wszystko było uczenie się Programowania Funkcyjnego (PF). PF mocno zniechęca do zmiany stanu zmiennej raz zainicjalizowanej. Ma to zasadniczy wpływ na współbieżność. Jeżeli nie możesz zmienić stanu zmiennej, nie masz problemu sytuacji wyścigu. Jeżeli nie możesz zaktualizować wartości zmiennej, nie masz problemu jej jednoczesnego nadpisania.
Uważano to za rozwiązanie problemu wielu rdzeni. W momencie, gdy rdzenie rozmnażały się, współbieżność, BA! jednoczesność stała się znaczącym problemem. PF miało więc zapewnić styl programowania, który łagodziłby problemy związane z obsługą 1024 rdzeni w procesorze.
Więc wszyscy zaczęli uczyć się Clojure, lub Scali, lub F# lub Haskella; ponieważ widzieli, że pociąg towarowy już pędził po torach i zmierzał w ich kierunku, a oni chcieli być przygotowani, kiedy nadjedzie.
Ale pociąg towarowy nigdy nie nadjechał. Sześć lat temu miałem laptopa z czterema rdzeniami. On tego czasu miałem ich jeszcze dwa. Wygląda na to, że mój następny laptop też będzie miał cztery rdzenie. Czy jesteśmy świadkami kolejnego spłaszczenia krzywej wzrostu?
Tak na marginesie, wczoraj wieczorem oglądałem film z 2007 roku. Bohaterka używała laptopa, przeglądała strony używając wymyślnej przeglądarki, używała Google'a i odbierała SMSy na telefonie z klapką. To wszystko wyglądało bardzo znajomo. Ooo, jasne, że minęło już trochę czasu - widziałem starszy model laptopa, starszą wersję przeglądarki i telefon z klapką nie przypominał dzisiejszych smartfonów. Nadal - zmiana ta nie była aż tak dramatyczna jak od roku 2000 do roku 2011. I nawet nie zbliżyła się do tej zmiany, jaka miała miejsce pomiędzy latami 1990 - 2000. Czy jesteśmy świadkami kolejnego spłaszczenia krzywej wzrostu w dziedzinie komputerów i technologii oprogramowania?
Więc, być może PF nie było tak kluczową umiejętnością, jak wtedy myśleliśmy. Może nie utoniemy pod zalewem rdzeni. Może nie musimy się martwić układami zawierającymi 32768 rdzeni. Może powinniśmy się odprężyć i wrócić do aktualizowania wartości zmiennych.
Myślę, że to byłby błąd. Duży błąd. Myślę, że to byłby błąd tak duży, jak niepowstrzymane użycie goto. Myślę, że byłoby to tak niebezpieczne, jak porzucenie dynamicznych, polimorficznych wywołań funkcji.
Dlaczego? Możemy zacząć argumentować od tego, co nas najbardziej interesuje. PF sprawia, że współbieżność jest bezpieczniejsza. Jeżeli budujesz system z wieloma wątkami, lub procesami, wtedy użycie PF znacząco zmniejszy problemy, które mógłbyś mieć z sytuacjami wyścigu i jednoczesną aktualizacją zmiennych.
Co jeszcze? Cóż, PF jest łatwiejsze do pisania, łatwiejsze do czytania, łatwiejsze do testowania i łatwiejsze do zrozumienia. Wyobrażam sobie, jak teraz część z was macha rękami i krzyczy do monitora. Spróbowałeś PF i stwierdziłeś, że nie znajdujesz w tym niczego łatwego. Wszystkie te operacje map i reduce, i cała ta rekurencja - szczególnie rekurencja ogonowa to nic prostego. Jasne. Rozumiem. Ale to tylko problem z zaznajomieniem się. Jak tylko obeznasz się z tymi pomysłami - aby rozwinąć taki stopień zaznajomienia nie trzeba dużo czasu - programowanie stanie się o wiele prostsze.
Dlaczego staje się prostsze? Ponieważ nie musisz śledzić stanu systemu. Stan zmiennych nie może się zmieniać; więc stan systemu pozostaje niezmieniony. I to nie tylko systemu nie musisz śledzić. Nie musisz śledzić żadnego stanu listy, czy stanu zbioru, czy stanu stosu, czy kolejki; bo te struktury danych nie moga być zmienione. Jeżeli wkładasz element na stos w języku PF, dostajesz nowy stos, nie zmieniając starego. To oznacza, że programista może żonglować większą ilością piłeczek w tym samym czasie. Jest mniej do zapamiętania. Mniej do śledzenia. I w ten sposób kod jest prostszy do napisania, czytania, rozumienia i testowania.
Więc jakiego języka powinieneś używać? Moim ulubionym jest Clojure. Powód jest taki, że Clojure jest absolutnie prosty. To jest dialekt Lisp, który jest wspaniale prostym językiem. Proszę bardzo, pozwól, że Ci zademonstruję.
To jest funkcja w Javie: f(x);
Teraz, aby zmienić ja w funkcję w Lispie, musisz po prostu przesunąć pierwszy nawias w lewo: (f x).
Teraz znasz już 95% Lispa, i umiesz około 90% Clojure. Ta śmieszna, mała składnia dotyczy większości tego rodzaju języków. To jest absurdalnie proste.


OK, może już widziałeś kiedyś programy w Lispie i nie spodobały Ci się te wszystkie nawiasy. I może nie lubisz tych operacji CAR i CDR i CADR i innych. Nie martw się. Clojure ma trochę lepszą interpunkcję niż Lisp, więc będzie trochę mniej nawiasów. Clojure zamieniło CAR i CDR i CADR na first i rest i second. Co więcej, Clojure jest zbudowany na JVM, co z kolei umożliwia kompletny dostęp do pełnej biblioteki Javy. Interoperacyjność jest szybka i łatwa. I, jeszcze lepiej, Clojure pozwala na pełny dostęp do możliwości OO JVM-a.
"Ale zaraz, zaraz!". Słyszę, jak mówisz. "PF i OO się wzajemnie wykluczają!". Kto Ci to powiedział? To bzdury! Ooo, to prawda, że w PF nie możesz zmienić stanu obiektu; ale co z tego? Tak jak wrzucenie liczby całkowitej na stos daje w wyniku nowy stos - wtedy, kiedy wywołujesz metodę, która aktualizuje jakąś wartość z obiektu, dostajesz nowy obiekt, zamiast zmieniać stary. Łatwo to ogarnąć, szczególnie jak przywykniesz.
Ale wracając do OO. Jedną z własności OO, którą uważam za najbardziej przydatną, w kontekście architektury oprogramowania, jest dynamiczny polimorfizm. I Clojure dostarcza całkowity dostęp do dynamicznego polimorfizmu Javy. Być może przykład wyjaśni to najlepiej.
(defprotocol Gateway
  (get-internal-episodes [this])
  (get-public-episodes [this]))
Powyższy kod definiuje polimorficzny interfejs dla JVM. W Javie ten interfejs wyglądałby tak:
public interface Gateway {
  List<Episode> getInternalEpisodes();
  List<Episode> getPublicEpisodes();
}
Na poziomie JVM wyprodukowany bajtkod jest identyczny. Dzięki tej samej cesze program w Clojure może implementować interfejs Javowy. W Clojure wygląda to tak:
(deftype Gateway-imp [db]
  Gateway
  (get-internal-episodes [this]
    (internal-episodes db))
  (get-public-episodes [this]
    (public-episodes db)))
Zauważ ten argument konstruktora db, i jak wszystkie metody mają dostęp do niego. W tym przypadku implementacje interfejsu po prostu przekazują go do funkcji lokalnych.
Najlepszy z tego wszystkiego, być może, jest fakt, że Lisp, a co za tym idzie Clojure, jest (uwaga) Homoikoniczny, co oznacza, że kod jest danymi, na których program operuje. To łatwo zobaczyć. Ten kod: (1 2 3) reprezentuje listę trzech liczb całkowitych. Jeżeli pierwszy element listy będzie funkcją, tak jak w: (f 2 3) stanie się to wywołaniem funkcji. Z tego, wszystkie wywołania funkcji w Clojure są listami; a listy mogą być bezpośrednio manipulowane przez kod. Z tego wynika, że program potrafi stworzyć i uruchomić inne programy.
Podsumowanie jest takie. Programowanie funkcyjne jest ważne. Powinieneś uczyć się go. I jeśli zastanawiasz się jakiego języka mógłbyś się uczyć, ja sugeruję Clojure.

Powyższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :


Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.

Droga Hackera!

uncle bob label image
Zawsze wydawało mi się, że Erik Meijer (@headinthebox) jest całkiem inteligentnym gościem. Prawda? Mam na myśli to, że koleś, który dał nam LINQ, nie może być idiotą, mam rację?
Ale ostatnio ... No cóż, ostatnio zdałem sobie sprawę, że dr Meijer jest po prostu niesamowicie genialny. To znaczy kreatywnie, kosmicznie, bohatersko genialny! A powód? POWÓD? POWÓD jest taki, że właśnie zrobił kawał stulecia!
Proszę, obejrzyj to. Po obejrzeniu tego Ron Jeffries zatweetował:
"no cóż, to było 45 minut, do których już nigdy nie wrócę"

Poniższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :


Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.

Popatrz na dr Meijera grzmiącego, pieklącego się, dyszącego, pocącego się, szturmującego scenę, emitującego więcej szaleństwa niż normalny móżg jest w stanie znieść. Grzmi wśród płomieni piekielnych i oparów siarki. Jest jak słusznie oburzony kandydat do sejmu. Jest jak moralnie dotknięty aktywista na rzecz praw obywatelskich.
Poczuj entuzjazm i pasję tego człowieka kiedy nawołuje swoich słuchaczy (w czasie 30:00), aby unikali testowania ich kodu. Mówi:
"Jedyna słuszna droga tworzenia Twojego oprogramowania to wrzucenie tego na produkcję! Ponieważ to się zawali. I wtedy, jak tylko się zawali, cofasz to do poprzedniej wersji! ... Nie ma żadnego innego sposobu, w który mógłbyś wcześniej testować swoje oprogramowanie. Więc całe to TDD to gówno? Zapomnij o nim. Jeżeli Twoja firma robi TDD - co robisz? Zwalniasz się! Odchodzisz! Wypisujesz wypowiedzenie już dziś! ... Pisanie testów to marnotrawstwo. TDD jest dla ciot."
Ale nie wyłączaj tego video! Słuchaj dalej! Oglądaj dalej! Zobacz, jak dr Meijer pokazuje nam "jedyną architekturę jaką zna", siedmiowarstwowe struktury OSI dla telekomunikacji. Nudziarstwo, mówisz? Ooo, nie! Na podstawie prostego przykładu architektury opartej na hierarchicznych warstwach, której w zasadzie nikt jeszcze nie zaimplementował, błyskotliwie argumentuje, że zespoły programistyczne powinny być zarządzane poprzez struktury ścisłego nadzoru i kontroli, jak w przypadku Kościoła Katolickiego, czy armii.
"Kościół istnieje od około 2000 lat. Żadne przedsiębiorstwo nie istnieje od 2000 lat. Dlaczego kościół potrafił przetrwać tak długo? Bo to architektura warstwowa!"
Oczywiście! Dlaczego nie wiedzieliśmy tego od samego początku! Kościół przetrwał, bo to wczesna implementacja stosu OSI!


W czasie 34:16 przedstawia obraz typowego programisty i twierdzi, że programiści to w zasadzie żołnierze, którym najlepiej służy wojskowa struktura, taka, jak armia. Mówi:
"Wszystkie nasze firmy powinny mieć kształt ściśle zhierarchizowanych struktur wojskowych."
Powołując się na paragraf w Podręczniku Marynarki Wojennej, Rozdział 1 : Działania Wojskowe mówi:
"Jeżeli zamienisz słowo 'wojna' na słowo 'oprogramowanie' to to po prostu pasuje! Ponieważ oprogramowanie jest jak walka na wojnie. A więc, koniec z tymi agilowymi bzdurami, spójrzmy na wojsko, jak robią to od tysięcy lat!"
I wtedy. I Wtedy. I WTEDY ...
"Czego nas może to nauczyć? Walka na wojnie nie jest dla starych ludzi! Starzy ludzie, jak ja, nie powinni być w tej branży."
Aby udowodnić swój punkt widzenia pokazuje wykres ze średnim wiekiem piłkarzy światowej klasy, który wynosi 27 lat +/- 1 rok. To ma oczywiste przełożenie na świat oprogramowania. To oczywiste, że twórcy oprogramowania są podobni, w każdy możliwy sposób, do piłkarzy światowej klasy. Te dwie branże są prawie identyczne w swoich celach i demografii. Prawda? Oczywiście.
"Chcę aby traktowano zespoły programistyczne jak zawodowe drużyny sportowe. Pomiędzy 22. a 32. rokiem życia, masz nie robić nic innego, tylko kodować! Koduj 24 godziny, 7 dni w tygodniu. Tak jak profesjonalny sportowiec."
O tak, oczywiście, to ma całkowicie sens. Programiści są wartościowi tylko w tym konkretnym przedziale wiekowym. Po osiągnięciu 32 lat ich ciało daje o sobie znać. Po osiągnięciu tego wieku wszyscy dostają Zespołu Cieśni Kanału Nadgarstka i nie mogą już więcej programować! Oczywiście!
"Wy, programiści, powinniście myśleć tylko o kodzie. Powinniście śnić o kodzie, jeść i pić kod."
I wtedy, następuje ostateczny cios. Mistrzowskie uderzenie. Mem, który wieńczy dzieło:
"Ale to także oznacza, że powinniście zarabiać tyle ile profesjonalny gracz w piłkę. Dlaczego, do diaska, Messi (piłkarz światowej klasy) zarabia szesnaście milionów dolarów rocznie, a ty, który piszesz kod, będąc profesjonalnym koderem oprogramowania tak samo utalentowanym jak Messi, co dostajesz? Sześćdziesiąt tysięcy Euro? Coś koło tego? To śmieszne! A więc powinieneś ruszyć dupę w troki i przez te dziesięć lat zarobić całą tę kasę i wtedy przejść na emeryturę."
Cóż, dlaczego ktoś mógłby odpowiedzieć "nie" na coś takiego?

Geniusz

W prezentacji dr Meijera jest tego więcej. Dużo więcej. Dla przykładu, gdy gdzieś w środku prezentacji mówi o strukturze zespołu i jak gówniany jest Agile, przerywa, aby zaprezentować wstęp do teorii sterowania i automatów Mealy'ego.
Na początku, oglądając Jego szalone wybryki, możesz mieć wrażenie, że troszeczkę odleciał. Potem możesz pomyśleć, że oszalał. Potem zatopisz się w głębi połączonych ze sobą nielogiczności, sprzeczności i emocji. Ale, na końcu, jeśli jesteś bystry, zaczynasz zauważać, że ten człowiek jest absolutnie genialny.
Jest genialny w przeprowadzaniu perfekcyjnej mistyfikacji.
Posłuchaj tłumu. Posłuchaj jak akceptują wszystko, co do nich mówi. Posłuchaj jak ich słabe umysły bezkrytycznie wskakują do tego niekończącego się pociągu śmiesznych pomyłek i nonsensu. Oni to łykają!
Dr Meijer wypełnił te czterdzieści pięć minut kompletnymi bzdurami i wszystkim się to spodobało. A to wymaga geniuszu.
Jestem pewien, że schodząc ze sceny chichotał tak mocno, że zmoczył sobie spodnie.

Powyższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :


Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.

Tragedia Rzemiosła

uncle bob label image
Wydajesz się zamyślony.
Tak. Właśnie przeczytałem transkrypcję prezentacji Martina Fowlera otwierającą konferencję Agile Australia 2018. Nazwał to "Stan Agile w 2018".
Aaa, tak, wspaniała prezentacja.
  • Strzeż się Złożoności Agile-Branżowej
  • Dbaj o Techniczną Doskonałość
  • Produkty ponad Projektami
    Fantastyczne treści! No więc, co Cię martwi?

Poniższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :


Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.


W tej prezentacji powiedział, że uformowanie się ruchu Software Craftsmanship (Rzemiosła Programistycznego) było tragedią.
Tak. Ma rację.
Ma? Jak to? Myślałem, że Software Craftsmanship było dobrą rzeczą.
O tak, jest. To bardzo dobra rzecz.
No to o co chodzi?
Tragedią jest, że ruch Agile miał promować wartości Rzemiosła; i poniósł porażkę. Sromotną.
Nie rozumiem.
Ruch Agile tak bardzo zaangażował się w promowanie konferencji i certyfikowanie Scrum Masterów i Menedżerów Projektu, że porzucił programistów i porzucił wartości i dyscypliny Rzemiosła.
Ale myślałem, że to programiści zapoczątkowali ruch Agile.
Tak. Tak było. To jest największa ironia. To programiści rozpoczęli ruch Agile mówiąc: "Hej popatrz! Zespoły się liczą. Kod powinien być czysty. Chcemy współpracować z klientem. I chcemy wdrażać wcześnie i często."
Ruch Agile rozpoczęli programiści i profesjonaliści od oprogramowania, którym drogie były ideały Rzemiosła. Ale wtedy wpadli menedżerowie i powiedzieli: "Łaaał! Agile jest nowym sposobem, w jaki możemy zarządzać projektami."
Jest taka stara piosenka napisana przez Alana Shermana, nazywa się "J.C. Cohen". Opowiada o zawiadowcy kolejki metra, który pracował przy upychaniu ludzi do wagonów. Robił to tak dobrze, że wypchnął maszynistę z pociągu. To samo się stało z ruchem Agile. Wepchnęli tak wiele menedżerów, wypychając jednocześnie programistów.
To nie jest dokładnie tak, jak Martin Fowler to opisał. Powiedział, że ruch Craftsmanship powstał, bo grupa programistów powiedziała: "Ooo, potrzebujemy stworzyć całkiem nowy świat dla nas samych [...] gdzie możemy pójść, odejść od tych wszystkich ekspertów biznesowych, menedżerów projektów i analityków biznesowych, żeby móc w spokoju pogadać o sprawach technicznych"
Oooo, nie. Martin odebrał to całkowicie błędnie. Wyraźnie widać z Manifestu Rzemiosła Oprogramowania, że celem Rzemiosła jest podążanie i rozwijanie przesłania Agile. Rzemiosło Oprogramowania to nie jest jakaś forma Technicznych Mokrych Fantazji Nocnych. Rzemiosło Oprogramowania jest po prostu kontynuacją oryginalnych celów Agile.
Rzemiosło to Agile, które ruch Agile porzucił.
Porzucił? Porzucił, żeby robić niby co?
Żeby promować konferencje, certyfikaty, i fajne nowe sposoby zarządzania projektami.
Co jest złego w certyfikatach?
Ujmę to w ten sposób: Każdy, kto zaproponowałby dwudniowy kurs certyfikacyjny z Rzemiosła zostałby wyśmiany i wyrzucony z pokoju, wyśmiany i wyrzucony z miasta, wyśmiany i wyrzucony z kraju. Ten pomysł jest czystym absurdem.
OK, ale jak chcesz mieć ruch bez szumu, certyfikatów, sesji treningowych, konferencji? Czy nie potrzebujesz tych rzeczy, aby pozyskać uwagę ludzi?
Być może. Ale mam nadzieję, że ruch Rzemiosła nie porzuci swojego oryginalnego celu w sposób, w jaki Ruch Agile to zrobił.
Co to za cel?
Oryginalny cel Agile. Widzisz, Rzemiosło nie jest o nowych rzeczach. Rzemiosło mówi o starych rzeczach. Jest o poprawnym działaniu, o dodawaniu wartości, robieniu dobrej roboty. Jest o współgraniu, o komunikacji, o współpracy. Jest o produktywności i reagowaniu na zmiany. Jest o profesjonalizmie i o etyce. Jest o celu, który Kent Beck ustalił dla Agile.
Co to był za cel?
Podczas konferencji Snowbird w 2001 roku, gdzie Manifest Agile był napisany, Kent Beck powiedział, że jednym z naszych celów jest zasypanie przepaści pomiędzy programistami i zarządzającymi.
Ruch Agile porzucił ten cel przekształcając Agile w biznes, który promuje "nowy-lepszy" sposób zarządzania. Zamiast zbliżać do siebie programistów i menedżerów, Ruch Agile skupił się niemal w całości na zarządzaniu projektem - praktycznie wykluczając programistów.
I dlatego programiści się odłączyli?
Nie! Programiści się nie odłączyli. Programiści zostali na starym kursie! Programiści kontynuowali oryginalnie zapoczątkowane dążenie Agile. Przeczytaj zdanie otwierające Manifest Agile: "My odkrywamy nowe metody programowania dzięki praktyce w programowaniu i wspieraniu w nim innych." My to znaczy Rzemieślnicy i Rzemieślniczki Oprogramowania, którzy kontynuują tę pracę. Nie menedżerowie projektów w ruchu Agile. Oni gonią za czymś innym.
Za czym więc oni gonią?
Za Nowością i Nowinkami. Dzisiaj ruch Agile jest o "Następnej Wielkiej Rzeczy" o "Całkowicie Nowej, Śmiałej Idei". Potrzebują nowości, żeby utrzymać poziom entuzjazmu i energii  bardzo wysoko. Potrzebują tego, aby ludzie zapisywali się na konferencje i certyfikaty. Chcą być postrzegani jako robiący - "postępy". Agile stał się biznesem; a biznes musi rosnąć.
Wydaje mi się, że osiągają sukces.
Osiągają. Nie osiągają jednak sukcesu w dziedzinie oryginalnych celów Agile. Porzucili te cele, aby zaspokajać potrzebę Nowości i Nowinek. Wynikiem jest, niestety, coś, co Fowler i Jeffries nazwali: "Błędnym Agile", "Mrocznym Scrumem", czy "Zwiotczałym SCRUMEM"
Ciężko mi w to uwierzyć.
Udowodnię Ci to. Co było pierwszym punktem prezentacji Fowlera - punkt o Złożoności Agile-Branżowej.
Powiedział coś, że ludzie najlepiej pracują, kiedy wybierają, w jaki sposób chcą pracować.
No właśnie. W zespole programistycznym, kto odwala najwięcej roboty?
Cóż, programiści oczywiście.
Jak dużo programistów było na sali podczas prezentacji Fowlera?
Cóż, użył słów "namiastka", "niewielu", "na pewno mniejszość".
C.n.d.. Kto chodzi na konferencje Agile? Na pewno nie programiści. Nie ludzie, którzy robią całą robotę. Programiści zapoczątkowali te konferencje. Programiści zapoczątkowali ruch. Programiści już tam nie chodzą. To nie programiści się zmienili. To konferencje, i co za tym idzie ruch się zmienił. Ruch Agile odszedł od programistów - odszedł od Agile. C.n.d..
Ale...
Zobacz. Agile nigdy nie było o zarządzaniu projektem; ale to jest to, w co to zamienili. Agile i zarządzanie projektem to całkowicie rozłączne rzeczy. Agile nie jest lepszym sposobem na zarządzanie projektem. Agile nie ma nic wspólnego z zarządzaniem projektem. Agile to zestaw wartości i dyscyplin, które pomagają relatywnie małym zespołom rzemieślników i rzemieślniczek oprogramowania tworzyć małe do średnich systemy.
Ale, czy to nie jest zarządzanie?
Nie! Na Boga Nie! Zarządzanie Projektem jest o datach, budżetach, deadlinach i kamieniach milowych. Jest o zarządzaniu personelem i motywacji. Dobre zarządzanie jest absolutnie potrzebne; ale nie ma nic wspólnego z Agile.
Tu masz. Spójrz na Manifest Agile. Przyuważ te cztery zdania i w jaki sposób są podzielone pomiędzy lewo i prawo. Co rozdziela od siebie te rzeczy po lewej i prawej stronie? Rzeczy po prawej stronie to zarządzanie. Rzeczy po lewej stronie to Agile. Menedżerowie odwołują się do procesów i narzędzi. Osoby w zespole Agile komunikują się ze sobą. Menedżerowie utrzymują wszechstronną dokumentację. Drużyny Agile budują działające oprogramowanie. Menedżerowie negocjują i ustalają kontrakty. Zespoły Agile współpracują z klientem. Menedżerowie upewniają się, że plany są wykonywane. Zespoły Agile reagują na zmiany.
No, ale czy Scrum Masterzy to niejako menedżerowie projektu?
O niebiosa, nie! Scrum Masterzy to doradcy, a nie menedżerowie. Ich rolą jest bronić wartości i dyscyplin. Ich rolą jest przypominać zespołowi, w jaki sposób przyrzekł sobie samemu pracować. Rola ta miała być dzielona pomiędzy zespół, a nie zawłaszczona przez menedżerów. Co kilka tygodni nowy członek zespołu mógłby, na ochotnika, pracować jako doradca - jeżeli byłaby taka potrzeba. Rola miała być tymczasowa. Dorosły zespół nie potrzebuje doradcy na pełny etat.
Łaaał, z całą pewnością teraz nie uczą tego w taki sposób. Czyli sądzisz, że to już koniec Agile.
Nie! Agile żyje, ma się dobrze i kwitnie w sposobie myślenia Rzemiosła. To tam Agile przeniosło się, kiedy menedżerowie projektu najechali i wzięli w niewolę ruch Agile.
No to czym naprawdę jest ruch Agile?
Dzisiaj, ruch Agile mógłby być nieoficjalną odnogą PMI. To jest biznes, który promuje konferencje, kursy i certyfikacje dla menedżerów projektu. A więc, jako takie, stało się przeciwieństwem do oryginalnego celu Beck'a. Ruch agile nie zasypuje przepaści pomiędzy programistami i menedżerami; on ją pogłębia.
Wydaje się, że chcesz powiedzieć, że ruch Agile nie jest Agile.
Nie jest. Stało się to już dawno. Dzisiaj ruch Agile jest o okropnie poronionym pomyśle mówiącym, że to zarządzanie projektem czyni zespół Agile.
Cóż, nie jest tak?
Nie, nie i jeszcze raz nie. Widzisz, zespół Agile to grupa rzemieślników i rzemieślniczek, którzy utrzymują wartości i dyscypliny drogie Agile. Zespół Agile będzie Agile, nie ważne w jaki sposób będzie zarządzany. Z drugiej strony zespół Agile nie stanie się Agile dzięki jakiejś nowej i fajnej strategii zarządzania projektem. Taki zespół będzie Błędnym Agile.
Czy chcesz powiedzieć, że dobry menedżer nie może poprowadzić zespołu, żeby był Agile?
To rzadko spotykany menedżer, który potrafi wpajać wartości i dyscypliny Rzemiosła. To nie jest niemożliwe; ale jest nieczęste. Zespoły Agile są najczęściej złożone z ludzi, którzy już podzielają wartości i dyscypliny Agile - wartości i dyscypliny Rzemiosła. Myślenie, że zespół może stać się Agile tylko dlatego, że Certyfikowany Scrum Master jest menedżerem projektu to marzenie ściętej głowy.
A więc, jaka będzie przyszłość?



Przyszłością będzie to, co było do tej pory zawsze. Wartości i dyscypliny Agile będą pomagały relatywnie małym zespołom programistycznym budować produkty od małych do średnich, i będą zasypywać przepaść dzielącą programistów i zarządzających. Dzisiaj, te wartości i dyscypliny są dochowywane przez ludzi, którzy, czy zdają sobie z tego sprawę czy nie, są związani z ideałami ruchu Software Craftsmanship.
Nie sądzę byśmy potrzebowali promowania ruchu Rzemiosła na poziomie organizacji. Nie sądzę, że potrzebujemy "Stowarzyszenia Rzemiosła". Myślę, że wszystko, czego potrzebujemy, jako ludzie dobrej woli - osoby, które wchodzą w interakcje i współpracują - to społeczność profesjonalistów, którzy pracują nad promowaniem zmian poprzez stałe dodawanie wartości. Myślę, ze idee Agile - idee Rzemiosła - są solidne na tyle, żeby rosnąć i rozprzestrzeniać się bez pomocy ze strony jakiejkolwiek organizacji.
A więc Rzemiosło Oprogramowania nie było tragedią?
Jak mogłyby ideały Rzemiosła kiedykolwiek być rozważane jako tragiczne? Są to odwieczne ideały, do których ludzie dążyli, odkąd stali się ludźmi. Tragedią było to, że ruch Agile stał się biznesem, który cisnął za siebie oryginalne wartości i dyscypliny Agile.


Powyższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :


Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.


Liczby Całkowite i Estymaty

uncle bob label image
Co to jest: a^2 + b^2 = c^2
Twierdzenie Pitagorasa
Dobrze. Czym jeszcze to jest?
Równaniem z trzema niewiadomymi.
Znasz jakieś rozwiązania tego równania?
Jasne. (3,4,5) i (5,12,13).

Poniższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :


Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.


Dobrze. To są często spotykane trójki pitagorejskie. Znasz jakieś inne?
Cóż, Google jest moim przyjacielem, zobaczmy. (wpisuje) Wygląda na to, że (7,24,25) i (9,40, 41) spełniają to równanie.
Zauważyłeś, że te rozwiązania, które podałeś zawieraja tylko liczby całkowite?
Ooo, no tak. Przypuszczam, że jest całe mnóstwo niecałkowitoliczbowych rozwiązań.
Słyszałeś o Diofantosie?
Czy to nazwisko jakiegoś Greka?
Tak, Diofantos zainteresowany był równaniami, które mają rozwiązania złożone z liczb całkowitych. Nazywamy takie równania równaniami diofantycznymi.
Więc a^2 + b^2 = c^2 jest równaniem diofantycznym?
Tak. I jest też wiele innych. Na przykład: a^3 + b^3 = c^3
Ok, spoko. I jakie są przykładowe rozwiązania?
Nie ma żadnych.
Naprawdę? Żadnych?
Tak. Żadnych. To zostało udowodnione. W rzeczywistości zostało udowodnione, że każde równanie a^n + b^n = c^n nie ma całkowitoliczbowych rozwiązań dla n > 2. To jest znane jako Wielkie Twierdzenie Fermata
Hmm. To mogłoby być całkiem interesujące, ale dlaczego mam się tym przejmować w ogóle?
Co to jest komputer cyfrowy?
Co masz na myśli? Ta rzecz na której Ty i ja rozmawiamy jest komputerem cyfrowym.
Tak, ale co dokładnie robi komputer cyfrowy?
Yyy. Oblicza cyfrowo?
Dokładnie! I słowo cyfrowy oznacza ... ?
Hmm. Z użyciem cyfr?
Własnie! I czy liczba tych cyfr jest skończona?
Oczywiście, choć bardzo, bardzo duża w dzisiejszych czasach.
... i skończona liczba cyfr to...?
Ooo, myślę, że wiem, do czego zmierzasz. Skończona liczba cyfr jest liczbą całkowitą.
Tak. Komputer cyfrowy to komputer, który oblicza przy użyciu liczb całkowitych. Przy użyciu tylko liczb całkowitych, niczego innego.
No cóż, chwileczkę. A co z liczbami zmiennoprzecinkowymi i liczbami wymiernymi.
Są reprezentowane w komputerze przez liczby całkowite. Komputer radzi sobie z liczbami całkowitymi - tylko z liczbami całkowitymi.
OK. Dobra. Liczby całkowite. Ale co to ma wspólnego z równaniami diofantycznymi?
Jakie są wejścia programu komputerowego?
Jest wiele różnych typów. Znaki z klawiatury, ruchy myszki, kliknięcia myszki, pakiety internetowe. Do wyboru, do koloru.
One są pod spodem liczbami całkowitymi, prawda?
Hmm. No tak. Wydaję mi się, że są. OK, czyli każde wejście do programu komputerowego to liczby całkowite.
A co z wyjściami?
No cóż, tak, piksele, znaki, pakiety sieciowe. One wszystkie też są złożone z liczb całkowitych.
Więc komuter cyfrowy pobiera liczby całkowite i zwraca liczby całkowite.
Prawda. Masz rację. To wszystko liczby całkowite.
Program komputera cyfrowego, zatem, reprezentuje równanie diofantyczne.
Czekaj. Co?
Liczby całkowite na wejściu. Liczby całkowite na wyjściu.
Ok. Pewnie. Ale to całkiem duże, skomplikowane równanie diofantyczne.
Właściwie, specyfikacja programu jest równaniem. Program znajduje rozwiązanie tego równania.
Tak, tak, OK. To prawda. Specyfikacja programu jest jednym wielkim równaniem diofantycznym z tryliolem niewiadomych i program spełnia tę specyfikację znajdując rozwiązanie tego ogromniastego równania. Czy ta wiedza jest do czegoś potrzebna?
Kto to jest David Hilbert?
Masz na myśli tego gościa, który zaprojektował tę śmieszną rekurencyjną krzywą, która wyglada jak siatka na owady?
(Yhy) To było jedno z jego osiągnięć, tak. On także pomógł Einsteinowi z Ogólną Teorią Względności. Był wspaniałym matematykiem.
I zgaduję, że zrobił coś w temacie równań diofantycznych
W rzeczy samej on robił wiele, wiele rzeczy. Pośród nich było słynne pytanie. Pytanie o "Entscheidung" - rozstrzygalność.
Co on chciał rozstrzygnąć?
Pamiętasz Wielkie Twierdzenie Fermata?
Masz na myśli to równanie, które nie ma rozwiązań. a^n + b^n = c^n gdzie n > 2?
Tak, właśnie to. Przez długi czas nie było dowodu, że przy n = 2 równanie ma jedyne rozwiązanie. Jak możesz obalić przypuszczenie, jeżeli wydaje Ci się ono nieprawdą?
Mógłbym napisać program, który znajduje kontrprzykłady. Na przykład dla n=999999999 to mogłoby zadziałać.
Dobra. I gdybyś znalazł takie rozwiązanie to obaliłbyś Twierdzenie Fermata. Ale jak długo zajęłoby Ci DOWIEDZENIE tego twierdzenia przy użyciu tej metody?
Program wykonywałby się w nieskończoność. Nie mógłbym dowieść twierdzenia w ten sposób.
Dokładnie. To, czego Hilbert chciał, to skończony algorytm do sprawdzenia czy rozwiązanie istnieje, czy nie. Chciał sposobu "decydowania" czy poszukiwania, takie, jak Ty zaproponowałeś byłyby praktyczne.
Czekaj, zaraz. Co? Nie szukał rozwiązań. Szukał możliwości dowiedzenia się czy byłyby rozwiązania?
Tak. Chciał skończonego algorytmu, który powiedziałby, czy dane równanie diofantyczne ma rozwiązania czy nie. Ten algorytm nie dostarczałby rozwiązań; dostarczałby tylko rozstrzygnięcie.
To dlatego nazwał to "rozstrzygalnością"?
Entscheidung. Tak.
Harumph! A teraz. Kto Twoim zdaniem rozwiązał problem rozstrzygalności?
Sądzę, że zaraz mi powiesz.
Dwoje ludzi, o których już słyszałeś. Dwoje wielkich ojców współczesnej informatyki. Alonzo Church i Alan Turing.
Church! To ten gość, który wymyślił programowanie funkcyjne, tak?
W pewnym sensie tak.
I Turing! Wygrał II Wojnę Światową, prawda?
No, na pewno się dołożył. Oni oboje udowodnili, używając zupełnie innych sposobów, że nie istnieje ogólne i skończone rozwiązanie dla rozstrzygalności.
To musiało zawieść Hilberta.
Być może. Ale nie o to chodzi.
OK, no to o co chodzi?
Kiedy dają Ci specyfikację programu, to jest równania diofantycznego, to o co zwykle proszą Cię na początku?
O estymatę oczywiście. Goście chcą wiedzieć jak długo potrwa napisanie programu.


I jeszcze raz, czym jest program w świetle równania diofantycznego?
Program jest ... rozwiązaniem ... dla ... AAA!
(uśmiech) Wydaje mi się, że zaczynasz rozumieć.
Taaa, że, oni proszą mnie abym ROZSTRZYGNĄŁ. Estymata jest rozstrzygnięciem.
I czy istnieje skończona metoda znalezienia rozstrzygnięcia w każdym przypadku?
Nie! O KURKA, to zabawne.
No właśnie. Fundamentalne podstawy informatyki dowodzą, że nie istnieje skończony mechanizm rozstrzygania czy program może być kiedykolwiek napisany. Fundamenty informatyki oparte są na dowodzie, że estymaty nie są gwarantowane.
No tak, ale nadal MOŻEMY estymować.
Tak, możemy. Ponieważ większość specyfikacji jest estymowalna.
A więc to była tylko mała matematyczna rozrywka bez żadnego użytecznego zastosowania.
Można tak powiedzieć. Ale podobało mi się to. Poza tym, to przepysznie ironiczne, że to właśnie dowód o NIEESTYMOWALNOŚCI stoi u podstaw dzisiejszej informatyki.

Powyższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :


Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.


Zasada skautów

uncle bob label image
Skauci mają zasadę: "Zawsze zostawiaj obozowisko czystsze niż je zastałeś." Jeśli zastaniesz bałagan, posprzątaj go, niezależnie od tego, kto to zrobił. Celowo ulepszaj otoczenie dla następnych obozowiczów. W rzeczywistości, oryginalne brzmienie tej zasady, zapisanej przez Roberta Stephensona Smytha Baden-Powella, ojca skautingu, jest następujące: "Postaraj się zostawić świat choć trochę lepszym, niż go zastałeś."

Poniższy tekst jest tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony (Wayback Machine) :


Bazowałem na tłumaczeniu jakie dokonał Rafał Legiędź. @rafek.

na nieistnieącej już stronie 97rzeczy.devblogi.pl.

Archiwum na Wayback Machine

Licencja oryginalnego tekstu: Creative Commons Attribution 3


Co byłoby gdybyśmy postępowali według tej samej zasady podczas naszego kodowania: "Zawsze wysyłaj do repozytorium moduł czystszy niż go pobrałeś"? Co byłoby gdybybyśmy zawsze wkładali trochę wysiłku, nieważne jak małego, aby ulepszyć moduł, niezależnie od tego, kto był oryginalnym autorem? Jaki byłby rezultat?
Myślę, że jeżeli wszyscy pracowalibyśmy według tej zasady, to doświadczylibyśmy końca nieustającego pogarszania się naszego oprogramowania. Zamiast tego, nasze systemy, ewoluując stawałyby się coraz lepsze. Dostrzeglibyśmy zespoły, które dbają o system jako całość, a nie tylko indywidualne jednostki dbające o swoje małe części.
Nie sądzę, aby ta zasada była prośbą o zbyt wiele. Nie musisz doprowadzać każdego modułu do perfekcji przed oddaniem go do repozytorium. Po prostu musisz tylko sprawić, aby stał się odrobinę lepszy niż go zastałeś. Oczywiście oznacza to, że jakikolwiek kod jaki dodajesz do modułu musi być czysty. Oznacza to również, że musisz poprawić chociaż jedną dodatkową rzecz zanim skomitujesz moduł do repozytorium. Mógłbyś po prostu poprawić nazwę zmiennej, albo podzielić długą funkcję na dwie mniejsze. Mógłbyś usunąć cykliczne zależności, albo wprowadzić interfejs, aby odłączyć kontrakt od detali.


Szczerze mówiąc, to brzmi jak zwykły dobry nawyk - jak mycie rąk po skorzystaniu z ubikacji, bądź wrzucenie śmieci do kosza zamiast na ziemię. W rzeczywistości fakt zostawiania bałaganu w kodzie powinien być tak samo nieakceptowalny społecznie, jak śmiecenie. To powinno być coś, czego po prostu się nie robi.
Ale to coś jeszcze wiecej. Dbanie o własny kod to jedno. Dbanie o kod zespołu to kolejna rzecz. Zespoły pomagają sobie i wzajemnie po sobie sprzątają. Pracują trzymając się Zasady Skautów, ponieważ jest dobra dla wszystkich, a nie tylko dobra dla nich samych.

Powyższy tekst jest tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony (Wayback Machine):


Bazowałem na tłumaczeniu jakie dokonał Rafał Legiędź. @rafek.

na nieistnieącej już stronie 97rzeczy.devblogi.pl.

Archiwum na Wayback Machine

Licencja oryginalnego tekstu: Creative Commons Attribution 3

WATS Linia 54

uncle bob label image
Tego ranka miałem interesującą rozmowę z Doc'iem Nortonem. Skłoniło mnie to do rozmyślań...
Wiesz co to jest numer 800. Niektórzy ludzie nazywają je "bezpłatna infolinia". Firma Telekomunikacyjna nazywa je liniami WATS. Wide Area Telephone Service.

Poniższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :


Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.


W roku 1976 podjąłem pracę w firmie na przedmieściach Chicago. Nazywała się Teradyne Central. Robiliśmy sprzęt testujący dla firmy telekomunikacyjnej. Nasz produkt nazywał się 4-Tel. Testował każdą linię telefoniczną, w jednym obszarze świadczenia usług, każdej nocy. Jeden obszar świadczenia usług telefonicznych mógł mieć 100'000 linii lub więcej.
System 4-Tel mógł mieć podłączonych do niego jednocześnie 21 terminali. Każdy terminal mógł był użyty przez testera do testowania linii telefonicznej gdziekolwiek w obszarze świadczenia usług. Test mógł wykryć i zdiagnozować dowolne problemy tych linii; i mógł określić czy dany problem jest po stronie centrali, samej linii czy telefonu klienta. To było ważne, ponieważ te trzy tematy były rozwiązywane przez oddzielne zespoły. Wysłanie odpowiedniego zespołu do odpowiedniego problemu pozwalało oszczędzić dużo pieniędzy.
4-Tel miał wiele innych fajnych funkcji. To był pokaźny system z wieloma przypadkami użycia. I był zainstalowany na obszarze całych Stanów Zjednoczonych.
Kiedy jeden z naszych klientów miał problem, mógł zadzwonić pod numer 800. To automatycznie przełączało go do jednej z dwóch naszych linii WATS. Jeżeli to było w czasie normalnych biznesowych godzin pracy, nasza recepcjonistka odebrałaby linię WATS. Gdy już upewniłaby się, że to klient dzwoni z prośbą obsługi serwisowej, prosiłaby o chwilę cierpliwości i mówiłaby przez nasz wewnętrzny system do powiadamiania:
Czy ktoś z oprogramowania mógłby odebrać WATS linię 54.
Kiedy to było już po godzinach, my, w laboratorium, mogliśmy tylko słyszeć dzwonek linii WATS.
Nie ważne, która to była godzina, zawsze odbieraliśmy.
Było nas około tuzin w zespole programistycznym. Szukalibyśmy najbliższego telefonu z migającą lampką oznaczoną "54". Ktokolwiek był najbliżej telefonu odebrałby telefon. Gdybym to był ja, powiedziałbym:
Teradyne Central Oprogramowanie: Mówi Bob Martin.
I wtedy zaczęlibyśmy procesować problem, i poradzilibyśmy klientowi, co robić.
Czasami, oczywiście, to był błąd pilota, który mogliśmy szybko naprawić. Czasami to był znany problem w naszym systemie, dla którego mogliśmy przedstawić obejście. I czasami to był nowy defekt lub problem, który musieliśmy zdiagnozować na miejscu.
Tak czy siak wisieliśmy na telefonie z klientem dopóki problem nie został rozwiązany.

Inżynierowie Odpowiedzialni

Może mógłbyś zapytać dlaczego nie mieliśmy działu obsługi klienta załatwiającego tego typu telefony; i wpisującego defekty w system śledzenia defektów. Odpowiedź do tego jest prosta. Czuliśmy się odpowiedzialni za system. Chcieliśmy wiedzieć czego doświadczają nasi klienci. Nie chcieliśmy mieć warstwy ludzi izolujących nas od problemów, które to my tworzyliśmy w terenie.
Mieliśmy taki termin w Teradyne: Inżynier Odpowiedzialny. To był podtytuł po linią podpisu na każdym Inżynieryjnym Zleceniu Zmiany. My podpisywaliśmy się pod zmianami, które robiliśmy. My byliśmy Inżynierami Odpowiedzialnymi.
Takie znaczenie miał właśnie dla nas ten termin. My czuliśmy się odpowiedzialni. I dlatego nie chcieliśmy czegokolwiek izolującego nas od rzeczywistych sytuacji naszych klientów.
W Teradyne prowadziliśmy nasz własny QA. Robiliśmy nasze własne DevOpsy. Robiliśmy naszą własną obsługę klienta. I często podróżowaliśmy do lokalizacji klienta żeby pracować z inżynierami Obsługi w Terenie.
W rzeczywistości, to była częsta praktyka dla każdego developera oprogramowania, żeby spędzić dzień lub dwa jeżdżąc z monterem telefonicznym; tylko po to, byśmy mogli zrozumieć, z czym ci goście musieli się mierzyć i jak oni naprawdę używali naszego systemu.

Izolacja

Współczesne zespoły programistyczne są zwykle mocno odizolowane. Żyją w świecie wolnym od rozproszeń pochodzących od klientów i ich "drobnych" problemów. Istnieją całe grupy ludzi, które służą izolowaniu programistów od prawdziwego świata. Dział Obsługi Klienta. Dział Jakości. DevOps. Proszę bardzo, do wyboru do koloru. I dlaczego te grupy w ogóle istnieją? Istnieją, ponieważ we wszystkich z tych dziedzin developerzy oprogramowania zawiedli tak bardzo, że firmy musiały się bronić tworząc całe nowe departamenty i struktury zarządcze.
Myślę, że to jest wstyd. Jak możesz być rzemieślnikiem oprogramowania, jeśli nie porozumiewasz się ze swoim prawdziwym klientem? Jak możesz być rzemieślnikiem oprogramowania, jeśli nie doświadczasz bezpośrednio tych koszmarów, które tworzysz dla devopsów? Jak możesz być rzemieślnikiem oprogramowania, jeśli zostawiasz wszystkie swoje bugi do znalezienia dla działu QA?


Rzemiosło Oprogramowania

Wydaje mi się, że rzemieślnik oprogramowania jest Inżynierem Odpowiedzialnym. Rzemieślnik Oprogramowania nigdy nie będzie odizolowany od prawdziwego świata klienta, od devopsów, od QA, od czegokolwiek jeszcze. Do obowiązków zespołu rzemieślników oprogramowania powinno zaliczać się QA; powinno zaliczać się devops; powinno zaliczać się obsługę klienta. I każdy członek takiego zespołu powinien być zdolny zastąpić każdego innego członka zespołu.
Nie ma nic złego w specjalizacji. Jest wiele złego w izolacji.

Powyższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :


Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.


W Dużej Skali

uncle bob label image
Od pierwszych chwil rewolucji Agile zastanawialiśmy się nad pytaniem o Agile w Dużej Skali. Jak możemy wziąć zasady lekkiego, częstego, przyrostowego, o wysokim poziomie informacji zwrotnej rozwoju oprogramowania i zastosować je do naprawdę ogromnych projektów?

Poniższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :


Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.


Pierwszymi odpowiedziami były takie rzeczy jak Scrum Scrumów. Pomysł był taki, żeby rekurencyjnie zastosować zasady rozwoju oprogramowania Agile na coraz wyższych poziomach skali. Projekt, który wymagał więcej niż jednego zespołu składającego się z 5-12 developerów mógłby być zbudowany z dwóch takich zespołów z zespołem wyższego poziomu do "doglądania?" ich.
Zauważ znak zapytania. Jak tylko zaczynamy rozważać większe projekty, nie udaje nam się uniknąć hierarchii; ale hierarchia wydaje się być herezją w Agile. Poza tym Agile jest o egalitaryźmie. Jest o odrzuceniu zarządzania i kontroli. Jest o odrzuceniu planów i harmonogramów i...
Ooo, co za bzdety! Nie jest!
Agile był rewolucją w sensie "obrotu koła". We wczesnych dniach pisaliśmy kod w zwinny sposób. Pisaliśmy małe kawałki, testowaliśmy je, łączyliśmy je w większe kawałki, testowaliśmy te kawałki w nigdy nie kończącym się cyklu. Jeżeli wróciłbyś do późnych lat 60-tych XX. wieku i popatrzył na kod, który był wówczas pisany, zauważyłbyś fragmenty Agile.
Oczywiście byliśmy ogromnie skrępowani technologią. Kompilacje zajmowały godziny. Edycja była robiona na dalekopisach. Większość programistów w tamtych czasach nie wiedziała, jak w ogóle używać klawiatury; mieli więc swoich operatorów dziurkarek, którzy wprowadzali ich kod za nich. W tego typu środowisku szybkie pętle odpowiedzi zwrotnej były trudne do osiągnięcia.
Nawet wtedy, robiliśmy wszystko, co tylko mogliśmy, żeby skrócić nasze pętle. Pisaliśmy w assemblerze, więc mogliśmy siedzieć przy konsoli i debuggować łatając nasz software przy użyciu liczb ósemkowych lub hexów. Testowaliśmy nasz kod uruchamiając go w debbugerze, lub nawet na jednokrokowym komputerze[1]. Byliśmy w tym całkiem dobrzy. To był jedyny sposób na zrobienie roboty w ciągu czegokolwiek bliskiego sensownemu przedziałowi czasu.
Ale koło kręciło się dalej. Zaczęliśmy używać języków, które nie były łatwe do debugowania w konsoli. Zaczęliśmy pisać coraz większe i większe programy. Żeby zrobić robotę w środowisku z tak długimi pętlami zwrotnymi potrzebowaliśmy planów.
To jest to środowisko, z którego wyłonił się waterfall. Kiedy ogarnięcie pętli wyedytuj/skompiluj/przetestuj zajmuje cały boży dzień, potrzeba wiele planowania i sprawdzania. Nie możesz robić TDD i Refaktoringu w 24 godzinnej pętli!
Ale koło kręciło się dalej. Prawo Moora wrzuciło nas na wykładniczą krzywą, o której większość dzisiejszych programistów nie ma bladego pojęcia. Poszliśmy od 24 godzinnych obrotów w 1970, do 60 minutowych obrotów w 1980, do dziesięciominutowych obrotów w 1990, do dziesięciosekundowych obrotów w 2000. I do 2005 roku czas obrotu dla większości programistów był poniżej sekundy.
To jest to środowisko, z którego wyłoniło się Agile. Agile było powrotem do szybkich obrotów, szybkiego feedbacku, strategii rozwoju oprogramowania z lat 60 XX. wieku, ale z o wiele potężniejszymi maszynami, o wiele lepszymi językami i narzędziami, i w większych projektach.
Ale Agile wyłoniło się także z płomieni. Waterfall, choć konieczny w latach 70-tych i 80-tych, był ekstremalnie bolesny. Dużo się nauczyliśmy przez te dziesięciolecia o tym czego nie robić. Więc, gdy Agile wyłonił się pod koniec lat 90-tych niósł ze sobą te lekcje, które odbyliśmy podczas tych ciemnych czasów.
Agile nie był tylko po prostu powrotem do krótkich cykli informacji zwrotnej. Agile wymusił dyscypliny na bazie tych krótkich cykli informacji zwrotnej. Dyscypliny takie jak testowanie, refaktoryzacja, programowanie w parach i intensywna automatyzacja. To prawda, że Agile był obrotem koła, ale gdy koła się obracają ciągną pojazd do przodu. Agile zdecydowanie popchnął nas do przodu w stosunku do strategii z lat 60-tych.
Ale do przodu z czym? Co było tym czymś ulepszonym przez rewolucję Agile?
Agile było rewolucją w tym, w jaki sposób stosunkowo małe zespoły mogą rozwijać stosunkowo małe projekty oprogramowania. Zauważ nacisk na słowo mały.
Zespół Agile jest świetny do stworzenia systemu oprogramowania o około 100'000 liniach kodu. I te 100'000 linii kodu może zrobić naprawdę wiele. Więc dla wielu przedsiębiorstw jeden lub dwa zespoły Agile są wystarczające do zrobienia czegokolwiek, co tylko te przedsiębiorstwa chcą zrobić.
Z drugiej strony, jeśli potrzebujesz stworzyć system na dziesięć milionów linii, jeden zespół Agile nie da rady. Potrzebujesz około setki zespołów żeby zbudować system z dziesięciu milionów linii kodu.
Ale jak zarządzisz setką zespołów agile'owych? W jaki sposób podasz im historyjki użytkownika. Jak skoordynujesz interfejsy pomiędzy nimi? Jak posegregujesz te dziesięć milionów linii kodu w sposób, w którym te zespoły będą mogły pracować niezależnie od siebie?
I jak (i to było prawdziwe pytanie) zrobisz to w sposób "Agile"?
Odpowiedź brzmi: nie zrobisz!
Sprawa jest taka. My, ludzie jesteśmy całkiem dobrzy w budowaniu wielkich projektów. Wiedzieliśmy jak to robić już od całkiem długiego okresu czasu.



Tylko pomyśl o naprawdę dużych projektach, które, my ludzie, ukończyliśmy.
  • Apollo: wrzuciliśmy człowieka na księżyc!
  • D-Day: Zaatakowaliśmy Normandię z 156'000 żołnierzy w poprzek 50 milowej, ciężko ufortyfikowanej granicy.
  • Mamy światową ekonomię utrzymującą 8 miliardów ludzi.
  • Świat jest pokryty ogromną cyfrową siecią pozwalającą czytać Ci ten tekst na telefonie w chwili, kiedy łazisz po lesie!
  • Potrzebujesz wihajster? Będziesz go miał dostarczony jutro, albo nawet dziś, po kilku dotknięciach palca na Twoim telefonie.
Nie potrzebuję iść dalej. My, ludzie, jesteśmy całkiem dobrzy w robieniu wielkich rzeczy. To jest to kim jesteśmy. To jest to co robimy. Wrzucamy czerwone, sportowe samochody na orbitę heliocentryczną. My robimy duże rzeczy.
Więc po co w ogóle przejmujemy się wielkim oprogramowaniem? My już dawno wiemy jak budować wielkie oprogramowanie. Robimy to już od 50 lat lub więcej. "Wielka" część nigdy właściwie nie była problemem. Problem, który rozwiązaliśmy dzięki "Agile" to była mała część. To, czego nie widzieliśmy jak robić dobrze, to było prowadzenie małych projektów.
Zawsze wiedzieliśmy jak robić wielkie projekty. Prowadzisz wielkie projekty w taki sposób, że dzielisz je na kilka małych projektów. Agile załatwiło tę "małą" część. Agile tak naprawdę nie ma nic wspólnego z tą dużą częścią.
Ale, ale, ale, ale... Egalitaryzm! Odrzucenie planów i Zarządzania i Kontroli! Agile!
Byzydury!
Agile nigdy nie był o egalitaryźmie. Agile nigdy nie był o odrzuceniu planów, albo o odrzuceniu zarządzania i kontroli. W rzeczy samej, Agile było wcieleniem komórki najmniejszego poziomu zarządzania i kontroli: Zespołu.
Tak, w pewnym momencie na drodze w dół hierarchii, zarządzanie i kontrola przestaje być efektywna. Mały zespół osób może pracować razem w krótkich cyklach z dużym poziomem informacji zwrotnej i intensywnym porozumiewaniem się, aby osiągnąć cel. To jest zespół Agile. Na tym poziomie ostre zarządzanie i kontrola są bardzo szkodliwe. Ale powyżej tego poziomu kontrola i zarządzania zaczynają być niezbędne. Im wyżej idziesz, tym bardziej konkretne i oczywiste to się staje. Nie projektujesz, budujesz, produkujesz i sprzedajesz setek milionów iPhone'ów bez straszliwej ilości zarządzania i kontroli.
Jest całkiem sporo strategii Agile W Dużej Skali tu i tam. Były na ten temat pisane książki i blogi. Całe przedsiębiorstwa doradcze były tworzone, aby wprowadzać podejście Agile W Dużej Skali do innych przedsiębiorstw. Nie ma w tym nic złego.
Nie ma nic złego w tych strategiach i technikach opisanych przez te podejścia Agile W Dużej Skali. Oprócz jednej rzeczy. Nie są Agile. Nie mają nic wspólnego z Agile. Raczej, one są odmianą strategii i technik "w klimacie" Agile, których ludzie używali przez tysiąclecia do tworzenia wielkich rzeczy.
Ten klimat wynika z użycia słownictwa i pomysłów z Agile. Nie ma nic złego w tym klimacie - jest w porządku. Jeżeli uważasz, że używanie słów i pomysłów Agile coś daje, idź w ten klimat. Ale nadmiernie nie przejmuj się rzeczywistą "Agile-nością" tego. W momencie, gdy robisz coś dużego, opuszczasz krainę Agile. Zapewne Twoje zespoły programistyczne używają dyscyplin Agile; ale całościowy projekt nie jest już Agile.
Bo Agile jest o małych rzeczach.

[1] W tych dniach, komputery miały przełączniki na przednim panelu, co pozwalało Ci zatrzymać wykonywanie, i wtedy mogłeś uruchamiać poszczególne instrukcje programu krok po kroku. Panel przedni miał światełka, które pokazywały zawartości różnych rejestrów. To pozwalało Ci obserwować, co się działo podczas wykonywania Twojego programu.
Spójrz na przełączniki po prawej na dole na obrazku poniżej. Zobaczysz przełączniki Sing Step i Sing Inst. Sing Step - jeden krok to był jeden cykl zegara. Instrukcja zawsze trwała kilka cykli zegara. Mogłeś więc obserwować jak uruchomienie instrukcji działa od wewnątrz.



Powyższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :


Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.


OO kontra FP

uncle bob label image
Przez kilka ostatnich lat programowałem w parach z ludźmi uczącymi się Programowania Funkcyjnego, którzy manifestowali swoją niechęć do OO. To zwykle sprowadzało się do stwierdzenia pokroju: "Ooo, to za bardzo przypomina Obiekt".

Poniższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :


Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.


Myślę, że to wynika z przekonania, że FP i OO są jakoś wzajemnie rozłączne. Wydaje mi się, że wiele osób myśli, że jeżeli program jest funkcyjny w całości, to nie jest już zorientowany obiektowo. Przypuszczam, że ta opinia wynika z naturalnej konsekwencji uczenia się czegoś nowego.
Wtedy, kiedy zajmujemy się nową techniką, często mamy tendencję do odrzucania starych technik używanych przez nas wcześniej. To jest naturalne, ponieważ wierzymy, że ta nowa technika będzie "lepsza" i stąd ta stara technika musi byś "gorsza".
W tym wpisie stawiam tezę, że ponieważ OO i FP są ortogonalne, nie mogą być wzajemnie rozłączne. Dobry program funkcyjny może (i powinien) być zorientowany obiektowo. I dalej, dobry program zorientowany obiektowo może (i powinien) być funkcyjny. Ale żeby osiągnąć ten cel musimy bardzo ostrożnie zdefiniować nasze pojęcia.

Co to jest OO?

Zamierzam tutaj przyjąć bardzo redukcjonistyczną postawę. Jest wiele poprawnych definicji OO, które obejmują bogaty zestaw pomysłów, zasad, technik, wzorców i filozofii. Zamierzam ominąć to wszystko i skupić się na podstawach. Powód dla takiego redukcjonizmu jest taki, że te wszystkie bogactwa otaczające OO nie są dla niego specyficzne; ale są częścią bogactwa tworzenia oprogramowania w ogólności. Tutaj, skupię się tylko na tej części OO, która jest ostateczna i nierozerwalna.
Rozważ te dwa wyrażenia:
1: f(o);
2: o.f();
Jaka jest różnica?
Jasne jest to, że właściwie nie ma różnicy w znaczeniu. Cała różnica siedzi w składni. Ale jedno wyrażenie wygląda proceduralnie, a drugie wygląda na zorientowane obiektowo. A to z takiego powodu, że wnioskujemy dodatkowe zachowanie z wyrażenia 2., którego nie znajdujemy w wyrażeniu 1. Tym dodatkowym zachowaniem w wyrażeniu jest: polimorfizm.
Kiedy widzimy wyrażenie 1. widzimy funkcję nazwaną f wołaną na obiekcie o nazwie o. Wnioskujemy, że jest tylko jedna taka funkcja o nazwie f i że nie jest jedną z grupy standardowych funkcji otaczających o.
Z drugiej strony, kiedy patrzymy na wyrażenie 2. widzimy obiekt o nazwie o, któremu wysyłana jest wiadomość o nazwie f. Wnioskujemy, że tam mogą być inne rodzaje obiektów, które akceptują wiadomość nazwaną f i z tego powodu nie wiemy, która szczególna funkcja f właściwie zostanie wywołana. Zachowanie jest zależne od typu obiektu o tzn. f jest polimorficzna.
To spodziewanie sie polimorfizmu jest istotą programowania OO. To jest definicja redukcjonistyczna; i jest nierozerwalnie związana z OO. OO bez polimorfizmu nie jest OO. Wszystkie inne cechy OO takie, jak: enkapsulacja danych, i metody łączenia się z tymi danymi, i nawet dziedziczenie jest bardziej powiązane z wyrażeniem 1. niż z wyrażeniem 2.
Programiści C i Pascala (i do pewnego stopnia nawet programiści Fortrana i Cobola) od zawsze tworzyli systemy złożone z enkapsulowanych funkcji i struktur danych. Nie wymaga to więc języka OOPL żeby tworzyć i używać takich enkapsulowanych struktur. Enkapsulacja i nawet proste dziedziczenie jest oczywiste i naturalne w tego typu językach. (Nawet bardziej naturalne w C i Pascal niż w innych.)
A więc tą rzeczą prawdziwie odróżniającą programy OO od programów nie-OO jest polimorfizm.
Mógłbyś poskarżyć się mówiąc, że przecież polimorfizm może być osiągnięty poprzez użycie instrukcji switch lub długich łańcuchów if/else w środku f. To prawda, więc muszę dodać jeszcze jedno ograniczenie do OO.
Mechanizm polimorfizmu nie może stworzyć zależności w kodzie od wołającego do wołanego.
Dla wyjaśnienia, spójrz jeszcze raz na te dwa wyrażenia. Wyrażenie 1: f(o), wydaje się posiadać zależność w kodzie do funkcji f. Wnioskujemy to z tego, co już wcześniej wywnioskowaliśmy, że tam jest tylko jedna funkcja f i dlatego wołający musi coś wiedzieć o wołanym.
Natomiast, gdy patrzymy na Wyrażenie 2. o.f() wnioskujemy coś całkiem innego. Wiemy, że może tam być wiele implementacji f, i nie wiemy, która z tych funkcji f zostanie tak naprawdę zawołana. Zatem kod źródłowy, który zawiera Wyrażenie 2. nie ma zależności kodu źródłowego funkcji, która jest wołana.
W bardziej konkretnych pojęciach oznacza to, że moduły (pliki źródłowe), które zawierają polimorficzne wywołania do funkcji nie mogą zależeć, w jakikolwiek sposób, od modułów (plików źródłowych), które zawierają implementacje tych funkcji. Nie może tam być żadnego include czy use czy require ani żadnej innej deklaracji tego typu, która powodowałaby, że jeden plik źródłowy zależy od drugiego.
A więc naszą redukcjonistyczną definicją OO będzie:
Technika wywoływania funkcji przy użyciu dynamicznego polimorfizmu, w której kod źródłowy wołający nie zależy od kodu źródłowego wołanego.

Co to jest FP?

Znowu, zamierzam być bardzo redukcjonistyczny. FP ma bogatą historię i tradycję, która sięga daleko poza oprogramowanie. Są zasady, techniki, teorie, filozofie i pomysły, które władają tym paradygmatem. Zamierzam zignorować je wszystkie i od razu przejść do sedna, do nierozerwalnego atrybutu, który odgradza FP od każdego innego stylu. I to jest, najprościej, to:
f(a) == f(b) kiedy a == b.
W programie funkcyjnym, każdorazowo, gdy wywołujesz konkretną funkcję z konkretną wartością, otrzymujesz ten sam rezultat; nie ważne jak długo będzie działał program. To jest czasami nazywane "przejrzystością referencyjną".
Konsekwencje tego są takie, że funkcja f nie może zmienić żadnego globalnego stanu, który wpływałby na zachowanie funkcji f. Co wiecej, jeżeli założymy, że ta funkcja f reprezentuje wszystkie funkcje w systemie - wtedy wszystkie funkcje w systemie powinny być przejrzyste referencyjnie - wtedy żadna funkcja w systemie nie powinna w ogóle zmienić żadnego globalnego stanu. Żadna funkcja w systemie nie może zrobić niczego co powodowałoby to, że inna funkcja w systemie zwraca różne wartości dla tych samych wejść.
Głębsza konsekwencja tego jest taka, że żadna nazwana wartość nie może być kiedykolwiek zmieniona. Co znaczy, nie może być żadnego operatora przypisania.
I teraz, kiedy zastanowisz się nad tym bardzo uważnie, możesz dojść do wniosku, że program ułożony z niczego innego jak z referencyjnie przejrzystych funkcji nie może w ogóle nic zrobić - no bo przecież każdy użyteczny program zmienia stan czegoś; nawet, gdy to jest tylko stan drukarki czy ekranu. Jeśli jednak wykluczyć sprzęt i jakiekolwiek elementy ze świata zewnętrznego z naszego ograniczenia do referencyjnej przejrzystości, wtedy wychodzi, że zamiast tego możemy stworzyć całkiem użyteczne systemy.
Tym trikiem jest, oczywiście, rekurencja. Rozważ funkcję, która przyjmuje stanową strukturę danych jako argument. Argument zawiera całą informację o stanie, jaką funkcja używa do swojego działania. Kiedy robota jest zrobiona funkcja tworzy nową stanową strukturę danych z uaktualnionymi wartościami. Jako ostatni krok, funkcja woła samą siebie z nową stanową strukturą.
To jest tylko jeden z tych prostych trików, których program funkcyjny może używać do śledzenia zmian w stanie zewnętrznym, które wydają się nie zmieniać właściwie żadnego wewnętrznego stanu[1].
A więc, redukcjonistyczna definicja programowania funkcyjnego brzmi:
Przejrzystość referencyjna - żadnych ponownych przypisań wartości.

FP kontra OO

Do tej chwili już obie społeczności OO i FP zdążyły wycelować swoje armaty w moim kierunku. Redukcjonizm nie jest dobrą drogą do zdobywania przyjaciół. Ale czasami jest użyteczny. Myślę, że w tym przypadku przydaje się do rzucenia nieco światła na mit FP kontra OO, który wydaje się krążyć tu i tam.
Wydaje się, że te dwie redukcjonistyczne definicje, które wybrałem, są do siebie kompletnie ortogonalne. Polimorfizm i przejrzystość referencyjna nie mają ze sobą nic wspólnego. Nie ma między nimi zbieżności.


Ale ortogonalność nie znaczy wzajemnego wykluczenia (tylko spójrz na Jamesa Clerka Maxwella). Jest całkowicie możliwe zbudowanie systemu, który zawiera te oba: dynamiczny polimorfizm i referencyjną przejrzystość. To nie tylko jest możliwe, to jest pożądane!
Dlaczego to jest pożądane? Dokładnie z tych samych powodów, dla których te oba aspekty są pożądane w pojedynkę. Pożądamy systemów zbudowanych z użyciem dynamicznego polimorfizmu, ponieważ mają niską zależność. Zależności mogą być odwracane poprzez granice architektoniczne. Są testowalne poprzez Mocki, Fake'i i inne rodzaje Dublerów Testowych. Jedne moduły mogą być zmieniane bez potrzeby zmieniania na siłę innych modułów. To sprawia, że takie systemy łatwiej zmieniać i ulepszać.
Pożądamy także systemów, które są zbudowane przy użyciu referencyjnej przejrzystości, ponieważ są one przewidywalne. Niezdolność systemu do zmiany wewnetrznego stanu czyni system łatwiejszym do zrozumienia, zmiany i poprawy. To znacznie zmniejsza szanse wystąpienia sytuacji wyścigu i innych problemów współbieżnej aktualizacji.
Podsumowanie jest następujące:
Nie ma czegoś takiego jak FP kontra OO.
FP i OO świetnie współpracują razem. Oba elementy są pożądanymi częściami współczesnych systemów. System, który jest zbudowany na zasadach obu OO i FP będzie maksymalizował elastyczność, utrzymywalność, testowalność, prostotę i stabilność. Wyrzucając jedną na korzyść drugiej tylko osłabi się strukturę systemu.

[1] Odkąd używamy maszyn z architekturą Von Neumanna, musimy założyć, że istnieją komórki pamięci, które faktycznie zmieniają stan. W przypadku rekurencyjnego algorytmu, który opisałem; optymalizacja rekurencji ogonowej zapobiegnie tworzeniu się nowych ramek stosu i spowoduje zamiast tego ponowne użycie oryginalnej ramki stosu. Ale to naruszenie referencyjnej przejrzystości jest (zwykle) w całości ukryte i nieistotne.

Powyższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :


Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.


Tylko Wykonywałem Polecenia

uncle bob label image
Jest rok 2006. Zarząd Volkswagena wie, że ich silnik diesla nie spełni amerykańskich standardów emisji. Więc poprosili inżynierów o rozwiązanie nie wymagające przeprojektowania silnika.
Wyobraź sobie scenę spotkania w salce konferencyjnej. Co było powiedziane? Na co się zgodzili? Możemy nigdy nie poznać wszystkich szczegółów; ale jasne jest to, że zarząd poprosił inżynierów o znalezienie sposobu oszukania testów emisji.

Poniższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :


Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.


Teraz pomyśl o tych inżynierach. Jaki fajny mieli problem do rozwiązania. No, naprawdę! Wyobraź sobie ile zabawy, może być w wymyśleniu jakiegoś sprytnego sposobu oszukania testów emisji. Jak byś to zrobił? Czy zrobiłbyś to w sprzęcie? Czy zrobiłbyś to w oprogramowaniu? Jak byś wykrył, że jesteś na stanowisku testowym?
"Czekajcie!" - powiedział jeden z geeków. Rozejrzał się po pokoju, upewniając się, że wszystkie oczy patrzą na niego, wykorzystując chwilę ciszy do perfekcji. "Na stanowisku testowym, ... koła się kręcą, ... ale samochód się nie porusza."
"O, WOW!" - mówi inny inżynier. "Czy nie moglibyśmy użyć GPS-a do sprawdzenia czy samochód się porusza"?


Wyobraź sobie tę burzę mózgów, te "dobre" pomysły. Te fajne uczucie, kiedy wiesz, że jest naprawdę sprytne rozwiązanie tego problemu.
Wyobraź sobie, jak zadowolony był zarząd z tym naprawdę fajnym rozwiązaniem inżynieryjnym. Wyobraź sobie, jak dumni byli inżynierowie.
...
I teraz, jeden z nich, James Liang, idzie do więzienia. Będą inni, którzy za nim pójdą. Linią ich obrony było, oczywiście, to, że oni tylko wykonywali polecenia. Oni tylko chcieli utrzymać swoje miejsca pracy - chcieli być pewni, że mogą zapewnić utrzymanie swoim rodzinom. Ale ta linia obrony nie zadziałała. Zostali wtrąceni do więzienia. Wiele lat w kiciu:
"Ten 40-miesięczny wyrok więzienia był [] najwyższym możliwym pięcioletnim okresem za tego typu przestępstwa. Prawnik Liang'a prosił o zamianę wyroku więzienia na okres aresztu domowego tłumacząc, że jego klient tylko wykonywał rozkazy w duchu 'źle pojętej lojalności dla swojego pracodawcy.'"
No i grzywna. Spora grzywna za spore partactwo.
"Mimo, że prokuratorzy federalni żądali tylko 20'000$ grzywny, sędzia stanu Michigan Sean Cox zdecydował uczynić przykład z tego komputerowca i nakazał zapłatę 10 razy większą, jako przestrogę dla innych inżynierów i zarządzających z branży motoryzacyjnej."
Inżynierowie, zapiszcie sobie, proszę: Wasz pracodawca Was nie obroni. Wykonywanie swoich obowiązków nie oznacza ślepego podążania za poleceniami. Sądy będą wymagać od Was wysokich standardów etycznych, nawet gdy pracodawca nie będzie ich od Was wymagał.



Powyższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :


Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.


FORA ZE DWORA, Responsywny Designie

uncle bob label image
Cholerne dzieciaki, nie potrafią zachować poprawnych definicji słów.
Pamiętasz czasy, kiedy słowo "responsywny" znaczyło szybki? O tak, wtedy to miało poprawne znaczenie. Zwykle mówiliśmy coś w rodzaju: "O kurcze, ten system jest z pewnością responsywny!" albo "Musimy włożyć dużo pracy, żeby ten system pozostał responsywny."

Poniższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :


Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.


Ale teraz, nagle, te słowo znaczy: kompatybilny z urządzeniami mobilnymi. Co? Responsywny? W jaki sposób dorabianie GUI to wielkości ekranu czyni system responsywnym? Na co, do diabła, system odpowiada? Na ekran? O rany!
Chciałbym wiedzieć kto porwał ten termin i dlaczego? Chciałbym usiąść i odbyć długą rozmowę z tym gościem. Czy nie moglibyśmy nazwać to "adaptywny", albo może "przyjazny telefonom komórkowym". Dlaczego, do jasnej ciasnej, on wybrał słowo "responywny"; słowo, które już miało całkiem dobre znaczenie?
Siedziałem jednego dnia na spotkaniu i usłyszałem, jak ktoś mówił: "Ale kiedy zrobisz system responsywnym". Moja natychmiastowa reakcja była taka, że ten system jest za wolny. Odpowiedziałem (responded)[1], mówiąc, że w zasadzie czas odpowiedzi (response) był całkiem dobry. Wszyscy odwrócili się i popatrzyli na mnie jak na neandertalczyka.
A tak przy okazji, jak już jestem w temacie słów, które nagle zmieniły swoje znaczenie bez jakiegokolwiek dobrego powodu, co za głupek, który ukradł słowo "Design"? To znaczy czy pamiętasz czasy kiedy "Design" był technicznym terminem oznaczającym wewnętrzną strukturę systemu oprogramowania? Projektanci oprogramowania byli wówczas głównymi programistami. Każdy chciał zostać projektantem (designer). Każdy aspirował do nauki projektowania oprogramowania (software design).
Ale nie teraz. Ooo nie! Teraz design oprogramowania oznacza Projekt Graficzny (Graphic Design). Co było złego w nazywaniu Projektu Graficznego, Projektem Graficznym? Co było złego w nazywaniu Projektantów Graficznych, Projektantami Graficznymi? Dlaczego mieliby odebrać nam nazwę naszego zawodu.
Byłem projektantem (designer) psia krew. Projektowałem systemy oprogramowania. Teraz mówię ludziom, że jestem projektantem oprogramowania i myślą, że jestem gościem od UX! Jak, do diabła, to się stało.
Cholerne dzieciaki! FORA ZE DWORA.


[1] Widzisz/ To jest to, co słowo "odpowiedzieć (respond)" znaczy. Odpowiadasz na bodziec. Ekran nie jest bodźcem. Ekran jest urządzeniem wejścia/wyjścia. Nie odpowiadasz na format urządzenia wejścia/wyjścia. Odpowiadasz na Użytkowników. Cholerne dzieciaki.

Powyższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :


Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.


Wpisz adres e-mail, aby zasubskrybować powiadomienia o nowych postach: