Sztuka pisania oprogramowania Wybor i redakcja Joel Spolsky.pdf

IDZ DO

PRZYK£ADOW Y ROZDZIA£

Sztuka pisania

SPIS TREœCI

oprogramowania. Wybór

i redakcja Joel Spolsky

KATALOG KSI¥¯EK

KATALOG ONLINE

Autor: Joel Spolsky

T³umaczenie: Andrzej Gra¿yñski

ISBN: 83-246-0464-2

Tytu³ orygina³ u: The Best Software Writing I:

Selected and Introduced by Joel Spolsky

Format: B5, stron: 320

ZAMÓW DRUKOWANY KATALOG

TWÓJ KOSZYK

DODAJ DO KOSZYKA

Programowanie to nie tylko wiedza — to tak¿e sztuka. Aplikacja jest narzêdziem, które

powinno byæ przede wszystkim u¿yteczne i ergonomiczne. Niestety, wielu twórców

oprogramowania zapomina o tym, pisz¹c swoje programy. Powodów jest wiele: zbyt

ma³o czasu, Ÿle sformu³owane za³o¿enia, nieprawid³owa komunikacja miêdzy cz³onkami

zespo³u projektowego czy te¿ niestosowanie siê do konwencji kodowania i testowania.

Niezale¿nie od przyczyn, konsekwencj¹ jest oprogramowanie, które nie spe³nia swojej

podstawowej funkcji, jak¹ jest u¿ytecznoœæ.

Po przeczytaniu ksi¹¿ki „Sztuka pisania oprogramowania. Wybór i redakcja Joel

Spolsky” spojrzysz na proces tworzenia aplikacji w inny sposób. Czytaj¹c zawarte

w niej artyku³y autorstwa doœwiadczonych programistów i mened¿erów, dowiesz siê,

jak prowadziæ projekty informatyczne, czego unikaæ i jakie techniki stosowaæ.

Znajdziesz w niej opracowania dotycz¹ce stylu kodowania, zarz¹dzania projektem,

testowania, korzystania z nieudokumentowanych w³aœciwoœci systemu oraz

zatrudniania programistów. Niewa¿ne, czy jesteœ programist¹, czy kierownikiem

projektu, dowiesz siê z niej wielu interesuj¹cych rzeczy.

W ksi¹¿ce poruszono miêdzy innymi:

Styl kodowania

Projektowanie interfejsów u¿ytkownika

Pu³apki outsourcingu

W³aœciwe procedury testowania

Unikanie nadmiernie rozbudowanych procesów decyzyjnych

Zasady pracy z zespo³em projektowym

Dobór odpowiednich pracowników

Jeœli chcesz podnieœæ jakoœæ tworzonego oprogramowania,

koniecznie przeczytaj tê ksi¹¿kê

CENNIK I INFORMACJE

ZAMÓW INFORMACJE

ONOWOœCIACH

ZAMÓW CENNIK

CZYTELNIA

FRAGMENTY KSI¥¯EK ONLINE

Wydawnictwo Helion

ul. Koœciuszki 1c

44-100 Gliwice

tel. 032 230 98 63

e-mail: helion@helion.pl

SPIS TREŚCI

O redaktorze ...................................................7

O autorach ......................................................9

Wprowadzenie ............................................. 17

Ken Arnold Styl jest istotny .............................................. 21

Ken Bambrick Nominacja do nagrody za najgłupszy

interfejs użytkownika: narzędzie

wyszukiwania Windows ................................ 29

Michael Bean Pułapki programistycznego outsourcingu.

Dlaczego niektóre firmy programistyczne

mylą pudełko z czekoladkami? ...................... 31

Rory Blyth Excel jako baza danych ................................. 39

Adam Bosworth Prosto, zwyczajnie, po ludzku ....................... 45

Danah Boyd Autystyczne oprogramowanie społeczne ....... 57

Raymond Chen Dlaczego nie blokować programów

wykorzystujących nieudokumentowane

mechanizmy? ............................................... 69

Kevin Cheng i Tom Chi Kopanie lamy ............................................... 73

SZTUKA PISANIA OPROGRAMOWANIA

Cory Doctorow Boże, zachowaj kanadyjski internet od WIPO .. 75

ea_spouse EA: ludzka historia ........................................ 81

Bruce Eckel Rygorystyczna kontrola typów kontra

rygorystyczne testowanie .............................. 89

Paul Ford Processing .................................................. 101

Paul Graham Wielcy hakerzy ........................................... 117

John Gruber Gdy pole URL staje się wierszem poleceń ... 133

Gregor Hohpe Dlaczego w Starbuck® nie korzysta się

z potwierdzania dwufazowego? .................. 141

John Jeffries Pasja ........................................................... 147

Eric Johnson C++ — zapomniany koń trojański ............. 151

Eric Lippert Ilu pracowników Microsoftu potrzeba

do wymiany żarówki? ................................. 157

Michael „Rands” Lopp Co robić, gdy zostaniesz wkręcony?

5 scenariuszy dla pracowitych

dyrektorów technicznych ............................ 161

Larry Osterman

Reguła tworzenia oprogramowania nr 2:

pomiar wydajności testerów za pomocą

metryk ilościowych nie zdaje egzaminu ....... 173

