W przypadku poprzedniego ujęcia zobacz wersję 1 tej odpowiedzi . Jednak komentarze i zmiany do pytania wyjaśniają, czego szuka pytanie, i pozwalają mi być bardziej klarownym.
Tak, inżynieria oprogramowania oparta na dowodach (EBSE) to coś. Wydaje się, że podjęto kilka wysiłków w kierunku baz danych EBSE, takich jak ten na Durham University i SEED, który został zapoczątkowany przez profesora z Cal Poly . Wszystkie te wysiłki, a także te omówione w wielu artykułach, które można znaleźć za pośrednictwem serwera IEEE Xplore lub biblioteki cyfrowej ACM(wymagana subskrypcja lub zakup wielu artykułów w obu), oparte są na medycynie opartej na dowodach. Zapewniają przegląd literatury opublikowanych danych empirycznych (obserwacyjnych i eksperymentalnych). W rzeczywistości uwzględnienie „przeglądu literatury” w ciągu wyszukiwania dowolnej wyszukiwarki publikacji dostarcza informacji na większość tematów - ponad 14000 trafień w ACM i ponad 1000 w bazie danych IEEE (przy ograniczeniu do tylko zagadnień komputerowych).
Patrząc na ogólne typy tematów omawianych w tych bazach danych EBSE i przeglądach literatury, widzę wspólny wątek - są one zwykle niezależne od technologii. Wydaje się, że nacisk kładziony jest głównie na proces i metodologię, a nie na konkretne narzędzia wykorzystywane do przeprowadzania inżynierii oprogramowania.
Tak więc ta koncepcja istnieje w inżynierii oprogramowania. Academia jest świadoma koncepcji opartej na dowodach i może z powodzeniem zastosować ją w inżynierii oprogramowania.
W szczególności pytanie dotyczy zastosowania technik EBSE do wyboru paradygmatu wydaje się trudne ze względu na samą liczbę zmiennych, które wymuszają przyjęcie założeń, a także ograniczają możliwość powtórzenia eksperymentu lub obserwacji. Jest powiedziane wprost w pytaniu - „jaki paradygmat wyłania się jako„ właściwa odpowiedź ”może zależeć od tego, na jakie wskaźniki zwraca uwagę dane badanie, na jakich warunkach badanie jest stałe lub różne, i bez wątpienia także od innych czynników” . Chociaż nie oznacza to, że badanie, który paradygmat jest „najlepszy” w danej sytuacji, sprawia, że jakikolwiek przegląd literatury tych dokumentów jest niezwykle trudny do uzupełnienia i nadal wyodrębnia informacje.
Zdecydowanie nie ma rozwiązania „obróć korbą” do wyboru paradygmatu.
Biorąc pod uwagę paradygmat programowania, można znaleźć badania w różnych akademickich i branżowych bazach danych na temat tego, jak ten paradygmat wpływa na różne aspekty rozwoju oprogramowania - jakość, wady, wydajność itd. - w różnych specyficznych warunkach, począwszy od wiedzy i doświadczenia zespół do domeny problemu. Każdy rygorystyczny dokument powinien jasno określać warunki, w jakich dane były gromadzone, i założenia. Problemem staje się próba wyodrębnienia czynników, które czynią go dobrym w każdym z tych warunków.
Naukowo istnieją pewne stwierdzenia, które można łatwo zbadać. Na przykład stwierdzenie, że paradygmat funkcjonalny dobrze nadaje się do aplikacji wymagających współbieżności, wynika z twierdzenia Churcha-Rossera . Z tego powodu jest prawdopodobne, że system oprogramowania napisany w języku funkcjonalnym będzie miał mniej wad związanych z współbieżnością niż ten sam system napisany w języku proceduralnym lub obiektowym.
Jednak z praktycznego punktu widzenia zespół programistów nie zawsze może stosować „najlepsze” narzędzie lub technikę do pracy tylko dlatego, że wskazują na to badania. Chociaż dążymy do produkcji systemów oprogramowania najwyższej jakości, działamy w ramach ograniczeń. Często widzę, że ograniczenia te są zminimalizowane (lub nawet usunięte z równania) podczas omawiania skuteczności dowolnej metodologii.
Jako praktykujący, kiedy biorę udział w wyborze technologii do zastosowania, staram się znaleźć najlepsze możliwe narzędzia. Ale potem ograniczam się do tego, co jest znane i dobrze rozumiane przez zespół, który mam. Wracając do mojego poprzedniego przykładu, jeśli mam zespół dobrze zorientowany w tworzeniu współbieżnych aplikacji w C ++ i brak doświadczenia w Haskell, nie ma sensu proponować zbudowania systemu w Haskell, ponieważ prawdopodobnie nie będę w stanie ograniczenia harmonogramu i budżetu, a moja jakość prawdopodobnie ucierpi z powodu braku doświadczenia w łańcuchu narzędzi.
Reasumując, inżynieria oprogramowania oparta na dowodach jest ogólnie dobrą rzeczą, a istnieją przeglądy literatury i są łatwo dostępne. Istnieją jednak aspekty inżynierii oprogramowania, w których zastosowanie podejścia opartego na dowodach ma niewielką wartość. Jednym z nich jest wybór paradygmatu programowania do prac rozwojowych na dużą skalę.
Jeśli chcesz dowiedzieć się, w jaki sposób obiektowa orientacja rozwiązuje problem ponownego użycia lub defektów w programowaniu funkcjonalnym - z łatwością znajdziesz publikacje na ich temat. Jednak nie znalazłem (ani nie zaufałbym) publikacji, która byłaby w stanie skutecznie zająć się wyborem paradygmatu w szerokim zakresie rzeczywistych projektów inżynierii oprogramowania.