Czy DRY jest wrogiem zarządzania projektami oprogramowania?

Jedną z najbardziej podstawowych i powszechnie akceptowanych zasad tworzenia oprogramowania jest OSUSZANIE (nie powtarzaj się). Oczywiste jest również, że większość projektów oprogramowania wymaga pewnego rodzaju zarządzania.

Jakie są teraz łatwe do zarządzania zadania (ocena, harmonogram, kontrola)? Właściwe, powtarzalne zadania, dokładnie takie, których należy unikać zgodnie z DRY.

Z punktu widzenia zarządzania projektami świetnie jest rozwiązać zadanie, kopiując istniejący kod 100 razy i wprowadzając niewielkie poprawki do każdej kopii, zgodnie z wymaganiami. Przez cały czas dokładnie wiesz, ile pracy wykonałeś i ile pozostało. Wszyscy menedżerowie cię pokochają.

Jeśli zamiast tego zastosujesz zasadę OSUSZANIA i spróbujesz znaleźć abstrakcję, która w mniejszym lub większym stopniu eliminuje duplikat kodu, sprawy wyglądają inaczej. Zwykle jest wiele możliwości, musisz podejmować decyzje, prowadzić badania, być kreatywnym. Możesz znaleźć lepsze rozwiązanie w krótszym czasie, ale możesz także zawieść. Przez większość czasu tak naprawdę nie można powiedzieć, ile pozostało pracy. Jesteś najgorszym koszmarem kierownika projektu.

Oczywiście przesadzam, ale oczywiście istnieje dylemat. Moje pytania brzmią: Jakie są kryteria decydujące o tym, czy programista przesadza z SUCHYM? Jak znaleźć dobry kompromis? A może istnieje sposób na całkowite przezwyciężenie tego dylematu, nie tylko poprzez znalezienie kompromisu?

Uwaga: To pytanie opiera się na tym samym pomyśle, co moje poprzednie, Ilość rutynowej pracy przy tworzeniu oprogramowania i jego wpływ na oszacowanie , ale myślę, że to wyjaśnia mój punkt widzenia, więc przepraszam, że się powtarzam :).

Wydaje się, że głównym celem zarządzania projektem jest uzyskanie dokładnych szacunków. Nie o to chodzi. Podstawowy cel zarządzania projektami jest taki sam, jak w przypadku programistów: dostarczenie wartości właścicielowi produktu.

Produkt wykorzystujący dużo powolnych ręcznych procesów zamiast automatyzacji może teoretycznie być łatwiejszy do oszacowania (chociaż w to wątpię), ale nie zapewnia klientowi stosunku jakości do ceny, więc jest to po prostu złe zarządzanie projektem. Nie ma dylematu.

Powszechnie wiadomo, że oszacowanie projektów oprogramowania jest trudne, napisano wiele książek i opracowano różne procesy zarządzania nimi.

Gdyby jedynym celem premiera było uzyskanie dokładnych szacunków, byłoby to łatwe. Po prostu uzupełnij szacunki do 10X i pozwól twórcom grać w gry do końca, jeśli ukończą wcześniej. Byłoby to w rzeczywistości lepsze niż twoja sugestia, aby użyć pracy kopiuj-wklej do wypełnienia czasu, ponieważ granie w gry nie zmniejszy możliwości konserwacji produktu.

Ale w rzeczywistości właściciel produktu chce użytecznych szacunków i produktu wysokiej jakości dostarczanego tak szybko i tanio, jak to możliwe. Są to rzeczywiste ograniczenia, z którymi będzie musiał korzystać premier.

W każdym razie kwestionuję twoje założenie, że powtarzalna praca fizyczna jest bardziej przewidywalna niż zautomatyzowana. Wszystkie doświadczenia pokazują, że powtarzalna praca ręczna jest bardziej podatna na błędy. A co jeśli błąd zostanie wykryty w wklejonym kodzie? Nagle koszt naprawy błędu zostaje pomnożony przez liczbę powtórzeń, co powoduje wybuch niepewności.