Mary Poppendieck

Kompensacja zespołowa ............................. 179

Rick Schaut

Mac Word 6.0 .............................................193

Clay Shirky

Grupa sama dla siebie

jest największym wrogiem ........................... 203

Clay Shirky

Grupa jako użytkownik: flamewars

a projektowanie oprogramowania

społecznego .................................................229

Eric Sink

Zamykanie luki, część 1. ............................. 241

Eric Sink

Zamykanie luki, część 2. ............................. 251

Eric Sink

Loteria zatrudniania .................................... 265

Aaron Swartz

PowerPoint — remiks ................................. 279

why the lucky stiff

Krótka, ilustrowana i (mam nadzieję)

bezstresowa wycieczka po języku Ruby ........285

Skorowidz .................................................. 311

Rozdział 11

Bruce Eckel

RYGORYSTYCZNA

KONTROLA TYPÓW

KONTRA RYGORYSTYCZNE

TESTOWANIE 1

Od redakcji : Pamiętam, że gdy pracowaliśmy w Microsofcie nad VBA, toczyli-

śmy niekończące się dyskusje na temat statycznej i dynamicznej kontroli

typów w programach.

Ze statyczną kontrolą typów mamy do czynienia wówczas, gdy weryfikacja

poprawności typów wszystkich zmiennych przeprowadzana jest na etapie

kompilacji programu. Jeżeli na przykład w programie znajduje się funkcja

log() , która wymaga liczby rzeczywistej jako jedynego parametru, wywołanie

tej funkcji w postaci log("foo") spowoduje sygnalizację błędu w rodzaju

„tu oczekuje się liczby rzeczywistej” lub podobnego. Konsekwencją użycia

1 Bruce Eckel, „Strong Typing vs. Strong Testing”, Thinking About Computing,

artykuły Bruce Eckela na MindView.net ( http://www.MindView.net ), 2 maja 2003.

Patrz http://mindview.net/WebLog/log-0025 .

SZTUKA PISANIA OPROGRAMOWANIA

niewłaściwego typu — łańcucha zamiast liczby — jest niemożność skom-

pilowania programu.

Dla odróżnienia, w ramach dynamicznej kontroli typów weryfikacja tychże

odbywa się w czasie wykonania programu. Konstrukcja log("foo") zosta-

nie skomplikowana, a jej niepoprawność okaże się faktem dopiero w trakcie

wykonania programu. Podejście to ma tę oczywistą wadę, iż fakt ten może

stać się wiadomy dopiero po kilku miesiącach czy latach eksploatacji pro-

gramu, zwłaszcza jeżeli wzmiankowane wywołanie znajduje się wewnątrz

funkcji wywoływanej bardzo rzadko.

Jako że projektowany VBA miał być z założenia językiem skryptowym dla

Excela, osobiście optowałem za kontrolą dynamiczną. Jest ona koncepcyjnie

prostsza dla użytkowników niebędących programistami, którzy mogą mieć

trudności ze zrozumieniem pojęcia zmiennej, nie mówiąc już o pojęciu typu.

Miałem wówczas po swej stronie wielu użytkowników Smalltalka argu-

mentujących (raczej ogólnikowo): „Wciąż szukasz przyczyny problemu,

więc lepiej byłoby, żebyś poznał ją w ciągu kilku sekund”. Często okazuje

się to prawdą, jednak nie zawsze.

Ostatecznie, po długich debatach, udało mi się przekonać innych do moich

racji i tak narodził się typ Variant — struktura zdolna przechowywać wartości

dowolnego typu — jako element VBA i COM oraz jako jedyny dopuszczalny

typ późniejszego języka skryptowego VBS.

Nie zapominam oczywiście, że rygorystyczna kontrola typów dokonywana

w czasie kompilacji jest wspaniałą rzeczą, umożliwia bowiem wczesne wy-

krycie wielu błędów, co dla mnie, jako użytkownika C++, jest sprawą bez-

dyskusyjną. Jeżeli na przykład tworzysz oprogramowanie dla przedsiębior-

stwa, w którym jedynie menedżerowie uprawnieni są do otrzymywania

nagród, możesz zdefiniować dwie różne struktury danych — dla pracowników

i menedżerów — i tylko drugą z tych struktur wyposażyć w metodę PayBonus() .

Wywołanie tej metody na rzecz rekordu reprezentującego szarego pracow-

nika, nie szacownego menedżera, będzie niemożliwe, bo nie pozwoli na to

kompilator.

Problem w tym, iż tworzenie typów danych — jako samoistnych bytów — tylko

po to, by częściowe testowanie programu przeprowadzone zostało już na

etapie kompilacji, jest pomysłem po trosze niefortunnym. Owo „częściowe

testowanie” może bowiem obejmować jedynie testy o charakterze general-

nym, w rodzaju „czy mogę zrobić z tym obiektem to a to”, nie zaś testy

bardziej szczegółowe w rodzaju „czy ta funkcja zwróci wartość 2,12 jeśli

parametry jej wywołania będą miały postać 1 , 32 i 'aardvark' .

W efekcie rygorystyczna kontrola typów — jako jeden z mechanizmów weryfi-

kujących pewien tylko aspekt poprawności programu — może okazywać się

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: