[Android] Niech Activity nie implementuje widoku (film!)

Jedną z najpopularniejszych rekomendacji dla programistów Androida jest zasada, która w ogólności mówi: oddzielaj elementy widoku od logiki aplikacji, a implementowana jest najczęściej poprzez wzorce MVC, MVP czy MVVM.

Wśród argumentów stojących za tą rekomendacją, najmocniejsze są dwa:

  1. kiedy logika jest w klasie pozbawionej elementów widoku, łatwiej jest ją testować
  2. im więcej kodu wyciągniemy z klas typu *Activity czy *Fragment, tym mniejsza jest szansa, że złamiemy zasadę pojedynczej odpowiedzialności

Zgadzam się, oczywiście z każdym z nich. Mam jednak wrażenie, że ten drugi nie jest do końca rozumiany. Uważam, że duża część programistów, którzy stosują wspomniane dobre praktyki, nie stawia sobie pytania: czy rzeczywiście zrobiłem wszystko żeby nie złamać SRP?

Czytaj dalej

Sprawdzanie czy mamy konflikt w Gicie

Praca z Gitem jest bardzo przyjemna… aż do chwili kiedy pojawiają się konflikty.

Jest kilka zasad, które umożliwiają ich ograniczanie do minimum, między innymi:

  • dziel zadania na mniejsze
  • komituj często
  • stosuj narzędzia do statycznej analizy kodu

A w tym poście opiszę jeszcze jedno narzędzie, które pomoże nam ich liczbę zmniejszyć!

Czytaj dalej

goto wcale nie jest takie złe

Chyba każdy z nas na początku nauki programowania usłyszał „najważniejszą zasadę pisania dobrego kodu”: nigdy nie używaj instrukcji goto. Uczenie młodych programistów, że unikanie goto to najważniejsza rzecz podczas programowania niesie ze sobą jedną dość poważną konsekwencję.

Chodzi o powszechne używanie dużo gorszych rozwiązań.

Czytaj dalej

„Zwężenie odcinka drogi” jako antywzorzec

Przeglądając kody źródłowe różnych projektów, pisane przez różnych programistów, często trafiam na pewną konkretną grupę brzydkich zapachów. Mimo, że przybierają przeróżne formy, mają ze sobą tyle wspólnego, że moim zdaniem reprezentują jeden antywzorzec.

Mam dla niego całkiem fajną nazwę: zwężenie odcinka drogi.

Czytaj dalej

[MoodOfTheSong] 4. Serwer ciągłej integracji

Dzisiaj napiszę o kilku technikach, które są bardzo pomocne przy dużych projektach, w których pracuje wiele osób. Ich stosowanie w moim, małym, jednoosobowym projekcie może się wydawać wbijaniem gwoździa młotem pneumatycznym; wolę jednak je poznać, wdrożyć i dopracować trochę za wcześnie niż trochę za późno.

Mowa tutaj o narzędziach, które pozwolą mi mieć pewność, że kod w repozytorium jest zawsze pozbawiony błędów, poprawny stylistycznie, a wszystkie testy przechodzą.

Czytaj dalej

Co jest lepsze od klas narzędziowych

To, że są wszędzie jeszcze jest małe piwko. Prawdziwym problemem jest to że w powszechnej świadomości są zgodnym z naturą problemu rozwiązaniem. W tym wpisie postaram się Was przekonać dlaczego klasy narzędziowe są złe i powodują, że nasz kod jest oderwany od rzeczywistości, którą próbujemy modelować.

Czytaj dalej

Czy testy jednostkowe zajmują czas?

Chyba wszyscy zgadzamy się z tym, że dobrze pisać testy jednostkowe. Ale nie wszyscy piszemy – zwłaszcza jeśli nie musimy (czyli np. w hobbistycznych projektach). Powód jest prosty – wydaje nam się, że ich tworzenie zajmuje czas, który można poświęcić na rozwój kodu aplikacji.

A to nie jest prawdą. I w tym wpisie wytłumaczę dlaczego.

Czytaj dalej

Usuwanie listy – refaktoring w praktyce

Aplikacja pozwalała już na dodawanie nowych list zadań i wybór którą z nich wyświetlić. Była doskonała dla kogoś kto, gdy już coś stworzy, nigdy tego nie usuwa. Jednak ja, będąc zwykłym użytkownikiem i nie mając możliwości skasowania listy, skorzystałbym z możliwości skasowania aplikacji.

Usunięcie listy wydarzyć musi się na dwóch frontach:

  • na ekranie
  • w bazie danych

Dziś zajmiemy się frontem pierwszym. Pokażę Wam jak szybko i łatwo przerobiłem kod tak, aby był łatwiejszy w utrzymaniu i dalszym rozwoju aplikacji.

Czytaj dalej