Masz rację - kopiuj-wklej działa świetnie, a DRY nie ma sensu, kiedy Twoim zadaniem jest stworzenie programu, dla którego skopiowany szablon lub kopia nie będzie musiała być utrzymywana ani rozwijana w przyszłości. Kiedy te dwa komponenty oprogramowania mają zupełnie inny cykl życia, to połączenie ich razem poprzez przefakturowanie wspólnego kodu do wspólnej biblioteki lib, która sama jest w fazie intensywnego rozwoju, może rzeczywiście mieć nieprzewidywalne efekty. Z drugiej strony, podczas kopiowania sekcji kodu w jednym programie lub systemie programowym, wszystkie te części zwykle mają taki sam cykl życia. Zilustruję poniżej, co to oznacza DRY i zarządzanie projektami.

Poważnie, istnieje wiele takich programów: na przykład przemysł gier komputerowych produkuje wiele programów, które muszą być utrzymywane przez krótki okres maksymalnie kilku miesięcy lub roku, a kiedy ten czas się skończy, kopiowanie i wklejanie stary kod z poprzedniej gry, w której okres konserwacji został przekroczony, w bazie kodu nowej gry jest całkowicie w porządku i może przyspieszyć.

Niestety cykl życia większości programów, z którymi miałem do czynienia w ciągu ostatnich lat, różni się bardzo od tego. 98% wymagań lub zgłoszeń o naprawę błędów, które do mnie dotarły, to żądania zmianydla istniejących programów. I ilekroć musisz zmienić coś w istniejącym oprogramowaniu, „zarządzanie projektami” lub planowanie działa najlepiej, gdy twoje wysiłki związane z testowaniem i debugowaniem są dość niskie - co nie będzie miało miejsca, jeśli zmienisz coś w jednym miejscu, ale z powodu kopiowania - wklejona logika biznesowa łatwo zapominasz, że musisz zmienić kilkanaście innych miejsc w bazie kodu. I nawet jeśli uda ci się znaleźć wszystkie te miejsca, czas na ich zmianę (i przetestowanie zmian) jest prawdopodobnie znacznie dłuższy, jakbyś miał tylko jedno miejsce do zmiany. Nawet Ty możesz dokonać dokładnego oszacowania zmiany, a koszty kilkanaście razy wyższe, niż trzeba, mogą z łatwością kolidować z budżetem projektu.

TLDR - za każdym razem, gdy tworzysz program, w którym nie ma potrzeby ani odpowiedzialności za naprawianie błędów i konserwację oryginału lub kopii, możesz ją skopiować. Ale jeśli Ty, Twój zespół lub firma jest lub może stać się odpowiedzialna, stosuj SUCHE, gdy tylko możesz.

Przykład

Jako dodatek pozwól mi wyjaśnić, co oznacza „naprawianie błędów i konserwacja” oraz jak prowadzi to do nieprzewidywalności w planowaniu, szczególnie w obrębie jednego produktu, na przykładzie z prawdziwego świata. Rzeczywiście widziałem, jak tego rodzaju rzeczy dzieją się w rzeczywistości, prawdopodobnie nie w 100 przypadkach, ale problemy mogą się nawet rozpocząć, gdy masz tylko jedną zduplikowaną instancję.

Zadanie: utwórz 100 różnych raportów dla aplikacji, każdy raport wygląda bardzo podobnie, pewne różnice wymagań między raportami, inna logika, ale w sumie niewiele różnic.

Twórca, który otrzymuje to zadanie, tworzy pierwsze (powiedzmy, że zajmuje to 3 dni), po pewnych zmianach lub drobnych poprawkach z powodu kontroli jakości i kontroli klienta zakończonej, wydaje się, że działa dobrze. Następnie zaczął tworzyć następny raport, kopiując-wklejając i modyfikując całość, a następnie następny i dla każdego nowego raportu potrzebuje średnio ~ 1 dnia. Bardzo przewidywalne, na pierwszy rzut oka ...

