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

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”?

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.

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!

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

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.

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.

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 $% ^ &!

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ąć. =)