Aplikacja to interfejs użytkownika

Oryginalny post: The User Interface Is The Application

Autor: Jeff Atwood

W artykule Niełatwo jest wypuścić produkt (ale ktoś to musi robić) Shawn Burk tłumaczy, dlaczego powinieneś opierać się pokusie wprowadzania zmian pod koniec projektu, niezależnie od tego, jak bardzo uzasadnione bądź racjonalne mogą wydawać Ci się ku temu powody. Nawet najmniejsza zmiana to rzeczywiste ryzyko wprowadzenia nowych błędów. Pierwsza osoba, która skomentowała ten artykuł, zażartowała:

W TeXu nie ma błędów... Być może jest to wyjątek, który potwierdza regułę :-)

Ian Ringrose błyskawicznie odpowiedział:

Ale czy ktokolwiek tego używa? Czy fakt, że z TeXa bardzo ciężko się korzysta nie jest bugiem samym w sobie?

Touché.

Yukihiro Matsumoto, twórca Ruby, ma jasny pogląd na ten temat:

Jeśli Twój system ma dobry interfejs a Ty dysponujesz zarówno czasem jak i środkami finansowymi, to praca nad tym systemem jest możliwa. Jeśli są w nim błędy albo jest on za wolny, możesz to poprawić. Jeśli jednak interfejs systemu jest kiepski, to praktycznie nie masz nic. Nie będzie miało znaczenia, że pod spodem jest to arcydzieło inżynierii oprogramowania. Zły interfejs sprawi, że z Twojego systemu nikt nie będzie korzystał. Interfejs systemu jest niezwykle ważny, ze względu na to, że jest tym, z czym mają do czynienia albo użytkownicy albo inne systemy.

Joel pisał na podobny temat w swoim artykule Sekret góry lodowej, ujawniony:

Dostałem tę nauczkę jako konsultant, gdy prezentowałem demo pewnego sporego projektu webowego dla zespołu wykonawczego naszego klienta. Projekt był ukończony prawie w 100%. Czekaliśmy jedynie na grafika, zeby dobrał czcionki i kolorystykę oraz żeby przygotował fajnie wyglądające, trójwymiarowe zakładki. W międzyczasie zastosowaliśmy najprostsze czcionki, kolorystyka była czarno-biała, mnóstwo miejsca na stronach było zmarnowanego i generalnie całość nie prezentowała się za dobrze, delikatnie mówiąc. Ale 100% funkcjonalności było zaimplementowane i pod spodem działy się całkiem niesamowite rzeczy.

Co się stało podczas demo? Całe spotkanie klienci spędzili na narzekaniu i krytykowaniu wyglądu aplikacji. Ich uwagi nawet nie dotyczyły interfejsu użytkownika jako takiego. Komentowali jedynie wygląd. "To po prostu nie wygląda fajnie." — skomentował ich kierownik projektu. Jedynie o tym byli w stanie myśleć. Nie potrafiliśmy skłonić ich do zastanowienia się nad samą funkcjonalnością. Oczywiście poprawienie graficznego designu zajęło raptem jeden dzień. Można było niemalże odnieść wrażenie, że nasi klienci myśleli, że zatrudnili malarzy.

Dokładnie tego samego doświadczyłem niedawno. Piszemy sobie cały ten fajny back-end i oczywiście w pewnym momencie potrzebowaliśmy zrobionego na szybko front-endu, żeby móc cokolwiek zaprezentować. Napisaliśmy więc stosunkowo prostą aplikację do celów demonstracyjnych. Wyszła całkiem nieźle, ale oczywiście nie mogła się równać z już istniejącymi, podobnymi aplikacjami konkurencji.

Zgadnij, jaką opinię na temat naszego projektu wyraził klient.

Nieważne jak dużo masz wypasionych diagramów architektury zrobionych w Visio; dla użytkownika to interfejs jest aplikacją. Zdaję sobie sprawę, że UI to ciężka sprawa, ale musisz zadbać o to, by interfejs sprawiał dobre wrażenie, w przeciwnym razie nikt nie będzie Cię brał na poważnie. Nadaj swojemu UI wysoki priorytet, na jaki zasługuje.

Data publikacji oryginału: sierpień 24, 2005

Inspekcje kodu: Po prostu je rób

Oryginalny post: Code Reviews: Just Do It

Autor: Jeff Atwood

W artykule The Soft Side of Peer Reviews Karl Wiegers zaczął od mocnego oświadczenia:

Wzajemne przeglądy -- czynność, podczas której osoby inne niż autor kawałka kodu przyglądają się mu pod kątem błędów oraz możliwości poprawy -- są jednym z bardziej potężnych, dostępnych narzędzi do podtrzymywania jakości kodu. Wzajemne przeglądy zawierają w sobie inspekcje, kontrole ogólne, wzajemne symulowanie logiki i inne podobne czynności. Po tym jak doświadczałem korzyści związanych ze wzajemnymi przeglądami przez niemal 15 lat, nigdy nie chciałbym pracować w zespole, który nie wykonuje tych czynności.

