Jak wytłumaczysz refaktoryzację osobie nietechnicznej?

Jak zabierasz się za wyjaśnianie refaktoryzacji (i zadłużenia technicznego) osobie nietechnicznej (zwykle PHB lub klientowi)? („Co, będzie kosztowało mnie miesiąc twojej pracy bez widocznej różnicy ?!”)

AKTUALIZACJA Dzięki za wszystkie dotychczasowe odpowiedzi, myślę, że ta lista dostarczy kilku przydatnych analogii, na które możemy wskazać odpowiednie osoby (choć edytowanie odniesień do PHB może być mądre!)

Kiedy masz duże kino domowe i dodajesz rzeczy, powoli, ale z pewnością tworzy się z tyłu duże gniazdo szczurów.

Jeśli często wymieniasz części, czasem warto to wszystko wyprostować.

Jasne, jeśli to zrobisz, działało to wcześniej i nie będzie działać lepiej niż kiedy zacząłeś, ale kiedy będziesz musiał się z tym pograć, wszystko będzie znacznie łatwiejsze.

W każdym razie prawdopodobnie najlepiej jest porównać to z jakimś obszarem tematycznym, z którym PHB lub klient jest już zaznajomiony, np. Samochód, konstrukcja lub coś ...

Ponowne faktoring przypomina proces przepakowywania walizki, dopóki wszystko nie będzie dobrze dopasowane. Czasami zastanawiasz się, dlaczego na początku próbowałeś dostać tyle śmieci.

Nie wyjaśniłbym pojęcia długu technicznego, ponieważ nie jest to konieczne. Zamiast tego skup się na refaktoryzacji: zmieniasz wygląd swojego programu, niekoniecznie tak, aby był „lepszy” lub „ulepszony”, zmieniasz go, aby mógł zaakceptować zmianę, którą musisz wprowadzić.

Analogia samochodowa może pasować: Musisz dodać klimatyzator do samochodu, ale nie był pierwotnie dla niego zaprojektowany. Nie tylko musisz stworzyć dziwny klimatyzator w kształcie litery L, ale musisz także najpierw usunąć inne rzeczy i zmienić system odpowietrzania.

Sądzę również, że lepszą strategią jest refaktoryzacja, gdy dostosowujesz nowe funkcje: w przeciwnym razie możesz zmienić projekt w coś, co tylko wygląda „lepiej”, ale może być źle dostosowane do okoliczności towarzyszących dodaniu kolejnej funkcji.

Używam terminu „dług techniczny” i odnoszę go bezpośrednio do czegoś, co rozumieją - długu korporacyjnego. Dług techniczny jest jak zaciągnięcie pożyczki. Płacisz za to odsetki. Np. Możesz zbudować nową fabrykę i zapłacić za nią od razu lub uzyskać pożyczkę. Jeśli dostaniesz pożyczkę, w rzeczywistości zapłacisz za nią więcej w dłuższej perspektywie, ale ma to sens finansowy, jeśli warunki są prawidłowe .

Jeśli jednak płacisz 25% odsetek od takiej pożyczki, stawiasz się w niezrównoważonej sytuacji. To samo dotyczy długu technicznego. Czasami warto wziąć na siebie jakiś dług techniczny. Przychodzi jednak moment, w którym odsetki są zbyt wysokie i należy je spłacić. Niektóre zadłużenie techniczne jest jak pożyczka mieszkaniowa, a inne jak dług karty kredytowej. W nagłych wypadkach dług karty kredytowej jest ważnym i cennym zasobem. Jednak może również rozbić bank (lub gospodarstwo domowe, jeśli wybierzesz), jeśli zostanie wykorzystany nierozsądnie.

Kolejny przykład: możesz zapłacić 10 000 USD za przesyłkę marketingową, aby pozyskać więcej potencjalnych klientów do sprzedaży w przyszłości. Spłacasz „dług sprzedaży”. Jest to wydatek z długoterminową spłatą. Zrównaj to z tym, dlaczego chcesz „wydawać” pieniądze na refaktoryzację fragmentu kodu. W obu przypadkach nie ma natychmiastowej wypłaty, ale decydujesz się na lepszą wydajność w przyszłości.

