Flaw of Software Design

Seria krótkich wykładów Maxa Kanata-Alexandera, dotycząca problemów jakie pojawiają się podczas tworzenia oprogramowania:

• Writing Code that isn't Needed
Zasada podobna do YAGNI (You aren't gonna need it), czyli nie tworzenie kodu, który nie jest nam potrzebny i usuwania kodu, który nie jest już wykorzystywany.
• Not Making the Code Easy to Change
Najczęściej ten problem, pojawia się przez zbyt wielką liczbę założeń w projekcie, co do tego jak nasz projekt będzie działał w przyszłości, lub przez pisanie kodu bez poświęcenie wystarczająco czasu na projektowanie. Jednym z częstych błędów jest np. przyjęcie założenia, że nasz kod, nie będzie wspierał wielu języków, albo nie wykorzysta frameworka do unit testów. Jeżeli tylko wiemy o konieczności w przyszłości dodania jakiejś zmiany, powinniśmy dodać bardzo minimalny interfejs, który to ułatwi (moim zdaniem troszkę, kłóci się to z pierwszą zasadą).

"Kod powinien być projektowany, na podstawie wiedzy, którą mamy obecnie, nie na podstawie tego co myślimy, że będzie działo się w przyszłości"
• Being Too Generic
Czyli over-engineering, coś co się przydarza często doświadczonym deweloperom. Próba tworzenia generycznych rozwiązań, które niekoniecznie są potrzebne już w tej chwili, gdy mniej generyczne rozwiązani są szybsze do implementacji i szybciej przynoszą wartość klientowi.

"Bądź tak generyczny, jak tego potrzebujesz w tej chwili"
• Incremental Development & Design
Za każdym razem, gdy chcesz dodać coś nowego do systemu, rezultat ma być taki jakby zostało to już na początku zaprojektowane do takiego działania. Wymaga to dużo refactoringu. Przystępując do pracy nad projektem najważniejszą kwestią jest to by tworzyć wszystko we właściwej kolejności, zacząć od najbardziej istotnych elementów systemu np. funkcja odtwarzania wideo, przed listą wyboru plików do odtworzenia.

Ściąga z wzorców projektowych

Kolejne moje poszukiwania, tym razem pod kątem wzorców projektowych, udało mi się znaleźć niestety tylko jeden fajny link.

• http://www.mcdonaldland.info/files/designpatterns/designpatternscard.pdf

Trochę o Unit Testach

Zbiorczy zestaw linków, traktujących o testach jednostkowych i trochę moich notatek.

http://www.youtube.com/watch?v=RlfLCWKxHJ0

Zastosowanie dependeny injection oraz prawo Demeter w testowaniu.

http://www.youtube.com/watch?v=wEhu57pih5w

Testy jednostkowy pozwalają nam wykryć błędy w działaniu małych komponentów. Dają przewagę nad testami systemowymi, pozwalając szybko zorientować się gdzie leży przyczyna błędu. Całościowe test, też mogą to wykazać, ale znacznie trudniej jest ustalić, gdzie leży usterka, albo co jest jej przyczyną.

Mieszanie mechanizmu tworzenie obiektów z business logic sprawia, że bardzo trudno napisać dobry test. Nie można tworzyć obiektów w izolacji. Jedyne co można tworzyć to cały łańcuch zależnych od siebie obiektów. Nie mamy wtedy już do czynienia z testami jednostkowymi (np. test silnika), tylko z testami systemowymi (test działania całego samochodu).

http://blog.stevensanderson.com/2009/08/24/writing-great-unit-tests-best-and-worst-practises/

Tutaj autor, przestawia TDD jako proces projektowania (i nie jest procesem testowania). TDD i testy jednostkowe pomagają dostarczyć komponenty oprogramowania, które indywidualnie zachowują się zgodnie z założeniami projektowymi. Jedynym odstępstwem, w którym testy jednostkowe naprawdę potrafią wykryć błędy jest proces refactoringu. Trochę inna wizja niż ta prezentowana na Google Talks.

Ciekawy pattern do nazywania testów np. ProductPurchaseAction_IfStockIsZero_RendersOutOfStockView()

• Subject
• Scenario
• Result

http://www.exubero.com/junit/antipatterns.html

Mowa o antywzorcach, jakie najczęściej pojawiają się podczas tworzenia testów jednostkowych. "Unit testing is the first of a long series of steps to verify that the code works correctly."

Clean code - ściągawka

Ściągawka (http://www.planetgeek.ch/wp-content/uploads/2013/06/Clean-Code-V2.1.pdf) podana dalej przez wujka Boba (Robert C. Martin) na Twitterze, przydatna jeżeli ktoś chce utrzymać swój kod "czystym".