Czy ponowne użycie oprogramowania wyklucza powtarzalność procesu

Ponowne użycie kodu jako problem

Zastanawiałem się nad tym pytaniem dotyczącym dostarczania oprogramowania i ciągle wracałem do kwestii powtarzalności i / lub odtwarzalności . Mają znaczenie, ponieważ jeśli nie powtórzysz projektu, trudniej jest ulepszyć proces użyty do jego zbudowania. Inżynieria obejmuje ciągłe doskonalenie procesów związanych z projektowaniem i budową w celu uzyskania projektów wyższej jakości.

Oprogramowanie może w dużym stopniu polegać na ponownym użyciu ze względu na swoją postać cyfrową. Zamiast przepisać moduł, po prostu wywołujemy go ponownie lub kopiujemy do innego systemu. Niektóre przykłady to uwierzytelnianie / logowanie lub funkcja logowania. Istnieje wiele dobrze znanych przykładów dla tych kategorii, a tradycyjną mądrością jest ponowne wykorzystanie tego, co istnieje, zamiast rozwijania własnych.

Niektóre porównania do innych dyscyplin

Budowa

W przeciwieństwie do tego, budowa systemów fizycznych (budynków, mostów) nie jest tak bliska, jak wielokrotnego użytku. To prawda, że ​​plan domu może być wielokrotnie użyty do zbudowania tej samej kopii domu, ale konstrukcję należy wykonać za każdym razem. Wytnij i wklej nie działa tak w świecie analogowym. Plany mostów są mniej przydatne niż domy, ponieważ warunki na miejscu będą się różnić.

