eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaPICowanieRe: PICowanie
  • Data: 2013-10-11 17:56:54
    Temat: Re: PICowanie
    Od: Sebastian Biały <h...@p...onet.pl> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    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.

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: