Ta książ­ka Yourdona leży u mnie na pół­ce nie­mal­że od dnia jej wyda­nia, gdy ją przy­pad­kiem upo­lo­wa­łem, zaraz po jej uka­za­niu się w księ­gar­niach. Napisanie o niej odkła­dam od lat, bo prak­tycz­nie nie ma tam obraz­ków UML, opi­sów wzor­ców itp.. Od jej prze­czy­ta­nia mówię sobie: jutro o niej napi­szę… i to trwa­ło do tego momentu.

To książ­ka w cało­ści napi­sa­na pro­zą, bez obraz­ków, w któ­rej autor dzie­li sie swo­imi prze­my­śle­nia­mi na temat archi­tek­tu­ry sys­te­mów, ich pro­jek­to­wa­nia i tym co z tego wynika. 

Bardzo cie­ka­wie pisze o tym, czym jest zło­żo­ność opro­gra­mo­wa­nia, o tym, że zło­żo­ność sys­te­mu to sto­pień kom­pli­ka­cji mode­lu dzie­dzi­no­we­go a nie ​„całe­go sys­te­mu”. Typowy sys­tem (tu apli­ka­cja dla biz­ne­su) skła­da się w ponad 90% z biblio­tek, z któ­rych nie­wąt­pli­wie trze­ba umieć zbu­do­wać śro­do­wi­sko apli­ka­cji, jed­nak to nie one decy­du­ją o tym do cze­go słu­ży ten sys­tem i czy w ogó­le komu­kol­wiek do cze­goś słu­ży… Z biblio­tek, na któ­re nie mamy wpły­wu, ale musi­my (chce­my) ich użyć. 

Jaki to jest skom­pli­ko­wa­ny sys­tem? Ile ma klas/komponentów by uznać go za zło­żo­ny? Gdzie jest gra­ni­ca zło­żo­no­ści małej i dużej? Czym jest archi­tek­tu­ra i po co ona nam? O tym tu przeczytacie.

Polecam tę książ­kę każ­de­mu, kto ma ambi­cję pro­jek­to­wać archi­tek­tu­rę sys­te­mów biz­ne­so­wych. Uczy poko­ry. Zwracam tu uwa­gę, że oso­ba mówią­ca o sobie ​„ana­li­tyk biz­ne­so­wy”, któ­re­go pro­duk­tem pra­cy mają być ​„wyma­ga­nia na opro­gra­mo­wa­nie”, to nie zbie­racz nota­tek a pro­jek­tant . Albo niech zmie­ni zawód..