Używam terminu „dług xxxx” jako analogii, gdy rozmawiam z kimkolwiek jest grupa docelowa. Np. Zadłużenie operacyjne - drukarnia, którą mamy teraz działa dobrze, ale zatrzymując produkcję na jeden dzień (lub tydzień) i uaktualniając do nowej maszyny, możemy zwiększyć wydajność o 25%.

EDYCJA - oto kolejne spojrzenie na to

Wiosenne porządki.

Nie wprowadzasz żadnych modyfikacji w domu. Po prostu przesuwasz rzeczy i pozbywasz się pyłu. Może wyrzucając rzeczy, których już nie używasz lub których nie potrzebujesz. ale nic nie dodajesz.

„Czy kiedykolwiek grałeś w Mouse Trap ? Kiedy wprowadzamy nowe funkcje, zmieniamy interfejsy i naprawiamy błędy, kod może zacząć wyglądać bardzo podobnie. Nadchodzi moment, w którym albo musimy wydać dużo kapitału (czas i wysiłek , która to kwota do ceny), upewniając się, że wszystkie ruchome części dobrze się bawią przy każdej nowej zmianie lub dodaniu, lub zamiast tego możemy poświęcić czas na zmianę projektu, w wyniku czego mniej ruchomych części musimy zarządzać za każdym razem, gdy dokonujemy zmiany. z punktu widzenia użytkownika końcowego może się wydawać , że refaktor nie ma żadnych korzyści, ale korzyść ta pojawia się za każdym razem, gdy nowa funkcja jest dodawana po refaktorze. Proces jest szybszy, wprowadza mniej błędów, a następnie jest tańszy, nie wspominając o tym, że refaktoryzowany kod jest często ogólnie bardziej wydajny.

Zastanawiasz się, dlaczego po pierwsze pozwoliliśmy mu zacząć wyglądać jak pułapka na myszy:

• Czasami zrobienie czegoś w tej chwili oznacza, że ​​musimy poświęcić elegancję i wydajność, aby po prostu „sprawić, by działało”.
• Funkcje językowe i inne technologie dostępne nam jako programiści często się zmieniają. Czasami nowe funkcje pozwalają nam zamienić drobiazgową mieszankę sześciu ruchomych części na jedną.
• Często, gdy dodamy funkcję C do funkcji A i B, nie wiemy, że B zostanie ostatecznie usunięte i dodane D. Jeden ze sposobów osiągnięcia C może działać bardzo dobrze z B, ale niezbyt dobrze z D.

Starając się budować lepszą pułapkę na myszy, musimy stale wracać i znajdować miejsca, aby zmniejszyć złożoność i usprawnić to, co mamy. To różnica między posiadaniem oprogramowania z wieloma funkcjami, a posiadaniem oprogramowania naprawdę wysokiej jakości ”.

Jest to nieco bardziej graficzna wersja analogii kina domowego.

Jeśli chcesz dodać jeszcze jedno nowe urządzenie [aka, nowa funkcjonalność], w mgnieniu oka możesz prawdopodobnie gdzieś go zmieścić.

Jeśli chcesz dodać kolejne urządzenie, możesz kupić przedłużacz, który kupi ci trochę czasu.

Ale przy każdym dodaniu trudniej jest znaleźć rozwiązanie. A ty narażasz się na ryzyko ¹ pożaru [aka błędów], i będziesz musiał wyciągnąć duże dolce, aby zapłacić komuś za włożenie nowych gniazd do ściany, co może całkiem eskalować aż do głównej płytka drukowana lub nawet dalej.

¹ Kolejna rzecz, że PHB nie grokują zbyt dobrze: „Cóż, jeśli to się może zdarzyć, czym się martwisz?”

Refaktoryzacja - przypomina organizowanie szafki na ubrania / szuflady na narzędzia.

• Nie wyrzucasz swoich ubrań / narzędzi tylko dlatego, że są wszędzie.

• Można argumentować, że nigdy nie powinni się zdezorganizować. Ale robią.

Tak jak kod. Zwłaszcza, że ​​rośnie z czasem.

A jeśli go nie wyczyścisz, będziesz się zastanawiać, co się stało z tą koszulką, którą kochałeś lub kluczem, którego zawsze potrzebujesz, ale którego nigdy nie możesz znaleźć!

