Punkt złożoności bez zwrotu. Jak to nazywasz?

13

Jako programista jednym z moich głównych zadań jest kontrolowanie złożoności.

Jednak w niektórych projektach moment, w którym poziom złożoności rośnie tak wysoko, że dochodzi do pewnego rodzaju punktu „bez powrotu”. Po tej chwili nigdy nie można przywrócić projektu do akceptowalnego poziomu złożoności w krótszym czasie, niż trzeba wszystko przepisać od nowa.

Czy ten konkretny moment ma nazwę w dialekcie programistów (coś podobnego do prawa trolla Godwina)?

--edytować--

Przepraszam, jeśli nie jestem jasny. Nie sądzę, by ten „moment” miał oficjalną nazwę lub poważny miernik. Myślałem o czymś w duchu „szczytu Ballmera” w xkcd .

terminology Thibault J
źródło
1
Widzę jedną kontrowersję w twojej definicji omawianego punktu: ... w krótszym czasie, gdy będziesz musiał przepisać wszystko od zera , co oznacza, że ​​ci, którzy zamierzają przepisać projekt, są wystarczająco dobrzy, a przynajmniej lepsi niż ci, którzy stworzył bałagan w pierwszej kolejności;)
mojuba
1
Myślę, że jednym z powodów, dla których nie uzgodniono nazwy, jest to, że zależy to od tego, kto patrzy na kod. To, co wydaje się beznadziejnie złożone lub niemożliwe do utrzymania dla jednego dewelopera, może wydawać się całkiem rozsądne dla drugiego. W ciężkich przypadkach po prostu kompiluję się do biblioteki DLL z prefiksem „ms” i mówię, że pochodzi ona od firmy Microsoft.
Kevin Hsu,
1
Może to wystarczy: horyzont techniczny dotyczący długu
PeterAllenWebb

Odpowiedzi:

20

Jest to bardziej kwestia łatwości konserwacji niż złożoności.

Zjawisko to nazywa się „długiem technicznym”, a gdy osiągnie poziom krytyczny, projekt znajduje się na drodze do bankructwa.

Czy o to ci chodziło?


źródło
Dziękuję za odpowiedź. Mam świadomość koncepcji „działu technicznego”. Każdy projekt ma jakiś dług techniczny. Mam na myśli: jak nazwać moment, w którym dług staje się tak wysoki, że wolisz wyrzucić projekt do śmieci i zacząć od nowa?
Thibault J
3
Podoba mi się twój termin „bankructwo techniczne”. Sugeruje to, że podobnie jak w przypadku prawdziwego bankructwa, trzeba dokładnie przyjrzeć się, które części można odzyskać, a które należy pozostawić. A może restrukturyzacja zadłużenia jest wszystkim, czego naprawdę potrzebujemy :)
Jaap
2
@Thibault J: Nie wierzę, że istnieje konkretny termin na ten moment. Chodzi bardziej o uświadomienie sobie, czy nadal jesteś szczęśliwy przed tym czasem, czy niestety przekroczyłeś go.
1
@ Developer Art: ... zdając sobie sprawę z tego, czy nadal jesteś szczęśliwy przed tym czasem lub niestety przekroczyłeś go - myślę, że jest to klucz do podania dobrej definicji punktu: projekt, który wykroczył poza ten punkt, jest projektem, którego żaden inżynier nie zrobiłby przejąć dobrowolnie.
mojuba
3
Pójdę na termin „bankructwo techniczne”, podoba mi się. I użyję twojej definicji.
Thibault J
16

„Punkt nadmiernej złożoności” jest w języku angielskim nazywany:

O MÓJ BOŻE CO TO JEST ODPADY.

Problem w tym, że może to dotyczyć czegoś, co jest naprawdę proste, ale jest realizowane w tak okropny sposób, że masz taką samą reakcję.

Zatem odróżnienie czegoś bardzo złożonego od czegoś okropnego może być trudne.