Mistrzowie budownictwa to znani eksperci, którzy zaprojektowali i / lub zbudowali dziesiątki, setki lub tysiące rzeczy na swoim terenie. Na przykład Frank Lloyd Wright , światowej sławy architekt i projektant designed more than 1,000 structures and completed 532 works. Porównaj to z Anderem Hejlsbergiem, który zaprojektował „tylko” pięć języków (Turbo Pascal; Delphi; J ++; C #; Maszynopis). Pod wieloma względami jest to niesprawiedliwe porównanie, ponieważ domeny są różne. Ale na szerokim poziomie, wymierna produkcja od dwóch bardzo inteligentnych ludzi jest zupełnie inna.

Sztuki walki

Artyści sztuk walki powiedzą, że opanowanie ruchu pochodzi tylko z tysięcy powtórzeń. Po włożeniu dużej części tych powtórzeń wielu artystów sztuk walki jest zaskoczonych tym, jak wcześniej postrzegana jako skomplikowana kata lub forma stała się prosta. Instruktorzy tych uczniów zauważą również, w jaki sposób ruch staje się bardziej płynny i celowy, a także ma ekonomię ruchu. Podobnie doświadczeni artyści sztuk walki są w stanie szybciej zbierać bardziej złożone kata niż mniej doświadczeni studenci. Doświadczenie z powtórzeń dało im strukturę lub proces, który pozwala im szybciej się uczyć.

Obróbka drewna

Stolarze doświadczają podobnej transformacji. Stolarze hobbystów zawsze odwołują się do pierwszego projektu, który wymagał wielu szuflad. Po zakończeniu projektu zyskują nowe uznanie dla wydajności, jaką wytwarzają linie montażowe. Istnieją inne korzyści, takie jak lepsze zrozumienie, w jaki sposób układać części szuflad na arkuszu blachy, aby zmaksymalizować wykorzystanie drewna. W porównaniu z hobbystami, profesjonalni stolarze są w stanie szybciej projektować, uruchamiać i konstruować przedmioty, które wielokrotnie wytwarzali. Zyskują także umiejętność dostrzegania nieodłącznych problemów w projektowaniu innej osoby, które popełniły ten błąd w swojej pracy.

Czy ponowne użycie oprogramowania uniemożliwia programistom uzyskanie większej biegłości?

Pod wieloma względami projektowanie i tworzenie oprogramowania jest zawsze nowe. Nie powtarzamy wcześniejszych prac, ponieważ jeśli możemy ponownie użyć modułu, biblioteki lub systemu, robimy to. Preferencyjnie rozszerzymy istniejący system przed przepisaniem całej rzeczy od zera. Ale powtarzanie pozwala nam znaleźć efektywność w projektowaniu i konstrukcji. Każdy, kto ćwiczy sport lub aktywność fizyczną, powie ci, że powtórzenie jest kluczem do zostania dobrym praktykiem.

Moje pytanie: czy możliwość ponownego wykorzystania oprogramowania zapobiega koniecznej poprawie procesu i wydajności wynikającej z powtarzania projektu?

Możliwość ponownego wykorzystania oprogramowania nie uniemożliwia poprawy procesu.

Jeśli myślisz o procesach związanych z budowaniem oprogramowania - opracowywaniem wymagań, projektowaniem systemu, wdrażaniem systemu, wdrażaniem systemu, zarządzaniem wymaganiami, zarządzaniem konfiguracjami, weryfikacją i weryfikacją produktu pracy, śledzeniem zmian i wieloma innymi (zobacz Obszary procesu CMMI dla jednego możliwego podziału kluczowych działań w rozwoju oprogramowania) - są one powtarzane w każdym projekcie, niezależnie od tego, ile masz ponownego wykorzystania. Ponadto każdy z nich ma pewien rodzaj miar ilościowych i jakościowych, które można wykorzystać do ustalenia, jak dobry jest ten konkretny proces lub działanie, a co za tym idzie, jak dobry jest proces rozwoju jako całości.

Z jednej strony ekstremum możemy założyć solidną linię oprogramowania. Z drugiej strony możesz założyć rozwój od podstaw. Nadal istnieje potrzeba wykonywania wszystkich tych procesów w różnym stopniu, chociaż mogą one zachodzić w różnym tempie, a może nawet w różnych sekwencjach. Na przykład przy wysokim stopniu ponownego wykorzystania większy procent przydzielonego czasu można przeznaczyć na działania integracyjne i weryfikacyjne / walidacyjne na poziomie systemu (wymagania V&V, testy integracyjne, testy systemowe, testy akceptacyjne). Dzięki nowym wysiłkom rozwojowym może być potrzebny większy procent czasu przy projektowaniu i wdrażaniu. Tak długo, jak co najmniej raz wykonujesz proces w trakcie projektu, możesz go zmierzyć (ilościowo i jakościowo). Po dokonaniu korekt i zobaczeniu, jak wpływają one na pewną miarę obszaru procesu lub ogólnej zdolności dostarczania oprogramowania,

Kluczem do udoskonalenia procesu jest logiczny podział działań i procesów, ustalenie sposobu ich pomiaru (najlepiej konsekwentnie) oraz zrozumienie tych pomiarów w celu wprowadzenia zmian w procesie pod koniec. Nie chodzi o powtarzanie projektu, ale o konsekwencję w powtarzaniu procesu.

Myślę, że pomysł, że inne dziedziny inżynierii nie wykorzystują ponownego użycia, jest błędny. Nawet podczas projektowania budynków / maszyn nadal masz komponenty, które są wykorzystywane w wielu innych projektach. Na przykład, czy projektujesz własne śruby? Silniki? Drzwi czy okna? Oczywiście nie. Są one często projektowane przez różnych ludzi, którzy następnie używają ich w różnych produktach. I są one często standaryzowane, co sprzyja jeszcze większemu wykorzystaniu.

Myślę, że problem lubi złożoność. Po prostu nie można porównać złożoności nawet najbardziej skomplikowanych budynków ze złożonym oprogramowaniem. Jest ogólnie przyjętym pomysłem, że złożoność oprogramowania utrudnia dostęp ze strony inżynieryjnej. W momencie, gdy masz proces, który pozwala Ci tworzyć oprogramowanie o akceptowalnej jakości, przekonasz się, że złożoność oprogramowania, które musisz stworzyć, przeskakuje według wielkości. Dlatego nie można użyć tego procesu. Gdybyśmy musieli wielokrotnie powtarzać część oprogramowania, dopóki nie będziemy zadowoleni z rezultatu, nigdy nie skończymy tego oprogramowania.

Dlatego promowany jest czysty kod. Możliwość zmiany przeszłego kodu na podstawie nowych doświadczeń można uznać za formę ponownego wykorzystania projektu. Dlatego zamiast wielokrotnie tworzyć różne oprogramowanie, dokonujemy refaktoryzacji i udoskonalania pojedynczego oprogramowania, ponownie wykorzystując nowe doświadczenia i projektując stare problemy. Wszystko podczas próby uczynienia oprogramowania tym samym.

Oprogramowanie jest inna niż w większości innych dyscyplin, więc ekonomia gdzie najlepiej spędzić nasz czas jest często inna.

W budownictwie poświęcasz pewną ilość czasu i pieniędzy na plan (a oprogramowanie jest o wiele bardziej podobne do tworzenia planu niż budowania budynku), a następnie, mówiąc z grubsza, o wiele więcej na faktycznym budowaniu go raz lub więcej razy. Warto więc włożyć dużo pracy w przygotowanie planu. Bardziej konkretnie na twoje pytanie - warto powtórzyć wysiłek zrobienia tego od zera, aby produkt końcowy był nieco lepszy.

W oprogramowaniu, gdy masz plan, zbudowanie produktu jest o wiele tańsze niż wykonanie projektu. Przynajmniej przez większość czasu - jeśli oprogramowanie zostanie wbudowane w rozrusznik serca, pod pewnymi względami jesteś znacznie bliżej sytuacji konstruktora mostów. Ogólnie jednak ponowne użycie oprogramowania może zaoszczędzić 90% kosztu największej pozycji budżetowej, w porównaniu z 90% znacznie mniejszej pozycji budżetowej na budowę mostu. Ponowne użycie wygrywa znacznie częściej.

Jeśli chodzi o produktywność - kiedy budujesz, powiedzmy, most, napotykasz naprawdę poważne ograniczenia w świecie rzeczywistym. Wyobraź sobie, że architekci otrzymali duże sumy pieniędzy za zaprojektowanie mostów dla ogromnych gier online dla wielu graczy, w których koszty budowy były bliskie zeru, a ograniczenia znacznie niższe niż w prawdziwym świecie. Zaprojektowaliby mosty, które są dziwacznie złożone według rzeczywistych standardów mostów. Faza projektu może potrwać nieco dłużej.

Ponadto istnieje ograniczona liczba mostów do zbudowania, a ponieważ projekt jest niewielką częścią kosztów, możesz zapłacić za najlepsze, a kilka z najlepszych może wykonać większość projektu. Istnieją setki tysięcy programistów i zasadniczo wszyscy mają olbrzymie zaległości, które mogliby zrobić, gdyby mieli czas. Nie znajdziesz jednego faceta, który zrobiłby ogromną część tego wszystkiego - to trochę zaskakujące, że są ludzie, którzy tak naprawdę się do siebie zbliżają.

Twoim prawdziwym punktem wydaje się być to, że możemy coś stracić przez ponowne użycie zamiast próbować powtarzać i poprawiać rzeczy. Myślę, że masz rację. Problem polega na tym, że choć najprawdopodobniej globalnie bardziej efektywne byłoby przepisanie niektórych podstawowych rzeczy i próba ich ulepszenia, każdy, kto je podejmie, ponosi całe ryzyko i prawdopodobnie nie tyle nagrody. (Istnieje również ogromny praktyczny problem piekła zależności, który prawdopodobnie zabiera część wygranej z przepisywania rzeczy, ale nie do tego stopnia, że ​​nie byłoby to opłacalne, przynajmniej patrząc na globalny obraz. Prawo autorskie i patenty również mogą zmusić proponowany wysiłek przeprojektowania odgryźć sporo pracy związanej z przepisywaniem, aby przerobić mniejsze fragmenty istniejącego kodu).

Jeśli chodzi o uczenie się na podstawie powtórzeń - we wszystkich dyscyplinach dzieje się to mniej w projektowaniu niż w budownictwie, ponieważ jest mniej powtórzeń, więc mniej szans na naukę i być może mniejsze korzyści. Ponadto proces projektowania prawdopodobnie po prostu nie jest tak powtarzalny. To trochę jak proces pisania powieści. Dobry proces może prawie na pewno pomóc, a oprogramowanie jest na ogół znacznie bardziej oparte na współpracy niż powieść, ale powtarzanie procesu, gdy celem jest wynalezienie czegoś nowego, jest problematyczne. Nawet powieściopisarze uczą się z przeszłości, bardzo, ale powtarzalny proces jest drugorzędnym czynnikiem twórczych przedsięwzięć. A jeśli jakakolwiek część tworzenia oprogramowania jest naprawdę powtarzalna, dlaczego komputer tego nie robi?

Czy możliwość ponownego wykorzystania oprogramowania zapobiega koniecznej poprawie procesu i wydajności wynikającej z powtarzania projektu?

Nawiasem mówiąc, przez ostatnie 17 lat pracowałem jako inżynier systemów i oprogramowania w tym samym dużym projekcie (myślę o referencji do Airbusa A380 w twoim pierwszym łączu) w branży lotniczej, chociaż moje obowiązki spoczywają w sektorze samolotów wojskowych. Historie takie są w zasadzie czystą fikcją i naprawdę naprawdę zabawne, gdy masz wgląd w nie.

Ale w przypadku twojego krótkiego i zwięzłego pytania: z mojego doświadczenia powiedziałbym, że tak i nie.

Pozwól mi najpierw powiedzieć, że jestem za recyklingiem oprogramowania we wszystkich formach (no może nie wszystkie ...). Zalety ponownego użycia niemal wszystkiego, od wycinków i wklejonych fragmentów kodu, po całe moduły kodu i biblioteki funkcji, są ogólnie o wiele lepsze niż zawsze zaczynać od początku (trochę popchnąć).

Minusem jest, jak zauważyłeś (lub przynajmniej wnioskujesz), że kiedy dodajesz funkcjonalność po prostu łącząc dany zestaw komponentów (i tak, upraszczam to do skrajności), tak naprawdę nie ewoluujesz jako programista, inżynier lub cokolwiek innego.

Patrząc na otaczających mnie inżynierów oprogramowania, wiem z długiego doświadczenia, że ​​większość z nich nie wie, a co gorsza - nie są zainteresowani nauką, nic o konstruowanym przez nas produkcie poza absolutnym minimum, które muszą wytworzyć dokument lub fragment kodu, do którego są przypisani.

Nie podchodzę tutaj do tematu, ale mam na myśli to, że gdy programiści nie muszą dowiedzieć się, do czego naprawdę będą budować kod, który budują, i nie muszą uczyć się wewnętrznego funkcjonowania systemu, ponieważ mogą po prostu ponownie wykorzystaj już napisane i przetestowane komponenty, wtedy większość z nich po prostu nie będzie tego robić.

To prawda, że ​​wynika to również z innych okoliczności, takich jak to, że budowany przez nas produkt jest niezwykle złożony i jedna osoba nie byłaby w stanie dowiedzieć się wszystkiego (a ja tylko mówię o jednym z komputerów w samolocie - najbardziej skomplikowany, ale nadal).

Gdyby nasi inżynierowie oprogramowania nie mieli możliwości ponownego wykorzystania tak dużej ilości kodu, jestem przekonany, że ogólnie byliby lepsi w swoim zawodzie, a znacznie większe zasoby w szczególności dla projektu.

Och, i pewnie zauważyłeś, że dużo tu o nich mówię . Oczywiście jestem również wśród tych inżynierów oprogramowania. Wyjątkiem jest to, że wydaje mi się, że jestem o wiele bardziej dociekliwy i chętny do uczenia się nowych rzeczy niż inni :-) W obliczu nowego zadania zawsze biorę na siebie odpowiedzialność, aby dowiedzieć się o tym jak najwięcej, zarówno w forma faktów i studiowanie kodu źródłowego (tak, to też mi się podoba).