Powiedziałbym „utrzymanie kodu” . Ważne jest, aby używać słów, które osoba nietechniczna zna i które mają sens w nietechnicznym spojrzeniu na świat. Jeśli osoba nietechniczna (klient) jest zaznajomiona z konserwacją aplikacji, łatwo jest przeprowadzić równoległą konserwację kodu i konserwacji aplikacji. Nawet jeśli nie są takie same, możesz wyjaśnić, że klientem końcowym są tutaj programiści lub osoby, które utrzymują system.

Załóżmy, że jesteś mechanikiem specjalizującym się w dostosowywaniu samochodów, a nawet budowaniu ich od podstaw, jeśli klient tego wymaga. Jest taki klient, który co jakiś czas powraca do twojego sklepu, aby zawsze wkładać nowe błyszczące rzeczy do swojej limuzyny o dużych rozmiarach.

Kiedy tylko przyjdzie, żeby zainstalować fajny system dźwiękowy. Starannie wykonujesz zadanie, przepuszczając przewody i łącząc je poprawnie. Wychodzi dzień później, jest szczęśliwy i jak zwykle dobrze płaci.

W następnym miesiącu wraca, ale tym razem chce zainstalować pełne kino domowe. Po raz kolejny wsiadasz do limuzyny. Jako profesjonalista ponownie odwiedzasz system dźwiękowy i ułatwiasz konserwację, instalując system rurek do prowadzenia przewodów wokół samochodu. W ten sposób przewody są chronione i łatwiej je wyciągnąć, a jeśli trzeba będzie dodać więcej, będzie to również łatwe. Więc oderwij stare przewody, zainstaluj rurkę i przekaż system dźwiękowy i dodatkowe przewody do kina, zamknij wszystko i gotowe.

Zdając sobie sprawę, że klient nie poprosił cię o wymianę starego systemu dźwiękowego, zdrapujesz część kosztów wymiany i lamp. Jednak nadal zarabiasz na umowie, po prostu nie tak bardzo, jakbyś po prostu rzucił system razem, tak jak za pierwszym razem.

Miesiąc później wraca, tym razem chce systemu oświetleniowego i chce, aby nowe głośniki uszkodziły stare na początku tygodnia.

Ponieważ wszystko było zadbane i uporządkowane, możesz szybko poprowadzić nowe przewody oświetleniowe przez rurkę, zainstalować system i wymienić głośnik. Tym razem jednak skończysz o wiele szybciej, a faktoring został opłacony, dzięki czemu masz kontrolę nad grą.

Twój konkurent, który śmiał się z ciebie za zerwanie idealnie dobrych przewodów i zainstalowanie wszystkich tych dodatkowych rurek, wciąż ma trudności z zaspokojeniem swojego klienta. Pewnie, że robił to szybciej niż ty przez większość czasu, ale z czasem jego klienci narzekają, że opóźnień jest coraz więcej, a ogólna jakość pracy pogarsza się.

Patrząc na to, zdajesz sobie sprawę, że Twoim celem nie tylko pozostanie w branży, ale bycie najlepszym strzelcem, jest zrównoważenie tego, co robisz, aby zaspokoić potrzeby klienta, i tego, co czynisz, aby ułatwić Ci życie. Bardzo rzadko klient płaci za oba, więc musisz ściśle zarządzać. Ryzykujesz, że poprzez proaktywne robienie rzeczy właściwie nawet kosztem robienia rzeczy dwukrotnie, utrzymasz koszty utrzymania na kontrolowanym stabilnym procencie swojej wydajności.

Oprogramowanie jest takie samo, z tym wyjątkiem, że programiści mogą bawić się cyfrową taśmą klejącą BARDZO długo, zanim efekty zostaną naprawdę odczuwalne przez klientów i menedżerów. Niestety do tego czasu koszt poprawnego wykonania czynności rośnie wykładniczo w stosunku do ilości taśmy izolacyjnej i średniego wieku tej taśmy izolacyjnej.

Dlatego tak ważne jest, abyśmy ciągle przebudowywali system. Bardzo często doświadczenie pokazuje nam nowy, bardziej wydajny sposób na zrobienie tego samego lub możemy połączyć podobną funkcjonalność i wykorzystać nadmiarowości zamiast po prostu skopiować je wcześniej. W ten sposób utrzymujemy system szczupły i złośliwy. Czas pokaże, że ciągłe przefakturowanie systemu w celu spełnienia wymagań utrzyma stałą produktywność poprzez kontrolowanie kwoty przeznaczonej na konserwację.