Teraz, gdy 100 raportów jest „gotowych”, program przechodzi do rzeczywistej produkcji i pojawiają się pewne problemy, które zostały przeoczone podczas kontroli jakości. Być może występują problemy z wydajnością, może raporty regularnie się zawieszają, a może inne rzeczy nie działają zgodnie z przeznaczeniem. Teraz, kiedy zastosowano zasadę DRY, 90% tych problemów można rozwiązać, zmieniając bazę kodu w jednym miejscu. Ale ze względu na podejście kopiuj-wklej problem musi zostać rozwiązany 100 razy zamiast raz. A ze względu na zmiany już zastosowane z jednego raportu do drugiego, deweloper nie może szybko skopiować i wkleić poprawki dla pierwszego raportu do drugiego 99. Musi przejrzeć wszystkie 100 raportów, przeczytać je, przetłumaczyć zmianę na zmodyfikowany zgłoś, przetestuj i może debuguj każdy z nich osobno. Dla premiera zaczyna to być naprawdę trudne - może oczywiście poświęcić czas na „zwykłą” naprawę błędu (powiedzmy 3 godziny) i pomnożyć to przez 100, ale w rzeczywistości jest to prawdopodobnie błędna ocena, niektóre poprawki mogą być łatwiejsze do wykonania niż inne, inne mogą być trudniejsze. I nawet jeśli ta ocena jest prawidłowa, koszt debugowania 100 razy wyższy, niż trzeba, będzie kosztować firmę dużo pieniędzy.

To samo stanie się następnym razem, gdy klient poprosi o zmianę koloru emblematu swojej firmy we wszystkich tych raportach, o skonfigurowanie rozmiaru strony lub o inne nowe wymagania, które wpływają na wszystkie raporty w podobny sposób. Jeśli tak się stanie, możesz oszacować koszty i obciążyć klienta 100-krotnością ceny, którą musiałby zapłacić, gdy kod był SUCHY. Spróbuj to jednak kilka razy, a następnie klient anuluje projekt, ponieważ prawdopodobnie nie będzie skłonny pokryć twoich wygórowanych kosztów rozwoju. I może w tym momencie ktoś zadaje pytanie, dlaczego tak się stało, i wskazuje palcem osobę, która podjęła decyzję dotyczącą programowania kopiowania i wklejania.

Chodzi mi o to: kiedy tworzysz oprogramowanie dla innych, zawsze masz przynajmniej na krótki czas odpowiedzialność za stworzenie rzeczy, naprawienie błędów, dostosowanie programu do zmieniających się wymagań itp. Nawet w projekcie typu green-field te są części mogą szybko zsumować znacznie więcej niż początkowo planowane prace rozwojowe. A zwłaszcza, gdy cały twój wklejony kod znajduje się w jednym produkcie, okres odpowiedzialności jest taki sam dla wszystkich części, co jest zupełnie inne niż sytuacja, w której skopiowałeś starszy kod z martwego projektu, który już nie jest w ramach czynnej konserwacji.

Z punktu widzenia zarządzania projektami świetnie jest rozwiązać zadanie, kopiując istniejący kod 100 razy i wprowadzając niewielkie poprawki do każdej kopii, zgodnie z wymaganiami. Przez cały czas dokładnie wiesz, ile pracy wykonałeś i ile pozostało. Wszyscy menedżerowie cię pokochają.

Twoje podstawowe twierdzenie jest nieprawidłowe.

To, co odróżnia oprogramowanie od innych zawodów, polega na tym, że każdego dnia tworzysz coś nowego. W końcu żaden klient nie zapłaci ci za zbudowanie czegoś, co ktoś już zrobił. Kierownicy projektów mogą lubić przewidywalność, ale ich szefowie lubią wartość . Jeśli tylko kopiujesz i wklejasz kod z niewielkimi zmianami, nie zapewniasz firmie dużej wartości.

