Paradygmaty programowania i programista konserwacji [zamknięte]

9

Czytałem, Fakty i błędy inżynierii oprogramowania, która zawiera sekcję dotyczącą konserwacji. Ponieważ od lat jestem programistą konserwacji, zaprezentowałem bardzo interesujące fakty. Oto trzy.

Fakt 41: Konserwacja zazwyczaj pochłania od 40 do 80 procent (średnio 60 procent) kosztów oprogramowania. Dlatego jest to prawdopodobnie najważniejsza faza cyklu życia oprogramowania.
Fakt 42: Ulepszenie odpowiada za około 60 procent kosztów utrzymania oprogramowania. Korekta błędu wynosi około 17 procent. Dlatego konserwacja oprogramowania polega głównie na dodawaniu nowych możliwości do starego oprogramowania, a nie naprawianiu go.
Fakt 45: Lepszy rozwój inżynierii oprogramowania prowadzi do większej konserwacji, a nie mniej.

Ten był sprzeczny z intuicją, okazuje się, że dobre oprogramowanie wymaga większej konserwacji, ponieważ łatwo je zmienić. Dlatego pozostaje dłużej w użyciu, co prowadzi do, tak, więcej zmian.

Który paradygmat (taki jak funkcjonalny, obiektowy, proceduralny) ma najlepszą łatwość utrzymania i czy istnieją jakieś badania na poparcie tego?

maintenance maintainability

— KaizenSoze
źródło

Posiadam kopię Fakty i błędy, a dla każdego faktu (i błędu) istnieją cytaty dla różnych publikacji, które go popierają. Nie mam pod ręką kopii, ale czy którykolwiek z tych cytatów omawia wpływ paradygmatu na utrzymanie?

— Thomas Owens

Książka została napisana w 2003 r., Wiele wniosków jest nadal aktualnych. Byłem ciekawy, czy ludzie mieli jakieś nowe badania na temat poszczególnych paradygmatów. Konserwacja wydaje się być przeoczoną częścią dyskusji.

— KaizenSoze

Jeśli którekolwiek z badań lub publikacji cytowanych w Fakty i błędach dotyczą możliwości utrzymania określonego paradygmatu, jedną z opcji byłoby przeszukanie baz danych IEEE lub ACM pod kątem innych artykułów i artykułów, które cytują ten papier. Jeśli nie masz dostępu do baz danych IEEE lub ACM, mogę wrócić do mojej książki po powrocie do domu i sprawdzić, czy mogę przeprowadzić takie wyszukiwanie. Niestety, będę mógł uzyskać tylko nazwy innych dokumentów, a nie same dokumenty.

— Thomas Owens

12

Myślę, że przekonasz się, że paradygmaty takie jak funkcjonalny, OO i proceduralne prawdopodobnie nie będą miały istotnego związku z utrzymywalnością oprogramowania.

Co można znaleźć następujące podstawowe informacje znacznie łatwiejsze w utrzymaniu oprogramowania:

Poziom zbierania wymagań i inżynieria wymagań
Dobre praktyki rozwoju: (luźne połączenie, wysoka kohezja, testy jednostkowe, YAGNI ...)
Wykwalifikowani i wykwalifikowani inżynierowie oprogramowania (są warte 10 razy więcej niż kretyn)
Wykwalifikowany i zorganizowany zespół ds. Technicznych kontroli jakości
Dobre zarządzanie projektami prowadzone przez kompetentnych kierowników projektów (nawet trudniejsze do znalezienia niż wykwalifikowani twórcy oprogramowania IMHO)
Dobrzy właściciele produktów lub menedżerowie aplikacji, silne przywództwo, dobry długoterminowy kierunek, dobre informacje zwrotne dla zespołów projektowych, ogólna wizja.

— wałek klonowy
źródło

+1 Chcę dodać dobrą dokumentację do listy

— treecoder

+1 Dodaj proces „Skoncentrowany na wartości” do listy. Proces określa i steruje tym, co zrobiono, a czego nie zrobiono. To, co proces mierzy, jest ważne, a to, czego proces nie mierzy, jest nieistotne. Szczególnie prawdziwe, gdy faceci HR zaczynają zapełniać miejsca „kretynami”.

— mattnz,

2

Ten był sprzeczny z intuicją, okazuje się, że dobre oprogramowanie wymaga większej konserwacji, ponieważ łatwo je zmienić. Dlatego pozostaje dłużej w użyciu, co prowadzi do, tak, więcej zmian.

Wygląda na to, że przeglądasz to na podstawie konserwacji, a nie procentu kosztów. Dobre oprogramowanie, które ma więcej funkcji, to po prostu większa ilość oprogramowania. Jeśli odsetek konserwacji jest stały (ponieważ było to dobre oprogramowanie i zakładamy, że dodatkowe funkcje zostały dodane jako dobre oprogramowanie), kwota wzrośnie. To tylko większy kawałek ciasta z taką samą liczbą plasterków.

W zależności od tego, o co pytasz, ważne jest, czy „dobre” oprogramowanie zostało napisane w: kodzie funkcjonalnym, OOP czy proceduralnym. Czy podarowanie komuś laserowej piły mechanicznej zaoszczędzi na drewnie, jeśli nie będzie wiedział, jak mierzyć?

— JeffO
źródło