Jeśli ktoś zaproponuje niezweryfikowane oświadczenie dotyczące praktyk tworzenia oprogramowania, czy odpowiadasz „cytatem potrzebnym”? [Zamknięte]

14

Niedawno wziąłem udział w wykładzie wygłoszonym przez Grega Wilsona (głównego naukowca oprogramowania Carpentry). Z streszczenia:

Pomysł, że twierdzenia o praktykach tworzenia oprogramowania powinny opierać się na dowodach, jest wciąż obcy dla programistów, ale w końcu zaczyna się zmieniać: każdy naukowiec, który twierdzi, że dane narzędzie lub praktyka sprawia, że ​​tworzenie oprogramowania jest szybsze, tańsze lub bardziej niezawodne, jest teraz oczekuje się, że poprze to twierdzenie jakimś studium empirycznym.

Podsumowując, wykład był bardzo pouczający i pozwolił mi głęboko przemyśleć moje podejście do rozwoju. W szczególności szukam teraz cytatów na poparcie wielu stwierdzeń. Wcześniej przyzwyczaiłem się po prostu powtarzać oferowane prawdy, być może z uwagą, by sprawdzić to później.

Mówiąc wprost, byłem łatwowierny .

Oto przykład wzięty z wykładu:

„Jeśli ponad 25% kodu wymaga refaktoryzacji, szybciej go przepisać”.

Brzmi realistycznie, ale czy to prawda? Gdzie badanie to potwierdza? Czy to prawda dla wszystkich języków? I tak dalej.

OK, całkiem możliwe jest doprowadzenie tego do skrajności i nie uwierzenie nikomu, chyba że sam wyprowadziłeś to z pierwszych zasad. W ten sposób leży szaleństwo (a może matematyka ;-)). Ale jeśli ktoś podejdzie do ciebie z oświadczeniem w stylu „Hej, robiąc to w [wybierz język chwili] będziemy w stanie zwiększyć wydajność o [wybrać wielokrotność 10]%”, czy jesteś skłonny po prostu zaakceptować, czy też poprosisz o udowodnione dowody?

Jeśli to ten drugi (i mam nadzieję, że tak jest), to

  1. gdzie byś poszedł znaleźć te dowody?
  2. jak surowy byłbyś?

Krótko mówiąc, jeśli ktoś zaoferuje niezweryfikowane oświadczenie, czy odpowiesz „cytatem potrzebnym”?

Gary Rowe
źródło
2
W ilu dziedzinach poza nauką ludzie wymagają dowodów empirycznych? Z moich obserwacji wynika, że ​​nie tak wiele, jak bym chciał.
David Thornley,
1
Co powiesz na komentarze na temat zamkniętych głosów? „Zbyt zlokalizowane” i „To nie jest prawdziwe pytanie” nie jest w tym kontekście oczywiste.
Inaimathi,
1
Tak, ja też chciałbym poznać uzasadnienie bliskich głosów.
Robert Harvey
@Robert Dzięki za edycję. O wiele mniej zapalny po odbiciu.
Gary Rowe,
1
Świetne pytanie. Widziałem, jak prof. Wilson przemawiał w CUSEC w zeszłym roku i był pod dużym wpływem tego, co miał do powiedzenia. Najlepsze było to, że uczeń rzucił mu wyzwanie, by zacytował swoje twierdzenie, że roszczenia powinny być cytowane, i zrobił to bez wahania.
Mateusz

Odpowiedzi:

3

Problem z tego rodzaju stwierdzeniami polega na tym, że nawet gdybyś miał dowody empiryczne na poparcie twierdzenia, bardzo trudno byłoby ustalić, czy badanie, które prowadzi do dowodów, ma zastosowanie w twojej obecnej sytuacji.

Prawie wszystko w zawodzie ma zastrzeżenie, lub kilka, więc każda poprawa w jednym miejscu ma szansę być niekorzystną sytuacją w innym miejscu.