Po tym jak brałem udział w inspekcjach kodu przez jakiś czas tutaj w Vertigo, wierzę, iż wzajemne przeglądy są najlepszą rzeczą, która może ulepszyć Twój kod. Jeśli nie uskuteczniasz inspekcji kodu teraz, wraz z innym programistą, to umyka Ci wiele błędów w Twoim kodzie oraz okradasz siebie z pewnych kluczowych szans na profesjonalne programowanie. Jeśli o mnie chodzi, mój kod nie jest skończony, dopóki nie zostanie on przejrzany przez innego programistę.

Ale nie ufajcie moim słowom. McConnell dostarcza wiele dowodów na skuteczność inspekcji kodu w książce Code Complete:

.. samo testowanie oprogramowania ma ograniczoną efektywność -- średni wskaźnik znajdowania defektów, to tylko 25% dla testów jednostkowych, 35% dla testów funkcjonalnych i 45% dla testów integracyjnych. Dla porównania średnia efektywność inspekcji projektu i kodu, to 55% i 60%. Analiza przypadków dla inspekcji jest imponująca:

  • W firmie zajmującej się utrzymywaniem oprogramowania, 55% jednolinijkowych zmian było błędnych przed tym, jak wprowadzono inspekcje kodu. Po wprowadzeniu inspekcji jedynie 2% zmian posiadało błędy. Kiedy wszystkie zmiany zostały wzięte pod uwagę, 95% było poprawnych po pierwszym razie, kiedy inspekcje zostały wprowadzone. Przed wprowadzeniem inspekcji, poniżej 20% było poprawnych za pierwszym razem.
  • W grupie 11 aplikacji, które zostały napisane przez tę samą grupę ludzi, pierwsze 5 zostało stworzonych bez inspekcji. Przy pozostałych 6 były obecne inspekcje kodu. Po tym jak wszystkie aplikacje zostały wdrożone na produkcję, pierwsze 5 miało średnio 4.5 błędu na 100 linii kodu. Te 6, które poddawane były inspekcjom, miały średnią 0.82 błędu na 100 linii. Inspekcje ucięły ilość błędów o 80%.
  • Aetna Insurance Company dzięki inspekcjom znalazła 82% błędów w swoim programie i była w stanie zmniejszyć zasoby potrzebne do tworzenia aplikacji o 20%.
  • Projekt Orbit IBMa, który ma 500000 linii, używał 11 poziomów inspekcji. Został wcześnie dostarczony i miał tylko około 1% błędów, które normalnie by posiadał.
  • Badania przeprowadzone w AT&T wskazują, że ponad 200 ludzi odnotowało 14% wzrost produktywności i 90% spadek liczby defektów po wprowadzeniu inspekcji przez organizację.
  • Jet Propulsion Laboratories szacuje, iż co inspekcję oszczędza $25000 poprzez znalezienie i naprawienie defektów we wczesnej fazie.

Jedyną przeszkodą w robieniu inspekcji kodu jest znalezienie szanowanego programisty, który by to robił oraz czasu na jej wykonanie. Myślę, iż jeśli już spróbujesz, to szybko się przekonasz, że każda minuta spędzona na inspekcji kodu zwróci się dziesięciokrotnie.

Jeśli inspekcje kodu są nowością w Twojej firmie, gorąco polecam książkę Karla, Peer Reviews in Software: A Practical Guide. Jak również przykładowe rozdziały, które Karl umieścił na swojej stronie, mogą być dobrym podkładem.

Data publikacji oryginału: 21 stycznia, 2006

Dobrzy programiści potrafią ruszyć swoją dupę

Oryginalny post: Good Programmers Get Off Their Butts

Autor: Jeff Atwood

Szukałem tego cytatu i tak jak Wes pamiętam, że go czytałem, ale nie pamiętam, gdzie dokładnie to było:

To nasuwa kolejny komentarz do ostatnio przeczytanego wpisu na blogu, którego autora nie potrafię sobie przypomnieć. Dobrzy programiści potrafią ruszyć swoją dupę. Zazwyczaj jest tak, że programiści nie piszą żadnego kodu, dopóki nie rozwiążą pewnych problemów projektowych, a wtedy czas ucieka bez większych postępów w projekcie. Produktywni programiści napiszą jakiś kod nawet, jeśli projekt jest niejasny, ponieważ tworzenie oprogramowania jest procesem iteracyjnym.

