Czy DRY jest wrogiem zarządzania projektami oprogramowania?

83

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 :).

Frank Puffer
źródło
96
Daj nam znać, jak czują się Twoi menedżerowie zarządzania projektami, gdy przychodzi czas na wytropienie, zmianę i przetestowanie czegoś we wszystkich 100 przypadkach kopiowania i wklejania. I nie zapomnij o dodatkowym czasie, który zostanie poświęcony na zastanowienie się, dlaczego tak się dzieje, ponieważ tylko 98 z nich zostało zmienionych.
Blrfl,
16
@Blrfl, z drugiej strony, przedwczesne OSUSZANIE kodu, zanim dobra abstrakcja jest jasna, może naprawdę zaszkodzić produktywności, ponieważ wspólna abstrakcja jest wspólną zależnością. Nie zgadzam się, po prostu, wskazując, że zdecydowanie można znaleźć równowagę.
GoatInTheMachine
16
Zasada, która uniemożliwia DRY wymknięcie się spod kontroli, to zasada YAGNI (nie będziesz jej potrzebować) .
Philipp
88
Nie ma dylematu. Jeśli kierownik projektu chce, abyś wykonał dużo zbędnej pracy ręcznej, ponieważ łatwo to oszacować, oczywistym rozwiązaniem jest zwolnienie kierownika projektu.
JacquesB
10
Jeśli powtórzysz się, nadal będziesz musiał wykonać całą tę trudną do oszacowania pracę , a także dodatkową pracę bezcelową. Jak to pomaga projektowi?
immibis

Odpowiedzi:

134

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.

JacquesB
źródło
21
Całkowicie zgadzam się z twoimi twierdzeniami tutaj, ale myślę, że należy zauważyć, że istnieje wielu kiepskich kierowników projektów, którzy naprawdę wolą przewidywalność niż szybkość lub jakość. Większość ludzi, którzy nie mają szkolenia w zakresie zarządzania projektami, dowiadują się o tym, co wiedzą o tym, co widzieli, a moje doświadczenie jest takie, że kierowników projektów, którzy potrafią radzić sobie z niepewnością w spokojny, racjonalny sposób, jest niewielu.
JimmyJames,
5
@FrankPuffer Byłem tam. Jak długo to zajmie? Jedną z opcji jest podanie zakresu. Przeczytaj o PERT, a konkretnie o szacunkach 3-punktowych, ponieważ powinni już o tym wiedzieć. Procent ukończony? To jest najbardziej denerwujące. Spróbuj to zignorować, ale jeśli nie pamiętasz, że jest to procent czasu, a nie procent zakodowanych linii lub cokolwiek innego. To, co naprawdę chcą wiedzieć, to kiedy zostanie ukończone? Na początku podaj konserwatywne prognozy dotyczące każdego zadania i udoskonalaj je w miarę upływu czasu. Czekanie do ostatniej chwili, by powiedzieć, że masz więcej czasu, doprowadzi ludzi do szaleństwa.
JimmyJames,
11
Jak długo to zajmie? Jestem 60% pewien, że możemy ukończyć to x, ale istnieje 10% szansa, że ​​zajmie to pięć razy dłużej.
David
18
@David: Prawdopodobnie doprowadziłoby to do szaleństwa premiera, ponieważ z doświadczenia wie, że to 10% szansy na trafienie zdarza się w 80% przypadków :)
Frank Puffer
7
Rzeczywistość jest taka, że ​​wiele miejsc chciałoby wyśledzić projekt, a potem odnieść niespodziewany sukces. Premierzy często są nagradzani za dokładne prognozy, więc mają przewrotne zachęty. To jest problem głównego agenta .
Sled
39

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.

Doktor Brown
źródło
4
Prawdopodobnie dobra odpowiedź, ale zbyt szczegółowa w porównaniu do innych dobrych odpowiedzi.
Vince O'Sullivan,
4
Możesz zignorować DRY, gdy „kopia nie będzie musiała być utrzymywana ani ewoluowana w przyszłości”, ale kod, który nigdy nie będzie ponownie używany, często i tak się kończy.
Andy Lester,
„kopiuj-wklej działa świetnie ...” - nie zgadzam się! Nawet jeśli program jest jednorazowy i gwarantuje, że nigdy nie ewoluuje poza początkową wersję, kod kopiuj-wklej nadal sprawia, że ​​znacznie więcej pracy i ryzyka naprawia błędy znalezione podczas opracowywania początkowej wersji programu. Chyba że nigdy nie popełniasz błędów, w takim przypadku jesteś Bogiem.
JacquesB,
1
@JacquesB: powinieneś uważniej przeczytać moją odpowiedź, nie napisałem nic innego.
Doc Brown
Programowanie komputerowe różni się od budowania identycznych maszyn za pomocą linii montażowej. Huh Kto by to zgubił? Może powinniśmy mieć programistów pracujących jako premierzy. Ale wtedy potrzebowalibyśmy programistów jako menedżerów. Programiści jako akcjonariusze. Programiści jako klienci ... Strzelaj, po prostu naucz wszystkich, jak programować i jak to zrobić. (Innymi słowy: nie-eksperci nigdy nie zrozumieją perypetii znanych przez ekspertów.)
19

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ą.