W końcu firma zda sobie sprawę, że może wykonać tę samą pracę w ułamku czasu, zatrudniając dobrego programistę. A jeśli nie, ich konkurenci to zrobią.

Programowanie metodą wycinania i wklejania prowadzi ostatecznie do porzuconego oprogramowania. Byłem wykonawcą systemu do zamawiania usług przewodowych od bardzo dużej firmy telefonicznej. System był wycinany i wklejany w reklamie, ponieważ wszystkie testy były ręczne i nie chcieli zmieniać żadnego działającego kodu. Najmniejsze ulepszenie może spowodować powstanie nowej kopii setek wierszy kodu. Pierwotnie aplikacja została napisana do obsługi kont do dwunastu fizycznych linii. Oczywiście to ograniczenie zostało wprowadzone w setkach miejsc w kodzie. Po około czterech latach firma zapytała zespół, co trzeba zrobić, aby obsłużyć większe konta. Oszacowali około 18 milionów dolarów. W tym momencie projekt został przekazany zespołowi offshore w celu minimalnej konserwacji. Istniejący zespół został zwolniony.

Organizacje, które myślą w ten sposób, są miażdżone przez firmy z lepszą technologią.

Często zapomnianą maksymą obowiązującą tutaj jest zasada 3 . Oznacza to, że można raz skopiować kod, ale poza tym należy go zastąpić kodem ogólnym.

3 może wydawać się liczbą dowolną, ale częstym scenariuszem jest zduplikowanie danych i logiki w aplikacji i bazie danych. Często cytowanym przykładem jest sytuacja, w której w bazie danych znajduje się tabela odnośników, a po stronie klienta wyliczenia. Różnica w paradygmatach nie pozwala na łatwe przechowywanie tego w jednym miejscu, dlatego informacje często pojawiają się w obu miejscach.

Chociaż dobrze jest mieć kod DRY, może się zdarzyć, że logika biznesowa dyktuje wyjątek, dlatego trzeba utworzyć dwa lub więcej bitów kodu ze źródła, które było wcześniej ogólne.

Więc - co robić? Kod status quo (w końcu YAGNI ). Podczas gdy kod powinien być napisany w celu ułatwienia modyfikacji, napisanie całego szeregu dzwonków i gwizdków dla czegoś, co może nie być potrzebne, to tylko podpalenie pieniędzy.

W swoim pytaniu wymieniasz tylko trzy funkcje zarządzania projektami - oszacowanie, harmonogram i kontrolę. Zarządzanie projektem polega na osiąganiu celów w ramach ograniczeń projektu. Metody stosowane do osiągnięcia celów w ramach ograniczeń projektu są inne w przypadku projektów oprogramowania niż wiele innych rodzajów projektów. Na przykład chcesz, aby procesy produkcyjne były wysoce powtarzalne i dobrze zrozumiane. Jednak tworzenie oprogramowania to głównie praca oparta na wiedzy- nie jest rutyną i wymaga myślenia, a nie sztywnych instrukcji i procedur. Techniki stosowane do inicjowania, planowania, wykonywania, monitorowania i kontroli oraz zamykania projektu oprogramowania będą musiały uwzględniać rodzaj pracy, którą należy wykonać w projekcie oprogramowania - w szczególności prace nierutynowe, których nie można wykonać do konkretnych instrukcji i procedur.

Myślę, że drugi problem polega na tym, że bierzesz DRY, koncepcję związaną z powtarzaniem informacji i próbujesz zastosować je do zarządzania zadaniami. DRY mówi po prostu, że powinieneś mieć tylko jedną wiarygodną reprezentację informacji. Kierownicy projektów powinni to zaakceptować, ponieważ oznacza to, że każdy będzie wiedział, gdzie szukać informacji, komunikowanie zmian będzie łatwe, a zmiany mogą być dobrze kontrolowane i zarządzane. SUSZENIE, dzięki elementom wielokrotnego użytku, pomaga utrzymać długoterminowe koszty na niskim poziomie, pomaga utrzymać długoterminowe harmonogramy i poprawić jakość - trzy części do Trójkąta Zarządzania Projektami . Trzeba zainwestować trochę czasu i pieniędzy, aby skutecznie sprawiać, że rzeczy stają się SUCHE, ale zadaniem kierownika projektu jest kompromis czasu, kosztów, harmonogramu i jakości.

