Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00189 005657 12774629 na godz. na dobę w sumie
Pragmatyczny programista. Od czeladnika do mistrza - ebook/pdf
Pragmatyczny programista. Od czeladnika do mistrza - ebook/pdf
Autor: , Liczba stron: 328
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-283-3462-5 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> inne - programowanie
Porównaj ceny (książka, ebook (-30%), audiobook).
Od ambitnego do najlepszego - czyli jak stać się programistą wydajnym, dociekliwym i gotowym do wszelkich zawodowych wyzwań! Twórcy rozmaitych narzędzi programistycznych nieustannie próbują nas przekonać o niewiarygodnych możliwościach swoich produktów, a specjaliści od metodyk obiecują, że to właśnie ich techniki zagwarantują nam największą wydajność. Każdy oczywiście twierdzi, że jego język programowania jest najlepszy.
Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Tytuł oryginału: The Pragmatic Programmer. From Journeyman to Master Tłumaczenie: Mikołaj Szczepaniak Projekt okładki: Jan Paluch ISBN: 978-83-283-3130-3 Authorized translation from the English language edition, entitled: The Pragmatic Programmer: From Journeyman to Master, First Edition, ISBN 020161622X by David Thomas and Andrew Hunt, published by Pearson Education, Inc, publishing as Addison-Wesley, Copyright © 2000 by Addison-Wesley. Polish language edition published by Helion SA Copyright © 2011, 2017 Lyrics from the song „The Boxer” on page 174 are Copyright © 1968 Paul Simon. Used by permission of the Publisher: Paul Simon Music. Lyrics from the song „Alice’s Restaurant” on page 235 are by Arlo Guthrie © 1966, 1967 (renewed) by APPLESEED MUSIC INC. All rights reserved. Used by permission. All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education Inc. Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji. Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli. Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialnościani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce. Materiały graficzne na okładce zostały wykorzystane za zgodą Shutterstock Images LLC. Wydawnictwo HELION ul. Kościuszki 1c, 44-100 GLIWICE tel. 32 231 22 19, 32 230 98 63 e-mail: helion@helion.pl WWW: http://helion.pl (księgarnia internetowa, katalog książek) Drogi Czytelniku! Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie/pragpv Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję. Printed in Poland. • Kup książkę • Poleć książkę • Oceń książkę • Księgarnia internetowa • Lubię to! » Nasza społeczność Spis tre(cid:258)ci 2 POSTAWA PRAGMATYCZNA 3 PODSTAWOWE NARZ(cid:268)DZIA S(cid:226)OWO WST(cid:268)PNE PRZEDMOWA 1 FILOZOFIA PRAGMATYCZNA 9 13 21 1. Kot zjad(cid:227) mój kod (cid:302)ród(cid:227)owy ............................................................ 22 2. Entropia oprogramowania ............................................................. 24 3. Zupa z kamieni i gotowane (cid:304)aby .................................................... 27 4. Odpowiednio dobre oprogramowanie ............................................. 29 5. Portfolio wiedzy ............................................................................. 32 6. Komunikuj si(cid:269)! .............................................................................. 38 45 7. Przekle(cid:281)stwo powielania ................................................................ 46 8. Ortogonalno(cid:292)(cid:254) ............................................................................... 53 9. Odwracalno(cid:292)(cid:254) ............................................................................... 63 10. Pociski smugowe ........................................................................... 67 11. Prototypy i karteczki samoprzylepne .............................................. 72 12. J(cid:269)zyki dziedzinowe ........................................................................ 76 13. Szacowanie ................................................................................... 83 89 14. Pot(cid:269)ga zwyk(cid:227)ego tekstu .................................................................. 91 15. Pow(cid:227)oki ......................................................................................... 95 16. Efektywna edycja ........................................................................ 100 17. Kontrola kodu (cid:302)ród(cid:227)owego ........................................................... 104 18. Diagnozowanie ............................................................................ 107 19. Operowanie na tek(cid:292)cie ................................................................ 116 20. Generatory kodu ......................................................................... 120 125 21. Projektowanie kontraktowe .......................................................... 126 22. Martwe programy nie k(cid:227)ami(cid:264) ....................................................... 138 23. Programowanie asertywne ........................................................... 140 24. Kiedy u(cid:304)ywa(cid:254) wyj(cid:264)tków ............................................................... 143 25. Jak zrównowa(cid:304)y(cid:254) zasoby ............................................................. 147 4 PRAGMATYCZNA PARANOJA Poleć książkęKup książkę 8 (cid:88) Spis tre(cid:292)ci 5 ZEGNIJ LUB Z(cid:226)AM 6 KIEDY KODUJEMY… 7 PRZED PROJEKTEM 155 26. Izolacja i prawo Demeter ............................................................. 156 27. Metaprogramowanie .................................................................... 162 28. Zwi(cid:264)zki czasowe .......................................................................... 167 29. To tylko widok ............................................................................. 174 30. Tablice ........................................................................................ 181 187 31. Programowanie przez koincydencj(cid:269) .............................................. 188 32. Szybko(cid:292)(cid:254) algorytmu .................................................................... 193 33. Refaktoryzacja ............................................................................. 200 34. Kod (cid:227)atwy do testowania .............................................................. 205 35. Z(cid:227)e kreatory ................................................................................. 213 217 36. Kopalnia wymaga(cid:281) ...................................................................... 218 37. Rozwi(cid:264)zywanie niemo(cid:304)liwych do rozwi(cid:264)zania (cid:227)amig(cid:227)ówek ............. 227 38. Nie, dopóki nie jeste(cid:292) gotowy ....................................................... 230 39. Pu(cid:227)apka specyfikacji .................................................................... 232 40. Okr(cid:269)gi i strza(cid:227)ki ........................................................................... 235 239 41. Pragmatyczne zespo(cid:227)y .................................................................. 240 42. Wszechobecna automatyzacja ...................................................... 246 43. Bezlitosne testy ........................................................................... 252 44. Pisanie przede wszystkim ............................................................ 262 45. Wielkie oczekiwania ..................................................................... 269 46. Duma i uprzedzenie .....................................................................272 275 Profesjonalne spo(cid:227)eczno(cid:292)ci ................................................................ 276 Budowa biblioteki ............................................................................. 276 Zasoby internetowe ........................................................................... 279 Bibliografia ....................................................................................... 288 293 317 B ODPOWIEDZI DO (cid:253)WICZE(cid:280) SKOROWIDZ 8 PRAGMATYCZNE PROJEKTY A ZASOBY Poleć książkęKup książkę Rozdzia(cid:239) 7. Przed projektem Czy kiedykolwiek czu(cid:227)e(cid:292), (cid:304)e projekt jest nie do zrealizowania, zanim jeszcze rozpocz(cid:269)(cid:227)a si(cid:269) jego realizacja? Taka sytuacja mo(cid:304)e mie(cid:254) miejsce, je(cid:292)li prac nad projektem nie poprzedzimy ustaleniem pewnych regu(cid:227). W przeciwnym razie równie dobrze mo(cid:304)na od razu odmówi(cid:254) realizacji projektu i oszcz(cid:269)dzi(cid:254) pieni(cid:264)dze jego sponsora. Na samym pocz(cid:264)tku projektu musimy okre(cid:292)li(cid:254) wymagania. Samo ws(cid:227)uchiwanie si(cid:269) w g(cid:227)os u(cid:304)ytkowników nie wystarczy — wi(cid:269)cej informacji na ten temat mo(cid:304)na znale(cid:302)(cid:254) w podrozdziale „Kopalnia wymaga(cid:281)”. Konwencjonaln(cid:264) wiedz(cid:264) i sposobami zarz(cid:264)dzania ograniczeniami zajmiemy si(cid:269) w podrozdziale „Rozwi(cid:264)zywanie niemo(cid:304)liwych do rozwi(cid:264)zania (cid:227)amig(cid:227)ówek”. W zale(cid:304)no(cid:292)ci od tego, czy pracujemy nad wymaganiami, analiz(cid:264), kodowaniem, czy testami, mo(cid:304)emy spodziewa(cid:254) si(cid:269) ró(cid:304)nych problemów. W wi(cid:269)kszo(cid:292)ci przypad- ków wspomniane problemy nie s(cid:264) takie trudne, na jakie pocz(cid:264)tkowo wygl(cid:264)daj(cid:264). Nawet po rozwi(cid:264)zaniu tych problemów wci(cid:264)(cid:304) mo(cid:304)emy nie mie(cid:254) pewno(cid:292)ci, czy projekt rzeczywi(cid:292)cie ma szanse powodzenia. Czy jest to tylko jaki(cid:292) niepokoj(cid:264)cy nawyk, odruch, czy co(cid:292) wi(cid:269)cej? W podrozdziale „Nie, dopóki nie jeste(cid:292) gotowy” mo(cid:304)na znale(cid:302)(cid:254) sytuacje, kiedy nale(cid:304)y zachowa(cid:254) zdrowy rozs(cid:264)dek i powa(cid:304)nie traktowa(cid:254) te ostrzegaj(cid:264)ce g(cid:227)osy w naszych g(cid:227)owach. Zbyt szybkie rozpocz(cid:269)cie projektu to jeden problem, ale zbyt d(cid:227)ugie oczekiwanie bywa jeszcze bardziej niebezpieczne. W podrozdziale „Pu(cid:227)apka specyfikacji” omówimy zalety specyfikacji na konkretnym przyk(cid:227)adzie. I wreszcie, w podrozdziale „Okr(cid:269)gi i strza(cid:227)ki” przeanalizujemy kilka typowych pu(cid:227)apek czyhaj(cid:264)cych na programistów w ramach formalnych procesów i meto- dyk wytwarzania. (cid:303)adna metoda nie zast(cid:264)pi my(cid:292)lenia, cho(cid:254)by by(cid:227)(cid:264) najlepiej zaplanowana i obejmowa(cid:227)a wszystkie znane „najlepsze praktyki”. Poleć książkęKup książkę 218 (cid:88) Rozdzia(cid:227) 7. Przed projektem Je(cid:292)li uda si(cid:269) wyeliminowa(cid:254) te krytyczne problemy przed przyst(cid:264)pieniem do w(cid:227)a- (cid:292)ciwego projektu, b(cid:269)dziemy mogli du(cid:304)o skuteczniej unika(cid:254) parali(cid:304)u analitycz- nego i sprawnie rozpocz(cid:264)(cid:254) prace nad projektem. 36 Kopalnia wymaga(cid:241) Doskona(cid:227)o(cid:292)(cid:254) osi(cid:264)ga si(cid:269) nie wtedy, kiedy nie mo(cid:304)na ju(cid:304) nic doda(cid:254), lecz gdy ju(cid:304) niczego nie mo(cid:304)na uj(cid:264)(cid:254)… Antoine de St. Exupéry, Ziemia, planeta ludzi, 1939 W wielu ksi(cid:264)(cid:304)kach i podr(cid:269)cznikach zbieranie wymaga(cid:281) jest prezentowane jako wczesna faza projektu. Samo s(cid:227)owo „zbieranie” sugeruje istnienie jakiej(cid:292) grupy beztroskich analityków, którzy (cid:304)ywi(cid:264) si(cid:269) le(cid:304)(cid:264)cymi wokó(cid:227) orzeszkami wiedzy przy pobrzmiewaj(cid:264)cych cicho d(cid:302)wi(cid:269)kach symfonii Pastoralnej. „Zbieranie” wskazuje na to, (cid:304)e wymagania ju(cid:304) istniej(cid:264), a nasza rola sprowadza si(cid:269) tylko do ich odna- lezienia, umieszczenia w koszyku i radosnego pod(cid:264)(cid:304)ania naprzód. Rzeczywisto(cid:292)(cid:254) jest nieco inna. Wymagania rzadko s(cid:264) dost(cid:269)pne od r(cid:269)ki. Zwykle s(cid:264) raczej dobrze ukryte pod warstwami za(cid:227)o(cid:304)e(cid:281), nieporozumie(cid:281) i decyzji poli- tycznych. WSKAZÓWKA NR 51 Nie należy zbierać wymagań — należy je wydobywać z ukrycia. Poszukiwanie wymaga(cid:241) Jak rozpozna(cid:254) prawdziwe wymagania podczas przekopywania si(cid:269) przez ota- czaj(cid:264)cy je mu(cid:227)? Odpowied(cid:302) jest jednocze(cid:292)nie prosta i skomplikowana. Prosta odpowied(cid:302) mówi, (cid:304)e wymaganie to stwierdzenie dotycz(cid:264)ce celu, który musi by(cid:254) osi(cid:264)gni(cid:269)ty. Dobre wymagania mog(cid:264) obejmowa(cid:254) nast(cid:269)puj(cid:264)ce elementy: (cid:122) Rekord pracownika mo(cid:304)e by(cid:254) przegl(cid:264)dany tylko przez wyznaczon(cid:264) grup(cid:269) osób. (cid:122) Temperatura g(cid:227)owicy cylindra nie mo(cid:304)e przekracza(cid:254) warto(cid:292)ci krytycznej, której poziom zale(cid:304)y od rodzaju silnika. (cid:122) Edytor b(cid:269)dzie wyró(cid:304)nia(cid:227) s(cid:227)owa kluczowe zale(cid:304)nie od typu edytowanego pliku. Okazuje si(cid:269) jednak, (cid:304)e bardzo niewiele wymaga(cid:281) jest formu(cid:227)owanych w tak ja- snych s(cid:227)owach, co znacznie komplikuje proces analizy wymaga(cid:281). Poleć książkęKup książkę Kopalnia wymaga(cid:281) (cid:87) 219 Pierwsze zdanie z powy(cid:304)szej listy równie dobrze u(cid:304)ytkownicy mogliby wyrazi(cid:254) s(cid:227)owami: „Tylko prze(cid:227)o(cid:304)eni pracowników i pracownicy dzia(cid:227)u personalnego mog(cid:264) przegl(cid:264)da(cid:254) rekordy pracowników”. Czy takie stwierdzenie rzeczywi(cid:292)cie jest wy- maganiem? By(cid:254) mo(cid:304)e dzisiaj takie odczytanie tego zdania jest mo(cid:304)liwe, ale za- warto w nim zdecydowanie zbyt du(cid:304)o elementów zale(cid:304)nych od polityki. Decyzje polityczne stale podlegaj(cid:264) zmianom i jako takie nie powinny by(cid:254) trwale wpisy- wane w nasze wymagania. Zach(cid:269)camy do dokumentowania tych decyzji po- litycznych poza wymaganiami i do ewentualnego wi(cid:264)zania obu dokumentów za pomoc(cid:264) hiper(cid:227)(cid:264)czy. Wymaganie powinno by(cid:254) ogólnym stwierdzeniem i przeka- zywa(cid:254) programistom informacje polityczne w formie przyk(cid:227)adu scenariusza, który musi by(cid:254) realizowany przez przysz(cid:227)(cid:264) implementacj(cid:269). Decyzje polityczne mo(cid:304)na te(cid:304) wyra(cid:304)a(cid:254) w formie metadanych steruj(cid:264)cych zachowaniem gotowej aplikacji. To z pozoru nieistotne rozró(cid:304)nienie ma zasadniczy wp(cid:227)yw na sytuacj(cid:269) programi- stów zaanga(cid:304)owanych w projekt. Je(cid:292)li wymaganie jest wyra(cid:304)one w ten sposób: „Tylko personel mo(cid:304)e przegl(cid:264)da(cid:254) rekord pracownika”, programista mo(cid:304)e by(cid:254) zmuszony do ka(cid:304)dorazowego kodowania stosownego testu, kiedy aplikacja uzy- skuje dost(cid:269)p do odpowiednich plików. Je(cid:292)li jednak to samo wyra(cid:304)enie zostanie wyra(cid:304)one s(cid:227)owami: „Tylko uprawnieni u(cid:304)ytkownicy maj(cid:264) dost(cid:269)p do rekordu pra- cownika”, programista najprawdopodobniej zaprojektuje i zaimplementuje jaki(cid:292) system kontroli dost(cid:269)pu. W razie zmiany polityki (co na pewno kiedy(cid:292) nast(cid:264)pi) aktualizacji b(cid:269)d(cid:264) wymaga(cid:227)y tylko metadane u(cid:304)ywane przez ten system. W prak- tyce gromadzenie wymaga(cid:281) w ten sposób naturalnie prowadzi do zaprojektowa- nia systemu dzia(cid:227)aj(cid:264)cego w oparciu o metadane. Podzia(cid:227) na wymagania, polityk(cid:269) i implementacj(cid:269) bywa bardzo nieczytelny w przy- padku rozwa(cid:304)a(cid:281) po(cid:292)wi(cid:269)conych interfejsom u(cid:304)ytkownika. „System musi umo(cid:304)- liwia(cid:254) u(cid:304)ytkownikowi wybór po(cid:304)yczki terminowej” — tak mo(cid:304)e brzmie(cid:254) jasne wymaganie. „Potrzebujemy listy wyboru z mo(cid:304)liwo(cid:292)ci(cid:264) wskazania po(cid:304)yczki terminowej” — to mo(cid:304)e, ale nie musi by(cid:254) wymaganie. Je(cid:292)li u(cid:304)ytkownicy ko- niecznie musz(cid:264) dysponowa(cid:254) list(cid:264) wyboru, mamy do czynienia z wymaganiem. Je(cid:292)li jednak chodzi tylko o mo(cid:304)liwo(cid:292)(cid:254) wyboru, a kontrolka listy wyboru jest tylko przyk(cid:227)adem, sytuacja nie jest ju(cid:304) taka oczywista. W ramce w dalszej cz(cid:269)(cid:292)ci tego podrozdzia(cid:227)u zostanie omówiony projekt, który zako(cid:281)czy(cid:227) si(cid:269) fiaskiem tylko dlatego, (cid:304)e ignorowano wymagania dotycz(cid:264)ce interfejsu u(cid:304)ytkownika. Bardzo wa(cid:304)ne jest odkrycie powodów, dla których u(cid:304)ytkownicy wykonuj(cid:264) okre- (cid:292)lone czynno(cid:292)ci, nie tylko sposobu ich wykonywania. W(cid:227)a(cid:292)ciwym celem two- rzenia oprogramowania jest przecie(cid:304) rozwi(cid:264)zywanie problemów biznesowych, nie bezrefleksyjna realizacja wymaga(cid:281). Dokumentowanie powodów uzasadnia- j(cid:264)cych poszczególne wymagania jest dla zespo(cid:227)u projektowego bezcennym (cid:302)ró- d(cid:227)em informacji podczas podejmowania codziennych decyzji dotycz(cid:264)cych samej implementacji. Istnieje pewna prosta technika bli(cid:304)szego poznawania wymaga(cid:281) u(cid:304)ytkowni- ków, która o dziwo nie cieszy si(cid:269) zbyt du(cid:304)(cid:264) popularno(cid:292)ci(cid:264) — wystarczy na chwil(cid:269) zosta(cid:254) u(cid:304)ytkownikiem. Piszemy system dla pracowników dzia(cid:227)u wsparcia technicznego? Warto po(cid:292)wi(cid:269)ci(cid:254) kilka dni na odbieranie telefonów od klientów Poleć książkęKup książkę 220 (cid:88) Rozdzia(cid:227) 7. Przed projektem (w towarzystwie do(cid:292)wiadczonego pracownika odpowiedniego dzia(cid:227)u). Otrzy- mali(cid:292)my zadanie automatyzacji systemu kontroli zasobów magazynowych? Mo- (cid:304)e warto sp(cid:269)dzi(cid:254) tydzie(cid:281) w magazynie1. Oprócz mo(cid:304)liwo(cid:292)ci zyskania g(cid:227)(cid:269)bszej wiedzy o przysz(cid:227)ych sposobach u(cid:304)ywania naszego systemu ze zdziwieniem od- kryjemy, jak pytanie: „Czy mog(cid:269) usi(cid:264)(cid:292)(cid:254) obok i przez tydzie(cid:281) przypatrywa(cid:254) si(cid:269) twojej pracy?” mo(cid:304)e pomóc w budowaniu zaufania i nawi(cid:264)zywaniu komunikacji z przysz(cid:227)ymi u(cid:304)ytkownikami. Musimy tylko pami(cid:269)ta(cid:254), aby nigdy nie przeszka- dza(cid:254) przysz(cid:227)ym u(cid:304)ytkownikom! WSKAZÓWKA NR 52 Aby myśleć jak użytkownik, należy z nim popracować. Proces gromadzenia i poznawania wymaga(cid:281) to tak(cid:304)e czas na nawi(cid:264)zywanie kontaktów z przysz(cid:227)ymi u(cid:304)ytkownikami, próby zrozumienia ich oczekiwa(cid:281) i na- dziei wi(cid:264)zanych z budowanym przez nas systemem. Wi(cid:269)cej informacji na ten temat mo(cid:304)na znale(cid:302)(cid:254) w podrozdziale „Wielkie oczekiwania” w rozdziale 8. Dokumentowanie wymaga(cid:241) Za(cid:227)ó(cid:304)my, (cid:304)e usiedli(cid:292)my ju(cid:304) przy jednym stole z u(cid:304)ytkownikami i próbujemy wyci(cid:264)gn(cid:264)(cid:254) od nich jakie(cid:292) ogólne wymagania. Wspólnie wypracowujemy kilka prawdopodobnych scenariuszy, które do(cid:292)(cid:254) dobrze opisuj(cid:264) funkcje przysz(cid:227)ej aplikacji. Jako profesjonali(cid:292)ci chcemy zapisa(cid:254) te wnioski i opublikowa(cid:254) gotowy dokument, tak aby ka(cid:304)dy (programi(cid:292)ci, u(cid:304)ytkownicy ko(cid:281)cowi i sponsorzy pro- jektu) móg(cid:227) go u(cid:304)ywa(cid:254) jako podstawy do dalszych dyskusji. Grupa odbiorców jest do(cid:292)(cid:254) szeroka. Ivar Jacobson [Jac94] zaproponowa(cid:227) model, w którym do gromadzenia wyma- ga(cid:281) wykorzystuje si(cid:269) przypadki u(cid:304)ycia. W ten sposób mo(cid:304)na opisywa(cid:254) kon- kretne scenariusze pracy z systemem — nie przez pryzmat interfejsu u(cid:304)ytkow- nika, tylko w sposób bardziej abstrakcyjny. W pracy Jacobsona zabrak(cid:227)o niestety szczegó(cid:227)ów, st(cid:264)d tak wiele wspó(cid:227)czesnych, zupe(cid:227)nie odmiennych koncepcji do- tycz(cid:264)cych kszta(cid:227)tu samych przypadków u(cid:304)ycia. Czy przypadki u(cid:304)ycia powinny mie(cid:254) formalny, czy nieformalny charakter; czy powinny mie(cid:254) posta(cid:254) opisowego tekstu, czy raczej dokumentu z precyzyjnie okre(cid:292)lon(cid:264) struktur(cid:264) (na przyk(cid:227)ad zbli(cid:304)on(cid:264) do formularza)? Jaki poziom szczegó(cid:227)owo(cid:292)ci b(cid:269)dzie w(cid:227)a(cid:292)ciwy (zwa(cid:304)ywszy na szerok(cid:264) grup(cid:269) odbiorców)? 1 Czy tydzie(cid:281) to zbyt d(cid:227)ugo? Z pewno(cid:292)ci(cid:264) nie, szczególnie je(cid:292)li w tym czasie mamy ob- serwowa(cid:254) procesy, w których kierownictwo i szeregowi pracownicy dzia(cid:227)aj(cid:264) w zupe(cid:227)- nie innych (cid:292)wiatach. W takim przypadku kierownictwo przedstawi nam jedn(cid:264) wizj(cid:269) funkcjonowania przedsi(cid:269)biorstwa, ale kiedy zejdziemy pi(cid:269)tro ni(cid:304)ej, odkryjemy zupe(cid:227)- nie inn(cid:264) rzeczywisto(cid:292)(cid:254), której zrozumienie z natury rzeczy wymaga czasu. Poleć książkęKup książkę Kopalnia wymaga(cid:281) (cid:87) 221 Czasem to interfejs jest właściwym systemem W artykule opublikowanym w magazynie „Wired” (styczeń 1999, strona 176.) produ- cent i muzyk Brian Eno opisał niewiarygodny przykład technologii — nowoczesną konsoletę mikserską. Taka konsoleta pozwala na dosłownie wszystko, co tylko można zrobić z dźwiękiem. Mimo to, zamiast umożliwiać muzykom tworzenie lepszych utworów oraz szybciej i taniej nagrywać kolejne dzieła, konsoleta staje na drodze procesu twórczego i mocno go zakłóca. Aby lepiej zrozumieć, dlaczego tak się dzieje, warto przyjrzeć się pracy inżynierów dźwięku. Okazuje się, że ustawiają parametry dźwięku intuicyjnie. Przez lata wypraco- wują swoistą pętlę zmysłów łączącą ich uszy i palce — na tej podstawie ustawiają suwaki wyciszania, obracają gałki itp. Co ciekawe, interfejs nowego miksera w żaden sposób nie wykorzystuje tych zdolności i przyzwyczajeń. Przeciwnie — zmusza użytkowników do wydawania poleceń za pomocą klawiatury i myszy. Zestaw funkcji oferowany przez nowy mikser był wystarczająco bogaty, jednak sposób ich opakowa- nia odbiegał od standardów i był wręcz egzotyczny. Funkcje potrzebne inżynierom dźwięku zostały ukryte za niezrozumiałymi nazwami lub są dostępne dopiero po użyciu nieintuicyjnych kombinacji podstawowych elementów. Podstawowym wymaganiem stawianym przed nowym środowiskiem jest efektywne wykorzystanie istniejących umiejętności użytkownika. Bezmyślne powielanie tego, co już istnieje, nie gwarantuje co prawda postępu, jednak musimy znaleźć sposób płynnego przejścia do przyszłości. Na przykład inżynierowie dźwięku najprawdopodobniej woleliby otrzymać interfejs z ekranem dotykowym, aby nadal mieć pod ręką namacalne kontrolki przynajmniej zbliżone do tych oferowanych przez tradycyjne konsolety mikserskie, a jednocześnie zyskać szersze możliwości zapewniane przez oprogramowanie (większe niż w przy- padku fizycznych gałek i przełączników). Warunkiem sukcesu jest zapewnienie płynnego, komfortowego przejścia pomiędzy znanymi rozwiązaniami a nowymi mechanizmami. Przytoczony przykład ilustruje też naszą tezę, zgodnie z którą najlepsze narzędzia muszą dostosowywać się do rąk rzemieślnika, który ich używa. W tym przypadku to narzędzia budowane przez nas dla innych muszą dostosowywać się do ich potrzeb i możliwości. Jednym ze sposobów odczytywania przypadków u(cid:304)ycia jest zwracanie szcze- gólnej uwagi na opisywane cele. Alistair Cockburn opracowa(cid:227) artyku(cid:227) opisuj(cid:264)cy ten model i zaproponowa(cid:227) szablony, które mo(cid:304)na wykorzysta(cid:254) (w oryginalnej lub zmienionej formie) jako punkt wyj(cid:292)cia ([Coc97a] oraz w internecie pod adresem [URL 46]). Na rysunku 7.1 pokazano uproszczony przyk(cid:227)ad takiego szablonu. Na rysunku 7.2 przedstawiono przyk(cid:227)adowy przypadek u(cid:304)ycia. Stosowanie formalnego szablonu w roli przypomnienia daje nam pewno(cid:292)(cid:254), (cid:304)e nasze przypadki u(cid:304)ycia zawsze b(cid:269)d(cid:264) obejmowa(cid:227)y wszystkie niezb(cid:269)dne informa- cje: parametry wydajno(cid:292)ci, informacje o innych zaanga(cid:304)owanych stronach, priorytet, cz(cid:269)stotliwo(cid:292)(cid:254) oraz rozmaite b(cid:227)(cid:269)dy i oczekiwane problemy, które mog(cid:264) pojawi(cid:254) si(cid:269) w przysz(cid:227)o(cid:292)ci (tzw. wymagania niefunkcjonalne). Przypadki u(cid:304)ycia Poleć książkęKup książkę 222 (cid:88) Rozdzia(cid:227) 7. Przed projektem Rysunek 7.1. Szablon przypadku użycia autorstwa Cockburna w tej formie stanowi(cid:264) te(cid:304) doskona(cid:227)e miejsce dla komentarzy u(cid:304)ytkowników, jak: „Nie, w razie wyst(cid:264)pienia warunku X musimy raczej zrobi(cid:254) Y”. Szablon pe(cid:227)ni funkcj(cid:269) gotowej agendy spotka(cid:281) z przysz(cid:227)ymi u(cid:304)ytkownikami naszych produktów. Proponowana organizacja umo(cid:304)liwia (cid:227)atwe porz(cid:264)dkowanie przypadków u(cid:304)ycia w ramach struktur hierarchicznych, gdzie bardziej szczegó(cid:227)owe przypadki u(cid:304)ycia s(cid:264) zagnie(cid:304)d(cid:304)ane w ramach przypadków wy(cid:304)szego poziomu. Na przyk(cid:227)ad p(cid:227)atno- (cid:292)ci kart(cid:264) debetow(cid:264) i kart(cid:264) kredytow(cid:264) to wyspecjalizowane formy transakcji kart(cid:264) p(cid:227)atnicz(cid:264). Diagramy przypadków u(cid:285)ycia Przep(cid:227)yw pracy mo(cid:304)na wyra(cid:304)a(cid:254) na diagramach czynno(cid:292)ci UML, za(cid:292) diagramy klas na poziomie poj(cid:269)ciowym mog(cid:264) by(cid:254) z powodzeniem wykorzystywane do mo- delowania interesuj(cid:264)cych nas procesów biznesowych. Prawdziwe przypadki u(cid:304)y- cia maj(cid:264) jednak posta(cid:254) tekstowych opisów z okre(cid:292)lon(cid:264) hierarchi(cid:264) i wzajemnymi odwo(cid:227)aniami. Przypadki u(cid:304)ycia mog(cid:264) zawiera(cid:254) hiper(cid:227)(cid:264)cza do innych przypadków u(cid:304)ycia i mog(cid:264) by(cid:254) zagnie(cid:304)d(cid:304)ane w ramach pozosta(cid:227)ych przypadków. Wielu programistów nie mo(cid:304)e uwierzy(cid:254), (cid:304)e ktokolwiek mo(cid:304)e powa(cid:304)nie traktowa(cid:254) pomys(cid:227) dokumentowania tak szczegó(cid:227)owych informacji, rysuj(cid:264)c ludziki z(cid:227)o(cid:304)one z kilku linii (patrz rysunek 7.3). Nie powinni(cid:292)my jednak przywi(cid:264)zywa(cid:254) si(cid:269) do ja- kiejkolwiek notacji; powinni(cid:292)my raczej wybiera(cid:254) t(cid:269) metod(cid:269), która pozwala naj- skuteczniej komunikowa(cid:254) wymagania naszym odbiorcom. Poleć książkęKup książkę Kopalnia wymaga(cid:281) (cid:87) 223 Rysunek 7.2. Przykładowy przypadek użycia Rysunek 7.3. Przypadki użycia w notacji UML — nawet dziecko to potrafi! Poleć książkęKup książkę 224 (cid:88) Rozdzia(cid:227) 7. Przed projektem Zbyt du(cid:285)a liczba szczegó(cid:239)ów Jednym z najwi(cid:269)kszych zagro(cid:304)e(cid:281) podczas sporz(cid:264)dzania dokumentu z wymaga- niami jest d(cid:264)(cid:304)enie do zapisania zbyt wielu szczegó(cid:227)ów. Dobre dokumenty o wy- maganiach zachowuj(cid:264) swoj(cid:264) abstrakcyjno(cid:292)(cid:254). W przypadku wymaga(cid:281) najprostsze stwierdzenia, które mo(cid:304)liwie precyzyjnie wyra(cid:304)aj(cid:264) potrzeby biznesowe, spraw- dzaj(cid:264) si(cid:269) zdecydowanie najlepiej. Nie chodzi jednak o przesadn(cid:264) ogólnikowo(cid:292)(cid:254) — w naszych wymaganiach musimy uwzgl(cid:269)dni(cid:254) niezmienniki semantyczne, a konkretne lub bie(cid:304)(cid:264)ce praktyki nale(cid:304)y udokumentowa(cid:254) raczej w formie polityki. Wymagania to nie architektura. Wymagania to nie projekt ani interfejs u(cid:304)yt- kownika. Wymagania to konieczno(cid:292)(cid:254). Widzie(cid:202) dalej Problem roku 2000 cz(cid:269)sto kojarzy si(cid:269) z krótkowzrocznymi programistami, którzy desperacko poszukiwali mo(cid:304)liwo(cid:292)ci oszcz(cid:269)dzenia cho(cid:254)by kilku bajtów pami(cid:269)ci w czasach, gdy najwi(cid:269)ksze komputery dysponowa(cid:227)y mniejsz(cid:264) ilo(cid:292)ci(cid:264) pami(cid:269)ci ni(cid:304) wspó(cid:227)czesny pilot do telewizora. W rzeczywisto(cid:292)ci nie by(cid:227)a to ani wina programistów, ani problem niedosta- tecznej ilo(cid:292)ci pami(cid:269)ci. Gdyby(cid:292)my mieli kogokolwiek wini(cid:254) za to niedopatrzenie, za b(cid:227)(cid:264)d odpowiadaj(cid:264) raczej analitycy i projektanci systemów. Problem roku 2000 mia(cid:227) dwie przyczyny — nieumiej(cid:269)tno(cid:292)(cid:254) przewidywania sytuacji poza bie(cid:304)(cid:264)c(cid:264) praktyk(cid:264) biznesow(cid:264) oraz naruszanie zasady DRY. Firmy pos(cid:227)ugiwa(cid:227)y si(cid:269) skróconym, dwucyfrowym formatem zapisu lat na d(cid:227)ugo przed pojawieniem si(cid:269) komputerów. By(cid:227)a to powszechna praktyka. Dzia(cid:227)anie wczesnych aplikacji przetwarzaj(cid:264)cych dane ogranicza(cid:227)o si(cid:269) do automatyzacji istniej(cid:264)cych procesów biznesowych, st(cid:264)d powielenie b(cid:227)(cid:269)dnego zapisu. Nawet gdyby architektura narzuca(cid:227)a programistom stosowanie dwucyfrowych repre- zentacji lat w danych wej(cid:292)ciowych, raportach i bazie danych, powinna istnie(cid:254) jaka(cid:292) abstrakcja DATA, która „wiedzia(cid:227)aby”, (cid:304)e te dwie cyfry to tylko skrócona forma rzeczywistej daty. WSKAZÓWKA NR 53 Abstrakcje żyją dłużej niż szczegóły. Czy „widzie(cid:254) dalej” wymaga od nas przewidywania przysz(cid:227)o(cid:292)ci? Nie — chodzi raczej o zapisywanie wymaga(cid:281) w nast(cid:269)puj(cid:264)cy sposób: System cz(cid:269)sto korzysta z abstrakcji DATA. System b(cid:269)dzie implementowa(cid:227) us(cid:227)ugi zwi(cid:264)zane z t(cid:264) abstrakcj(cid:264), jak formatowanie, zapisywanie czy operacje matematyczne, w spójny i uniwersalny sposób. Poleć książkęKup książkę Kopalnia wymaga(cid:281) (cid:87) 225 Wymagania w tej formie okre(cid:292)laj(cid:264) tylko to, (cid:304)e system b(cid:269)dzie operowa(cid:227) na datach. Mog(cid:264) te(cid:304) sugerowa(cid:254), (cid:304)e na datach b(cid:269)d(cid:264) wykonywane jakie(cid:292) dzia(cid:227)ania matema- tyczne. Mog(cid:264) wskazywa(cid:254), (cid:304)e daty b(cid:269)d(cid:264) dodatkowo przechowywane w rozmaitych formatach. Mamy tutaj do czynienia z ogólnymi wymaganiami dotycz(cid:264)cymi mo- du(cid:227)u lub klasy DATA. Jeszcze tylko jedna malutka funkcja… Wiele projektów ko(cid:281)czy si(cid:269) niepowodzeniem wskutek niekontrolowanego roz- szerzania zakresu prac, czyli zjawiska okre(cid:292)lanego mianem przerostu funkcji. Mamy tutaj do czynienia z pewnym aspektem syndromu gotowanej (cid:304)aby z pod- rozdzia(cid:227)u „Zupa z kamieni i gotowane (cid:304)aby” w rozdziale 1. Co mo(cid:304)emy zrobi(cid:254), aby zapobiec wpadni(cid:269)ciu w pu(cid:227)apk(cid:269) zbyt wielu wymaga(cid:281)? W literaturze mo(cid:304)na znale(cid:302)(cid:254) opisy wielu ró(cid:304)nych miar, jak liczba zg(cid:227)oszonych i usuni(cid:269)tych b(cid:227)(cid:269)dów, g(cid:269)sto(cid:292)(cid:254) usterek, spójno(cid:292)(cid:254), zwi(cid:264)zki, punkty funkcyjne, wier- sze kodu itp. Warto(cid:292)ci tych miar mo(cid:304)na (cid:292)ledzi(cid:254) r(cid:269)cznie lub za pomoc(cid:264) odpo- wiedniego oprogramowania. Okazuje si(cid:269) jednak, (cid:304)e tylko w niewielkiej cz(cid:269)(cid:292)ci projektów aktywnemu (cid:292)ledze- niu podlegaj(cid:264) wymagania. Oznacza to, (cid:304)e uczestnicy tych raportów nie maj(cid:264) mo(cid:304)liwo(cid:292)ci raportowania o zmianach zakresu prac — tego, kto (cid:304)(cid:264)da(cid:227) poszczegól- nych funkcji, kto zatwierdzi(cid:227) te wnioski, jaka jest (cid:227)(cid:264)czna liczba zaakceptowanych wymaga(cid:281) itp. Kluczem do zarz(cid:264)dzania wzrostem liczby wymaga(cid:281) jest jasne stwierdzenie, (cid:304)e ka(cid:304)da nowa funkcja wyd(cid:227)u(cid:304)a termin przekazania gotowego produktu sponsorom projektu. Kiedy projekt jest opó(cid:302)niony o rok wzgl(cid:269)dem pocz(cid:264)tkowych szacunków i kiedy wszyscy dooko(cid:227)a zaczynaj(cid:264) formu(cid:227)owa(cid:254) wzajemne oskar(cid:304)enia, warto dys- ponowa(cid:254) precyzyjnym, kompletnym obrazem tego, jak i kiedy zanotowano wzrost liczby wymaga(cid:281). Bardzo (cid:227)atwo wpa(cid:292)(cid:254) w wir „tylko jednej dodatkowej funkcji”, jednak uwa(cid:304)ne (cid:292)ledzenie wymaga(cid:281) mo(cid:304)e nam u(cid:227)atwi(cid:254) odkrycie, (cid:304)e ta tylko jedna dodatkowa funkcja to tak naprawd(cid:269) ju(cid:304) pi(cid:269)tnasty element dodany w tym miesi(cid:264)cu. Utrzymywanie glosariusza W momencie przyst(cid:264)pienia do rozmowy o wymaganiach u(cid:304)ytkownicy i eksperci z danej dziedziny zaczynaj(cid:264) u(cid:304)ywa(cid:254) pewnych terminów, które maj(cid:264) dla nich specyficzne znaczenie. Mog(cid:264) na przyk(cid:227)ad odró(cid:304)nia(cid:254) klienta od kupuj(cid:264)cego. W ta- kim przypadku zamienne stosowanie obu s(cid:227)ów w systemie by(cid:227)oby niew(cid:227)a(cid:292)ciwe. Warto wi(cid:269)c utworzy(cid:254) i utrzymywa(cid:254) glosariusz na potrzeby projektu, czyli jedno miejsce, w którym b(cid:269)d(cid:264) definiowane wszystkie terminy i s(cid:227)ownictwo u(cid:304)ywane w ramach projektu. Wszyscy uczestnicy projektu, od u(cid:304)ytkowników ko(cid:281)cowych po pracowników dzia(cid:227)u wsparcia, powinni pos(cid:227)ugiwa(cid:254) si(cid:269) tym glosariuszem, aby Poleć książkęKup książkę 226 (cid:88) Rozdzia(cid:227) 7. Przed projektem zachowywa(cid:254) spójno(cid:292)(cid:254) terminologii. Oznacza to, (cid:304)e glosariusz powinien by(cid:254) po- wszechnie dost(cid:269)pny — to jeden z argumentów przemawiaj(cid:264)cych za dokumenta- cj(cid:264) udost(cid:269)pnian(cid:264) na stronach WWW (wrócimy do tego tematu w dalszej cz(cid:269)(cid:292)ci tego podrozdzia(cid:227)u). WSKAZÓWKA NR 54 Należy stosować glosariusz projektu. Bardzo trudno pomy(cid:292)lnie zako(cid:281)czy(cid:254) projekt, w którym u(cid:304)ytkownicy i programi- (cid:292)ci stosuj(cid:264) odmienne nazwy dla tych samych elementów czy zdarze(cid:281) lub — co gorsza — odwo(cid:227)uj(cid:264) si(cid:269) do ró(cid:304)nych aspektów, pos(cid:227)uguj(cid:264)c si(cid:269) t(cid:264) sam(cid:264) nazw(cid:264). Dokumenty s(cid:200) dla wszystkich W podrozdziale „Pisanie przede wszystkim” w rozdziale 8. omówimy problem publikowania dokumentów projektu w wewn(cid:269)trznych serwisach WWW, tak aby zapewni(cid:254) (cid:227)atwy dost(cid:269)p do tych dokumentów wszystkim uczestnikom projektu. Proponowana metoda dystrybucji dokumentacji jest szczególnie przydatna w przypadku dokumentów po(cid:292)wi(cid:269)conych wymaganiom. Prezentuj(cid:264)c wymagania w formie dokumentu hipertekstowego, mo(cid:304)emy sku- teczniej odpowiada(cid:254) na oczekiwania ró(cid:304)nych odbiorców — ka(cid:304)dy czytelnik mo(cid:304)e znale(cid:302)(cid:254) w tego rodzaju dokumentach to, co go interesuje. Sponsorzy projektu mog(cid:264) otrzymywa(cid:254) informacje na wysokim poziomie abstrakcji, które dadz(cid:264) im pewno(cid:292)(cid:254) co do spe(cid:227)niania celów biznesowych. Programi(cid:292)ci mog(cid:264) u(cid:304)ywa(cid:254) hiper- (cid:227)(cid:264)czy do wygodnego przechodzenia do coraz bardziej szczegó(cid:227)owych informa- cji (nawet na poziomie odwo(cid:227)a(cid:281) do odpowiednich definicji lub specyfikacji in- (cid:304)ynierskich). Model, w którym dokumentacja jest umieszczana na stronach internetowych, eliminuje te(cid:304) problem typowych, opas(cid:227)ych tomów zatytu(cid:227)owanych Analiza wy- maga(cid:281), których nikt nigdy nie czyta i które staj(cid:264) si(cid:269) nieaktualne, zanim obe- schnie tusz na papierze. Je(cid:292)li co(cid:292) jest internecie, jest szansa, (cid:304)e nawet programi(cid:292)ci to przeczytaj(cid:264). Pokrewne podrozdzia(cid:227)y (cid:122) „Zupa z kamieni i gotowane (cid:304)aby” w rozdziale 1. (cid:122) „Odpowiednio dobre oprogramowanie” w rozdziale 1. (cid:122) „Okr(cid:269)gi i strza(cid:227)ki” w rozdziale 7. (cid:122) „Pisanie przede wszystkim” w rozdziale 8. (cid:122) „Wielkie oczekiwania” w rozdziale 8. Poleć książkęKup książkę Rozwi(cid:264)zywanie niemo(cid:304)liwych do rozwi(cid:264)zania (cid:227)amig(cid:227)ówek (cid:87) 227 Wyzwania (cid:122) Czy u(cid:304)ywasz oprogramowania, które piszesz? Czy mo(cid:304)na dobrze zgroma- dzi(cid:254) i zrozumie(cid:254) wymagania bez samodzielnego sprawdzenia oprogra- mowania? (cid:122) Wybierz jaki(cid:292) problem niezwi(cid:264)zany z komputerami, który w(cid:227)a(cid:292)nie musisz rozwi(cid:264)za(cid:254). Opracuj wymagania dla rozwi(cid:264)zania tego problemu (bez u(cid:304)ycia komputera). (cid:253)wiczenia 42. Które z poni(cid:304)szych zda(cid:281) zas(cid:227)uguj(cid:264) na miano pe(cid:227)nowarto(cid:292)ciowych wyma- ga(cid:281)? Spróbuj (je(cid:292)li to mo(cid:304)liwe) inaczej wyrazi(cid:254) zdania, które nie spe(cid:227)niaj(cid:264) warunków dobrych wymaga(cid:281). 1. Czas odpowiedzi musi by(cid:254) krótszy ni(cid:304) 500 ms. 2. Okna dialogowe b(cid:269)d(cid:264) mia(cid:227)y szary kolor t(cid:227)a. 3. Aplikacja zostanie zorganizowana jako pewna liczba procesów frontowych oraz jeden serwer wewn(cid:269)trzny. 4. Je(cid:292)li u(cid:304)ytkownik poda znaki nienumeryczne w polu numerycznym, system odtworzy d(cid:302)wi(cid:269)k ostrzegawczy i odrzuci wprowadzon(cid:264) warto(cid:292)(cid:254). 5. Kod i dane aplikacje nie mog(cid:264) zajmowa(cid:254) wi(cid:269)cej ni(cid:304) 256 kB. Patrz odpowiedź 42. w dodatku B. 37 Rozwi(cid:200)zywanie niemo(cid:285)liwych do rozwi(cid:200)zania (cid:239)amig(cid:239)ówek Gordios, król Frygii, zawi(cid:264)za(cid:227) kiedy(cid:292) w(cid:269)ze(cid:227), którego nikt nie potrafi(cid:227) rozsup(cid:227)a(cid:254). Mówiono, (cid:304)e ten, kto rozwi(cid:264)(cid:304)e zagadk(cid:269) w(cid:269)z(cid:227)a gordyjskiego, zdob(cid:269)dzie w(cid:227)adz(cid:269) nad Azj(cid:264). Zagadk(cid:269) rozwi(cid:264)za(cid:227) dopiero Aleksander Wielki, który przeci(cid:264)(cid:227) w(cid:269)ze(cid:227) mieczem. Okaza(cid:227)o si(cid:269), (cid:304)e wystarczy(cid:227)a tylko inna interpretacja wymaga(cid:281) — to wszystko… i rzeczywi(cid:292)cie Aleksander podbi(cid:227) znaczn(cid:264) cz(cid:269)(cid:292)(cid:254) Azji. Od czasu do czasu odkrywamy gdzie(cid:292) w (cid:292)rodku projektu, (cid:304)e nie potrafimy zrobi(cid:254) cho(cid:254)by kroku naprzód. Trafiamy na przeszkod(cid:269) niemo(cid:304)liw(cid:264) do rozwi(cid:264)zania, jak nieumiej(cid:269)tno(cid:292)(cid:254) radzenia sobie z jak(cid:264)(cid:292) technologi(cid:264) czy fragment kodu, który okazuje si(cid:269) du(cid:304)o trudniejszy do napisania, ni(cid:304) pocz(cid:264)tkowo zak(cid:227)adali(cid:292)my. By(cid:254) mo(cid:304)e problem rzeczywi(cid:292)cie wydaje si(cid:269) niemo(cid:304)liwy do rozwi(cid:264)zania. Czy jednak rzeczywi(cid:292)cie jest taki trudny, na jaki wygl(cid:264)da? Przeanalizujmy tradycyjne uk(cid:227)adanki — wszystkie te k(cid:227)opotliwe kszta(cid:227)ty z drew- na, stali lub plastiku, które tak cz(cid:269)sto znajdujemy pod choink(cid:264) lub na wyprze- da(cid:304)ach niepotrzebnych rzeczy. Zwykle wystarczy przenie(cid:292)(cid:254) okr(cid:264)g(cid:227)y kszta(cid:227)t w inne miejsce, umie(cid:292)ci(cid:254) klocek w kszta(cid:227)cie T w okre(cid:292)lonym miejscu itp. Poleć książkęKup książkę 228 (cid:88) Rozdzia(cid:227) 7. Przed projektem Przenosimy wi(cid:269)c okr(cid:264)g(cid:227)y kszta(cid:227)t lub próbujemy umie(cid:292)ci(cid:254) klocek w kszta(cid:227)cie litery T w okre(cid:292)lonym miejscu, aby szybko odkry(cid:254), (cid:304)e to oczywiste rozwi(cid:264)zanie nie zdaje egzaminu. Uk(cid:227)adanek nie mo(cid:304)na rozwi(cid:264)zywa(cid:254) w ten sposób. To, (cid:304)e rozwi(cid:264)zanie nie jest oczywiste, nie powstrzymuje ludzi przed próbami wielokrotnego powta- rzania tych samych czynno(cid:292)ci w przekonaniu, (cid:304)e (cid:227)amig(cid:227)ówka musi mie(cid:254) jakie(cid:292) rozwi(cid:264)zanie. To oczywiste, (cid:304)e w ten sposób nie mo(cid:304)na doj(cid:292)(cid:254) do rozwi(cid:264)zania. Rozwi(cid:264)zanie le(cid:304)y gdzie indziej. Sekretem uk(cid:227)adanki jest identyfikacja rzeczywistych (nie wyobra- (cid:304)onych) ogranicze(cid:281) i znalezienie rozwi(cid:264)zania w ich ramach. Niektóre ogranicze- nia maj(cid:264) bezwzgl(cid:269)dny charakter; inne maj(cid:264) raczej posta(cid:254) nieuzasadnionych uprzedze(cid:281). Ograniczenia bezwzgl(cid:269)dne musz(cid:264) by(cid:254) przestrzegane niezale(cid:304)nie od tego, czy sprawiaj(cid:264) wra(cid:304)enie nielogicznych lub wr(cid:269)cz g(cid:227)upich. Istniej(cid:264) te(cid:304) pozorne ograniczenia, które nie maj(cid:264) nic wspólnego z rzeczywisto(cid:292)ci(cid:264). Istnieje na przy- k(cid:227)ad stara sztuczka znana bywalcom barów, która polega na wzi(cid:269)ciu nowej, zamkni(cid:269)tej butelki szampana i przyjmowaniu zak(cid:227)adów, jakoby mo(cid:304)na z niej wypi(cid:254) piwo. Ca(cid:227)a sztuka polega na odwróceniu butelki do góry nogami i wlaniu niewielkiej ilo(cid:292)ci piwa do wg(cid:227)(cid:269)bienia na jej spodzie. Wiele problemów dotycz(cid:264)cych oprogramowania mo(cid:304)na rozwi(cid:264)za(cid:254) w równie przebieg(cid:227)y sposób. Stopnie swobody Popularne wyra(cid:304)enie „wykracza(cid:254) my(cid:292)lami poza schematy” (ang. thinking out- side the box) zach(cid:269)ca nas do identyfikacji ogranicze(cid:281), które w naszym przypadku nie znajduj(cid:264) zastosowania, i do ich ignorowania. Przytoczona koncepcja nie jest jednak w pe(cid:227)ni s(cid:227)uszna. Je(cid:292)li tym „schematem” jest warunek graniczny, problem polega raczej na znalezieniu schematu, który co najwy(cid:304)ej mo(cid:304)e by(cid:254) istotnie szerszy, ni(cid:304) pocz(cid:264)tkowo s(cid:264)dzimy. Kluczem do rozwi(cid:264)zania uk(cid:227)adanki jest zarówno rozpoznanie kr(cid:269)puj(cid:264)cych nas ogranicze(cid:281), jak i stopni swobody, którymi dysponujemy — dopiero na tej pod- stawie mo(cid:304)emy znale(cid:302)(cid:254) wyj(cid:292)cie z sytuacji. W(cid:227)a(cid:292)nie dlatego uk(cid:227)adanki s(cid:264) takie k(cid:227)opotliwe; cz(cid:269)sto zbyt pochopnie rezygnujemy z potencjalnych rozwi(cid:264)za(cid:281). Czy potrafimy na przyk(cid:227)ad po(cid:227)(cid:264)czy(cid:254) wszystkie punkty na poni(cid:304)szym rysunku i wróci(cid:254) do punktu wyj(cid:292)cia, rysuj(cid:264)c zaledwie trzy proste odcinki (bez odrywania d(cid:227)ugopisu od papieru ani dwukrotnego rysowania odcinka (cid:227)(cid:264)cz(cid:264)cego te same punkty) [Hol78]? Musimy zmierzy(cid:254) si(cid:269) ze wszystkimi przyj(cid:269)tymi z góry wyobra(cid:304)eniami i oceni(cid:254), czy rzeczywi(cid:292)cie reprezentuj(cid:264) fizyczne ograniczenia. Poleć książkęKup książkę Rozwi(cid:264)zywanie niemo(cid:304)liwych do rozwi(cid:264)zania (cid:227)amig(cid:227)ówek (cid:87) 229 Problemem nie jest wi(cid:269)c to, czy my(cid:292)limy schematycznie, czy potrafimy wyj(cid:292)(cid:254) poza schematy. Kluczem do rozwi(cid:264)zania jest raczej znalezienie schematu — identyfi- kacja faktycznych ogranicze(cid:281). WSKAZÓWKA NR 55 Nie należy wykraczać myślami poza schemat — należy raczej znaleźć ten schemat. W razie napotkania szczególnie k(cid:227)opotliwego problemu warto zapisa(cid:254) sobie wszystkie mo(cid:304)liwe (cid:292)cie(cid:304)ki rozwi(cid:264)zania, które na tym etapie potrafimy dostrzec. Nie nale(cid:304)y niczego pomija(cid:254), cho(cid:254)by wydawa(cid:227)o si(cid:269) zupe(cid:227)nie niepraktyczne lub wr(cid:269)cz g(cid:227)upie. Dopiero po sporz(cid:264)dzeniu tej listy warto j(cid:264) uwa(cid:304)nie przejrze(cid:254) i wyja- (cid:292)ni(cid:254), dlaczego ta czy inna (cid:292)cie(cid:304)ka nie doprowadzi do szcz(cid:269)(cid:292)liwego ko(cid:281)ca. Czy na pewno? Potrafimy to udowodni(cid:254)? Przypomnijmy sobie histori(cid:269) konia troja(cid:281)skiego — nowatorskiego rozwi(cid:264)zania problemu, który wydawa(cid:227) si(cid:269) niemo(cid:304)liwy do rozwi(cid:264)zania. Jak niepostrze(cid:304)enie przerzuci(cid:254) wojsko do dobrze ufortyfikowanego miasta? Jeste(cid:292)my pewni, (cid:304)e kon- cepcja „przez g(cid:227)ówn(cid:264) bram(cid:269)” pocz(cid:264)tkowo by(cid:227)a odrzucana jako samobójcza. Warto przypisywa(cid:254) poszczególne ograniczenia do kategorii i nadawa(cid:254) im prio- rytety. Kiedy stolarze przyst(cid:269)puj(cid:264) do projektu, zaczynaj(cid:264) od ci(cid:269)cia najd(cid:227)u(cid:304)szych fragmentów drewna, by nast(cid:269)pnie odpowiednio poci(cid:264)(cid:254) pozosta(cid:227)e fragmenty. W ten sam sposób chcemy najpierw identyfikowa(cid:254) najbardziej kr(cid:269)puj(cid:264)ce ograni- czenia i umieszcza(cid:254) pozosta(cid:227)e ograniczenia w ich ramach. Rozwi(cid:264)zanie zagadki czterech punktów (cid:227)(cid:264)czonych trzema odcinkami mo(cid:304)na znale(cid:302)(cid:254) w dodatku B. Musi istnie(cid:202) prostszy sposób! Zdarza si(cid:269), (cid:304)e pracujemy nad rozwi(cid:264)zaniem problemu, który sprawia wra(cid:304)enie du(cid:304)o trudniejszego, ni(cid:304) jest w rzeczywisto(cid:292)ci. Cz(cid:269)sto s(cid:264)dzimy, (cid:304)e obrali(cid:292)my niew(cid:227)a(cid:292)ciw(cid:264) drog(cid:269) — musi przecie(cid:304) istnie(cid:254) prostszy sposób osi(cid:264)gni(cid:269)cia celu! By(cid:254) mo(cid:304)e ju(cid:304) teraz nie jeste(cid:292)my w stanie dotrzyma(cid:254) harmonogramu lub wr(cid:269)cz popa- damy w rozpacz, trac(cid:264)c wiar(cid:269) w mo(cid:304)liwo(cid:292)(cid:254) prawid(cid:227)owego funkcjonowania sys- temu, poniewa(cid:304) jaki(cid:292) problem wydaje si(cid:269) „niemo(cid:304)liwy do rozwi(cid:264)zania”. W takich przypadkach powinni(cid:292)my zatrzyma(cid:254) si(cid:269) na chwil(cid:269) i zada(cid:254) sobie kilka pyta(cid:281): (cid:122) Czy istnieje prostszy sposób? (cid:122) Czy rozwi(cid:264)zujemy w(cid:227)a(cid:292)ciwy problem, czy natrafili(cid:292)my tylko na zewn(cid:269)trzn(cid:264) przeszkod(cid:269) techniczn(cid:264)? (cid:122) Dlaczego w ogóle analizowana kwestia jest problemem? (cid:122) Co sprawia, (cid:304)e jego rozwi(cid:264)zanie jest trudne? Poleć książkęKup książkę 230 (cid:88) Rozdzia(cid:227) 7. Przed projektem (cid:122) Czy nie ma innego rozwi(cid:264)zania? (cid:122) Czy w ogóle musimy to robi(cid:254)? Próby odpowiedzenia sobie na te pytania nierzadko prowadz(cid:264) do zaskakuj(cid:264)cych odkry(cid:254). W wielu przypadkach wystarczy ponowna interpretacja wymaga(cid:281), aby pozby(cid:254) si(cid:269) ca(cid:227)ego zbioru problemów (tak jak w przypadku w(cid:269)z(cid:227)a gordyjskiego). Wszystko, czego nam trzeba, to prawdziwe ograniczenia, nietrafione ograniczenia oraz wiedza, jak je rozró(cid:304)nia(cid:254). Wyzwania (cid:122) Spróbuj z dystansu spojrze(cid:254) na dowolny trudny problem, który w(cid:227)a(cid:292)nie próbujesz rozwi(cid:264)za(cid:254). Czy mo(cid:304)esz po prostu przeci(cid:264)(cid:254) ten w(cid:269)ze(cid:227) gordyjski? Zadaj sobie wymienione powy(cid:304)ej pytania, w szczególno(cid:292)ci: „Czy nie ma innego rozwi(cid:264)zania?”. (cid:122) Czy zbiór ogranicze(cid:281) by(cid:227) znany w momencie podpisywania kontraktu na bie(cid:304)(cid:264)cy projekt? Czy zdefiniowane wówczas ograniczenia wci(cid:264)(cid:304) s(cid:264) aktualne i czy ich interpretacja zachowa(cid:227)a swoj(cid:264) warto(cid:292)(cid:254)? 38 Nie, dopóki nie jeste(cid:258) gotowy Czasem chwila zawahania mo(cid:304)e by(cid:254) wybawieniem. James Thurber, The Glass in the Field Najlepsi wykonawcy maj(cid:264) jedn(cid:264) wspóln(cid:264) cech(cid:269): wiedz(cid:264), kiedy zacz(cid:264)(cid:254) i kiedy sko(cid:281)czy(cid:254). Nurek stoi na trampolinie i czeka na idealny moment do skoku. Dyry- gent nieruchomo stoi przed orkiestr(cid:264) z uniesionymi r(cid:269)kami a(cid:304) do momentu, w którym uzna, (cid:304)e to najlepszy czas na rozpocz(cid:269)cie koncertu. My tak(cid:304)e chcemy by(cid:254) wielkimi wykonawcami. Musimy ws(cid:227)uchiwa(cid:254) si(cid:269) w g(cid:227)os podpowiadaj(cid:264)cy: „Zaczekaj”. Je(cid:292)li siadamy do pisania kodu i stale nachodz(cid:264) nas jakie(cid:292) w(cid:264)tpliwo(cid:292)ci, nie mo(cid:304)emy ich lekcewa(cid:304)y(cid:254). WSKAZÓWKA NR 56 Należy słuchać uporczywych wątpliwości — nie wolno zaczynać pracy, dopóki nie jest się gotowym. Istnia(cid:227) kiedy(cid:292) model trenowania tenisa okre(cid:292)lany mianem „gry wewn(cid:269)trznej”. Trening polega(cid:227) na wielogodzinnym przebijaniu pi(cid:227)ek nad siatk(cid:264) bez zwracania szczególnej uwagi na precyzj(cid:269) — chodzi(cid:227)o raczej o ocen(cid:269) miejsca upadania pi(cid:227)ki wzgl(cid:269)dem jakiego(cid:292) celu (zwykle krzes(cid:227)a).Celem tych (cid:254)wicze(cid:281) by(cid:227)o trenowanie pod(cid:292)wiadomo(cid:292)ci i refleksu, tak aby zawodnik potrafi(cid:227) bez zastanowienia wy- biera(cid:254) w(cid:227)a(cid:292)ciwy sposób uderzenia pi(cid:227)ki. Poleć książkęKup książkę Nie, dopóki nie jeste(cid:292) gotowy (cid:87) 231 Jako programi(cid:292)ci robimy mniej wi(cid:269)cej to samo przez ca(cid:227)(cid:264) karier(cid:269). Próbujemy rozmaitych rozwi(cid:264)za(cid:281) i sprawdzamy, które z nich zdaj(cid:264) egzamin, a które oka- za(cid:227)y si(cid:269) nietrafione. Z czasem gromadzimy rozmaite do(cid:292)wiadczenia i wiedz(cid:269). Kiedy zmagamy si(cid:269) z uporczywymi w(cid:264)tpliwo(cid:292)ciami lub nasze do(cid:292)wiadczenie podpowiada nam, aby obra(cid:254) inn(cid:264) drog(cid:269), warto z tych „podszeptów” skorzysta(cid:254). By(cid:254) mo(cid:304)e nie jeste(cid:292)my w stanie dok(cid:227)adnie wskaza(cid:254) palcem, co nam si(cid:269) nie podoba, ale wystarczy troch(cid:269) czasu, aby obecne w(cid:264)tpliwo(cid:292)ci przerodzi(cid:227)y si(cid:269) w co(cid:292) bardziej namacalnego — konkretny problem do rozwi(cid:264)zania. Wytwarzanie opro- gramowania wci(cid:264)(cid:304) nie jest nauk(cid:264). Mo(cid:304)emy wi(cid:269)c pozwoli(cid:254) sobie na udzia(cid:227) in- stynktu w realizowanych przedsi(cid:269)wzi(cid:269)ciach. Uzasadniona obawa czy niepotrzebna zw(cid:239)oka? Ka(cid:304)dy boi si(cid:269) pustej kartki papieru. Rozpoczynanie nowego projektu (lub nawet rozpoczynanie prac nad nowym modu(cid:227)em w ramach istniej(cid:264)cego projektu) bywa bardzo irytuj(cid:264)cym do(cid:292)wiadczeniem. Wielu programistów wola(cid:227)oby jak najd(cid:227)u(cid:304)ej odk(cid:227)ada(cid:254) te szczególnie trudne, pocz(cid:264)tkowe fazy projektu. Jak w takim razie stwierdzi(cid:254), czy mamy do czynienia z nieuzasadnion(cid:264) gr(cid:264) na zw(cid:227)ok(cid:269), czy odpo- wiedzialnym oczekiwaniem na zgromadzenie wszystkich niezb(cid:269)dnych elementów? W naszym przypadku najskuteczniejsz(cid:264) technik(cid:264) radzenia sobie w tych oko- liczno(cid:292)ciach jest tworzenie prototypów. Nale(cid:304)y wybra(cid:254) obszar, który wydaje nam si(cid:269) szczególnie k(cid:227)opotliwy, i przyst(cid:264)pi(cid:254) do tworzenia rozwi(cid:264)za(cid:281) potwierdzaj(cid:264)cych lub obalaj(cid:264)cych te za(cid:227)o(cid:304)enia. W wi(cid:269)kszo(cid:292)ci przypadków tworzenie prototypów prowadzi do jednej z dwóch sytuacji. Z jednej strony, krótko po przyst(cid:264)pieniu do tych eksperymentów mo(cid:304)emy uzna(cid:254), (cid:304)e tracimy czas. To zniech(cid:269)cenie cz(cid:269)sto pokazuje, (cid:304)e pocz(cid:264)tkowe obawy by(cid:227)y spowodowane tylko niech(cid:269)ci(cid:264) do pierw- szych faz projektu. Warto wówczas przerwa(cid:254) prace nad prototypami i przej(cid:292)(cid:254) do w(cid:227)a(cid:292)ciwego wytwarzania. Z drugiej strony, podczas tworzenia prototypów mo(cid:304)emy nagle odkry(cid:254), (cid:304)e które(cid:292) z podstawowych za(cid:227)o(cid:304)e(cid:281) dotycz(cid:264)cych danego projektu by(cid:227)o b(cid:227)(cid:269)dne. Co wi(cid:269)cej, b(cid:269)dziemy potrafili jasno okre(cid:292)li(cid:254), jak zmieni(cid:254) i wyrazi(cid:254) na nowo to za(cid:227)o(cid:304)enie. W takim przypadku mo(cid:304)emy w poczuciu komfortu przerwa(cid:254) prace nad prototy- pami i przyst(cid:264)pi(cid:254) do realizacji w(cid:227)a(cid:292)ciwego projektu (z uwzgl(cid:269)dnieniem skorygo- wanej wiedzy). Instynkt nas nie zawiód(cid:227) — w(cid:227)a(cid:292)nie oszcz(cid:269)dzili(cid:292)my sobie i nasze- mu zespo(cid:227)owi mnóstwo wysi(cid:227)ku, który w przeciwnym razie poszed(cid:227)by na marne. Je(cid:292)li decydujemy si(cid:269) na przygotowanie prototypu jako sposobu lepszego zba- dania (cid:302)róde(cid:227) swojego niepokoju, koniecznie musimy pami(cid:269)ta(cid:254) o pierwotnych przyczynach tej decyzji. Ostatni(cid:264) rzecz(cid:264), której nam potrzeba, jest po(cid:292)wi(cid:269)cenie wielu tygodni na powa(cid:304)ne prace programistyczne tylko po to, aby wreszcie przypomnie(cid:254) sobie, (cid:304)e pracujemy tylko nad prototypem. Proponowany model jest te(cid:304) przejawem cynizmu — (cid:227)atwiej zyska(cid:254) polityczn(cid:264) akceptacj(cid:269) dla eksperymentu z prototypem ni(cid:304) prostego stwierdzenia: „Mam obawy co do tego projektu” i ostentacyjnego rozpocz(cid:269)cia uk(cid:227)adania pasjansa. Poleć książkęKup książkę 232 (cid:88) Rozdzia(cid:227) 7. Przed projektem Wyzwania (cid:122) Omów syndrom obaw przed pocz(cid:264)tkiem projektu ze swoimi wspó(cid:227)pra- cownikami. Czy inni do(cid:292)wiadczaj(cid:264) tego samego? Czy g(cid:227)o(cid:292)no wyra(cid:304)aj(cid:264) swoje obawy? Jakich sztuczek u(cid:304)ywaj(cid:264) do radzenia sobie z tym proble- mem? Czy ca(cid:227)a grupa jest zaanga(cid:304)owana w rozwiewanie obaw poszcze- gólnych cz(cid:227)onków zespo(cid:227)u, czy raczej wywiera dodatkow(cid:264) presj(cid:269)? 39 Pu(cid:239)apka specyfikacji Pilot l(cid:264)duj(cid:264)cy zachowuje status pilota prowadz(cid:264)cego do momentu zej(cid:292)cia na wysoko(cid:292)(cid:254) decyzyjn(cid:264), kiedy prowadz(cid:264)cy pilot niel(cid:264)duj(cid:264)cy przejmuje zadania nieprowadz(cid:264)cego pilota l(cid:264)duj(cid:264)cego, chyba (cid:304)e ten drugi wyda komend(cid:269) „odej(cid:292)cie”. W takim przypadku niel(cid:264)duj(cid:264)cy pilot prowadz(cid:264)cy dalej prowadzi, a l(cid:264)duj(cid:264)cy pilot nieprowadz(cid:264)cy dalej nie prowadzi a(cid:304) do nast(cid:269)pnej komendy „l(cid:264)duj” lub „odej(cid:292)cie”. W zwi(cid:264)zku z ostatnimi nieporozumieniami dotycz(cid:264)cymi tych przepisów, uzna(cid:227)em, (cid:304)e nale(cid:304)y je doprecyzowa(cid:254). Memorandum linii British Airways cytowane w pi(cid:292)mie „Pilot Magazine”, grudzie(cid:281) 1996 Specyfikacja programu to proces przetwarzania wymaga(cid:281) i ich redukowania do punktu, w którym programista mo(cid:304)e efektywnie korzysta(cid:254) ze swoich umiej(cid:269)tno- (cid:292)ci. Tworzenie specyfikacji to akt komunikacji, wyja(cid:292)niania i precyzowania fak- tów w sposób pozwalaj(cid:264)cy wyeliminowa(cid:254) najwa(cid:304)niejsze niejasno(cid:292)ci. Oprócz przes(cid:227)ania dla programisty, który b(cid:269)dzie pracowa(cid:227) nad pocz(cid:264)tkow(cid:264) implementa- cj(cid:264), specyfikacja jest te(cid:304) zapisem dla przysz(cid:227)ych pokole(cid:281) programistów, którzy b(cid:269)d(cid:264) konserwowali i rozszerzali ten kod. Specyfikacja jest te(cid:304) swoist(cid:264) umow(cid:264) z u(cid:304)ytkownikiem — zapisem jego potrzeb i nieformalnym kontraktem potwier- dzaj(cid:264)cym, (cid:304)e system w swojej ostatecznej formie b(cid:269)dzie spe(cid:227)nia(cid:227) konkretne wymaganie. Pisanie specyfikacji to du(cid:304)a odpowiedzialno(cid:292)(cid:254). Problem w tym, (cid:304)e wielu projektantów nie wie, kiedy przesta(cid:254). Pracuj(cid:264) w po- czuciu, (cid:304)e zadanie jest wykonane dopiero po zapisaniu ka(cid:304)dego, cho(cid:254)by naj- drobniejszego szczegó(cid:227)u. Taka metoda jest b(cid:227)(cid:269)dna z kilku powodów. Po pierwsze, wiara w to, (cid:304)e jakakol- wiek specyfikacja mo(cid:304)e uwzgl(cid:269)dnia(cid:254) wszystkie szczegó(cid:227)y i niuanse systemu b(cid:264)d(cid:302) jego wymaga(cid:281), jest przejawem naiwno(cid:292)ci. W ograniczonych dziedzinach proble- mów istniej(cid:264) zwykle formalne metody opisywania systemów, co jednak nie zwal- nia projektanta z obowi(cid:264)zku wyja(cid:292)nienia znaczenia stosowanej notacji u(cid:304)yt- kownikom ko(cid:281)cowym — (cid:304)adna notacja nie eliminuje problemu interpretacji przez cz(cid:227)owieka. Nawet bez problemów zwi(cid:264)zanych z t(cid:264) interpretacj(cid:264) trudno oczeki- wa(cid:254), aby przeci(cid:269)tny u(cid:304)ytkownik potrafi(cid:227) precyzyjnie okre(cid:292)li(cid:254), czego oczekuje od nowego systemu. Nawet je(cid:292)li u(cid:304)ytkownicy twierdz(cid:264), (cid:304)e rozumiej(cid:264) wymagania, Poleć książkęKup książkę Pu(cid:227)apka specyfikacji (cid:87) 233 i podpisuj(cid:264) przygotowany przez nas 200-stronicowy dokument, mo(cid:304)emy by(cid:254) pewni, (cid:304)e kiedy zobacz(cid:264) dzia(cid:227)aj(cid:264)cy system, zasypi(cid:264) nas (cid:304)(cid:264)daniami zmian. Po drugie, pewnym problemem jest ograniczony potencja(cid:227) wyra(cid:304)ania my(cid:292)li w na- szym j(cid:269)zyku. Wszystkie techniki prezentowania informacji w formie diagramów oraz metody formalne opieraj(cid:264) si(cid:269) na zapisach dotycz(cid:264)cych wykonywanych ope- racji wyra(cid:304)onych w konkretnym j(cid:269)zyku2. Praktyka pokazuje, (cid:304)e j(cid:269)zyki naturalne nie najlepiej sprawdzaj(cid:264) si(cid:269) w tej roli. Wystarczy spojrze(cid:254) na s(cid:227)ownictwo stoso- wane w dowolnej umowie — prawnicy d(cid:264)(cid:304)(cid:264)cy do maksymalnej precyzji pos(cid:227)u- guj(cid:264) si(cid:269) wyj(cid:264)tkowo nienaturalnym j(cid:269)zykiem. Zach(cid:269)camy do prostego eksperymentu. Spróbujmy napisa(cid:254) krótki tekst, który wyja(cid:292)ni odbiorcy, jak wi(cid:264)za(cid:254) sznurowad(cid:227)a. Do dzie(cid:227)a! Ka(cid:304)dy, kto ma z tym zadaniem podobne problemy do nas, napisze: „Owi(cid:281) teraz kciuk i palec wskazuj(cid:264)cy, tak aby wolny koniec wszed(cid:227) pod lewe sznurowad(cid:227)o…” lub co(cid:292) równie niezrozumia(cid:227)ego. To zadziwiaj(cid:264)co trudne zadanie. Co ciekawe, wi(cid:269)kszo(cid:292)(cid:254) z nas wi(cid:264)(cid:304)e buty, w ogóle nie my(cid:292)l(cid:264)c o tej czynno(cid:292)ci. WSKAZÓWKA NR 57 Niektóre rzeczy lepiej robić, niż o nich mówić. I wreszcie po trzecie, istnieje problem kaftana bezpiecze(cid:281)stwa. Projekt, który nie pozostawia koduj(cid:264)cemu (cid:304)adnego pola do implementacji, uniemo(cid:304)liwia mu pe(cid:227)ne pokazanie swoich umiej(cid:269)tno(cid:292)ci. Niektórzy twierdz(cid:264), (cid:304)e w(cid:227)a(cid:292)nie takie rozwi(cid:264)zanie jest najlepsze, ale nie maj(cid:264) racji. Cz(cid:269)sto w(cid:227)a(cid:292)nie podczas kodowania ujawniaj(cid:264) si(cid:269) pewne potencjalne opcje. Nierzadko podczas kodowania my(cid:292)limy sobie: „Ciekawe, poniewa(cid:304) zakodowa(cid:227)em t(cid:269) funkcj(cid:269) w ten sposób, móg(cid:227)bym uzu- pe(cid:227)ni(cid:254) j(cid:264) o pewne dodatkowe rozwi(cid:264)zanie dos(cid:227)ownie w pi(cid:269)(cid:254) minut” lub „Specyfikacja mówi, (cid:304)e mam zrobi(cid:254) to i to, ale niemal identyczne rezultaty mog(cid:269) osi(cid:264)gn(cid:264)(cid:254) w inny sposób, po(cid:292)wi(cid:269)caj(cid:264)c na to dwa razy mniej czasu”. Nie powinni(cid:292)my, oczywi(cid:292)cie, zbyt pochopnie wprowadza(cid:254) zmian w projekcie, ale warto pami(cid:269)ta(cid:254), (cid:304)e nawet nie dostrzegliby(cid:292)my wspomnianych okazji, gdy ten projekt by(cid:227) zbyt precyzyjny. Jako pragmatyczni programi(cid:292)ci powinni(cid:292)my postrzega(cid:254) gromadzenie wymaga(cid:281), projektowanie i implementacje jako odmienne aspekty tego samego procesu — procesu dostarczania systemu wysokiej jako(cid:292)ci. Nie warto inwestowa(cid:254) w (cid:292)ro- dowiska, gdzie zbieranie wymaga(cid:281), pisanie specyfikacji i samo kodowanie ma posta(cid:254) odr(cid:269)bnych, odizolowanych czynno(cid:292)ci. Powinni(cid:292)my raczej wdra(cid:304)a(cid:254) modele (cid:227)(cid:264)cz(cid:264)ce te elementy, gdzie specyfikacja i implementacja stanowi(cid:264) tylko ró(cid:304)ne aspekty jednego procesu identyfikacji i kodowania wymaga(cid:281). Ka(cid:304)da z tych czyn- no(cid:292)ci powinna prowadzi(cid:254) wprost do nast(cid:269)pnej bez sztucznych granic. Szybko 2 Istniej(cid:264) co prawda formalne metody algebraicznego wyra(cid:304)ania operacji, jednak rzadko s(cid:264) stosowane w praktyce. Tego rodzaju techniki wci(cid:264)(cid:304) wymagaj(cid:264) od analityka t(cid:227)umacze- nia poszczególnych zapisów u(cid:304)ytkownikom ko(cid:281)cowym. Poleć książkęKup książkę 234 (cid:88) Rozdzia(cid:227) 7. Przed projektem odkryjemy, (cid:304)e w(cid:227)a(cid:292)ciwy proces wytwarzania oprogramowania zach(cid:269)ca jego uczestników do uwzgl(cid:269)dniania wniosków p(cid:227)yn(cid:264)cych z implementacji i testów w procesie przygotowywania specyfikacji. Dla jasno(cid:292)ci podkre(cid:292)lamy, (cid:304)e nie jeste(cid:292)my przeciwnikami generowania specyfi- kacji. Przeciwnie — zdajemy sobie spraw(cid:269) z tego, (cid:304)e w pewnych przypadkach na- wet najbardziej szczegó(cid:227)owe specyfikacje s(cid:264) niezb(cid:269)dne (na przyk(cid:227)ad dla jasno(cid:292)ci kontraktu, z uwagi na specyficzne (cid:292)rodowisko, w którym pracujemy, lub z powo- du nietypowego charakteru tworzonego produktu)3. Musimy przy tym mie(cid:254) (cid:292)wiadomo(cid:292)(cid:254), (cid:304)e zapisuj(cid:264)c coraz bardziej szczegó(cid:227)owe specyfikacje, pr(cid:269)dzej czy pó(cid:302)niej osi(cid:264)gniemy punkt, od którego dalsze uszczegó(cid:227)awianie tych zapisów nie b(cid:269)dzie przynosi(cid:227)o (cid:304)adnych korzy(cid:292)ci lub wr(cid:269)cz b(cid:269)dzie powodowa(cid:227)o straty. Powinni- (cid:292)my te(cid:304) unika(cid:254) budowy specyfikacji ponad innymi specyfikacjami bez uprzedniego opracowywania implementacji czy cho(cid:254)by prototypów — bardzo (cid:227)atwo zapisa(cid:254) w specyfikacji rozwi(cid:264)zania, których w praktyce nie b(cid:269)dzie mo(cid:304)na zbudowa(cid:254). Im d(cid:227)u(cid:304)ej trwa tworzenie specyfikacji i im bardziej ten proces jest wykorzysty- wany w roli tarczy chroni(cid:264)cej programistów przed przera(cid:304)aj(cid:264)cym zadaniem pisania kodu, tym trudniej przyst(cid:264)pi(cid:254) do w(cid:227)a(cid:292)ciwego kodowania. Nie mo(cid:304)emy wpada(cid:254) w spiral(cid:269) specyfikacji — w pewnym momencie musimy zacz(cid:264)(cid:254) kodowa(cid:254)! Je(cid:292)li odkrywamy, (cid:304)e nasz zespó(cid:227) przyj(cid:264)(cid:227) wygodn(cid:264) postaw(cid:269) pisania specyfikacji w niesko(cid:281)czono(cid:292)(cid:254), musimy to przerwa(cid:254). Warto wówczas rozwa(cid:304)y(cid:254) opracowanie prototypów lub zastosowanie modelu pocisków smugowych. Pokrewne podrozdzia(cid:227)y (cid:122) „Pociski smugowe” w rozdziale 2. Wyzwania (cid:122) Przytoczony wcze(cid:292)niej przyk(cid:227)ad sznurowade(cid:227) jest interesuj(cid:264)c(cid:264) ilustracj(cid:264) problemu wyra(cid:304)ania prostych czynno(cid:292)ci s(cid:227)owami. Czy nie warto by(cid:227)oby opisa(cid:254) ten proces za pomoc(cid:264) diagramów zamiast s(cid:227)ów? A mo(cid:304)e zastoso- wa(cid:254) zdj(cid:269)cia? Mo(cid:304)e warto skorzysta(cid:254) z jakiej(cid:292
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Pragmatyczny programista. Od czeladnika do mistrza
Autor:
,

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: