Ja nie mam czasu nie pisać testów jednostkowych

Czasami (czasami często) słyszę, że:

…ktoś nie napisał testu jednostkowego bo nie miał na to czasu.

Gdy to słyszę to aż bolą mnie zęby. Jak można nie mieć czasu na sprawdzenie, czy nasz kod działa poprawnie? Wtedy zawsze staram się wyjaśnić, że:

… ja nie mam czasu nie pisać testów jednostkowych.

Continue reading →

Poziomy abstrakcji

Kilka lat temu, ucząc się programowania w języku C++, natknąłem się na ten tekst.

„Komputery są jedynie urządzeniami elektronicznymi. Nie mają pojęcia o oknach czy menu, nie znają programów ani instrukcji, a nawet nie wiedzą nic o zerach i jedynkach. W rzeczywistości jedyne zmiany, jakie zauważają, to zmiany napięcia mierzonego w odpowiednich punktach układów elektronicznych. Nawet to jest dla nich pewną abstrakcją: w rzeczywistości elektryczność jest tylko wygodną intelektualną koncepcją dla zaprezentowania działania cząstek subatomowych, które z kolei są abstrakcją dla czegoś innego.”

„C++ dla każdego” Jesse Liberty

 

Trzymaj się jednego sposobu osiągania danego celu

Zmieniając swoje zachowania, zasady, sposób postępowania, za każdym razem zaczynamy wszystko od nowa i nigdy nie osiągamy rezultatów. Wierz w to co robisz. Nigdy nie wolno Ci się zniechęcać. Nie szukaj wymówek. Wytrwałość w osiąganiu celu wybranym jednym sposobem jest kluczem do sukcesu.

Na przykład, gdy chcesz się nauczyć języka obcego. Rozpoczynasz starannie wybrany kurs. Gdy pojawiają się pierwsze trudności nie zmieniaj tego kursu na inny bo wtedy zaczynasz od nowa.

Trzymaj się wybranego sposobu rozwiązania, nie zmieniaj go co chwilę, nie wymyślaj nowych zasad.

Nie ważne ile kursów zaczniesz. Ważne ile skończysz. Trzymaj się jednego sposobu osiągania danego celu.

Kalkulator napisany z pomocą behavior-driven development (BDD)

Postawiłem sobie za cel napisanie kalkulatora przy użyciu metody BDD a wynikami mojej pracy chcę się z wami podzielić.

Kalkulator ten będzie zachowywać się jak ten z lat dziewięćdziesiątych, pokazany poniżej na obrazku. Mam jeszcze taki sam w domu — ma już chyba 20 lat. Ten, który tutaj zaimplementuje, będzie posiadał, tak samo, jak ten oryginalny, kilka dziwnych zachowań. Na przykład, przy każdym ponownym wciśnięciu „=”, liczba na wyświetlaczu będzie się zwiększać o jeden, jeśli wcześniej wykonaliśmy działanie „1+1”.

Continue reading →

Scrum a błędy na produkcji

Klasyfikacja błędów

Bugi klasyfikujemy ze względu na DOLEGLIWOŚĆ oraz ZŁOŻONOŚĆ. Każda z tych klasyfikacji może osiągnąć poziom WYSOKI lub NISKI. Każdy bug możemy przyporządkować do jednej z czterech kombinacji tej klasyfikacji.

  • Wysoka złożoność i wysoka dolegliwość.
  • Niska złożoność i wysoka dolegliwość.
  • Wysoka złożoność i niska dolegliwość.
  • Niska dolegliwość i niska złożoność.

Continue reading →

Osiąganie najwyższych tonów & Odnajdywanie świetnych programistów

To czy firma programistyczna osiągnie sukces na rynku zależy od warunków pracy.

Najlepsze warunki pracy,

przyciąga najlepszych programistów,

którzy piszą najlepszy kod,

który przynosi zysk.

Nawet bardzo liczna grupa przeciętnych programistów, niezależnie od czasu jaki poświęci na tworzenie kodu zawsze napisze oprogramowanie, które jest tylko przeciętne podczas gdy zaledwie kilku bardzo dobrych programistów w krótkim czasie jest wstanie napisać bardzo dobre oprogramowanie.

Continue reading →

Szybciej, wolniej, wolniej

Poniższy fragment książki jest brutalną prawdą, esencją strasznej zarazy panującej w firmach, która z zimną krwią wyniszcza wszystko, co jej stanie na drodze.

Systematyczne lekceważenie planowania i projektowania prowadzi do rozwoju w cyklu „szybciej, wolniej, wolniej”.

Wygląda to mniej więcej tak:

  1. Błyskawicznie dostarczasz wersję 1.0, pisząc cały kod na kolanie.
  2. Budujesz wersję 2.0, na bieżąco rozwiązując problemy stwarzane przez uciążliwy bałagan w kodzie.
  3. Wraz z kolejnymi wersjami rozwiązywanie problemów ze starym kodem „na bieżąco” sprawia, że bałaganu przybywa, a praca staje się coraz wolniejsza. Wyrzyscy stopniowo tracą wiarę w system, programistów i całą sytuację, w której się znaleźli.
  4. Gdzieś w okolicach wersji 4.0 zdajesz sobie sprawę, że nie wygrasz. Zaczynasz rozważać opcję przepisania systemu od podstaw.

„Refaktoryzacja do wzorców projektowych” Joshua Kerievsky

Continue reading →