Umieszczenie taśmy izolacyjnej chwilowo zwiększy wydajność kosztem przenoszenia nieoptymalnego systemu. Dług techniczny powstaje, ilekroć preferowana jest natychmiastowa wydajność, ze szkodą dla innych aspektów systemu. Analogia długu jest dobra, ponieważ podobnie jak odsetki od pożyczonego kapitału pochłaniają zyski, pożyczony czas sprawia, że ​​rzeczy szybko podlegają wyższej konserwacji i zwiększają niestabilność systemu, zmuszając zespół do wydawania dodatkowych zasobów na utrzymanie, a nie tworzenie. Podobnie jak w przypadku jego krewnego, jeśli pożyczka trwa nadal, większość środków jest wydawana na spłatę odsetek, pozostawiając niewiele do poprawy. Dług techniczny pochłonie zasoby techniczne do punktu, w którym większość zasobów zostanie wydana, po prostu utrzymując system w ruchu szlifując, aby zatrzymać wszystkie inne możliwe ulepszenia.

Tak więc ostatecznie pytania nie brzmią, czy powinniśmy lub nie powinniśmy tego robić, ale czy etyczne jest pozwalanie menedżerom i klientom wierzyć, że mogą polegać na danych dotyczących wydajności sztucznie rozdętych za pomocą cyfrowej taśmy izolacyjnej. Niektórzy uważają, że jest to decyzja biznesowa, ale szczerze mówiąc, dzieje się tak dlatego, że menedżerowie jej nie rozumieją. W końcu ktoś będzie musiał spłacić dług albo przez intensywne przefakturowanie, albo przez migrację do nowego systemu. Ostatecznie do nas, programistów, należy utrzymanie systemów w utrzymaniu, nie powinniście musieć prosić o zmianę faktury, ponieważ jest to nieodłączna część pracy, niezrozumienie tego nie jest w stanie zrozumieć, na czym polega inżynieria oprogramowania. To powiedziawszy, zdaję sobie sprawę, że istnieją systemy, które już zaciągnęły ważny dług i spłacenie tego długu będzie wymagało decyzji płatników. Twoim zadaniem jest, aby przynajmniej zrobić wszystko, aby przestać zaciągać pożyczki. Dług ten został zaciągniętyPRZEZ NAS może dlatego, że nie wiedzieliśmy lepiej, ponieważ byliśmy do tego zmuszeni, jednak wzięliśmy na siebie ten dług i bardzo często ludzie, którym go powierzyliśmy, aby go nie rozumieli, a zatem nie mogą nim właściwie zarządzać.

Oto twoje oprogramowanie, gotowe, mam nadzieję, że ci się spodoba ... A tak przy okazji, zmaksymalizowałem twoją kartę kredytową, mam nadzieję, że nie masz nic przeciwko ... cya

Ponowne faktoring ma na celu uproszczenie projektu i usunięcie nieefektywności. Ułatwia to naprawianie błędów i dodawanie nowych funkcji w przyszłości.

Debugowanie jest dwa razy trudniejsze niż pisanie kodu. Dlatego, jeśli piszesz kod tak sprytnie, jak to możliwe, z definicji nie jesteś wystarczająco inteligentny, aby go debugować.

Jeśli nadal będziesz dodawać nowe funkcje do kodu, przefakturowanie szybko się zwróci. Będzie to widoczne przy niższym poziomie błędu, szybszym debugowaniu i szybszych poprawkach.

Pisanie oprogramowania przypomina pisanie dużej książki non-fiction lub encyklopedii.

Pierwszy ciąg zawsze jest do kitu. Zawsze można to poprawić, reorganizując go, usuwając sekcje, które nie muszą tam być, i zapewniając spójny styl przez cały czas.

Za każdym razem, gdy trzeba dokonać korekty, najprostszą rzeczą jest dodanie nowej sekcji, zmiana kilku słów i tak dalej. Ale wraz ze wzrostem liczby wersji książka zaczyna tracić swoją organizację. Musisz więc dokonywać kolejnych reorganizacji. Jeśli tego nie zrobisz, książka stanie się niedorzeczną mieszanką.