Pisanie nowego kodu to tylko niewielka część zadania

Twoja sugestia ułatwiłaby oszacowanie części początkowego pisania nowego kodu. Jednak faktyczne wprowadzenie czegoś nowego (bez względu na to, czy jest to zupełnie nowy system, dodanie funkcji lub zmiana funkcjonalności) nie jest wystarczające i stanowi jedynie niewielką część pracy - szacunki widoczne w literaturze mówią, że w praktyce część stanowi około 20% -40% całkowitej pracy.

Tak więc większość pracy (w tym dostosowanie początkowego rozwoju do tego, co było rzeczywiście potrzebne, integracja, testowanie, przepisywanie, ponowne testowanie) nie jest łatwiejsza do oszacowania; na odwrót, celowe unikanie DRY spowodowało, że ta część była znacznie większa, trudniejsza i bardziej zmienna w oszacowaniach - ten błąd lub konieczność zmiany, która wymaga zmiany wszystkich sklonowanych części, może się nie zdarzyć, ale jeśli tak, to twoje oceny będą całkowicie w błędzie.

Nie uzyskuje się lepszych szacunków, poprawiając jakość oszacowania niewielkiej części pracy, ale pogarszając dużą część pracy; więc nie jest to tak naprawdę kompromis, ale sytuacja, w której tracisz i tracisz, kiedy masz gorszą wydajność, ale także gorsze szacunki.

OSUSZANIE jest przydatne, ale jest również przereklamowane. Niektórzy ludzie mogą posunąć się za daleko. Wielu programistów nie zdaje sobie sprawy z tego, że za każdym razem, gdy implementujesz DRY w celu użycia tej samej metody do dwóch (nieco) różnych celów, wprowadzasz rodzaj bardzo ścisłego powiązania między różnymi zastosowaniami. Teraz za każdym razem, gdy zmieniasz kod dla pierwszego przypadku użycia, musisz również sprawdzić, czy regresuje on drugi przypadek użycia. Jeśli są to zasadniczo niezależne przypadki użycia, bardzo wątpliwe jest, czy powinny być ściśle powiązane - prawdopodobnie nie powinny.

Nadużywanie DRY może również prowadzić do metod Boga, które eksplodują w złożoności, aby obsłużyć wszystkie różne przypadki użycia, do których są przypisane, podczas gdy ogólnie mniejsze metody atomowe replikujące część kodu byłyby znacznie łatwiejsze do utrzymania.

Sugerowałbym jednak, że pytanie nie jest tak naprawdę istotne na poziomie zarządzania projektem. Kierownik projektu naprawdę nie chce się martwić o ten poziom szczegółowości wdrożenia. Jeśli tak, to prawdopodobnie mikro-zarządzanie. Naprawdę ... to, jak rzeczy są wdrażane, jest bardziej odpowiedzialnością programisty i kierownika technicznego. Zarządzanie projektami bardziej zależy na tym, co zostanie zrobione i kiedy .

EDYCJA: na komentarz, zgadzam się jednak, że w celu ułatwienia oszacowania czasu rozwoju, unikanie DRY może czasami zmniejszyć poziom niepewności. Uważam jednak, że jest to nieistotna kwestia w związku z bardziej palącymi pytaniami: (1) jak długo trzeba czekać na spełnienie wymagań biznesowych, (2) jaki dług techniczny bierze się pod uwagę w procesie i (3) ryzyko związane z całkowitymi kosztami własność dokonanych wyborów architektonicznych - w wielu przypadkach, czy przejść na SUCHO, czy nie, to wybór projektowy, który powinien opierać się bardziej na ryzyku / korzyściach związanych z tymi czynnikami, niż na tym, czy nieco łatwiej jest zapewnić menedżerom projektów bardziej dokładne informacje .

