Czy ponowne użycie oprogramowania wyklucza powtarzalność procesu


25

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?


Jeśli napisałeś fragment kodu, zasadniczo rozwiązałeś problem. Jeśli jesteś w tym dobry, ten kawałek rozwiązuje KLASĘ problemów. Jeśli jesteś naprawdę dobry, można go rozszerzyć na metaklasę problemów. A potem tracisz zainteresowanie: nie ma potrzeby doskonalenia jednego roweru, jeśli leżą nierozwiązane problemy projektowe. Dreszczyk rozwiązywania problemów wynika z świecenia nowych rzeczy, a nie ze szlifowania starych problemów do perfekcji.
Deer Hunter

2
dobre projekty oprogramowania „przenoszą” dużą powtarzalność na kontrolę jakości. Kiedy byłem testerem w 1,5-letnim projekcie, przeprowadzaliśmy cykle testowe przy cotygodniowych wydaniach „kontrolnych”, 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 powiedz mi firmę budowlaną, która zbudowała 500 mostów - wszystkie z tym samym zespołem
komara

@gnat - to doskonały wgląd i perspektywa, nad którą jeszcze się nie zastanawiałem. Inne aspekty SDLC stają się znacznie bardziej wydajne dzięki temu powtórzeniu.

1
@ GlenH7 rozszerzył ją na odpowiedź , głównie w celu dołączenia zdjęć mostów :)
skomentował

Ile problemów musiał rozwiązać Frank Lloyd Wright w swoich 1000 strukturach w porównaniu do Andersa Hejsberga podczas definiowania zaledwie 5 języków? Wright musiał podejmować decyzje dekretem, Anders musiał uzasadniać decyzje wielu osobom równie mądrym i kompetentnym jak on. Założę się, że Anders musiał rozwiązać wiele, wiele innych problemów. Tak więc twoje liczby rzucania w miksie zależą tylko od tego, co chcesz policzyć, a nie żadnych PRAWDZIWYCH liczbowo porównywalnych liczb. Więc podoba mi się pytanie, po prostu nie lubię rozumowania / przykładów inspirujących pytanie. Skuteczność SW znacznie się poprawiła na przestrzeni lat.
Dunk

Odpowiedzi:


10

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.


zależy od tego, co jest rzeczywiście ponownie wykorzystywane, może nawet spaść w CMMI Acquisition, tj. nie będzie prac rozwojowych.
imel96

1
Ale CMMI nie udało się w żaden znaczący sposób. Żadna z „zabójczych aplikacji” XXI wieku nie została zbudowana przez osoby zainteresowane matrycą dojrzałości CMMI. Niektórzy błyskotliwi ludzie wpadli na pomysł i wdrożyli go, a następnie zatrudnili więcej błyskotliwych ludzi, aby zwiększyć skalę rozwiązania. Przeciwnie, projekty, które prawdopodobnie w najmniejszym stopniu odpowiadały standardom takim jak CMMI, poniosły porażkę, np. Próba zbudowania nowej aplikacji płacowej przez Departament Obrony USA.
kevin cline

1
@kevincline Nie ma znaczenia, że ​​CMMI się udało lub nie. Siedząc w przemyśle lotniczym / obronnym, widzę CMMI w mojej organizacji i firmach, z którymi współpracujemy, których jesteśmy podwykonawcami i podwykonawcami. Chodzi mi jednak o to, że aby usprawnić proces, musisz zidentyfikować swoje procesy. CMMI to jedno narzędzie do tego. Tam są inni i możesz zdefiniować własne. Po utworzeniu procesów możesz je zdefiniować, zmierzyć i ulepszyć.
Thomas Owens