Weźmy na przykład komputer stacjonarny. Masz wieżę, monitor, klawiaturę, mysz, drukarkę, skaner i głośniki. Ostatecznie wszystko, czego chcesz, to ładnie zorganizowane biurko. Więc po prostu podłączasz rzeczy na ślepo, a kilka minut później, oto wszystko jest ustawione tak, jak chcesz. Cóż ... prawie tak, jak tego chcesz.

Dzień później, kiedy zmieniasz równowagę głośników, zdajesz sobie sprawę, że przypadkowo umieściłeś lewy i prawy głośnik w niewłaściwych miejscach, więc chcesz zamienić ich pozycje. Ale nie! Jest dżungla splątanych sznurów; kiedy przesuwasz głośniki, przewód myszy zaczepia się, a teraz mysz jest ciągnięta wraz z głośnikami. Ponadto klawiatura nie ma już luzu - można było przenosić ją z biurka na kolana.

W porządku, możesz po prostu odłączyć mysz i klawiaturę i włożyć je ponownie, aby wszystko zostało naprawione. Ale to nie pomoże w przyszłej reorganizacji i przyszłych dodatkach. Problemem jest także przecinanie kabli myszy i klawiatury przez dżunglę.

Lepszym rozwiązaniem jest ponowne podłączenie wszystkiego, aby podłączyć je z powrotem w schludny, czysty sposób, w którym każdy przewód nie koliduje z innym. Teraz przyszłe zmiany są łatwe i nadal będą łatwe. Później inwestujesz trochę z góry, aby uzyskać duże zyski.

Kluczową kwestią jest to, że oryginalne rozwiązanie działało głównie. To jest właśnie kwestia refaktoryzacji: na początek działa, ale musisz zmienić sposób, w jaki istnieją rzeczy, aby łatwo wprowadzić przyszłe zmiany (przesunięcie głośników).

To trochę jak sprzątanie domu po szalonej i szalonej imprezie z poprzedniej nocy.

Powiedzmy, że salon został całkowicie zniszczony. Dom jest nadal domem, salon jest nadal salonem. Działa, ale nie jest tak, jak mogłoby być. Po wpatrzeniu się w bałagan zdajesz sobie sprawę, że należy go posprzątać.

Więc zaczynasz pakować śmieci. Już wygląda lepiej. Rozglądasz się po pokoju i decydujesz się wyprostować meble. Odkładasz jeden kawałek z powrotem, a następnie następny i następny. Wow, pokój wygląda naprawdę dobrze. Jesteś dumna.

Twoja siostra wchodzi i mówi, że pokój wygląda jak śmieci, powinieneś naprawić półkę z książkami i odkurzyć dywan. Ona ma rację. Pokój wygląda naprawdę dobrze.

Rozglądasz się i widzisz, że zasłony okienne wyglądałyby znacznie lepiej, gdyby wszystkie były na tej samej wysokości. Gotowy. Wow, pokój jest niesamowity.

Traktuj swój kod w ten sam sposób.

Łatwo!

Weźmy na przykład ... każdy w swoim życiu napisał list do ukochanego. To musi być ktoś kochany, ponieważ w tych listach zwykle zwracamy również uwagę na kompozycję.

Tak więc masz swój tekst ... znaczenie przejdzie przez obie strony, ale chcesz, żeby całość brzmiała ładnie! Dobrze?

Refaktoryzacja, to samo ... mniej więcej te same informacje, ale kompozycja jest lepsza. I prawdopodobnie spowoduje to lepszą recenzję czytelnika.

Kolejny przykład - pisanie artykułu do magazynu. Dwóch pisarzy, obaj znają „swoje rzeczy”, jedyną różnicą jest to, że jeden wie, „jak pisać”, a drugi pisze tak, jak nauczył się pisać na podstawie takich odpowiedzi.

Czyj artykuł zapamiętasz?

Wszystkie analogie do rzeczy w świecie fizycznym - jak budowanie teatru - są, według IMO, okropne.

Musisz wyjaśnić, że kod refaktoryzacji jest jak ... kod refaktoryzacji. Oprogramowanie jest plastyczne w sposób, w jaki fizyczne analogi nie są. W miarę jak sprawy stają się coraz bardziej złożone, należy przefakturować (lub przerobić, jak chcesz) masywne lub małe części bazy kodu, abyśmy mogli nadal zwiększać złożoność bez szaleństwa.