Ach - cholera, znów śledzone z boku ... Moją wymówką jest to, że nie spałem przez 32 godziny, więc moja zdolność skupiania się jest trochę ... co mówiłem?

Jeśli ktoś nadal czyta, mój wniosek jest następujący:

Tak , zbyt częste ponowne użycie oprogramowania powoduje, że inżynierowie oprogramowania mają mniejszą wiedzę, co powoduje, że są znacznie mniej wydajni, gdy faktycznie muszą wiedzieć, jak to działa. Analiza problemu jest dobrym przykładem, a nawet po prostu jest w stanie stwierdzić, czy sugerowane rozwiązanie projektowe jest wykonalne. I oczywiście usprawnienie procesu jest również trudniejsze do osiągnięcia, gdy tak naprawdę nie wiesz, co robisz :-)

i Nie , ponowne używanie oprogramowania ostrożnie może potencjalnie dać ci dużo czasu na przemyślenie i zaplanowanie ulepszeń procesu.

Jak wskazano w zaakceptowanej odpowiedzi w innym pytaniu dla programistów, należy zachować ostrożność przy analogiach z budową:

zalecanym lektorem jest analogia budowy oprogramowania jest zepsuta

oprogramowanie jest często porównywane do konstrukcji. Niestety ta analogia jest błędna, a wnioski wyciągnięte z branży budowlanej są podejrzane ...

