Better Software Design Mariusz Gil

"Jak mamy pozyskać świetnych architektów, jeśli w swojej karierze będą mieli okazję ją tworzyć mniej niż pół tuzina razy?". Dokładnie takie pytania postawił Ted Neward, szukając sposobu na doskonalenie umiejętności tworzenia architektury. I trudno się tu nie zgodzić, patrząc jak często w zespołach duże projekty powstają od samego początku. Istnieje jednak prosty sposób na rozwiązanie tego problemu.

Jeśli wycena projektu podawana jest w dwóch wersjach, z uwzględnieniem testów i bez, to z software craftsmanshipem ma to niewiele wspólnego. To tak, jakby pytać chirurga, czy może przyspieszyć operację nie dezynfekując skalpela. Jakość nie powinna być elementem przetargowym. Chyba, że pracujemy nad proof-of-concept, ale tego rodzaju projekty często lubią płynnie przejść w fazę protoduction...

Odpowiedzialność za zapewnienie jakości w projekcie nie spoczywa na pojedynczej osobie, tylko na całym zespole. A rola QA nie sprowadza się tylko i wyłącznie do projektowania i implementacji przypadków testowych w procesie inspekcji systemu, ale także na byciu adwokatem jakości w projekcie, i czasem zadawaniu trudnych pytań o to, dlaczego pewne funkcjonalności są zrobione w ten, a nie inny sposób.

Tworzenie oprogramowania nie sprowadza się jedynie do backendu, natomiast tematyka architektury front-endu do tej pory była w zasadzie zupełnie nieobecna w Better Software Design. Do tej pory, ponieważ dzisiejszy odcinek otwiera nowy rozdział w podkaście i tego rodzaju zagadnienia będą się co jakiś czas pojawiać. A rozmowy na takie właśnie tematy prowadzić będzie najlepszy znami mi architekt front-endu, Tomasz Ducin.

Błędów nie popełnia tylko ten, co nic nie robi, a szramy Wietnamu biorą się z nie z czytania książek, tylko z osadzania zawartych w nich idei w złożonej rzeczywistości konkretnych projektów. Dziś zapraszam na rozmowę o często trudnych realiach wprowadzania Domain-Driven Design do organizacji i procesach Domain Discovery.

Czy kilka twoich projektów dla różnych klientów ma dokładnie taką samą strukturę wewnętrzną, stosowane są dokładnie te same wzorce organizacji kodu i architektury? Albo wszędzie widzisz możliwość zastosowania CQRS, rozdziału na komendy i query, czy możliwość zaimplementowania taktycznych wzorców z DDD? W wielu przypadkach będzie to zapewne całkowicie uzasadnione, poza tymi, w których nie ma to większego sensu...