Już nie pamiętam ile razy zasiadałem do projektowania po czym, podczas programowania porzucałem bądź radykalnie modyfikowałem projekt, ponieważ..

  • Zapomniałem o czymś bardzo ważnym
  • Znalazłem inne, łatwiejsze rozwiązanie
  • To co robiłem, nie miało sensu
  • Na nowo wynajdywałem koło, a powinienem był znaleźć gotowca w sieci
  • Hej, przecież nie muszę tego robić od razu!

W prawdziwym świecie istnieje ciasna pętla przyczynowo-skutkowa pomiędzy fazą implementacji a projektowania. Jeśli używasz Photoshopa jako narzędzia do projektowania, wszystko jest możliwe. Niestety, Visual Studio nie jest takie wyrozumiałe.

Nie proponuje tutaj metodologii programowania, które zamienia się w piekło. Podczas mojego doświadczenia zaobserwowałem, iż kodowanie bez planowania jest tak samo bezskuteczne jak kodowanie ze zbyt dużą ilością planowania. Tworzenie oprogramowania jest paskudnym problemem; nigdy nie powinieneś podejmować decyzji w sprawie planowania bez jakiegokolwiek prototypu w postaci kodu dla pewności, iż podejmujesz świadome decyzje. Jeśli zbyt dużo planujesz w oderwaniu od kodowania gwarantuję Ci, iż robisz coś, co będzie wyrzucone bądź zmienione nie do poznania.

Najbardziej destruktywnym symptomem nadmiernego planowania jest błędne pojęcie, iż bycie Architektem Oprogramowania(tm) oznacza rysowanie dużej ilości diagramów UML i przekazywanie ich grupie programistów w Bangalore. UML jest świetny, jeśli nie chcesz wykonać żadnej pracy; rysujesz jedynie obrazki przedstawiające to, jak by to wyglądało, jeśli praca byłaby faktycznie wykonana. To nie tylko granica lenistwa, to również przepis na katastrofę. Nie można na białej tablicy stworzyć architektury modelującej świat rzeczywisty. Musisz stworzyć prototyp w kodzie, aby zebrać informacje o wydajności oraz implikacje wynikające z projektu na podstawie Twoich decyzji. W innym razie tak naprawdę nie masz pojęcia, czy tworzysz coś, co ma sens -- bądź czy w ogóle jest wykonalne! Tak jak zaznaczył to Robert Glass w książce Facts and Fallacies of Software Engineering, że podczas projektowania oprogramowania praktyka jest obowiązkowa:

Projektowanie, będące daleko od bycia przewidywalnym, dającym się ustrukturyzować, proceduralnym procesem -- według ustaleń Curtisa i Solowaya (1987) -- jest czynnością pełną zamieszania, operającą się na metodzie prób i błędów. A pamiętaj, że te ustalenia są wynikiem obserwacji najlepszych projektantów podczas pracy. Można sobie wyobrazić mniej doświadczonych ludzi używających jeszcze bardziej zagmatwanego procesu. Najprawdopodobniej najgorsze podejście projektowe, a jednocześnie takie, które kusi wielu nowicjuszy, to "najpierw-rzeczy-łatwe". Pomimo iż łatwo jest rozpocząć projektowanie z tym podejściem, to często wiedzie ono do wczesnych rozwiązań, które nie integrują się z rozwiązaniem końcowym. W wyniku czego, wczesne rozwiązania często muszą być porzucone.

Na podstawie tego dobrze widać, iż faza projektowania jest złożona i iteracyjna. (Ta myśl jest wyraźna w książce Wiegersa [1996].) W zasadzie, jest to prawdopodobnie najbardziej zajmująca intelektualnie czynność w procesie tworzenia oprogramowania. Jak również łatwo zauważyć, początkowe rozwiązania projektowe całkiem często okazują się być złe. A co z rozwiązaniem optymalnym? Cóż, z pewnością początkowe rozwiązania rzadko kiedy bywają optymalne. Natomiast to słowo rodzi kolejne interesujące pytanie -- czy istnieje takie coś jak optymalne rozwiązanie projektowe?

Jako programiści -- a w szczególności jeśli rościmy sobie prawa do określania nas mianem "architektów" -- zawsze powinniśmy podejmować decyzje oparte na doświadczeniu i danych. Możesz to lubić bądź nie, ale to oznacza ruszenie swojego dupska i napisania jakiegoś kodu.

Data publikacji oryginału: 21 listopada, 2004

Programuj w języku dziedziny

Opublikowaliśmy kolejne tłumaczenie w serwisie 97rzeczy:
  • Programuj w języku dziedziny (autor: Dan North)
    "Używanie klucza, żeby szukać innego klucza, który przeprowadza sprawdzenie istnienia czegoś tam nie jest specjalnie oczywiste. W jaki sposób ktoś miałby intuicyjnie domyślić się, że kod który odpowiada za regułę biznesową uniknięcia konfliktu jest zaimplementowany?"
Related Posts with Thumbnails