Cytowane odniesienia do najlepszych praktyk w zakresie oprogramowania

Obecnie piszę pracę doktorską. Znaczną część mojego doktoratu spędziłem na czyszczeniu i rozszerzaniu istniejącego kodu naukowego, stosując najlepsze praktyki inżynierii oprogramowania, które wcześniej nie były używane, i chciałbym o tym napisać w mojej pracy magisterskiej. Zamiast po prostu powiedzieć „Dodałem testy jednostkowe”, chcę móc napisać coś takiego:

J. Doe wynalazł testy jednostkowe w 1975 r. [ 23 ] . Ostatnie badanie Bloggsa i in. [ 24 ] wykazało, że testy jednostkowe zmniejszają częstotliwość występowania błędów oprogramowania o 73% ... 234 oddzielne testy jednostkowe zostały dodane do podstawy kodu, zarządzanej przez platformę xUnit stworzoną przez Timpkins i in.$^{[23]}$$^{[24]}$$^{[25]}$

Szukam cytowanych odniesień akademickich (najlepiej artykułów w recenzowanych czasopismach, w których mogę uzyskać DOI, BibTeX itp.) Do powszechnie akceptowanych najlepszych praktyk inżynierii oprogramowania, w szczególności:

• testy jednostkowe
• kontrola wersji
• modularyzacja / rozdzielenie problemów
• profilowanie / optymalizacja wydajności na podstawie informacji o profilowaniu
• śledzenie błędów / problemów

Szukam informacji zarówno o początkowym wynalazku, jak i późniejszych ocenach skuteczności. Jeśli jest artykuł poglądowy, który zawiera listę wszystkich tych rzeczy w jednym miejscu, to tym lepiej.

Książka Steve'a McConnella Code Complete, wydanie drugie, zawiera obszerną bibliografię omawiającą te kwestie z punktu widzenia bardziej twórców oprogramowania niż naukowców zajmujących się obliczeniami. Książka zaczyna być trochę przestarzała, ponieważ zbliża się do dekady, więc nie obejmuje nowszych metodologii testowania, takich jak rozwój oparty na zachowaniu. Niemniej jednak jestem najbliżej obszernego artykułu przeglądowego na temat budowy oprogramowania, o którym wiem. Możesz także poszukać artykułów w oprogramowaniu IEEE.

Jeśli chodzi o naukę obliczeniową, myślę, że najlepszym artykułem jest prawdopodobnie wersja PLoS preprint arXiv DavidKetcheson cytowany w „Best Practices for Scientific Computing”. Mówię, że pochodzi to z inżynierii, gdzie mniej osób powołuje się na referencje do arXiv lub publikuje preprinty arXiv, a zatem powołuje się na „prawdziwy artykuł w czasopiśmie” (odkładając oczywiście na bok wszystkie omawiane obecnie kwestie dotyczące publikacji naukowych) ) jest postrzegana bardziej przychylnie (i mam wrażenie, że właśnie dlatego autorzy zdecydowali się opublikować go w czasopiśmie).

Autorzy artykułu PLoS, o którym wspominali DavidKetcheson i ja, są częścią organizacji o nazwie Software Carpentry, która organizuje (zwykle 2-dniowe) „obozy szkoleniowe”, aby uczyć naukowców o najlepszych praktykach tworzenia oprogramowania i przydatnych umiejętnościach obliczeniowych dla naukowców (nie tylko naukowcy obliczeniowi). Strona internetowa Software Carpentry zawiera obszerną bibliografię związaną z tworzeniem oprogramowania w nauce. Jeśli jesteś zainteresowany tymi problemami, zachęcam do skontaktowania się z nimi; zawsze szukają większej liczby zwolenników najlepszych praktyk w tworzeniu oprogramowania, aby wykonywać wolontariat na różne sposoby. ( Oświadczenie : Zgłaszam się na ochotnika do stolarki programowej.)

Innym powszechnym uzasadnieniem dla angażowania się w najlepsze praktyki w zakresie tworzenia oprogramowania jest odtwarzalność. Victoria Stodden opracowała długą listę powtarzalnych referencji badawczych, które mogą być interesujące, w zależności od tego, co chcesz powiedzieć.

Nie mam referencji dotyczących pochodzenia każdego z tych pomysłów / praktyk. Ale oto kilka bardzo aktualnych odnośników:

• Co sprawia, że ​​komputerowe biblioteki oprogramowania open source są skuteczne?
• Najlepsze praktyki obliczeń naukowych

IMHO Z wielką starannością powołuję się na „Najlepsze praktyki” w kontekście naukowo udowodnionego podejścia. Większość praktyk wywodzi się z „tego, co wydaje się sprawdzać dla zestawu projektów przez kogoś postrzeganego jako guru zaangażowany w te projekty”, a nie z rygorystycznego testowania różnych podejść. W inżynierii oprogramowania jest po prostu zbyt wiele zmiennych i czynników ludzkich, aby stwierdzić, że istnieje odpowiednia lista „najlepszych praktyk” (np. Praktyka, która działa na jednym projekcie, całkowicie zawiedzie w innym).

Podejdę do tego, podając, czego potrzebuje twój projekt, dlaczego go potrzebuje i dodaj odniesienia do zastosowanych metod i dlaczego je wykorzystałeś.

Chciałbym również skłaniać się do zgłaszania wymiernych wyników, a nie odniesień do stwierdzenia waszej opinii. Na przykład, jeśli twoje testy jednostkowe wykryły 100 błędów, z których 10 jest wystarczająco poważnych, aby podważyć wątpliwości dotyczące wcześniej opublikowanego wyniku. Jest to o wiele mocniejsze stwierdzenie, które można mieć w swoim doktoracie, niż stwierdzenie, że znasz pochodzenie testów jednostkowych.

edit: (poprawiona literówka) - Odpowiadając na następujące pytania - Często podam wychowujące dzieci jako analogię do projektów programowych. Istnieje wiele metod i sprawdzonych sposobów ich wychowywania, próbując wychowywać dzieci za pomocą jednej metody, ponieważ działa ona na średnią lub testowaną podpróbkę, będzie działać, o ile twoje dziecko jest takie samo jak ta przetestowana. Lepiej poznać wiele metod i zastosować te, które działają w twojej instancji. Tak, testy jednostkowe mogą być udowodnione, ale zastosowanie ich w oparciu o to samo może oznaczać, że Twój projekt wejdzie na rynek późno i dlatego nie spełni swojego celu (jeśli taki jest cel). Mówię, że zastosowanie metody, aby uzyskać wynik i dać wynik tego wyniku, moim zdaniem jest lepsze w pracy dyplomowej, niż wymienienie rzeczy, które wypróbowałeś w oparciu o inne projekty - chyba że tematem pracy jest pomiar metodologii :)