Posts Tagged ‘programowanie’

Piękny kod. Tajemnice mistrzów programowania. Recenzja.

30 sierpnia 2010

Wstęp

Książka Piękny kod. Tajemnice mistrzów programowaniaPiękny kod. Tajemnice mistrzów programowania to wydane przez wydawnictwo Helion tłumaczenie Beautiful Code: Leading Programmers Explain How They Think zredagowana przez Andy-ego Oram-a i Grega Wilsona.

Autorzy

Piękny kod to zbiór 33 esejów na temat programowania z imponującą listą autorów. Wśród autorów są między innymi:

Treść

Poszczególne eseje omawiają fragmenty kodu, algorytmów (np. Map Reduce), programów, systemów (Ruby) i bibliotek (sterowników jądra Linuksa).

Autorzy posługują się różnymi językami programowania, od dobrze znanego C, poprzez Javę, Perl-a, Pyton-a do funkcyjnego Haskell-a.

Lektura Pięknego kodu jest więc też znakomitą okazją do szybkiego spojrzenia na możliwości oferowane przez inne języki programowania.

W mojej pamięci szczególnie utkwiły rozdziały:

  • Wyrażenia regularne – C, wskaźniki i rekurencja — piękna, bo prosta i elegancka, implementacja wyrażeń regularnych w C,
  • Najpiękniejszy kod, którego nigdy nie napisałem — omawiający algorytm quicksort oraz elegancki sposób mierzenia jego złożoności,
  • Poprawny, piękny, szybki — zawierający parę rad na temat sprytnych optymalizacji,
  • Generowanie w locie kodu do przetwarzania obrazów — zaczął się kiepsko, ale wciągnął jak dobry kryminał,
  • Kod w ruchu — omawiający wpływ złożoności kodu na jego jakość i czytelność.

Przyznam się, że nie wszystkie rozdziały przeczytałem. Parę rozdziałów pominąłem.

Nie dlatego, że były kiepskie, tylko dlatego, że omawiały zagadnienia zbyt trudne (np. genom lub współbieżność) abym wieczorem mógł skupić się na tyle, aby coś z nich zrozumieć :(.

Podsumowanie

Jeżeli ktoś pasjonuje się programowaniem to Piękny kod jest książką dla niego. Znakomici autorzy, interesujące, a często fascynujące treści, dają wielokrotną szansę na zachwyt nad elegancją i prostotą przedstawianych rozwiązań.

Jak swego czasu zanotowałem na Twitterzeod czasu lektury Perełek oprogramowania nie czytałem tak dobrej książki na temat programowania (kodowania).

Recenzje: Szacowanie oprogramowania: kulisy czarnej magii

31 maja 2009

Książka Steve’a McConnell’a Szacowanie oprogramowania: Kulisy czarnej magii to pouczająca, choć dość nudna niestety, lektura, omawiająca dokładnie podstawowe techniki szacowania oprogramowania, ich możliwe zastosowania, wady i zalety poszczególnych metod estymacji oraz częste błędy popełniane podczas szacowania oprogramowania.

Już rozdział drugiSprawdzenie swoich umiejętności szacowania — jest niezwykle pouczający. Brutalnie obnaża jak kiepscy jesteśmy w szacowaniu oraz jak fatalnie źle rozumiemy proces szacowania i jego dokładność.

Książka składa się z trzech części:

  1. Podstawowe elementy szacowania
  2. Podstawowe techniki szacowania
  3. Szczególne wyzwania związane z szacowaniem

Szacowanie oprogramowania: Kulisy czarnej magii opisuje nie tylko naukowo–techniczne metody szacowania, ale także te praktyczne jak szacowanie przez analogię, czy metodę Wideband Delphi.

Książka zawiera też wiele przykładów zastosowania poszczególnych technik estymacji oraz ich skuteczności i chociażby z tego powodu warto ją przeczytać.

Niestety spora liczba tabel, liczb i wykresów powoduje, że książka nie nadaje się na lekturę do poduszki (chyba, że dla dziecka — jak Code Complete :)).

Dwa najważniejsze wnioski płynące z książki są takie:

  1. Nie szacuj tego, co można policzyć.
  2. Najdokładniejsze szacowanie można podać na podstawie danych historycznych.

Dla ciekawych — o książce wielokrotnie pisał Jeff Atwood na swoim blogu coding horror.

O zabawnych komentarzach w kodzie na Stack Overflow…

26 kwietnia 2009

Na Stack Overflow padło znakomite pytanie.

Jedna z lepszych odpowiedzi które czytałem jest tutaj.

Bo zawsze są jakieś zaciachy…

10 marca 2009

Wiele miesięcy temu rozmawiałem na temat narzędzi do prowadzenia projektów informatycznych. Marek zwrócił uwagę, że ważne jest aby narzędzie pomagało dokumentować estymacje i realny czas spędzony na zadaniu, co pozwala na lepszą estymację kolejnych projektów.