JEDNAK: To, co faktycznie dzieje się z każdym oprogramowaniem, jest trochę podobne:

Krok 1: Miej niezłą specyfikację, zrób fajny projekt, zaimplementuj fajne rzeczy. Wszyscy szczęśliwi.

Pod koniec kroku 1: programiści gratulują sobie wspaniałej elegancji swojego projektu i odchodzą szczęśliwi, myśląc „Mam tutaj wspaniałe dziedzictwo dla innych, aby dodać coś w przyszłości, będzie cudownie, a świat będzie lepsze miejsce."

Krok 2: Dokonano pewnych zmian, dodano rzeczy, dodano nowe funkcje. Architektura i struktura z kroku 1 sprawiły, że proces ten był dość bezbolesny. [Ale ups, „współczynnik cruft” nieco się zwiększył.]

Pod koniec kroku 2: programiści gratulują sobie wspaniałej elegancji swojego projektu i odchodzą szczęśliwi myśląc: „Ojej, jestem taki sprytny, że uwzględniłem wszystkie te kroki w kroku 1. Poszło tak dobrze. Mam wspaniałe dziedzictwo tutaj, aby inni mogli dodawać rzeczy w przyszłości, będzie cudownie, a świat będzie lepszym miejscem ”.

Krok 3: Więcej zmian zostaje wprowadzonych, więcej rzeczy zostaje dodanych, więcej nowych funkcji, wiele rzeczy się zmienia, opinie użytkowników są w rzeczywistości słuchane.

Pod koniec kroku 3: programiści gratulują sobie wspaniałej elegancji swojego projektu i odchodzą dość szczęśliwi, myśląc: „Ta architektura jest całkiem dobra, aby pozwolić na tak wiele zmian, aby łatwo się wprowadzić. Ale jestem trochę niezadowolony o X, Y i Z. Można by je teraz trochę posprzątać, ale !!! Achhh! Jestem taki sprytny, że wziąłem pod uwagę wszystkie te kroki w kroku 1. To poszło tak dobrze. Mam tutaj wspaniałe dziedzictwo inni będą dodawać rzeczy w przyszłości, będzie cudownie, a świat będzie lepszym miejscem ”.

Krok 4: podobnie jak krok 3. Z wyjątkiem:

Pod koniec kroku 4: programiści myślą: „To, co było tak dobre, sprawia, że ​​UGLY jest w stanie utrzymać. Naprawdę potrzebuje poważnych zmian. Nie bardzo lubię pracować nad tym. To wymaga refaktoryzacji. Zastanawiam się, co szef powie, kiedy mu powiem, że potrzebuje 6 tygodni, a użytkownicy nie będą mieli nic do zobaczenia na końcu tego ... ale będę miał kolejne 5 lat pysznych przyszłych modyfikacji, robiąc to ... hmmm .. czas iść do pubu na piwo. "

Krok 5: Należy wprowadzić kilka zmian.

I PODCZAS kroku 5 programiści mówią sobie: „Ten kod jest do kitu. Kto to napisał? Powinni zostać zastrzeleni. To okropne. MUSIMY PONOWNIE NAPISAĆ”.

Krok 5 jest śmiertelny. W tym momencie współczynnik cruft jest tak zły, że kod nie może zawierać tylko kilku innych zmian, musi wprowadzić DUŻE zmiany.

Problemem w kroku 5 jest chęć wyrzucenia go i rozpoczęcia od nowa. Powodem, dla którego jest to śmiertelne, jest „The Netscape Factor”. Przejdź do google. Firmy giną w tym momencie, ponieważ rozpoczęcie od nowa oznacza, że ​​zaczniesz od około 50% założeń zamiast faktów, 150% entuzjazmu zamiast wiedzy, 200% arogancji zamiast pokory („Ci goście byli tacy głupi!”). I wprowadzasz całą masę nowych błędów.

