On 2013-10-11 11:59, Sylwester Łazar wrote:
> Nawyk dokumentowania kodu mam już od 15 roku życia.

Ja od 12-go, mając w ręku ZX Spectrum - Z80, przez 6502, 8051, 680x0,
8086, arm, mips. Znam(łem) assemblery wszystkich i we wszystkich
pisałem. I obecnie programuje ogromna aplikację w C++ na duzym systemie
i w wolnych chwilach roluje bity na GPIO AVRka. Skażenie asm nie
przeszkodziło mi znajdywać zalety zarówno programowania
wysokopoziomowego jak i asm, dosuje obie techniki, wliczając to takie
ciekawoski jak programowanie deklaratywne czy constrains a nawet
ostatnio kawalek w prawie-prologu się trafił (na uC :). Używam wielu
narzedzi, a nie tylko młotka asm, bo problemy mam różne więc i narzędzia
też.

> Jednak wyrobienie sobie takiego nawyku przez kilkanaście lat pracy,
> powoduje, że teraz to idzie szybko.

Mam znajomego ktory niezwykle szybko kopie doły łopatą. Do tego stopnia
ze konkuruje z minikoparkami. Czy jesteś pewny że kopanie łopatą ma
jednak przyszłość? Bo ja tak, sprawdza mi się w ogródku.

> Wiadomym jest, że jak stukasz w klawiaturę wpisując ~destruktory w C++,
> czy inne konstrukcje, nie dodając żadnych komentarzy zawsze będzie to
> szybsze,
> niż rysowanie algorytmu, dokładanie opisu słownego po polsku czy angielsku,
> kopiowanie tekstu, czy tworzenie historii zmian.

Szybsze będzie tworzenie unit testów, abstrakcji oraz czytelnego kodu
które pozwolą w pełni przetestować kod zamiast pisania komentarzy które
po miesiącu nie mają nic wspólnego z rzeczywistością bo nie istnieje
żadnej przymus aby były synchronicznie zmieniane z kodem. W "zespole"
jednoosobowym bywają z tym problemy. Wobraź sobie jak to wygląda w
zespole N>1.

> a) przyjemność zabrania się za analizę kodu przedstawionego na kolorowym
> algorytmie,

Ja mam przyjemnośc nie analizowania kodu tylko stwierdzenia jakie
warunki brzegowe ma realizować widząc testy. Implementacja ma tylko tyle
na znaczeniu że musi mieć założoną złożoność bądź restryckje czasowe.

> b) poprawianie, czy adaptacja kodu nie zabiera już tyle czasu, a wręcz
> przyspiesza.

Refaktoring kodu przyspiesza kiedy masz testy.

> c) uruchamianie jest już formalnością i czasem jest tak, że rysujesz/piszesz
> program 3 dni,
> a samo uruchamianie z oscyloskopem czy analizatorem stanów - kilka godzin.

Patrz, zupełnie jak przetestowany kod in virto.

> Gdy znajdziemy błąd, często pada od razu po spojrzeniu w dokumentację
> zdania:
> " No tak... śmieszny błąd"

Albo jak padnie unit test to patrzymy w kod i naprawiamy.

> Dzieje się tak, gdyż poświęcając dużo czasu na przygotowanie kodu, zanim
> zacznie się pisać słowa w dowolnym języku programowania, już wcześniej
> korygujemy wiele błędów natury logicznej, składni, nazwy, czy zwykłych
> pomyłek.

Dzieie się tak gdy przygotujesz sobie test suide na długo przed
napisaniem pierwszego słowa kluczowego algorytmu.

> Po wpisaniu kodu - jest on już niemal pewny.

Ba, przetestowany kod jest nie tylko pewny, ale i *przetestowany*.

> Zmiany zwyczajowo dokonują się poprzez poprawę kilkunastu znaków w kodzie.
> A w większości pewnie w komentarzach i historii zmian.

Która to historia znajduje się w systemie kontroli wersji który bez
watpienia używasz.

> Samo wpisanie daty 2013103 to już 7 znaków :-)

Tym bardziej że zbędne.

> Odpowiadając na Twoje zapytanie - tak kod jest zawsze rozwojowy.
> I tak miało być w założeniu.

Nie wątpie że łopata można kopać dziury różnych kształtów.

> W związku z tym czasem podrzucam żonie mój algorytm sprzed nastu lat na
> 8051,
> a żona przerabia go na PIC32 zmieniając (bardzo optymalnie zresztą) kod.

Zupełnie jak kompilator pawie każdego języka.

> Uczę tej pracy też dzieci, więc już trójka z mojej całej piątki opanowała
> rysowanie algorytmów,
> choć są dopiero na poziomie <liceum.

3 łopaty kopią szybciej niż jedna :P

Odkryłeś kwadratowe koło i je pielęgnujesz piłując pieczołowicie rogi aż
wyjdzie romb. Bez wątpienia warsztat masz znakomity, znajomość asm w
jednym palcu, ale czy na pewno widziałeś jak wygląda warsztat
przeciętnego programisty poza twoim domem? Wiesz ile i jakich narzędzi
używa, jak pracuje w zespole bądź samotnie, ile twoich problemów
rozwiązano w latach 70-tych i gdzie obecnie znajdują się jezyki
programowania? Programiści embedded to czesto skansen osobliwości i
rozwiązań poroblemów które albo nie istnieją albo zostały rozwiązane
dziesięciolecia temu. Nie dalej jak miesiac temu trafilem na mistrza
ktory programuje 8051 w edytorze hex pod dosem znając na pamięc kod
*maszynowy*. Nie dalej jak wczoraj musiałem zmagaś się z
systemverilogiem w którym ktoś intensywnie wymyśla nowe "lepsze"
programowanie obiektowe ignorując to co wiemy od smalltalka.

Nie zrozum mnie źle: szanuje Twoją pracę i wiedzę. Ale proszę, dla dobra
ludzkosci, nie przedstawiaja jej jako wzorca dla kogokolwiek. Jesli Ci
pasuje to ok, jesli sprawia radość to tym lepiej.

Koniecznie obejrzyj to:

http://vimeo.com/71278954

Od 4:00 jest pouczający kawałek na temat "assembler jest najfajniejszy
do wszystkiego".

Tak, ten film to rodzaj żartu, ale czy nie ciekawy? Polecam dla
wszystkich aby to obejrzeć do końca.