Telastyn
źródło
2
Twierdziłbym,
12
@ BlueRaja-DannyPflughoeft: Nie bardzo. Pracując jako inżynier elektronik / elektryk, mogę zaświadczyć, że większość zawodów inżynieryjnych na dużą skalę (projekty wymagające uruchomienia, takie jak budowa statków i elektrowni) polega na upewnieniu się, że ludzie robią coś, co zostało wypróbowane i przetestowane, aby zrobiło to poprawnie. To właśnie biznes uważa za „inżynierię”. Robienie czegoś nowego to „R&D”
slebetman,
3
@slebetman Może po prostu nie zauważyłeś całej pracy, którą wykonało twoje zarządzanie; nawet jeśli ciągle robisz to samo, środowisko zmienia się za każdym razem - nie masz szablonu elektrowni, który możesz po prostu dostarczyć klientowi i zrobić to, musisz przeprowadzić ankietę, dowiedzieć się, jak zaopatrzyć zakład w surowce i wycofać produkt z powrotem, zarządzać wszystkimi surowcami do budowy oraz radzić sobie z problemami z zaopatrzeniem i brakami pracy oraz milionem innych rzeczy. Wygląda na to, że działa szablon (jak wiele wysiłków programistycznych), ale tak naprawdę nie jest.
Luaan,
1
@Luaan: Tak, ale nic z tego nie robi czegoś nowego. Wszyscy „robią coś, co umiemy”. Rozwój oprogramowania jest inny. Przede wszystkim dlatego, że w oprogramowaniu, w przeciwieństwie do projektów inżynierii fizycznej, mamy tendencję do enkapsulacji rzeczy, które już wiemy, jak robić w bibliotekach, więc nie musimy ręcznie „przeprowadzać ankiet” itp. Po prostu zaimportujemy bibliotekę i wykorzystamy ją .
slebetman
2
@slebetman Prawie całe pisane oprogramowanie to „coś, co wiemy, jak to zrobić”. Biblioteki żyją również w środowisku, które zawsze się zmienia. I nie masz 100% wiedzy i doświadczenia z całą biblioteką, i wszystkimi zależnościami tej biblioteki i innych zależności, które masz, i jest wiele dziwnych systemów i konfiguracji sprzętowych, które po prostu odmawiają działania tak, jak powinien rozsądny system praca. Kapsułkowanie jest świetne, ale wciąż jest drogie jak diabli i wymaga wielu badań. I technika ma hermetyzacji też - prefabrykowane bloki, układy scalone itp
Luaan
12

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ą.

Kevin Cline
źródło
Uważa, że ​​to lepszy mózg niż lepsza technologia. Technologia pochodzi z mózgu, prawda? Cokolwiek się stało z „Think Smarter, not harder”?
10

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.

Robbie Dee
źródło
6
Pamiętaj, że oznacza to, że powinieneś komentować, że skopiowałeś kod (w obu miejscach), abyś wiedział, że jeśli chcesz go skopiować ponownie, nie powinieneś!
Mark Hurd
3
Zrobiłem to w przypadku, gdy dwie klasy potrzebowały tej samej metody, ale ledwo były ze sobą powiązane - coś w rodzaju odległych kuzynów. Musiałbym dodać zależności do prawie tuzina klas, aby faktycznie dzieliły kod. Podobało mi się więc to, co zasugerował Mark - skopiowałem i wkleiłem metodę, a także zostawiłem duży, oczywisty komentarz, który wskazywał inne miejsce dla tej metody.
Jeutnarg,
@MarkHurd Tak - świetny punkt ...
Robbie Dee,
8

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.

Thomas Owens
źródło
Jasne, tworzenie oprogramowania to praca oparta na wiedzy. Właściwie nie uważałbym nawet mojego pierwszego przykładu (kopiuj / wklej) za programowanie w ścisłym tego słowa znaczeniu. Jednak zarządzanie tego typu pracą jest znacznie trudniejsze, więc premier, nawet jeśli ma doświadczenie w rozwoju i wie o tym wszystkim, w swojej roli jako premier zwykle go ignoruje. (Nie mówię, że to dobra rzecz, to właśnie obserwowałem wiele razy. Nie sądzę też, że ci PM są głupi lub niekompetentni. Bardziej przypomina to rolę, która czasami zmusza ich do działania w ten sposób. )
Frank Puffer
3
@FrankPuffer Nie zgadzam się, że rola kierownika projektu zmusza osobę do podejmowania konkretnych decyzji. Bardziej prawdopodobne jest, że jest to siła edukacyjna lub organizacyjna. Z tego, co widziałem, większość edukacji w zakresie zarządzania projektami koncentruje się na bardziej tradycyjnych technikach zarządzania projektami (prawdopodobnie dlatego, że są one częściej stosowane w większej liczbie projektów) niż technikach zarządzania projektami. Może to przeniknąć do organizacji, które tego oczekują i nie patrzą na inne techniki zarządzania projektami opartymi na wiedzy, takimi jak tworzenie oprogramowania.
Thomas Owens
2
@FrankPuffer Na pewno jest trudniejszy, ale zapewnia większą wartość. Jeśli szef twojego szefa jest wystarczająco bystry, pozbywa się menedżera, który próbuje „ułatwić sobie życie” i znajduje kogoś, kto rzeczywiście może wykonywać swoją pracę. Nie zrozumcie mnie źle, jeśli ułatwianie rzeczy zapewnia wartość, wybierzcie ją - ale w tym, co opisacie, jest to prawie na pewno ze szkodą dla wartości końcowej.
Luaan,
4

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.

