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.