Zauważyłem, że dobre projekty oprogramowania „przenoszą” wiele powtarzalności na zapewnienie jakości.

Kiedy byłem testerem w 1,5-letnim projekcie, przeprowadzaliśmy cykle testowe przy cotygodniowych wydaniach „kontrolnych”, łącznie około 70 razy w całym projekcie. To było… dość powtarzalne, delikatnie mówiąc (niewiele rzeczy się zmienia w ciągu tygodnia). Testowanie nocnych wersji było, oczywiście, jeszcze bardziej powtarzalne - około 500 razy w ramach projektu (kilka zabawnych błędów showstopper było zbyt rzadkich, aby coś zmienić).

Teraz, kierując się tą „podejrzaną” analogią, powiedz mi firmę budowlaną, która zbudowała 500 mostów - wszystkie z tym samym zespołem.

• Idąc dalej, powiedz mi firmę, która używała głównie tych samych cegieł i żelaza na każdym z nowych mostów (tutaj, odnoszę się do faktu, że testowane wersje miały w większości te same fragmenty kodu dzień po dniu, tydzień po tydzień - „niewiele się zmienia”).
  

Mistrzowie budownictwa to znani eksperci, którzy zaprojektowali i / lub zbudowali dziesiątki, setki lub tysiące rzeczy na swoim terenie.

