sztuka-pisania-oprogramowania.-wybor-i-redakcja-joel-spolsky full, ebooki-ksiazki

[ Pobierz całość w formacie PDF ]
IDZ DO
PRZYK£ADOW
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³
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
 6
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
.
 90
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ę
[ Pobierz całość w formacie PDF ]