Najlepiej zrobić to refaktoryzować. Zmieniaj trochę na raz. Jeśli architektura trochę się męczy, napraw ją. Dodawaj, przedłużaj, ulepszaj. Stopniowo. Na każdym kroku po drodze testuj, testuj i testuj jeszcze więcej. Takie przyrostowe zmiany oznaczają, że 10 lat później obecny i oryginalny kod są jak topór dziadka („miał 10 nowych głów i 3 nowe uchwyty, ale nadal jest toporem dziadka”). Innymi słowy, nie ma wiele wspólnego. Ale stopniowo i ostrożnie przechodziłeś ze starego do nowego. Zmniejsza to ryzyko, a dla klientów zmniejsza czynnik wkurzony.

szybko
źródło
Założę się, że dostaniesz więcej głosów, jeśli skrócisz swoje kroki.
Codism
Muszę dodać, że większość firm nie przeznacza na to budżetu, więc refaktoryzacja jest zawsze za mało i za późno. Aby zarządzać rosnącą entropią systemów, należy skonfigurować, że od pierwszego dnia budżet (10% -20%) jest przydzielany na każde zadanie na utrzymanie domu. To nie jest budżet na naprawę błędów. O wydatkach budżetowych decyduje inżynieria, a nie zarządzanie, marketing czy sprzedaż. Służy wyłącznie do odliczenia entropii stworzonej przez rozwój, a wydatki zmniejszają się, gdy produkt zbliża się do końca życia.
mattnz
Zgoda. Kierownictwo zawsze chce przycinać tego rodzaju rzeczy. Czasami możesz uciec od ukrycia go (Dodaj około 20% do oszacowania rozwoju za zrobienie czegokolwiek, a gdy potrzebne jest refaktoryzowanie - ZRÓB TO).
szybko_nie
1
Jest punkt, w którym naprawdę nie można refaktoryzować. Jeśli masz kilka różnych aplikacji biznesowych, które zależą od tego samego kiepskiego interfejsu lub bazy danych, nie możesz bardzo dobrze naprawić podstawowych problemów bez zepsucia wszystkich innych aplikacji, które zależą od gównianego fundamentu. W tym momencie naprawdę jesteś wkręcony.
John Cromartie
2

Zgadzam się, że ten moment jest trudny do rozpoznania i można go uniknąć dzięki odpowiednim procesom. Pytanie dotyczyło jednak, jak to nazwać. W realnej ekonomii istnieje koncepcja „malejących zysków”: punkt, w którym zwiększenie nakładu na jeden zasób w procesie zmniejsza ogólny zysk na jednostkę. Odnosi się to z pewnością do kodowania, a nawet dobre rzeczy, takie jak abstrakcja, ponowne użycie itp., Mają tak malejący zwrot. Ogólnym terminem specyficznym dla programowania jest „nadinżynieria”. Dla kogoś, kto ma taką skłonność, podoba mi się termin Joela „ astronauta architektury ”.

Kilian Foth
źródło
1

Zbyt często dobry kod jest odrzucany pod fałszywym wrażeniem, że nowy zespół z nowymi narzędziami może zrobić to taniej, szybciej i bardziej niezawodnie, tylko po to, aby znaleźć

  • Złożoność wynika z wymagań dotyczących nieudokumentowania
  • Nowe narzędzia są trudniejsze w użyciu niż obiecana witryna flash
  • Nowy zespół nie jest tak „gorący”, jak im się wydawało

Być może czas, który opisałeś, nadchodzi z pewnymi podstawami kodu (kiedyś tak myślałem). Nigdy osobiście nie doświadczyłem przypadku starego kodu powodującego upadek projektu lub przepisania kodu w celu zapisania projektu.

Nie uwzględniam w tych przypadkach, w których do identyfikacji konkretnych problematycznych modułów lub projektów wykorzystano mierniki, które następnie zostały ubite i wymienione.

