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

Odpowiedzi:

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