1
@Kevin: „Aplikacje Killera” są ze swej natury „poza głównym nurtem”. Nic więc dziwnego, że większość nowych i innowacyjnych prac powstała w wyniku eksperymentów i hakowania, a nie w drodze zdyscyplinowanego procesu. Chociaż „aplikacja zabójcy” zależy od własnej definicji. To aplikacja, która staje się modą, naprawdę jest „aplikacją zabójczą” lub jest programem DoD, który pozwala Jet Fighters bezpiecznie latać i zapobiega strzelaniu do sojuszników w bardziej „zabójczą aplikację”. Mody często nie wymagają żadnych umiejętności / innowacji (np. Pet rock, hula-hoop) ......
Dunk

... w tym wiele naprawdę popularnych „modnych” aplikacji. Natomiast duże projekty typu DoD prawie zawsze wymagają ogromnej ilości umiejętności i procesu. Również twój pogląd na porażkę CMMI prawdopodobnie mówi więcej o twoim doświadczeniu (lub jego braku) w branżach, które używają CMMI niż sama CMMI. CMMI nie jest doskonały i prawdopodobnie nawet niezbyt dobry, ale przynajmniej zmusza firmy do przynajmniej próby spisania i śledzenia procesu, a nawet próby jego ulepszenia. Jeśli to wszystko osiąga CMMI, oznacza to sukces.
Dunk

5

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.


Nie jest tak, że inne dyscypliny nie wykorzystują ponownie projektu, różnica polega na ilości ponownego użycia. Wszystkie wymienione obiekty muszą być skonstruowane fizycznie dla każdej instancji. Nie mogę na przykład po prostu skopiować i wkleić drzwi. Powtarzanie pochodzące z konstrukcji prowadzi do identyfikacji wydajności i ulepszeń, które nie są oczywiste na początku. Zbuduj zestaw szafek kuchennych, a odkryjesz nowe rzeczy między 1. a ostatnim. Masz rację co do ogólnej złożoności, ponieważ wirtualny charakter oprogramowania pozwala nam kumulować złożoność nieświadomie.

1
@ GlenH7 Chodzi o to, że tworzenie oprogramowania się nie buduje. Jego projektowanie. Budując, ciągle robisz to samo. Ale przy projektowaniu zawsze masz różne cele i problemy. Nie należy go porównywać z budową budynku, ale z tworzeniem jego planu.
Euforii

2
Nie jestem pewien, czy w pełni zgadzam się z twoją opinią na temat rozwoju oprogramowania. Rozwój oprogramowania to zarówno projekt, jak i konstrukcja. Konstrukcja powinna zapewniać sprzężenie zwrotne z projektem. Zarówno w dziedzinie analogowej, jak i cyfrowej dobrzy architekci „brudzą sobie ręce” i budują w celu uzupełnienia sprzężenia zwrotnego. Nawet jeśli skupimy się na samym projekcie, myślę, że powtórzenie projektu identyfikuje wydajność, która prowadzi do lepszego projektu. SW nie powtarza się tak jak inne pola. Każdy most wymaga modyfikacji z ogólnego podejścia dostosowującego go do miejsca, w którym się znajduje.

SW dev nie jest tak skomplikowane w porównaniu z projektem, który opracowałby architekt. Po prostu myślimy, że jest ciężko, ponieważ nie traktujemy oprogramowania jako właściwej dyscypliny inżynieryjnej i dlatego, że ciągle wymyślamy na nowo. Gdybyś tylko wiedział, co się w projektowaniu innych rzeczy, że można zauważyć, że większość oprogramowania powinny być banalne, ale robimy to trudne dla nas :(
gbjbaanb

Aby porównać do mostu - masz rację, mosty to rozwiązany problem. Chcesz nowego mostu, odkurzyć stare projekty i zrobić kilka drobnych poprawek, a masz nowy mostek (oczywiście przesadzam tutaj z prostotą). Dlaczego więc usługa internetowa nie jest podobnie zbudowana w oprogramowaniu? Dlatego oprogramowanie nie jest inżynierią IMHO, traktujemy to bardziej jako rzemiosło (lub sztukę), w którym każdy projekt jest niestandardową pracą.
gbjbaanb

2

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?


2

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.


Czy fakt, że większość programistów SW może sobie z tym poradzić, nie znając wewnętrznych zasad działania systemu, nie jest silnym wskaźnikiem intensywnego ponownego wykorzystania? Zabawne jest również to, że historie z projektów rządowych wydobywają się z tego brzmienia po prostu straszne, ale gdybyś miał jakąkolwiek wiedzę na temat pracy rządu, zrozumiałbyś, jak autor jest nieświadomy. 1500 młotków itp. ... Wszystko staje się zrozumiałe, gdy uznasz, że procesy rządowe wymagały 10 osób do przejrzenia i uzyskania konkurencyjnych ofert przed zakupem LUB po prostu nie przesuwało się środków między koszykami rachunkowymi.
Dunk

Nie pocieszam się wiedząc, że inżynier oprogramowania, który pracuje na „najbardziej złożonym” systemie komputerowym w samolocie , nie spał w ciągu 32 godzin. =)
RubberDuck