Ludzie w okopach znają różnicę poprzez doświadczenie i generalnie nie mają funduszy / czasu / zasobów, aby spróbować udowodnić to poprzez badania naukowe.

Ludzie, którzy próbują to udowodnić za pomocą badań naukowych, oczywiście mają zasoby, które mogą poświęcić na takie badania, i dlatego bardzo prawdopodobne jest, że coś ci sprzedadzą, więc powiedziałbym, że powinieneś jeszcze bardziej rygorystycznie stosować swoje osobiste doświadczenie do wszystkiego, co twierdzi poparte badaniami empirycznymi.

Gdyby ktoś powiedział ci: „Jeśli więcej niż 2% kodu wymaga refaktoryzacji, szybciej go przepisujesz”, wiedziałbyś, że jest to fałsz, tak jakby ktoś powiedział ci „Tylko jeśli więcej niż 98% kodu wymaga refaktoryzacji, to szybciej to przepisać ". Gdzie rzeczywista liczba zależy od tego, co robisz i jak daleko od ideału jest obecny kod.

Pomysł, że po pewnym momencie łatwiej jest zrobić reaktor jądrowy, jest oczywiście prawdziwy w wielu przypadkach, ale faktyczny odsetek stanowi raczej przykład, który należy rozważyć poprzez pryzmat własnego doświadczenia (zespołu) i obecnej sytuacji.

Rachunek
źródło
+1 za dokładną analizę przykładowej instrukcji. Czy naprawdę sądzisz, że wszystkie badania naukowe mają komercyjny charakter, który należy wykorzystać? (Wybacz mi naiwność, ale naprawdę jestem tego ciekawy)
Gary Rowe
@Gary: Wszystkie rzeczy są idealne nie, ale bardzo trudne jest, jeśli nie niemożliwe, ustalenie stronniczości badania z zewnątrz. Podwójnie, gdy nie ma uzgodnionych wskaźników obejmujących całą sytuację
Bill
8
Jeśli ktoś zaproponuje niezweryfikowane oświadczenie dotyczące praktyk tworzenia oprogramowania, czy odpowiadasz „cytatem potrzebnym”?

Nie, umieszczam go tutaj i sprawdzam, czy otrzyma jakieś pozytywne opinie. Dowód społeczny jest lepszy niż brak dowodu!

Steven A. Lowe
źródło
2
Ten model może ci się przydać, ale wzdrygam się na myśl o artykule podającym programmers.SE jako źródło.
Inaimathi,
@Inaimathi: jest przynajmniej tak wiarygodna jak wikipedia, jeśli nie bardziej!
Steven A. Lowe,
+1 za szukanie dowodu - zawsze dobra rada. Ile głosów przychodzących, zanim w to uwierzysz? ;-)
Gary Rowe,
1
@Gary: na SO, dziesięć. na tej stronie, dwadzieścia. na meta, sto - chyba że dotyczy jednorożców i gofrów, w takim przypadku musi to być prawda
Steven A. Lowe
Uwielbiam ten jednorożec - muszę zdobyć jednego z nich
Gary Rowe,
4

Wielu programistów opiera swoje decyzje od chwili do chwili na doświadczeniu w okopach pracujących z kodem i klientach, którym ten kod służy.

Gdy klasa lub metoda została tak rozdrobniona przez poprawki błędów i prośby o zmianę klienta, że ​​stała się niemożliwa do utrzymania, programista czasami podejmie decyzję o jej przepisaniu zamiast refaktoryzacji, zgodnie z teorią, że zaoszczędzi czas i wysiłek w dłuższej perspektywie , ponieważ wynikowy kod będzie wyższej jakości.

Tego rodzaju inteligencję doświadczeń nazywają działy HR „kapitałem ludzkim”. Jest to jedna z rzeczy, które sprawiają, że doświadczeni programiści są cenni, i jeden z powodów, dla których dobre firmy robią wszystko, aby starać się zachować długowieczność swoich ludzi.