Myślę, że źle rozumiesz SUCHO.

Użyjmy przykładu:

public Class A
{
    public int Multiply(int x, int y)
    {
        return x * y;
    }
}

public Class B
{
    public int Multiply(int x, int y)
    {
        return x * y;
    }

    public int Add(int x, int y)
    {
        return x + y;
    }
}

vs.

public Class C : A
{
    public int Add(int x, int y)
    {
        return x + y;
    }
}

Zastępując klasę B literą C, postępowaliśmy zgodnie z zasadą DRY i ograniczono powielanie kodu. Ale nie zwiększyliśmy niewiadomych ani ryzyka dla projektu (chyba że nigdy wcześniej nie dziedziczyłeś).

Myślę, że to, co masz na myśli, mówiąc o DRY, jest czymś w rodzaju zadania projektowego. To znaczy:

public Class A
{
    public int Multiply(int x, int y)
    {
        return x * y;
    }
}

!!! Nowy wymóg! Niektórzy klienci muszą być w stanie pomnożyć liczby podwójne!

// Use class B for new clients!!
public Class B
{
    public int Multiply(double x, double y)
    {
        return x * y;
    }
}

vs.

public Class A // Version 2
{
    public int Multiply(int x, int y)
    {
        return Multiply(x as double, y as double);
    }

    public int Multiply(double x, double y)
    {
        return x * y;
    }
}

Tutaj (zakładając, że to działa) zaprojektowaliśmy rozwiązanie, które może poradzić sobie zarówno ze starym ORAZ nowym wymogiem, zasadniczo próbując stworzyć matematyczny model rzeczywistego problemu lub reguł biznesowych. W prawdziwym życiu system, który modelujemy, będzie oczywiście znacznie bardziej skomplikowany, nasz model nie będzie dokładnie pasował, a przypadki skrajne i nieoczekiwane wyniki zajmą trochę czasu, aby je znaleźć i poprawić.

Czy w takim przypadku powinniśmy wziąć wersję B lub A w wersji 2?

• B będzie bardziej specyficzny dla rzeczywistej żądanej zmiany z mniejszą liczbą efektów ubocznych oraz będzie łatwiejszy do oszacowania i szybszy.

• Wersja 2 spowoduje zmniejszenie ogólnego kodu i będzie bardziej eleganckim rozwiązaniem

Znowu powiem, że sprowadza się to do jakości specyfikacji i wymagań.

Jeśli mamy bardzo jasne specyfikacje, które obejmują przypadki brzegowe i kompatybilność wsteczną, możemy być pewni, że rozumiemy system wystarczająco dobrze, aby refaktoryzować model bez powodowania błędów.

Jeśli mamy żądanie awaryjne dla jednego klienta, w przypadku którego jedynym wymaganiem jest zmiana zachowania tego klienta bez uwzględnienia całego systemu; następnie „ulepszenie” modelu przez refaktoryzację A niesie ze sobą znaczne ryzyko. Zarówno złamanie innych klientów, jak i przekroczenie terminu z powodu dodatkowego nieznanego czasu potrzebnego na zaprojektowanie i przetestowanie rozwiązania.

Akapit po akapicie

Jedną z najbardziej podstawowych i powszechnie akceptowanych zasad tworzenia oprogramowania jest OSUSZANIE (nie powtarzaj się). Oczywiste jest również, że większość projektów oprogramowania wymaga pewnego rodzaju zarządzania.

Poprawny.

Jakie są teraz łatwe do zarządzania zadania (ocena, harmonogram, kontrola)? Właściwe, powtarzalne zadania, dokładnie takie, których należy unikać zgodnie z DRY.

Powtarzające się zadania powinny być zautomatyzowane, obowiązkowe . Są nudne, podatne na błędy, gdy są wykonywane ręcznie.