mattnz
źródło
Cóż, widziałem projekt tak zajebisty, że jego budżet na utrzymanie był trzy lub cztery razy większy niż początkowy budżet na rozwój. W każdym razie termin, którego szukam, nie jest „oficjalny” i poważny, ale bardziej przypomina „szczyt Ballmera” w xkcd. Przepraszam, jeśli nie jestem bardzo jasny.
Thibault J
Ale jak to się stało, że tak kurwa? Jeśli jest to spowodowane złożonymi wymaganiami, złym zarządzaniem i optymistycznymi inżynierami, dlaczego przepisanie go naprawić?
mattnz
Ponieważ zespół przepisujący go nie jest tym samym, co ten, który pisze go na początku?
Thibault J,
1

Prawdziwy problem z tym teoretycznym „momentem” polega na tym, że rozpoznaje się go dopiero po fakcie. O ile twoi koledzy nie są psychopatami, każde zatwierdzenie do bazy kodowej odbywa się z przekonaniem, że jest to poprawa w tej bazie kodowej. Patrzy tylko na powstały bałagan, który widzisz, że minął ten „moment”.

Ale podoba mi się, że możemy nadać temu nazwę. „Panowie”, można by powiedzieć, przyciągając do siebie innych programistów. „Przekroczyliśmy Piekło Utrzymania w Piekle. Wyślij SMS-a do swojej żony i daj jej do zrozumienia, że ​​nie zobaczysz jej jeszcze przez jakiś czas”.

Dan Ray
źródło
„Każde zatwierdzenie do bazy kodowej odbywa się z przekonaniem, że jest to poprawa w tej bazie kodowej”. Wygląda na to, że nigdy nie pracowaliśmy w tych samych firmach :)
Thibault J
@ThibaultJ - Być może twoi koledzy byli psychopatami?
Dan Ray
@Thibault J: Uważam, że każde zatwierdzenie jest wykonywane z przekonaniem, że jest to poprawa w tej bazie kodu. Oczywiście przekonanie to jest czasem słabo zbadane i bezpodstawne.
David Thornley,
W mojej ostatniej pracy nie sądzę, aby było jakieś zobowiązanie konserwacyjne, które ktoś zrobiłby kiedykolwiek z przekonaniem, że było to ulepszenie bazy kodowej.
Tabele Bobby'ego,
Czasami wymagania projektu mogą ulec zmianie na tyle, aby wymusić zastąpienie nowym projektem, ale może być jednak konieczne wprowadzenie zmian w starej wersji. Jeśli większość byłych użytkowników starej wersji będzie korzystać z nowego systemu i nie będzie już potrzebować starego, może być całkowicie uzasadnione stworzenie wersji spełniającej wymagania tych nielicznych, dla których nowy system jest nieodpowiedni, nawet gdyby był sprawiają, że system jest mniej użyteczny dla ludzi, którzy i tak już go nie potrzebują.
supercat
-1

Nie wiem, czy jest jakaś nazwa, ale jeśli jej nie ma, proponuję nazwać ją „punktem topnienia”

DPD
źródło
Albo pożyczyć inny termin nuklearny: masa krytyczna.
John Cromartie
-2

To nie jest bardzo interesujące pytanie.

Rzeczywiście jest to banalne.

Jest to tak trywialne, że opracowaliśmy wiele sposobów radzenia sobie.

  1. Metodologie wodospadu. Wiele osób spędza dużo czasu na przeglądaniu wymagań i opracowywaniu dokumentów, aby mieć pewność, że złożoność jest zarządzana.

  2. Zwinne metodyki. Mniej osób spędza mniej czasu na omawianiu tego, co ma natychmiastowe zastosowanie, aby rozwiązać czyjś problem i wydać mu oprogramowanie. Złożonością zarządza się, ponieważ wszyscy koncentrują się na wydaniu czegoś.