Prośba doświadczonych programistów o przedstawienie badań i danych empirycznych jako dowodu, że ich techniki są prawidłowe, nie wydaje się sprawiedliwe ani praktyczne. Doświadczenie nie działa w ten sposób. Przeciwnie, doświadczenie jest czymś w rodzaju „odczuwania zmysłu”. W świecie refaktoryzacji często nazywamy to „zapachem”.

Ostatecznie stwierdzenie typu „Jeśli więcej niż 25% kodu wymaga refaktoryzacji, szybciej go przepisać” nie może zostać udowodnione, że działa w każdych okolicznościach, więc stwierdzenie [potrzebne źródło] jest naprawdę sposobem na poinformowanie programisty dogmatycznego, który stara się narzucić innym swoje poglądy, że nie zawsze jest to „Jego droga lub autostrada”.

Robert Harvey
źródło
Ach, stary, dobry kapitał ludzki i zasoby ludzkie, te cudowne bliźniacze frazy promujące trwającą dehumanizację robotników na całym świecie ...
Aaronaught,
@Aaronaught: Wykonanie pomysłu może czasami nie spełniać wzniosłego słownictwa używanego do jego opisania. Dlatego sceptyczni ludzie czasami proszą o dowód.
Robert Harvey
Czy nie byłoby dobrze, gdyby realizacja tych konkretnych koncepcji nie udała się?
Aaronaught,
+1 za dobre wykorzystanie obrony „potrzebnego cytatu” przed programistą dogmatycznym - bardzo przydatne
Gary Rowe
4

Myślę ze wszystkim, czego nigdy nie wiesz, dopóki tego nie spróbujesz. Nawet z dowodem na potwierdzenie oświadczenia, zawsze można nagiąć fakty z korzyścią dla twojego punktu widzenia. Biorąc to pod uwagę, nie powinieneś próbować każdej nowej rzeczy, która uderza w interweby. Dokonaj najlepszego osądu. Pamiętaj, że jeśli coś brzmi zbyt dobrze, aby mogło być prawdziwe, prawdopodobnie tak jest. Zawsze pytaj siebie, dlaczego musisz coś adoptować? Co musisz zyskać? Czy ma to sens z perspektywy biznesowej? Nigdy nie zaślepiony, z wyjątkiem wiary.

Carlosfocker
źródło
+1 za pytanie „dlaczego musisz coś adoptować”. Czasami cofnięcie się od krawędzi prowadzącej jest dobrą rzeczą.
Gary Rowe,
Uważam, że zbyt często programiści wpadają w kolejną najlepszą rzecz, nie analizując jej i nie rozumiejąc, w jaki sposób może to przynieść im korzyści i zniechęcić. Widziałem sytuacje, w których organizacje stosują coś takiego jak Asp.Net MVC zamiast Asp.Net Webforms, ale nie przyjmują TDD.
Carlosfocker,
3

Przykład z wykładu to heurystyka, zasada praktyczna i nic więcej. To powinno być domyślnie oczywiste.

Heurystyka jest jak wszystko inne: podlegają one określonemu kontekstowi i zależą od dowolnej liczby nieokreślonych założeń, a ich przydatność może być bardzo niedeterministyczna. Tyle samo arbitralnego osądu idzie na uznanie ich za przydatne, co przede wszystkim na sformułowanie ich.

Czy to oznacza, że ​​są bezwartościowi? W ogóle bym tego nie powiedział.

Heurystyka jest jednym z podejść, które możemy zastosować w celu rozwiązania problemów związanych z NP-zupełnością, a pod wieloma względami inżynieria oprogramowania sama w sobie jest problemem kompletnym dla NP.

Adam Crossland
źródło
Słuszne uwagi. =)
Pablo,
1

To zależy. :) Gdy czyjaś wypowiedź zaprzecza powtórzeniu, refleksji i osobiście zweryfikowanemu doświadczeniu, wtedy tak, chciałbym zobaczyć jakieś odniesienie do badania. Z drugiej strony, jeśli ktoś powtarza pomysł, który wiele razy widziałeś i żyłeś, reakcja nie była zbyt duża (nie oznacza to, że pomysł jest nieomylny).