2

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”).
    http://upload.wikimedia.org/wikipedia/commons/thumb/0/0c/GoldenGateBridge-001.jpg/220px-GoldenGateBridge-001.jpg http://upload.wikimedia.org/wikipedia/commons/thumb/5/52/Ponte25Abril1.jpg/220px-Ponte25Abril1.jpg

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 ...


1
Doskonałe punkty i myślę, że ucieczki, które zostały następnie przywrócone do zautomatyzowanego zestawu testów, odzwierciedlają niektóre doświadczenia, o których mówię. Jeśli chodzi o twierdzenia o „tej samej drużynie”, wracam do doświadczenia Wrighta. Po wybudowaniu ponad 500 budynków był wspólnym elementem wszystkich tych obiektów. Ale o to chodzi i zgadzam się z niektórymi założeniami.

@ GlenH7 tak, wpływ powtórzeń był naprawdę głęboki i wykraczał daleko poza pakiety testowe. Wiedza gromadzona wszędzie tam, gdzie zdarzyło się powtórzenie - wiesz, wszystko zwykle osiąga optymalne wyniki po 20 ... 30 ... 50 razy. Przygotowania do punktów kontrolnych / nocnych, zgłaszanie błędów (i całe „życie błędów”), komunikacja między dev / QA / mgmt / sysadmins, dokumentowanie rzeczy itp. Skupiłem się tylko na powtarzalności, ponieważ nurkowanie w kwestiach gromadzenia wiedzy, które nastąpiło naturalnie, byłoby mieć efekt węża ognistego, prezentując moją rację
komara

-1

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.


1
Myślę, że dotykasz niektórych potencjalnie ważnych punktów, ale nie widzę, żeby łączyły się, aby odpowiedzieć na pytanie. I nie zgadzam się z twoim stosunkiem 99: 1 do ponownego użycia. Myślę, że rażąco przecenia to, ile powtórnie się zdarza. Nawet w przypadku oprogramowania, wskaźnik ponownego użycia nie jest tak wysoki.

-2

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.


3
Rozumiem niektóre punkty, które próbujesz przedstawić, ale opierają się one na domniemaniu i nieznajomości. Kiedyś tworzyłem dla komputerów mainframe i zapewniam cię, że tempo rozwoju było tak samo szybkie jak w systemach otwartych. Proces był inny, ale tempo było takie samo. Twoja odpowiedź byłaby silniejsza, koncentrując się na przekazywalnym składniku umiejętności i objaśniając potencjalne korzyści uzyskane w ten sposób.

Musisz spojrzeć na historię, na przykład nie pojawiały się nowe technologie na systemach mainframe dla CDC 6600 Kronos OS. Był w zasadzie statyczny przez 15 lat. Teraz sprawy toczą się znacznie szybciej i nie ma czasu na zdobycie głębokiej wiedzy zdobytej w ciągu 15 lat. Na przykład nie ma programistów Flash z 15-letnim doświadczeniem. Po ponownym przeczytaniu mojego postu stoję przy swoim oryginalnym poście.
Edward
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.