Projektowanie

Prostota stanowi klucz

Ukończenie prostego projektu zawsze zabiera mniej czasu niż złożonego. Dlatego zawsze wykorzystaj najprostszy sposób, która będzie działał zgodnie z naszymi założeniami. Jeśli natrafisz coś skomplikowanego zamień to na prostszy odpowiednik. Zawsze szybciej i taniej jest pozbyć się złożonego kodu teraz, niż później. Zaoszczędzisz wiele czasu zmarnowanego na upraszczanie już wykorzystywanego kodu. Utrzymuj rzeczy tak proste, jak jest to możliwe, nie dodając zawczasu żadnej nowej funkcjonalności dopóki jawnie nie zostanie zaplanowane jej wprowadzenie. Tym niemniej uważaj, utrzymanie prostej struktury w rozbudowanych projektach nie musi być łatwe.

Wybór standardu nazewnictwa

Określcie system przenośni, aby zachować zgodność w nazywaniu klas i metod. To jak nazywasz swoje obiekty jest bardzo znaczące dla zrozumienia całego projektu systemu, a także wielokrotnego używania kodu. Jeśli możemy domyślić się jak coś zostałoby być nazwane, zaoszczędzisz dużo czasu na zgadywaniu. Wybierz odpowiedni system nazewnictwa dla twoich obiektów, do którego wszyscy będą mogli się odnosić bez potrzeby poznania dokładnej wiedzy na temat działania projektu.

Np. system rozliczeń firmy Chrysler został zbudowany w oparciu o elementy linii produkcyjnej. U Forda natomiast samochody są sprzedawane jako struktury złożone z komponentów. Jest także nazewnictwo znane jako "naiwna", bazujące na własnej domenie. Ale nie wybieraj tej metody, jeśli nie jest wystarczająco prosta.

Karty CRC

Użyj kart CRC (ang. Class, Responsibilities and Collaboration), opisujących poszczególne klasy, ich odpowiedzialność i relacje, by zaprojektować system jako zespół współpracujących jednostek. Największą wartością kart CRC jest pozwolenie ludziom na odrzucenie proceduralnego stylu tworzenia i docenienie w pełni możliwości technologii obiektowej. Karty CRC umożliwiają całemu zespołowi na współpracę podczas projektowania. Im więcej osób mogących pomóc zajmuje się projektowaniem systemu, tym więcej ciekawych pomysłów może zostać wprowadzonych w życie.

Do reprezentacji poszczególnych obiektów używamy oddzielnych kart CRC. Klasa obiektu może być napisana w górnej części karty, odpowiedzialność po lewej, a klasy, z którymi współpracuje po prawej stronie. Piszemy "może być napisane", gdyż niekiedy uczestnicy sesji CRC będą na tyle znali problematykę projektu, że będą potrzebowali tylko kilku kart z nazwą klasy i praktycznie żadna z nich nie będzie dokładnie wypełniona. Demonstrujemy krótki przykład jako część projektu ekspresu do kawy.

Podczas sesji CRC dokonujemy symulacji naszego systemu, omawiając, które obiekty przesyłają informacje do innych obiektów. Poprzez stopniowe przechodzenie dalej, analizując kolejne obiekty, łatwo odkrywamy słabości i potencjalne problemy danego projektu. Alternatywne rozwiązania możemy szybko zbadać przeprowadzając symulację na proponowanym modelu.

Jeśli znajdzie się zbyt wiele osób omawiających i przesuwających karty naraz po prostu ogranicz liczbę osób stojących i poruszających kartami do dwóch. Kiedy jedna osoba siada, inna może przejąć głos. Metoda ta sprawdza się, gdy sesja zaczyna wymykać się spod kontroli, co często zdarza się, gdy tłum ożywia się po rozwiązaniu trudnego problemu.

Jedną z większych wad systemu kart CRC jest brak opracowanego projektu na piśmie. Przeważnie możemy się bez niego obejść, ponieważ karty CRC sprawiają, że projekt jest przejrzysty. Jeśli niezbędne jest utrwalenie sesji należy wypełnić w całości po jednej karcie w każdej klasie zachowując je jako dokumentację.

Utwórz rozwiązanie impulsowe