Piotr jest
źródło
Trafne spostrzeżenie. Jednak DRY lub podobne zasady dotyczą również innych zadań, takich jak testowanie lub integracja. Większość rzeczy można zrobić w sposób mechaniczny, bez większego zastanowienia lub w bardziej inteligentny sposób. Inteligentne rozwiązania są często znacznie szybsze, ale wiążą się z ryzykiem niepowodzenia. Ponadto musisz włożyć w to sporo pracy, zanim uzyskasz jakikolwiek wynik.
Frank Puffer,
Nie ma „ryzyka awarii”, istnieje pewność awarii. Wcześniej czy później wszystko zawiedzie. Po prostu wybierasz, jak drogi jest karawan i jak szybko jeździsz.
4

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 .

Brad Thomas
źródło
Oczywiście kierownik projektu nie powinien zajmować się szczegółami wdrożenia. Nie o to mi chodzi. Chodzi mi o to, że w zależności od sposobu, w jaki programista coś implementuje, jest on mniej więcej w stanie dostarczyć informacje wymagane do zarządzania projektem.
Frank Puffer,
Nie ma dla mnie sensu uszkadzanie / ograniczanie produktu lub zaciąganie długu technicznego po prostu po to, aby móc lepiej o nim raportować. Wartość raportu z pewnością musi być o rząd wielkości niższa niż wartość pracy wysokiej jakości. Ale YMMV
Brad Thomas
Może programiści powinni otrzymywać wynagrodzenie o wielkości większe niż menedżerowie?
2

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.

Ewan
źródło
7
Nie zgadzam się Dziedziczenie nie jest czymś, co robisz raz, a potem opanowujesz. Istnieje wiele pułapek. Istnieją powody, dla których kompozycja powinna być preferowana nad dziedziczeniem. Musimy więc podjąć decyzję: Dziedziczenie? Kompozycja? Coś innego? Ta decyzja będzie prawdopodobnie trudna w prawdziwym świecie. W drugim przykładzie istnieje również wiele alternatyw. Co z rodzajami / szablonami? Czy może jakieś funkcjonalne podejście z wykorzystaniem lambdas? Ponownie: Wiele możliwości, z których każda będzie miała określone implikacje.
Frank Puffer,
4
Chodzi o to, że w pierwszym przykładzie dosłownie usuwasz zduplikowany kod za pomocą dowolnej metody. ale dokładnie ten sam kod działa w obu kierunkach. Zatem nie ma żadnej zmiany funkcjonalności. W drugim przykładzie zmienić podejście do czegoś którego nadzieja jest funkcjonalnie eqivilant ale aktualnie znajduje się inny kod
Ewan
1
Byłem w sytuacji, w której twoja „prośba o pomoc” była normą. Firma, w której pracowałem, stworzyła niestandardowe systemy danych dla wielu różnych klientów. Najpierw stworzyli jeden system z Cobolem, a następnie skopiowali go dla następnego klienta itp., Dopóki nie mieli 100 klientów. Teraz mieli pracę nad sobą, próbując dokonywać systematycznych ulepszeń i aktualizacji. Pracowałem nad systemem, który mógłby replikować zachowanie większości tych systemów, używając jednego zestawu kodu źródłowego, ale dostosowań przechowywanych w danych konfiguracyjnych. Nie mogliśmy zrobić wszystkiego, a niektórych rzeczy nie można było dodać.
1

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.

Bakudan
źródło
Zaimplementuj coś teraz w prosty, szybki sposób, ponieważ było to wymagane. Później, gdy potrzebny jest złożony sposób, oryginalny wysiłek jest na nic, trzeba zacząć od nowa. Managerowi się to nie podoba. Jakby powiedziałeś: „Czas spędzony na jeździe na zachód był bezużyteczny, jeśli teraz musimy jechać na wschód”. Ale podróżowanie po całym świecie po raz pierwszy, abyśmy mogli cały czas iść na wschód, to także zmarnowany czas.
1

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.

radarbob
źródło
„Zmierz mikrometrem, zaznacz kredą, wytnij siekierą”.