Przeczytałem Zasady dla zwinnego architekta , w których zdefiniowano kolejne zasady:
Zasada nr 1 Zespoły kodujące system projektują system.
Zasada nr 2 Zbuduj najprostszą architekturę, która może działać.
Zasada nr 3 W razie wątpliwości należy je zakodować.
Zasada # 4 Budują to, testują.
Zasada nr 5 Im większy system, tym dłuższy pas startowy.
Zasada # 6 Architektura systemu to współpraca roli.
Zasada nr 7 Nie ma monopolu na innowacje.
Artykuł mówi, że większość projektowania architektury jest wykonywana podczas fazy kodowania, a tylko projekt systemu wcześniej. W porządku.
Jak więc odbywa się projektowanie systemu? Używasz UML? Lub dokument definiujący interfejsy i główne bloki? Może coś jeszcze?
Odpowiedzi:
Zastrzeżenie: ja jestem architektem w agile środowiska, ale jak Helmut Karl Bernhard von Moltke mówi: „Żaden plan bitwy przetrwa kontaktu z wrogiem”. Innymi słowy, praktyczność oznacza, że nie zawsze można przestrzegać dokładnej litery wytycznych.
Większość punktów zebranych powyżej jest przestrzegana najlepiej, jak potrafi drużyna. Jednak zasada 1 (Zespoły, które kodują system projektujący system) jest naprawdę trudna do przestrzegania, gdy zespół składa się z dziesiątek (lub setek) programistów podzielonych na różne kontynenty i strefy czasowe . Nie ma to nic wspólnego z umiejętnościami i postawami programistów, a bardziej z logistycznym problemem ich obecności w celu zebrania wymagań od klientów i zrozumienia istniejących złożonych systemów.
Często architekt identyfikuje główne komponenty, a następnie definiuje interfejsy między nimi (w tym niefunkcjonalne wymagania, takie jak bezpieczeństwo, szybkość i niezawodność) i przekazuje wewnętrzny projekt komponentów poszczególnym zespołom . Jest to dobry kompromis między pozwoleniem zespołom na projektowanie własnych komponentów bez konieczności od wszystkich posiadania wiedzy na temat systemu.
Każda organizacja ma swój własny zestaw standardów dla projektów architektonicznych, który czasem różni się w zależności od projektu w organizacji. Ten projekt wykonany przed rozpoczęciem kodowania przez zespół lub tak wcześnie, jak to możliwe i zwykle zawiera (i nie jest to pełna lista):
Krótko mówiąc, konstrukcja systemu w zwinnym procesie jest dokładnie taka sama jak w tradycyjnym procesie wodospadowym. Jednak w zwinnych środowiskach mniej prac projektowych odbywa się z góry, a więcej jest przekazywanych zespołom składowym . Kluczem jest określenie, jak głęboko sięgać początkowo, które decyzje odłożyć na później i określenie, kiedy należy podjąć decyzję. Decyzje mające wpływ na wiele zespołów programistycznych powinny być podejmowane wcześniej, zwłaszcza na skalowalność i bezpieczeństwo. Decyzje takie jak dodanie dodatkowych języków do już umiędzynarodowionego produktu można odłożyć na później.
Po utworzeniu wstępnego projektu architekt współpracuje z każdym z zespołów i sprawdza ich projekty. Jeśli dla jednostki pracy wymagane są dodatkowe zmiany konstrukcyjne lub projektowe (takie jak sprint scrum), architekt dąży do tego, aby była ona dostępna do czasu rozpoczęcia tej jednostki pracy. Architekt jest również odpowiedzialny za przekazywanie wszelkich zmian zespołom lub interesariuszom, których to dotyczy.
źródło
Oświadczenie: Nie jestem zwinnym trenerem / architektem - to właśnie widziałem w zwinnych projektach, nad którymi pracowałem i myślę, że działa dobrze.
Nie sądzę, że jest to całkiem zdefiniowane przez Agile, jak robisz architekturę - zwinny koncentruje się na metodologiach i praktykach programistycznych. Z drugiej strony, UML to tylko język komunikacji z architekturą, która jest poza zwinna (używasz go, jeśli pasuje do twojego projektu i twojego zespołu).
Jedną z zasad architektury, która naprawdę ma zastosowanie, jest podjęcie decyzji w ostatnim możliwym odpowiedzialnym momencie - co oznacza, że będzie dobrze, jeśli nie podejmiesz wszystkich decyzji na początku projektu, zwłaszcza, że na tym etapie masz najmniej informacji. Z czasem możesz podejmować decyzje, które „rozwijają” architekturę. Tak, może to wyglądać na przeróbkę, ale wynika to również z faktu, że nauczyłeś się nowych rzeczy na temat środowiska, wymagań, co jest możliwe, czego nie ma itp.
Najważniejszą rzeczą, której chciałbyś uniknąć, jest zgnilizna architektury - gdzie kod tak naprawdę nie jest zgodny z żadną konkretną architekturą i jest tylko splątanym bałaganem. Główną różnicą w porównaniu do ewolucji architektury jest to, że w tym drugim przypadku podejmujesz okresowe świadome decyzje i dokumentujesz je z jasnych powodów, a następnie postępujesz zgodnie z tym, aby upewnić się, że kod podąża za nim.
źródło
Podczas programowania opartego na testach tworzysz kod testowy, który testuje twoje moduły w izolacji (= możliwie najbardziej niezależny od innych modułów)
Aby ułatwić tworzenie kodu testowego, wprowadzasz interfejsy do innych modułów, które można łatwo wyśmiewać.
W ten sposób jako efekt boczny automatycznie otrzymujesz architekturę, w której sprzężenie między modułami jest tak małe, jak to możliwe.
Moim zdaniem tdd to także dzieło architektoniczne.
źródło