Formalizm

Każda sformalizowana metodyka projektowa przyjmie największego gniota za dobrą monetę, o ile ten będzie spełniał wymogi tej metodyki.

Metodyki projektowe służą głównie do wspomagania i dokumentowania pomysłów i procesów twórczych, a nie do ich wymyślania czy usprawniania. Metodyka tylko porządkuje i ujednolica pewne sprawy, ale nigdy nie zastąpi właściwej iskry twórczej, jaką powinien wykazać architekt aplikacji czy programista. W standardzie UML jednakowo dobrze wyglądają poprawne i niepoprawne schematy. Nie znaczy to, że metodyka projektowa zabija inicjatywę twórczą (chociaż trochę podcina skrzydła i nuży swoją urzędniczą miałkością) - ona jedynie porządkuje i dokumentuje fazy procesu planowania i wytwarzania.

Równie dobrze można skonstruować knota, posługując się, bądź i nie, metodyką. Sęk w tym, że daje się obserwować większy nacisk kładziony na formalizm w projekcie niż na jakość samego produktu. Mówimy nie tylko o niezawodności, ale przede wszystkim o wydajności, innowacyjności, szybkości, ergonomii - czyli cechach, które zupełnie nie są związane z metodykami projektowymi. Przy tworzeniu produktu należy rozdzielać sferę twórczą od rzemieślniczej, czyli artystów separować od urzędników. Nie oznacza to, że nie trzeba tworzyć dokumentacji projektowej. Trzeba, ale do roli tej powinno przeznaczać się ludzi o innych talentach niż nieco chaotyczni i bałaganiarscy kreatorzy koncepcji. Myślę, że jest to dobry moment, aby odpowiedzieć sobie na pytanie, czy projektant systemów jest bardziej artystą czy rzemieślnikiem.

Zmęczenie i przeciążenie formalizmami może przejawiać się w niezbyt udanych czy niewydajnych algorytmach przetwarzających, w nieciekawej architekturze czy fatalnych strukturach danych. Formalizm projektowy nigdy nie zastąpi zdrowego rozsądku ani twórczego zacięcia. Jeśli ktoś będzie polegać jedynie na gotowych wzorcach, to okaże się, że jego produkt będzie miał mało ciekawy wyraz końcowy albo będzie najeżony błędami. Niektórzy zbyt mocno ufają w inżynierię kodu, zapominając o inżynierii algorytmicznej i funkcjonalnej, czy - mówiąc bardziej po ludzku - o jakości użytkowej oprogramowania. Stąd biorą się właśnie takie dziwne zachowania doskonale udokumentowanych systemów.

Użytkownicy myślą, że dziwne zachowanie się systemu jest jego immamentną cechą, że inaczej się nie da. Nie zdają sobie sprawy, że na przykład brak blokady przed jednoczesną edycją tych samych zasobów nie jest naturą systemów informatycznych, a tylko projektowym niedomaganiem konkretnego produktu. Bo o tym nie decyduje żaden wzorzec projektowy. O tym po prostu musi pamiętać sam projektant i nikt go w tym nie wyręczy. A jeśli będzie o tym pamiętał, to na pewno znajdzie to następnie wyraz w odpowiednim schemacie formalnym.


TOP 200