Jedyny raz, kiedy ktoś zmaga się ze „złożonością”, jest to, że nie przestrzega metodologii i nie zarządza swoim czasem właściwie.

  • Brak szczegółowego nadzoru w metodyce wodospadu. Nie są zmuszeni do przeglądu produktów do pracy pośredniej pod kątem wymagań, architektury, projektowania na wysokim poziomie lub szczegółowych recenzji projektów.

  • Brak terminów sprintu i odpowiednich priorytetów przypadków użycia w metodologii Agile. Nie koncentrują się na jak najszybszym udostępnieniu użytkownikowi treści.

Złożoność powinna być ograniczona poprzez ustalanie celów.

Walka ze złożonością oznacza, że ​​cele nie są ustalone lub nie są odpowiednio wynagradzane.

Nie ma „punktu zwrotnego”. Jeśli zarządzanie złożonością jest w jakiś sposób problemem, coś jest już źle organizacyjnie.

S.Lott
źródło
1
Nie widzę sensu. Dobrze zarządzany projekt raczej nie osiągnie punktu bez zwrotu, ale nie wszystkie projekty są dobrze prowadzone. Niektóre źle prowadzone projekty i tak się powiodą, a reszta zakończy się niepowodzeniem z różnych powodów, czasami osiągając punkt złożoności bez powrotu, a czasem nie.
David Thornley,
@David Thornley: Właśnie o to mi chodzi. „Punkt złożoności bez powrotu” nie istnieje. To po prostu złe zarządzanie. Nie ma potrzeby wyszukanego imienia ani reguły. Złożoność jest tylko objawem złego zarządzania. Niezbyt interesujące.
S.Lott
@ S.Lott: Myślę, że istnieje, chociaż nie w dobrze zarządzanych projektach. Istnieje horda źle zarządzanych projektów, a niektóre z nich dostaną się do horyzontu złożoności, a niektóre nie. Naprawdę nie sądzę, że użyteczne jest zebranie całego złego zarządzania razem.
David Thornley,
@David Thornley: Myślę, że bardzo trudno jest oddzielić złe zarządzanie (co prowadzi do przerażającej złożoności) od złego zarządzania (co powoduje, że wszyscy rezygnują). Nie widzę sposobu, aby stwierdzić, czy projekt stanie się zbyt złożony, czy spóźniony, czy po prostu niekompetentny.
S.Lott,
@ S.Lott: Istnieje jednak różnica między projektem, w którym wszyscy rezygnują lub cierpią z powodu poważnego załamania zdrowia, a projektem, w którym złożoność staje się zbyt duża. Istnieją różne sposoby niepowodzenia, a ich kategoryzacja może być interesująca lub nawet przydatna.
David Thornley,
-2

Istnieją metody wizualizacji i monitorowania ryzyka zwiększenia złożoności (dużych) projektów i kodu. Kiedy są stosowane w uzasadniony sposób, mamy nadzieję, że nowa nazwa punktu bez powrotu nie jest potrzebna. (Istnieje powiązany MOOC na openHPI: https://open.hpi.de/courses/softwareanalytics2015/ )

Złożoność strukturalna jest ogólnym problemem projektowym - nie tylko w przypadku projektowania oprogramowania w dużych zespołach. Wizualizacja to pierwszy krok w zarządzaniu złożonością strukturalną. W tym celu można również zastosować macierze i ukierunkowane wykresy.

Niektóre metody zmniejszania złożoności strukturalnej to http://www.buch.de/shop/home/suche/?fq=3540878890 :

  • modularyzacja
  • unikanie pętli sprzężenia zwrotnego
  • triangulacja

Ponadto istnieje koncepcja projektowania aksjomatycznego: https: \ en.wikipedia.org \ wiki \ Axiomatic_design \ Dzięki tej koncepcji można uniknąć problemów z niezawodnością z powodu niepotrzebnej złożoności.

Tak więc dostępnych jest wiele metod. W końcu zawsze chodzi o decyzję, aby o nich pomyśleć, ponieważ projekt staje się wystarczająco duży.

Eddi
źródło
To nie odpowiada na pytanie.
Hulk