Z punktu widzenia zarządzania projektami świetnie jest rozwiązać zadanie, kopiując istniejący kod 100 razy i wprowadzając niewielkie poprawki do każdej kopii, zgodnie z wymaganiami. Przez cały czas dokładnie wiesz, ile pracy wykonałeś i ile pozostało. Wszyscy menedżerowie cię pokochają.

Myślę, że możesz zmienić słowo „adaptacja” za pomocą „konfiguracji”. Rozważ, że masz błąd w tym fragmencie kodu, który ma zostać skopiowany. Błąd pojawiający się w określonych warunkach. Jeśli nie zostanie to naprawione w oryginalnym źródle i zostanie skopiowane, będzie wiele miejsc do naprawienia. Może to być złe, ale wtedy ktoś musi:

• najpierw popraw kod w oryginalnym źródle;
• napraw kod w każdym innym miejscu;
• upewnij się, że to były wszystkie miejsca. Kiedy powiesz, że to musiało zostać zrobione kierownikowi, prawdopodobnie przynajmniej kogoś nienawidzi.

Jeśli zamiast tego zastosujesz zasadę DRY i spróbujesz znaleźć abstrakcję, która w mniejszym lub większym stopniu eliminuje duplikat kodu, sprawy wyglądają inaczej. Zwykle jest wiele możliwości, musisz podejmować decyzje, prowadzić badania, być kreatywnym. Możesz znaleźć lepsze rozwiązanie w krótszym czasie, ale możesz także zawieść. Przez większość czasu tak naprawdę nie można powiedzieć, ile pozostało pracy. Jesteś najgorszym koszmarem kierownika projektu.

Usunięcie duplikatów prowadzi do pojedynczego punktu awarii. Jeśli coś zawiedzie, możesz być całkiem pewien, gdzie to się dzieje. Wzory SOLID i wzorce projektowe pomagają rozwiązać dokładnie ten problem. Zbyt krótkie terminy zwykle wywołują „kodowanie” proceduralne. Więcej czasu zainwestowanego w jeden projekt w celu stworzenia czegoś do ponownego użycia oznacza, że ​​minimalna ilość czasu powinna zostać poświęcona w następnym projekcie, kiedy funkcja będzie ponownie używana, ale powinna być konfigurowalna w pierwszej kolejności.

Oczywiście przesadzam, ale oczywiście istnieje dylemat. Moje pytania brzmią: Jakie są kryteria decydujące o tym, czy programista przesadza z SUCHYM? Jak znaleźć dobry kompromis? A może istnieje sposób na całkowite przezwyciężenie tego dylematu, nie tylko poprzez znalezienie kompromisu?

Wiele osób wskazało, że nie ma tu dylematu. Tak i nie.

Jeśli masz coś wysoce eksperymentalnego, czego nigdy wcześniej nie robiono - nie ma dylematu. W przeciwnym razie, jeśli masz coś, co trzeba zrobić ponownie, np. Nowy system rezerwacji, masz już abstrakty, zależy tylko od tego, czego potrzebujesz.

Myślę, że dylemat polega na tym - czy powinniśmy wdrożyć coś w funkcji, jeśli jest mało prawdopodobne, aby o nią poprosić. Zaimplementuj coś na żądanie. Nikt nie potrzebuje ogromnej infrastruktury, która nie będzie używana.

w ogóle nie chodzi tu o projektowanie do ponownego użycia ani o zasadę YAGNI. Chodzi o powtarzanie kodu w bieżącym pakiecie roboczym.

Absolutnie chodzi o design. Może nie do ponownego wykorzystania jako takiego , ale mimo to projektuj.

Jakie są kryteria decydujące o tym, czy programista przesadza z OSUSZANIEM?

Doświadczenie i twoje istniejące środowisko / sytuacja. W przypadku danego problemu nabierzesz silnego poczucia zasady Prado, gdy będziesz próbował większego stopnia SUSZENIE. Nagle pojawiają się rozważania dotyczące zarządzania. Czas, cele, klient, długoterminowe zarządzanie kodem (ktoś powiedział, że ma dług techniczny ) itp. Poinformuje o twoim planie ataku.