Dlaczego dokonujemy refaktoryzacji? Ponieważ kod, który nigdy nie jest refaktoryzowany, kosztuje więcej za minutę utrzymania i zmiany, a ostatecznie staje się bardziej problematyczny.

Ciekawe w refaktoryzacji jest to, że przerabiamy bazę kodu, ale przynajmniej na początku funkcjonalność pozostaje taka sama.

Ponowne faktoring to to samo, co sprzątanie czegoś i dawanie nowego miejsca na „pobyt”

Proste proste i coś, co może zająć wiele razy. Czasami nawet dodam, że osoba X pozostawiła ogromny bałagan i muszę to posprzątać.

Pomyślałem o innym przykładzie, o którym najwyraźniej nikt tu nie wspominał: refaktoryzacja jest prawie dokładnie taka sama, jak zmiana układu równania w matematyce (choć, jak sądzę, może to wykraczać poza zakres „osoby nietechnicznej”).

Kiedy zmieniasz równanie, po prostu „przesuwasz rzeczy”, aby uczynić je bardziej czytelnymi i użytecznymi, bez zmiany znaczenia .

Daj im proste równanie matematyczne. Na przykład:

Co jest prostsze?

y = x + x

lub

y = 2x

Refaktoryzacja jest podobną koncepcją, tyle że zamiast prostych równań matematycznych wprowadzasz algorytmy. Główną ideą jest to, że możesz przełączać się między dwoma sposobami robienia rzeczy, ponieważ dają one ten sam rezultat.

Najprostszym refaktoryzowaniem, jakie można wykonać, jest zmiana nazwy.

doX() { ... }
{
   doX()
}

Teraz, ponieważ tak naprawdę nie chcemy, aby rzeczy nazywały się doX, ponieważ tak naprawdę nie wiemy, co to znaczy, zmieniamy nazwę na inną, która jest bardziej zrozumiała i zastępujemy ją gdziekolwiek z niej korzystaliśmy.

doBusinessTransaction() { ... }
{
   doBusinessTransaction()
}

Pozwoli to zaoszczędzić pieniądze później, gdy wystąpi problem lub ulepszenie, ponieważ skraca czas na zrozumienie i naprawienie aplikacji. Aby dodatkowo zaoszczędzić pieniądze, dostępne są bezpłatne narzędzia, które wykonują tę pracę automatycznie w zależności od używanego języka. Te narzędzia są również licencjonowane w taki sposób, że nie są restrykcyjne i wymagałyby od ciebie zrobienia czegoś specjalnego poza potwierdzeniem, jeśli używasz ich bezpośrednio.

Obraz mówi tysiąc słów. Na przykład refaktoryzacja ma dwa przypadki użycia:

• Gdy za pierwszym razem nie wszystko zostanie wykonane poprawnie:

• Gdy sprawy są nużące:

Bibliografia

• xkcd: dobry kod

• xkcd: czy to jest warte czasu?

Zastanów się nad odpowiedzią podaną w Refaktoryzacji i nie wyjaśniaj jej osobom nietechnicznym. Refaktoryzacja to czynność techniczna, o której nie muszą wiedzieć:

Oczywiście wiele osób twierdzi, że kieruje nimi jakość, ale bardziej harmonogram. W tych przypadkach udzielam bardziej kontrowersyjnej rady: nie mów!

Wywrotowy? Nie wydaje mi się Twórcy oprogramowania to profesjonaliści. Naszym zadaniem jest jak najszybsze tworzenie skutecznego oprogramowania. … Menedżer oparty na harmonogramie chce, żebym robił rzeczy najszybciej, jak mogę; jak to robię, to moja sprawa. Najszybszym sposobem jest refaktoryzacja; dlatego refaktoryzuję.

(Refaktoryzacja, Martin Fowler, 2000, strona 61)

Oczywiście to nie zadziała, jeśli zamierzasz spędzić miesiąc robiąc tylko refaktoryzację, ale myślę, że i tak jest to ogólnie zły pomysł i o wiele lepiej jest po prostu refaktoryzować w zakresie niezbędnym do ułatwienia bieżącego lub następnego zadania lub wyczyścić kod, nad którym właśnie pracowałeś.