Na przykład książka „Code Complete” przytacza dziesiątki badań w każdym rozdziale, aby przedstawić swoje uwagi, czasem na temat pozornie drobnych kwestii (takich jak wcięcia i odstępy lub długość nazwy zmiennej). Pamiętam niektórych (młodszych) programistów, którym wprowadziłem książkę do myślenia, że ​​ten poziom szczegółowości i dowodów jest głupi. Ale kilka miesięcy później, mając więcej doświadczenia w kodowaniu produkcji i po kilku recenzjach kodu, niektórzy z tych samych programistów mieli uczciwość przyznać, że tak, nawet liczba miejsc w wcięciach ma znaczenie. Dobre komentarze mają znaczenie. Kapsułkowanie ma znaczenie. itd itd.

Z drugiej strony, gdy sprzedawca twierdzi, że nowe IDE jest o 50% wydajniejsze, moją pierwszą reakcją jest byk $% ^ &!

limist
źródło
1
To zależy, ale nawet pełne przykłady kodu zależą od twojej sytuacji. Na przykład: jeśli masz parsujący formater, a twoje narzędzie do porównywania ignoruje białe znaki, to argument wcięcia staje się dość trywialny
Bill
1
+1 za przykład Kod Complete (również w przypadku Rapid Development autorstwa tego samego autora Steve'a McConnella).
Gary Rowe,
@Bill Ciekawe, że w miarę jak technologia poprawia problemy, które wymagały wcześniej dowodu, znikają. Zastanawiam się, czy to efekt, który zmniejsza naszą potrzebę prośby o dowód?
Gary Rowe,
1
@ Gary Nie sądzę, że to (w ogólnym sensie) jest zarówno poprawą, jak i odmianą. Przykłady kompletnego kodu odnoszą się zdecydowanie do określonego zestawu narzędzi w określonym momencie, więc są oba, ale typ „kiedy refaktoryzować” ma znacznie więcej wspólnego z sytuacją niż z technologią. Pomyśl o kluczowym dla bezpieczeństwa oprogramowaniu w pojeździe w porównaniu z rozwiązaniem do przetwarzania danych. Wymagania dotyczące testowania będą znacznie wyższe w systemie bezpieczeństwa, więc punkt refrakcji zawsze będzie znacznie wyższy, zanim nastąpi zysk netto.
Bill
1

Czy nie jest to coś, co zależy od wielu zmiennych niematerialnych (zmiennych, których naukowo nie można zmierzyć)?

Moim zdaniem mówią o empirycznej metodzie pomiaru emocji. Coś, czego nawet Spock nie mógłby osiągnąć. =)

Pablo
źródło
1
+1 za interesujące podejście. Odkładając (celowo) wełniany przykład na bok, jeśli ktoś powiedziałby wam, że Rails jest lepszym szkieletem niż SpringMVC, jak byście poszli o ustalenie jego ważności?
Gary Rowe,
Jak stwierdza Benjamin Graham w swojej klasycznej książce o inwestowaniu („Analiza bezpieczeństwa”), narzędzia (inwestycyjne) miały być mierzone w dwóch różnych, ale samotnych aspektach: jakościowym (wartości niematerialne, uczucia) i ilościowym (liczby rzeczywiste, matematyka) , obliczenia, logika).
Pablo
Ilościowy jest tym, co mierzysz metodą naukową. Jakościowy jest tym, co mierzysz własnym instynktem. Nie ma możliwości oceny emocji względem emocji bez posiadania emocji związanych z analizą.
Pablo
Mówiąc co najmniej, kiedy mówimy o opiniach i różnicach w nich, po prostu nie możemy zgodzić się na rozsądną, naukową i namacalną metodę pomiaru streszczenia.
Pablo
Moja odpowiedź jest taka, że ​​możemy mierzyć tylko aspekty techniczne, a nie abstrakcyjne myśli / opinie. Nie chcę też brzmieć jak osioł. Te posty nie miały być jakąś głupią odpowiedzią.
Pablo