Jak znaleźć dobry kompromis?

Uh ... projekt? Refaktoryzacja to projekt, a powinien być. Zakres DRYing może łatwo rozszerzyć się jak super nowa z pętli, do metody, do klasy (klas). Byłem tam, zrobiłem to. Ale tak naprawdę nie możesz wiedzieć, dopóki nie przestudiujesz problemu - to jest projekt.

Jak może nie być problemem projektowym? Musisz rozważyć ten problem szerzej niż natychmiastowy zduplikowany kod. Jest to działanie projektowe, niezależnie od tego, czy jest to istniejący kod, czy pusty arkusz; czy jest to „metoda wyodrębniania”, czy tworzenie nowych klas i modułów.

Epilog

... zadane pytanie i jego odpowiedzi nie obejmują aspektu zarządzania projektem.

Typowe zarządzanie, ignorowanie czasu projektowania. Idealnie byłoby zaprojektować zbędną zbędną powtarzalność przed kodowaniem. Zamiast tego kierownictwo uważa, że ​​rozwój (i poprawki błędów) jest pojedynczym wydarzeniem olimpijskim - kodowaniem - podczas gdy w rzeczywistości jest to dziesięciobój. Mierzą z dokładnością do 1/1000 sekundy, ponieważ uważają, że to wszystko analog.

Jeśli zamiast tego zastosujesz zasadę OSUSZANIA i spróbujesz znaleźć abstrakcję, która w mniejszym lub większym stopniu eliminuje duplikat kodu, sprawy wyglądają inaczej.

Miałem takie doświadczenie: „Spędziłem dwa dni pisząc ten wiersz (formularza GUI) i dwie godziny pisząc resztę formularza”. Mam na myśli, że poświęciłem czas na identyfikację klas wielokrotnego użytku - SUCHY jest naturalnym efektem ubocznym - GUI z wiersza i w / w tym innych. Po debugowaniu były one stosowane indywidualnie i w składzie w całej formie, która teraz kodowała się bardzo szybko, a testowanie było wyjątkowo szybkie pomimo narastającej złożoności. I przeszedł także formalne testy z zadziwiająco niskim wskaźnikiem błędów.

Przez większość czasu tak naprawdę nie można powiedzieć, ile pozostało pracy. Jesteś najgorszym koszmarem kierownika projektu.

Ja też nie wiedziałem, ale wierzyłem, że wysiłek włożony w projektowanie przyniesie efekty. Wszyscy to mówimy, ale zarząd w szczególności nie ufa. Zarząd pomyślałby, że się pieprzę. „Dwa dni, a nie masz jeszcze 2% zakodowanych!”

W jednym przypadku trzymaliśmy się broni, gdy kierownictwo powiedziało: „spędzasz zbyt dużo czasu na projektowaniu, zaczynaj”. I współpracownicy mówią „to za dużo klas”. Cóż, o wiele mniej skomplikowany podprojekt miał zająć około 1 miesiąca (myślałem, że to OK, ale chyba 5 miesięcy). 3 miesiące trwały testy / naprawy, ponieważ był to taki POS. „Ale nie mieliśmy czasu na projektowanie!”. Właściwie to powiedzieli.

Moje pytania brzmią: Jakie są kryteria decydujące o tym, czy programista przesadza z SUCHYM? Jak znaleźć dobry kompromis? A może istnieje sposób na całkowite przezwyciężenie tego dylematu, nie tylko poprzez znalezienie kompromisu?

Pokaż zarządzanie, jak to działa. Przechwyć niektóre dane. Porównaj z innymi pracami, zwłaszcza z twoimi współpracownikami, którzy wykonują pośpiech w pośpiechu. Ta kupka porażek zawsze wydaje się przegrywać wyścig, utknąć w teście, a następnie po wydaniu wracała w kółko, aby naprawić więcej błędów.