Właśnie przeczytałem opublikowany link do artykułu, muszę powiedzieć, że Fowler napisał kilka bardzo dobrych punktów i wiele rzeczy, które powiedział, opowiadam się z naszym zespołem od lat.
IMO, jeśli wykonasz jakiś porządny projekt, nie powinieneś wchodzić w sytuację, która byłaby uważana za ślepą uliczkę. Zawsze uważałem oprogramowanie za zbudowane z elementów . Nadal wierzę w pewne wstępne projekty, ale głównym celem nie jest zaprojektowanie całego produktu, ale zapewnienie ogólnej architektury / kierunku, aby Twój zespół mógł wyobrazić sobie wspólny obraz, nad którym wszyscy pracujemy. Jeśli masz kilka kostek i trójkątów, warto naszkicować, w jaki sposób zamek zostałby złożony, zanim zaczniesz po prostu uderzać klockami.
Ponieważ pochodzę z ziemi OO, dla mnie każdy blok jest klasą, a powierzchnia tego bloku jest interfejsem publicznym (co jest widoczne dla klas zewnętrznych lub pochodnych). Jeśli będziesz przestrzegać dobrych zasad SOLID, upewnisz się, że każdy blok jest wyjątkowo prosty i ma intuicyjny interfejs publiczny. Wracając do mojej analogii, chcesz mieć pewność, że kod tworzy tylko proste kształty. Za każdym razem, gdy tworzysz zbyt złożone klasy (wiele funkcji, wiele zmiennych), tworzysz kształty, które trudno wykorzystać ponownie, gdy zmieniają się wymagania.
Zgadzam się z Fowlerem, że największym ryzykiem / wyzwaniem związanym z projektowaniem ewolucyjnym jest pozostawienie decyzji projektowych czasowi kodowania i oczekiwanie od każdego dewelopera podjęcia takich decyzji. W tym miejscu system może się zepsuć, jeśli nie masz odpowiednich mechanizmów sprzężenia zwrotnego. Ilekroć pojawia się prośba o nową funkcję, niezwykle kuszące jest po prostu znalezienie funkcji, którą należy rozszerzyć, umieszczenie w niej jakiegoś warunku i dodanie do niej całej wiązki kodu. Czasami może to być wszystko, czego potrzeba, ale jest to również (IMO) najczęstsza praktyka prowadząca do ślepych zaułków. Nie ma to nic wspólnego z projektowaniem ewolucyjnym. To się nazywa „brak projektu”.
Tak długo, jak poświęcisz czas, aby się cofnąć i powiedzieć: poczekaj chwilę, ta klasa ma już 15 zmiennych składowych, pozwól mi wyodrębnić 6 z nich i umieścić je w swojej własnej, zamkniętej klasie, twoje oprogramowanie będzie się składać z bardzo lekkiego - lekkie, elastyczne i wielokrotnego użytku bloki konstrukcyjne. Jasne, że jeśli pojawią się premierzy i zmienią o połowę wymagania dotyczące produktów, być może będziesz musiał usunąć niektóre swoje klocki, odłożyć je z powrotem na półkę i dobrać nowe (tak jak podczas budowania zamku, nie możesz użyć wszystkich twoje cylindry). Ale w tym momencie to tylko część robienia interesów. Wymagania się zmieniły i zachowując elastyczność i modułowość kodu, powinieneś być w stanie zmienić swój produkt, aby dostosować go do nowego kierunku działalności.
Wierzę, że to ewolucyjne podejście do projektowania działa na każdym poziomie umiejętności inżyniera. Osobiście tworzyłem oprogramowanie przez bardzo długi czas i zanim nasz zespół przeszedł na zwinną metodologię, byłem odpowiedzialny za wysyłkę kilku głównych komponentów z mojego komputera deweloperskiego prawie bezpośrednio do klienta przy prawie żadnej kontroli jakości. Jednocześnie elementy te zawsze były elastyczne i łatwe w utrzymaniu.
Próbuję tylko powiedzieć, że uważam się za względnie przyzwoitego w projektowaniu oprogramowania. Jednocześnie, jeśli poprosiłeś mnie o napisanie 100-stronicowego dokumentu projektowego, przekazanie go programistowi i oczekiwanie, że zadziała, prawdopodobnie nie mógłbym zaprojektować się z papierowej torby. Kiedy zaczynałem pracę, czasami szkicowałem kilka diagramów podobnych do UML (bardzo uproszczonych, ale nie w pełnym języku), ale kiedy zaczynam kodować, refaktoryzowałem według potrzeb, a mój końcowy kod nigdy nie wyglądałby tak, jak pierwotnie narysowałem. Nawet jeśli spędzam miesiąc lub dwa, zastanawiając się nad każdym najmniejszym szczegółem, nie mogę sobie wyobrazić, że ktoś inny może wziąć moje diagramy i wymyślić solidne oprogramowanie bez zmiany projektu podczas kodowania.
Na drugim końcu spektrum, obecnie w moim zespole (teraz zwinny i w pełni to popieram) mamy kilku facetów, którzy dołączyli do nas z zagnieżdżonej ziemi, gdzie zajmowali C tylko przez ostatnie 15 lat. Oczywiście pomogłem przy wstępnym planowaniu i układaniu klas, ale zadbałem również o regularne przeglądy kodu i sesje burzy mózgów, podczas których omawiamy zastosowania SOLID i zasad projektowania. Stworzyli kod spaghetti, który sprawił, że trochę się skrzywiłem, ale po lekkim trąbieniu zacząłem refaktoryzować to, co już zostało wyprodukowane, a zabawne jest to, że jeden z nich wrócił do mnie kilka dni później i powiedział: Nienawidzę żeby to powiedzieć, ale po przeniesieniu tego kodu wygląda to o wiele bardziej czytelnie i zrozumiale. Ślepy zaułek odwrócony. Punkt I Staram się, aby nawet ktoś, kto jest zupełnie nowy w OO, mógł stworzyć całkiem przyzwoity kod, o ile ma mentora z większym doświadczeniem, aby przypomnieć mu, że „projekt ewolucyjny” to nie to samo, co „brak projektu”. I nawet niektóre z jego „bardziej złożonych” klas nie są aż tak przerażające, ponieważ każda klasa nie ma tak dużej odpowiedzialności (tj. Niezbyt dużego kodu), więc najgorsze staje się gorzej, jeśli ta klasa „ślepych zaułków”, my rzuć to i napisz klasę zastępczą, która ma ten sam publiczny interfejs (do tej pory nigdy nie widziałem potrzeby takiej nieprzewidzianej treści w żadnym napisanym artykule i robiłem recenzje kodu dwa razy w tygodniu).
Na koniec jestem również zwolennikiem dokumentów projektowych (przynajmniej w warunkach biznesowych mojego obecnego zespołu), ale głównym celem naszych dokumentów projektowych jest Pamięć Organizacyjna , więc rzeczywiste dokumenty są pisane po wygenerowaniu kodu i odnowione. Przed kodowaniem generalnie mamy szybką (czasem nie tak szybką) fazę projektowania, w której szkicujemy klasy na serwetkach / mspaint / visio i zawsze przypominam ludziom, że ta faza tworzy ścieżkę do naśladowania, a nie plan, a kiedy zaczynają kodować, wszystko, co nie ma sensu, powinno zostać zmienione. Nawet z tymi przypomnieniami nowi faceci starają się przywrócić kod do oryginalnego projektu, bez względu na to, jak nienaturalnie wydaje się im nawet. Zwykle pojawia się to w recenzjach kodu.
Dang, dużo pisałem. Przepraszam za to.