Temat: Programowanie jako budowanie teorii

Ostatnio spotkałem się z dosyć ciekawym podejściem do programowania. Otóż podstawowym zadaniem programisty nie jest zbudowanie programu, systemu czy ogólnie mówiąc produktu, ale zbudowanie teorii ze wszystkimi wynikającymi z tego konsekwencjami.

Podobnie jak robili to fizycy i chemicy z ostatnich trzech stuleci, programista powinien opisać rzeczywisty świat swoją teorią zmaterializowaną w postaci kodu źródłowego. Jakie są tego konsekwencje? Otóż programista nie opisuje całej rzeczywistości, a jedynie jej wycinek. Programista powinien najpierw zbudować spójny model dla swojej teorii, wypracować zrozumiały język, określić prawa, zależności oraz ograniczenia. Aby tego dokonać powinien posługiwać się nie tylko kodem (analogia z zmaterializowanymi przedmiotami), ale również opisami, rysunkami, dokumentacją, podręcznikiem użytkownika itp.

Jednakże z powodu ułomności opisów słownych i graficznych, oraz fakt budowania modelu opusu rzeczywistości a nie dokładnego opisu rzeczywistości, sam opis programu, opis modelu oraz kod jest daleko niewystarczający, ale konieczny w zakresie umożliwiającym wdrożenie nowego programisty lub przekazania prac nad rozwojem lub mutacją systemu innemu zespołowi.

Tak więc programista, który taką teorie stworzył powinien móc odpowiedzieć na kilka kluczowych pytań:
1. W jakim stopniu teoria opisuje rzeczywistość i pomaga rozwiązać rzeczywiste problemy?
2. Dlaczego konkretna część programu (moduł, klasa, kontroler itp.) jest tym czym jest i do czego służy?
3. Czy proponowana modyfikacja kodu zmienia stary model teoretyczny czy nie? A jeśli zmienia to w jakim zakresie i czy ta modyfikacja powoduje de facto konieczność zbudowania nowej teorii?

Jakie są konsekwencje takiego podejścia?
1. Otóż sam opis systemu jest jedynie uproszczonym opisem uproszczonego modelu rzeczywistości.
2. Sam kod nie opisuje założeń, ograniczeń i modelu teorii. Jest jedynie zmaterializowaną nieprzezroczystą skorupą.
3. Kod i opis systemu nie opisuje teorii. Jest ułomnym opisem rzeczywistości, który doskonale rozumieją osoby, którzy go sporządzili.
4. Wtajemniczenie kolejnych osób wiąże się z koniecznością przeprowadzenia wspólnej rozmowy na podstawie dokumentacji.
5. Utrata kolejnych osób z zespołu może spowodować osiągnięcie stanu, w którym pozostali przestają rozumieć teorię i model.

Na koniec dodam, że nie zgubiłem po drodze analityka, projektanta i architekta. Obecnie powszechnie mamy sytuację, w której jedna osoba (programista) lub zespół programistów jest niewystarczający. Dochodzą wszyscy Ci pozostali. To tak jak kiedyś Newton potrzebował jedynie krzywej wieży w Pizie do sformułowania swojego prawa powszechnego ciążenia i obecne badania w CERN, mające na celu potwierdzenie założeń Modelu Standardowego. Jedna osoba tego nie dokona.

Temat: Programowanie jako budowanie teorii

wkraczasz w dyskusje o tym, czy racje ma Popper a kwestii tego czym jest "opracowanie teorii", po drugie "czym jest programowanie"? Czy to wymyślenie "algorytmu" czy "zakodowanie" (implementacja) algorytmu"?

Temat: Programowanie jako budowanie teorii

Jarek Żeliński:
wkraczasz w dyskusje o tym, czy racje ma Popper a kwestii tego czym jest "opracowanie teorii", po drugie "czym jest programowanie"? Czy to wymyślenie "algorytmu" czy "zakodowanie" (implementacja) algorytmu"?

Słusznie zauważyłeś, Jarku, że całość opiera się na przekonaniach Poppera z przemyśleniami Naura. Kilka ciekawych rzeczy z tych przemyśleń jednak wynika, chociażby brakujące uzasadnienie stosowania metafory systemu :)

Na pomysł opisania tej tezy wpadłem po ostatnich dyskusja o programistach-murarzach. Nie chcę arbitralnie popierać jednego albo drugiego podejścia. Zwyczajnie przypomniałem sobie ten model.

Natomiast jeśli chodzi o algorytmy, to moim zdaniem zdecydowanie to programista powinien algorytm wymyślić (przypomnieć) i go zrealizować. Czy powinien zaprojektować system? To zależy od wielkości projektu i sytuacji. Czy programista powinien zajmować się architekturą? Moim zdaniem zdecydowanie nie.

Z mojego punktu widzenia, innym bardzo ważnym wnioskiem jest to, że wspólny język mają jedynie uczestnicy, którzy tę teorię wymyślili.

Temat: Programowanie jako budowanie teorii

Aleksander Olszewski:
Natomiast jeśli chodzi o algorytmy, to moim zdaniem zdecydowanie to programista powinien algorytm wymyślić (przypomnieć) i go zrealizować.

zwalam to na karb mojej ogólnikowej wypowiedzi: pisząc algorytm mam na myśli scenariusz obsługi jakiegoś dokumentu czy transakcji biznesowej, czyli pozainformatyczną wiedzę (biznesową). Nie mówię tu o algorytmie sortowania czy liczenia mediany :)

Czy powinien zaprojektować system?
To zależy od wielkości projektu i sytuacji.

nie raz "proste" komponenty może wykonać sam programista bo albo to jakiś przykład "wzorca projektowego" albo dobrej praktyki (zresztąto chyba to samo ;)))

Czy programista powinien zajmować się architekturą? Moim zdaniem zdecydowanie nie.

też tak sądze...

Z mojego punktu widzenia, innym bardzo ważnym wnioskiem jest to, że wspólny język mają jedynie uczestnicy, którzy tę teorię wymyślili.

:D, nie mniej jednak promowanie pracy DDD/MVC moim zdaniem ma sens bo daje jakieś rozdzielne obszary odpowiedzialności...