W porządku, po przytoczonym powyżej wyjaśnieniu powtarzalności, mogę powiedzieć co? Wówczas nasza mała, niezbyt specjalna grupa testerów zweryfikowała, patrz powyżej („około 500”) setki rzeczy w naszej okolicy.

Jeśli chodzi o twórców projektów, zbudowali dosłownie („kompilacje nocne”) - zobacz, słowo jest takie samo, a znaczenie jest właściwe w tym kontekście - setki rzeczy w ich obszarze.

Jeśli ktoś chce kontynuować tę „podejrzaną” analogię do „tysięcy rzeczy”, kwoty te nie są niczym spektakularnym w rozwoju oprogramowania, jeśli spojrzymy na właściwe rzeczy.

• Jako przykład, kolejny z moich poprzednich projektów (znowu nic spektakularnego, raczej regularny), tym razem w roli deweloperów, trwa już ponad 5 lat (8 głównych wydań, kilkadziesiąt mniejszych). Były podobne cotygodniowe punkty kontrolne ( 5x52~=250z nich), podobne nocne wydania ( 5x365~=1800z nich) i podobnie, te same zespoły projektantów / QA pracujące nad nimi. Dzień po dniu, tydzień po tygodniu, miesiąc po miesiącu, głównie powtarzające się rzeczy (niewiele zmian między dwiema nocnymi wersjami) - zgodnie z obietnicą, w zakresie tysięcy razy (1800).

Dłużej żyjące projekty, takie jak Windows, Java lub AutoCAD mogą trwać 10, 20, 30 lat, co z łatwością pozwala na powtarzanie tylu „tysięcy” nocnych wersji i testów nocnych, jak to możliwe.

Koncepcja przejścia na powtarzalność do QA staje się jeszcze bardziej widoczna dzięki ciągłej integracji ...

praktykę ... łączenia wszystkich kopii roboczych programistów ze wspólną linią główną kilka razy dziennie ... CI można postrzegać jako intensyfikację praktyk okresowej integracji.

Oprócz zautomatyzowanych testów jednostkowych, organizacje używające CI zwykle używają serwera kompilacji do wdrażania ciągłych procesów stosowania kontroli jakości w ogóle - małe nakłady pracy, często stosowane. Oprócz przeprowadzania testów jednostkowych i integracyjnych takie procesy uruchamiają dodatkowe testy statyczne i dynamiczne, mierzą i profilują wydajność, wyodrębniają i formatują dokumentację z kodu źródłowego oraz ułatwiają ręczne procesy kontroli jakości. To ciągłe stosowanie kontroli jakości ma na celu poprawę jakości oprogramowania i skrócenie czasu jego dostarczania, zastępując tradycyjną praktykę stosowania kontroli jakości poukończenie całego rozwoju. Jest to bardzo podobne do pierwotnego pomysłu częstszej integracji w celu ułatwienia integracji, stosowanej tylko w procesach zapewniania jakości ...