Stwórz rozwiązanie impulsowe, aby znaleźć odpowiedzi na trudne problemy techniczne lub dotyczące samego projektu. Rozwiązanie impulsowe to bardzo prostu program, którego zadaniem jest wyszukiwanie potencjalnych rozwiązań danego problemu. Zbuduj system, który zajmuje się wyłącznie analizą problemu i pomija inne aspekty. Większość tego typu programów nie jest wystarczająco dobra, by używać ich przez dłuższy czas, tak więc spodziewaj się, że będziesz musiał się go pozbyć. Głównym założeniem jest zmniejszenie, na ile to możliwe ryzyka wystąpienia problemów typu technicznego, a także zwiększenie wiarygodności oceny opowieści użytkownika.

Kiedy trudności techniczne zagrażają rozwojowi systemu, niech dwoje developerów (programistów) zajmie się tym przez tydzień lub dwa i spróbuje zmniejszyć potencjalne ryzyko wystąpienia problemu.

Nie dodawaj funkcjonalności za wcześnie.

Niech system nie będzie zaśmiecony dodatkowymi rzeczami?, o których myślisz, że użyjesz je później. Tak naprawdę zaledwie 10% z nich zostanie kiedykolwiek użyte, a więc marnujesz 90% swojego czasu. Wszystkich nas kusi, aby dodać funkcjonalność raczej teraz (wcześniej) niż później, ponieważ wiemy dokładnie jak jej użyć. Poza tym to tak ulepszyłoby system... Wydaje się, że byłoby znacznie szybciej dodać ją właśnie teraz. Ale musimy ciągle sobie powtarzać, że tak naprawdę nie będzie nam ona potrzebna. Dodatkowa funkcjonalność jedynie spowolni naszą pracę i zmarnuje zasoby. Przymknij oko na przyszłe wymagania i dodatkową elastyczność. Skup się tylko na tym, co zaplanowane jest na dziś.

Bez skrupułów przebudowuj istniejące rozwiązania.

My programiści kurczowo trzymamy się naszych projektów, nawet wtedy, gdy stają się one trudne do obsługi i nieporęczne. Ciągle używamy kodów, z których tak naprawdę nie da się dłużej korzystać bezproblemowo i które wymagają nieustannego ulepszania. W naszym przekonaniu jednak, nadal funkcjonują one w miarę dobrze, a my boimy się je zmieniać. Ale pomyślmy czy takie postępowanie jest efektywne. Extreme Programming (XP) próbuje nas przekonać, że nie. Kiedy usuwamy nadmiarowość, eliminujemy nieużywaną funkcjonalność i odmładzamy przestarzałe projekty, to właśnie wtedy przebudowujemy system. Refaktoring stosowany w trakcie całego procesu projektowania to oszczędność czasu i poprawa jakości.

Przebudowywuj istniejące rozwiązania bez zbędnych skrupułów. W ten sposób projekt pozostanie prosty i przejrzysty, a ty unikniesz bałaganu i zawiłości. Niech kod będzie jasny i zwięzły - tak, by można go było bez problemu zrozumieć, czy też w razie potrzeby zmieniać i rozszerzać. Upewnij się, że wszystko wyrażone jest tylko raz. W rezultacie stworzenie systemu zajmuje mniej czasu a on sam jest doskonale dopieszczony.

Aby przebudować system potrzebna jest pewna dawka Zen. Na początku jest to trudne, ponieważ musisz odpuścić sobie projekt, który sobie wyobraziłeś i być w stanie zaakceptować wersję, jaką niespodziewanie odkryłeś po refaktoringu. Należy sobie zdać sprawę, że projekt, który sobie wymarzyłeś, był świetny, ale spełniał jedynie funkcję drogowskazu podczas pracy. Teraz jest już przestarzały.

Spójrz na przykład. Gąsienica jest idealnie przystosowana do zjadania ogromnych ilości liści, ale w tej postaci nie może znaleźć partnera. Aby osiągnąć ten cel, musi przeobrazić się w motyla, który będzie przystosowany do eksploracji nieba w przeszukiwaniu "drugiej połowy". Musisz uwolnić się od swoich dotychczasowych wyobrażeń o tym , jaki system ma być a jaki nie. Spróbuj zobaczyć ten nowy, wyłaniający się przed tobą projekt.