Marek przeprowadził nawet eksperyment. Wziął specyfikację jednego z przednich projektów, poszedł z nią do doświadczonego programisty i poprosił o wycenę czasową. Programista rzekł 4 tygodnie, co było zgodne z pierwotnym szacowaniem i całkowicie niezgodne z realnym czasem trwania projektu — kilkanaście tygodni.

Na pytanie Marka, dlaczego uznał, że projekt zajmie 4 tygodnie, podczas gdy projekt trwał o wiele dłużej, programista odpowiedział, że w tamtym projekcie były jakieś zaciachy.

Puenta Marka była taka — zawsze są jakieś zaciachy i szacując trzeba o tym pamiętać.

Używając dokładnie tego samego zwrotu — bo były zaciachy — tłumaczyłem z kolegami opóźnienie jednego z ostatnich projektów w którym brałem udział. Liczne zaciachy rzeczywiście były, tylko szacując czas wykonania projektu, nie wzięliśmy ich pod uwagę…

Wniosek: zaciachy trzeba dokumentować i brać pod uwagę estymując kolejny projekt.

Obszernie o zbieraniu danych historycznych pisze Steve McConnell w książce Szacowanie oprogramowania: kulisy czarnej magii.

FogBugz, system zarządzania projektami informatycznymi firmy FogCreek, implementuje zbieranie danych historycznych.

Copy and Paste, a jakość kodu. Część druga

30 maja 2007

Destrukcyjna funkcjonalność Copy & Paste coraz bardziej mnie przeraża…

Od czasu ostatniego wpisu, uważnie obserwuję temat i już parę razy złapałem siebie i innych, na bezrefleksyjnym kopiowaniu kodu…

W moim wypadku, była to, co prawda, tylko jedna linia kodu formatująca bieżącą datę na potrzeby zapytania SQL, ale:

  • Kopiowaną linię kodu napisałem dawno temu, gdy dopiero poznawałem używany w produkcie język programowania i aby uzyskać bieżącą datę, użyłem funkcji zwracającej bieżącą datę i czas, a ze zwróconej wartości obcinałem czas (przez formatowanie wartości do postaci czystej daty).
  • Teraz wiem, że istnieje funkcja, która zwraca bieżącą datę, więc nie trzeba było niczego obcinać i formatować.
  • Właściwa implementacja nie powodowała błędów wywołanych przez ustawienia regionalne (różna kolejność dnia i miesiąca w dacie w zależności od ustawień regionalnych).

A inne zaobserwowane przypadki to:

  • Kopiowanie kodu wykonującego zapis danych z formularza do bazy (zmieniał się tylko typ zapisywanej wartości), który w nieoptymalny sposób, odwoływał się do bazy danych.
  • Kopiowanie kodu pokazującego okno z komunikatem — problem był tylko w tym, że na początku (stałym) komunikatu była literówka…
  • Skopiowanie kodu pokazującego na stronie WWW formularz oraz kodu zapisującego dane z tego formularza. Kopista ograniczył się do dodania nowych pól na formularzu, ale, pracując pod presją czasu, zapomniał o modyfikacji kodu zapisującego dane z formularza w bazie danych — czytaj uwzględnieniu przez zapis nowych pól.

Możliwości tworzenia i powielania błędów stworzone przez funkcję Copy & Paste są naprawdę porażające… Wiem. Zawsze można zrzucić winę na kopistę, ale łatwość użycia funkcji Copy & Paste do tworzenia nowego kodu jest zbyt kusząca, aby z niej nie korzystać dla większości z programistów i niestety, także, deweloperów.

Podrzuciłem ten temat na forum strony Marka Rafałowicza.

Copy and Paste, a jakość kodu. Część pierwsza

3 kwietnia 2007

Byłem jakiś czas temu świadkiem ciekawej rozmowy, po której naszła mnie następująca myśl — pozbawienie programisty funkcji Copy & Paste dramatycznie poprawiłoby jakość kodu przez niego tworzonego.

Dlaczego? Bo nie mogąc kodu skopiować w nowe miejsce musiałby pomyśleć jak z tego kodu zrobić użyteczną funkcję. A więc wydzielić logiczne bloki kodu (które być może także stałyby się funkcjami), odpowiednio taką funkcję sparametryzować, aby była jak najbardziej ,,reużywalna”, itd.

Także utrzymanie takiego kodu byłoby prostsze — nie trzeba byłoby wyszukiwać wszystkich wystąpień skopiowanego kodu i poprawiać błędów lub zmieniać funkcjonalność we wszystkich miejscach gdzie kod został wklejony.

A co Wy, drodzy czytelnicy o tym myślicie?