Powtarzalność jest tam, tyle, ile można sobie wyobrazić.

Dzięki częstej / ciągłej kontroli jakości rzeczy, które się nie udają, szybko wracają do programistów, którzy są zmuszeni do powtarzania prób zrobienia tego dobrze, dopóki testy nie zakończą się pomyślnie. W pewnym sensie ten cykl powtarzania aż do przejścia przypomina kod kodu ,

ćwiczenie w programowaniu, które pomaga programistom doskonalić swoje umiejętności poprzez ćwiczenie i powtarzanie ...

Niektóre z twoich wypowiedzi są prawdziwe: np. Biblioteki rozwiązują funkcje nierozwiązane przez języki wysokiego poziomu, które rozwiązują problemy nierozwiązane przez asembler, które rozwiązują problemy nierozwiązane przez kod maszynowy. Kiedy wywołujesz System.out.println () w java, tracisz z oczu sposób, w jaki procesor wysyła dane do urządzenia.

Więc tak, tracisz coś. Zyskujesz możliwość skupienia się na nierozwiązanych problemach. Być może teraz musisz zanurzyć się w innych aspektach technologii (np. Funkcjonowanie sieci), aby rozwiązać problem. Ale nie musisz stać się ekspertem w czytaniu języka maszynowego, gdy wszystko, co chcesz zrobić, to zbudować stronę internetową.

W ten sam sposób budowniczowie mostów za każdym razem rozwiązują nieco inny problem (inna rzeka). Nie martwią się tym, jak stworzyć stalowe belki o określonej wytrzymałości na rozciąganie lub jak obrabiać śruby z określoną tolerancją. Pozostawiają to specjalistom, którzy rozwiązali ten problem.

Przyjrzyj się uważnie, a zobaczysz, że całe nasze społeczeństwo i infrastruktura zbudowane są w 99% z ponownego wykorzystania i tylko 1% z prawdziwych postępów. Większość nowych rzeczy to tylko stare rzeczy z dodanym lub usuniętym dodatkiem. Jest to nagromadzenie ludzkiej wiedzy. Możesz pisać kod w języku wysokiego poziomu z przyzwoitymi bibliotekami, ponieważ ktoś wymyślił wszystkie zadziwiająco skomplikowane rzeczy wymagane do osiągnięcia tego punktu. Pozwala rozwiązać nowe i ciekawe problemy.

Aby połączyć to wszystko razem i odpowiedzieć na komentarze: Nie musisz rozwiązywać problemów, które zostały już rozwiązane, aby rozwinąć biegłość. Co więcej, znaczna część tego, co robisz, będzie na nowo wymyślać koło. Krótko mówiąc, odpowiedź brzmi „nie” - nie trzeba ponownie wdrażać funkcji bibliotek, aby uzyskać biegłość. Istnieje wiele możliwości, niektóre z nich są dostępne, niektóre z nich są kreatywne, aby doskonalić swoje rzemiosło.

Chodzi o zasoby. Wiele lat temu, jeśli opracowywałeś projekty oprogramowania dla dużych komputerów mainframe, mogą one istnieć przez około 15 lat w większości ze statycznym środowiskiem programistycznym. Program FORTRAN napisany do obliczania listy płac lub program COBOL był doskonalony przez dziesięciolecia, ponieważ był stale używany. Były zasoby, aby zobaczyć, jak można to poprawić. Nie mamy już takiego powolnego środowiska, aby dostroić i dopracować umiejętności konkretnego projektu. Ale bierzemy umiejętności i dostosowujemy je do przyszłych zasobów projektu, na które pozwalają. Ale w końcu stanie się wyborem pieniędzy wydanych na nowy projekt, aby wykonać pracę lub wykonać nową pracę z dużą ilością pozłacania. Pozłacanie projektu oznacza ulepszenie go do n-tego stopnia i dodanie ton dzwonków i gwizdów, nawet jeśli użytkownik tego nie zrobił

Najlepsze, co możemy zrobić, to spojrzeć na ogólny projekt nowego projektu i zobaczyć, jak można go ulepszyć w oparciu o wcześniejsze doświadczenia zespołu. Ale prawdziwy architekt oprogramowania musi mieć wizję tego, co faktycznie uważa się za ulepszenie projektu w celu poprawy umiejętności, a nie po prostu uwzględnienie najnowszego modnego hasła w rozwoju, takiego jak Agile, OOP itp.