Jak radzić sobie z błędnymi przekonaniami o „przedwczesnej optymalizacji jest źródłem wszelkiego zła”?

26

Spotkałem wielu ludzi, którzy są dogmatycznie przeciwni czemukolwiek, co można uznać za „optymalizację” w ogólnym znaczeniu tego słowa w języku angielskim, i bardzo często cytują dosłownie (częściowo) cytat „przedwczesna optymalizacja jest źródłem wszelkiego zła” jako uzasadnienie ich stanowiska, sugerując, że interpretują wszystko, o czym mówię, jako „przedwczesną optymalizację”. Jednak te poglądy są czasami tak absurdalnie zakorzenione, że odrzucają praktycznie wszelkie odchylenia algorytmiczne lub struktury danych od najczystszej „naiwnej” implementacji… lub przynajmniej wszelkie odchylenia od tego, co robili wcześniej.Jak można podejść do takich osób w taki sposób, aby ponownie „otworzyły uszy” po tym, jak przestały słyszeć o „wydajności” lub „optymalizacji”? Jak omówić temat projektowania / wdrażania, który ma wpływ na wydajność, nie każąc ludziom od razu myśleć: „Ten facet chce spędzić dwa tygodnie na dziesięciu liniach kodu?”

Teraz stanowisko, czy „wszelka optymalizacja jest przedwczesna, a zatem zła”, czy nie, zostało już omówione tutaj, jak również w innych zakątkach sieci , i już dyskutowano, jak rozpoznać, kiedy optymalizacja jest przedwczesna, a zatem zła , ale niestety wciąż istnieją ludzie w prawdziwym świecie, którzy nie są tak otwarci na wyzwania związane z wiarą w antyoptymalizację.

Poprzednie próby

Kilka razy próbowałem podać pełny cytat z Donalda Knutha , aby wyjaśnić, że „przedwczesna optymalizacja jest zła” ↛ „cała optymalizacja jest zła”:

Powinniśmy zapomnieć o małej wydajności, powiedzmy około 97% czasu: przedwczesna optymalizacja jest źródłem wszelkiego zła. Nie powinniśmy jednak tracić naszych szans w tak krytycznych 3%.

Jednak, dostarczając cały cytat, ludzie ci czasami stają się bardziej przekonani, że to, co robię, to Premature Optimization ™ i kopie i nie chce słuchać. To prawie tak, jakby przeraża je słowo „optymalizacja”: Kilka razy byłem w stanie zaproponować rzeczywiste zmiany kodu poprawiające wydajność bez zawetowania ich, po prostu unikając użycia słowa „optymalizacja (e | acja)” ( i „wydajność” - to słowo też jest przerażające) i zamiast tego używa wyrażeń takich jak „architektura alternatywna” lub „ulepszona implementacja”. Z tego powodu naprawdę wydaje się, że to naprawdę jest dogmatyzm, a nie faktyczna ocena tego, co mówię krytycznie, a następnie odrzucenie go jako niepotrzebnego i / lub zbyt kosztownego.

errantlinguist
źródło
10
Cóż, kiedy ostatnio rozmawiałeś o tym, czy naprawdę mierzyłeś, że wydajność byłaby zła przy najczystszej, naiwnej realizacji? A przynajmniej dokonał przybliżonej oceny oczekiwanego czasu działania? Jeśli nie, te inne osoby mogłyby mieć całkowitą rację ze swoimi opiniami, nie możesz tego wiedzieć.
Doc Brown
12
@errantlinguist: Jeśli program jest naprawdę „powolny jak melasa”, to z pewnością powinieneś być w stanie łatwo wykryć „krytyczne 3%” Knutha, a zatem przebija wszelkie argumenty przeciwko jego optymalizacji. A jeśli nie możesz tego wykryć ... to jeszcze nie odrobiłeś pracy domowej i nie jesteś jeszcze gotowy do optymalizacji. Więc nie jest jasne, gdzie jest problem.
Nicol Bolas,
6
@errantlinguist: Jeśli przedstawiłeś dowody na to, że ta sekcja kodu stanowi poważny problem z wydajnością aplikacji, a aplikacja jako całość działała wolniej, niż powinna, i nadal zaprzeczają potrzebie modyfikacji kodu, oznacza to, że „ to ważne. Masz do czynienia z ludźmi, którzy są odporni na rozumowanie oparte na dowodach, a zatem są nierozsądni.
Nicol Bolas,
6
@errantlinguist: Kluczowe pytanie: czy klienci narzekali, że aplikacja w tym obszarze była powolna?
Gort the Robot
5
Głosuję za zamknięciem, ponieważ OP najwyraźniej szuka tylko kogoś, kto potwierdzi opinię, a nie odpowiedź na rzeczywiste pytanie. Nie sądzę, żeby to pozostało (lub powinno) pozostać otwarte w Workplace.SE.
BlueRaja - Danny Pflughoeft

Odpowiedzi:

35

Wygląda na to, że szukasz skrótów, aby nie wypróbować „najczystszej naiwnej implementacji” i bezpośrednio wdrożyć „bardziej wyrafinowane rozwiązanie, ponieważ wiesz wcześniej, że naiwna implementacja tego nie zrobi”. Niestety, rzadko to działa - jeśli nie masz twardych faktów lub argumentów technicznych, aby udowodnić, że naiwne wdrożenie jest lub będzie zbyt wolne, najprawdopodobniej się mylisz, a to, co robisz, to przedwczesna optymalizacja. A próba kłótni z Knuthem jest przeciwieństwem trudnego faktu.

Z mojego doświadczenia wynika, że ​​będziesz musiał najpierw ugryźć kulę i wypróbować najpierw „naiwną implementację” (i prawdopodobnie będziesz zaskoczony, jak często jest to wystarczająco szybka), albo przynajmniej dokonasz przybliżonej oceny czasu pracy, na przykład:

„Naiwnym wdrożeniem będzie O (n³), a n jest większe niż 100 000; to potrwa kilka dni, podczas gdy niezbyt naiwne wdrożenie będzie działać w O (n), co zajmie tylko kilka minut” .

Tylko przy takich argumentach masz pewność, że Twoja optymalizacja nie jest przedwczesna.

Jest tylko jeden wyjątek od IMHO : gdy szybsze rozwiązanie jest również prostsze i czystsze, powinieneś użyć szybszego rozwiązania od samego początku. Standardowym przykładem jest użycie słownika zamiast listy, aby uniknąć niepotrzebnego kodu pętli do wyszukiwania, lub użycie dobrego zapytania SQL, które daje dokładnie jeden rekord wyniku, którego potrzebujesz, zamiast dużego zestawu wyników, który musi być filtrowane później w kodzie. Jeśli masz taki przypadek, nie kłóć się o wydajność- występ może być dodatkową, ale najprawdopodobniej nieistotną korzyścią, a kiedy o nim wspomnisz, ludzie mogą ulec pokusie użycia Knutha przeciwko tobie. Dyskutuj o czytelności, krótszym kodzie, czystszym kodzie, łatwości konserwacji - nie musisz tutaj niczego maskować, ale ponieważ te (i tylko te) są tutaj poprawnymi argumentami.

Z mojego doświadczenia wynika, że ​​ten drugi przypadek jest rzadki - tym bardziej typowym jest to, że najpierw można wdrożyć proste, naiwne rozwiązanie, które jest lepiej zrozumiałe i mniej podatne na błędy niż bardziej skomplikowane, ale prawdopodobnie szybsze.

I oczywiście powinieneś znać wymagania i przypadek użycia na tyle dobrze, aby wiedzieć, jaka wydajność jest akceptowalna i kiedy sytuacja staje się „zbyt wolna” w oczach użytkowników. W idealnym świecie klient otrzymałby formalną specyfikację wydajności, ale w rzeczywistych projektach wymagana wydajność jest często szarą strefą, coś, co użytkownicy powiedzą tylko wtedy, gdy zauważą, że program zachowuje się „zbyt wolno” w produkcji. I często jest to jedyny działający sposób stwierdzenia, kiedy coś jest zbyt wolne - informacja zwrotna od użytkownika, a następnie nie trzeba cytować Knutha, aby przekonać członków zespołu, że ich „naiwne wdrożenie” nie było wystarczające.

Doktor Brown
źródło
15
@errantlinguist: może nie wyraziłem się jasno, czy po prostu nie to chciałem usłyszeć? Moja rada jest następująca: nie próbuj używać * filozoficznych argumentów ”Knutha o„ 3% ”lub„ 97% ”. Zachowaj ten fakt, w przeciwnym razie Twoi koledzy najprawdopodobniej mają rację, że twoje argumenty dotyczące wydajności są niewłaściwe.
Doc Brown
4
@errantlinguist: w przypadku opisanym w komentarzu do odpowiedzi Karla Bielefelda wydaje się, że masz wszystkie argumenty po swojej stronie, bez potrzeby używania „performance”. Chciałbym pójść o krok dalej i powiedzieć, że jeśli kłócisz się o wydajność w takim przypadku, popełniasz ogromny błąd, ponieważ twoi koledzy mają rację: wydajność zwykle nie ma znaczenia. Kłóć się o prostotę, czytelność, łatwość konserwacji, mniej linii kodu, ale nie (!) O wydajność, nawet na marginesie. Nie oferuj im możliwości użycia Knuth przeciwko tobie.
Doc Brown
2
@errantlinguist: nie zakopać go - umieścić te aspekty pod naciskiem, gdy prawdą jest, że te aspekty powinny być w centrum uwagi, a nie używać osiągi jako argument, gdy nie można udowodnić jej, że to sprawia, że istotną różnicę dla użytkownika końcowego.
Doc Brown
2
@errantlinguist: Nie jestem pewien, jak dojść do tego wniosku. Odpowiedź doktora Browna wydaje się całkowicie jasna: przebijasz te bezproduktywne argumenty, które masz ze swoimi kolegami, trzymając się faktycznych stwierdzeń na temat tego, co jest, a co nie jest do przyjęcia.
jl6
1
To dobra rada dla małych programistów, ale ignorowanie pytań dotyczących wydajności na poziomie projektowania architektonicznego może doprowadzić zespół do długiego ślepego zaułka, ponieważ może wiele zrobić, zanim będzie musiał zmierzyć się z problemem, i nie ma gwarancji, że wiele z tych prac będzie można ponownie wykorzystać, gdy problem ma charakter architektoniczny (widziałem, jak zabija produkt). Wiem, że masz wyjątek w swojej odpowiedzi, ale aby wiedzieć, czy dotyczy, nadal musisz zadać pytanie , a nawet zadawanie tego pytania jest najwyraźniej przekleństwem dla współpracowników błędnych poglądów.
sdenham
18

Zadaj sobie to:

  • Czy oprogramowanie NIE spełnia specyfikacji wydajności?
  • Czy oprogramowanie ma problem z wydajnością?

To są powody do optymalizacji. Więc jeśli ludzie są przeciwni, po prostu pokaż im specyfikację i wróć do nich i wyjaśnij, że musimy zoptymalizować, ponieważ nie spełniamy specyfikacji. Poza tym trudno byłoby przekonać innych, że optymalizacja jest konieczna.

Myślę, że głównym punktem cytatu jest to, że jeśli nie masz problemu, nie przeprowadzaj niepotrzebnej optymalizacji, ponieważ czas i energię można by wydać gdzie indziej. Z perspektywy biznesowej ma to doskonały sens.

Po drugie, dla tych, którzy obawiają się optymalizacji, zawsze wykonuj kopię zapasową wyników za pomocą wskaźników. O ile szybszy jest kod? Jak bardzo poprawiła się wydajność w porównaniu do poprzednich? Gdyby spędzić dwa tygodnie tylko na poprawieniu kodu o 2% w stosunku do poprzedniej wersji, gdybym był twoim szefem, nie byłbym szczęśliwy. Te dwa tygodnie można było poświęcić na wdrożenie nowej funkcji, która może przyciągnąć więcej klientów i zarobić więcej pieniędzy.

Wreszcie większość oprogramowania nie musi być wysoce zoptymalizowana. Tylko w kilku wyspecjalizowanych branżach szybkość jest naprawdę ważna. Tak więc przez większość czasu można z powodzeniem korzystać z istniejących bibliotek i frameworków.

Jon Raynor
źródło
4
Chociaż jest to dobra informacja, nie odpowiada to na moje pytanie, jak pracować z ludźmi, którzy stonewall dyskusję w chwili, gdy ma to związek z wydajnością.
errantlinguist
7
Zgadzam się z tym wszystkim, z wyjątkiem „Tylko w kilku wyspecjalizowanych branżach szybkość jest naprawdę ważna”. Myślę, że nie doceniasz ilości oprogramowania, które ma problemy z wydajnością z perspektywy klienta.
Gort the Robot
@StevenBurnap: Tak - czy są dzikie aplikacje internetowe, które tak naprawdę nie są wolne? - Chciałbym zobaczyć jedną z tych samych dziedzin nauki.
errantlinguist
1
google.com jest dość szybki. :-P
Gort the Robot
Spróbuj użyć google.com na połączeniu mobilnym EDGE. Tak, to absurdalny przypadek na krawędzi, ale na pewno nie będzie dość szybki . ;) (Pun właściwie nie zamierzano - naprawdę)
errantlinguist 12.04.16
7

Jak pracować z ludźmi, którzy stonewall dyskusję w momencie, gdy ma to związek z wydajnością?

Zacznij od wspólnych zasad, które opierają się na strategicznym kierowaniu twoją grupą.

Moje zasady:

Moje osobiste zasady pisania kodu polegają najpierw na poprawności w moim programie, a następnie na jego profilowaniu i ustaleniu, czy wymaga optymalizacji. Sam profiluję swój kod, ponieważ inni programiści są potencjalnymi odbiorcami mojego kodu - i nie będą go używać, jeśli jest wolny - dlatego w moim kodzie prędkość jest cechą.

Jeśli Twoi klienci są klientami, powiedzą Ci, czy potrzebujesz szybszego kodu.

Istnieją jednak znane, wyraźnie lepsze wybory w kodzie, które można dokonać. Wolę to zrobić w moim pierwszym projekcie z kilku powodów:

  1. Jeśli poprawię to za pierwszym razem, mogę zapomnieć o implementacji (wykorzystując ukrywanie informacji) i nie zaśmiecam mojego kodu TODO.
  2. Inni (szczególnie ci, którzy uczą się tylko w pracy) uważają, że zrobiono to we właściwy sposób, a także uczą się i używają tego samego stylu kodu. I odwrotnie, jeśli zobaczą, że robię to w niewłaściwy sposób, zrobią to również w niewłaściwy sposób.

Zakładając, że potrzeba optymalizacji jest poprawna

Zakładając, że jest to naprawdę ważna część twojego kodu, która wymaga optymalizacji, możesz opowiedzieć przypowieść o malarzu Schlemiela lub podkreślić resztę cytatu:

„Programiści marnują mnóstwo czasu na myślenie lub martwienie się o szybkość niekrytycznych części swoich programów, a te próby wydajności mają silny negatywny wpływ, gdy rozważa się debugowanie i konserwację. Powinniśmy zapomnieć o małej wydajności, powiedzmy o 97% czasu: przedwczesna optymalizacja jest źródłem wszelkiego zła. Jednak nie powinniśmy tracić naszych możliwości w tak krytycznych 3%. ” - Donald Knuth

Zważyć koszty dodatkowej złożoności

Czasami istnieje realny koszt w zakresie utrzymania dodatkowej złożoności. W takim przypadku możesz zachować dodatkową implementację w innej funkcji lub podklasie i zastosować do niej te same unittests, aby nie było wątpliwości, że jest poprawna. Później, jeśli wyprofilujesz swój kod i stwierdzisz, że naiwna implementacja stanowi wąskie gardło, możesz przełączyć swój zoptymalizowany kod i wyraźnie ulepszyć swój program.

Przywództwo

Czasami problemem jest ego - niektórzy woleliby używać nieoptymalnego lub błędnego kodu, niż gdyby ktoś miał więcej racji niż oni. Prawdopodobnie chcesz uniknąć pracy z tymi ludźmi.

Przywództwo, szczególnie gdy nie masz pozycji nad ludźmi, polega na przedstawianiu rozsądnych sugestii i prowadzeniu innych do konsensusu. Jeśli nie możesz poprowadzić swojego zespołu do spotkania umysłów, być może nie warto tego naciskać. Prawdopodobnie są większe ryby do smażenia.

Aaron Hall
źródło
6

Droga naprzód polega na zapomnieniu o aktualnym cytacie i różnych interpretacjach - tak czy inaczej dogmatyzm tak bardzo koncentruje się na konkretnym cytacie guru. Kto powiedział, że Knuth i tak ma zawsze rację?

Zamiast tego skup się na projekcie pod ręką, oprogramowaniu, które rozwijasz wraz ze współpracownikami, z którymi się nie zgadzasz. Jakie są wymagania dotyczące akceptowalnej wydajności dla tego oprogramowania? Czy to wolniejsze niż to? Następnie zoptymalizuj.

Nie musisz nazywać go „optymalizacją”, możesz nazwać to „naprawieniem błędu”, ponieważ z definicji jest to błąd, jeśli implementacja nie spełnia wymagań.

Mówiąc bardziej ogólnie, istnieją dwie możliwości optymalizacji:

  1. Zoptymalizowany kod jest także krótszy, łatwiejszy do zrozumienia i łatwiejszy w utrzymaniu.

  2. Zoptymalizowany kod jest bardziej skomplikowany do zrozumienia, zajmuje więcej czasu na pisanie i testowanie, lub byłby bardziej skomplikowany do zmiany w przyszłości, jeśli wymagania zmienią się w nieoczekiwany sposób.

W przypadku (1) nie musisz nawet kłócić się o optymalizację. Ale jeśli tak jest (2), wówczas podejmujesz decyzję o kompromisie . W rzeczywistości jest to decyzja na poziomie biznesowym, a nie wyłącznie decyzja techniczna. Musisz porównać koszt optymalizacji z korzyścią. Aby nawet przyniosła korzyść, nieefektywność musi być przede wszystkim problemem, albo ze względu na złe wrażenia użytkownika, albo znacznie wyższy koszt sprzętu lub innych zasobów.

JacquesB
źródło
Cóż, w pełni zgadzam się na twoje pierwsze zdanie. Jestem jednak pewien, że oprogramowanie może być „denerwująco wolne dla zamierzonego przypadku użycia” bez wyraźnego formalnego określenia wymagań wydajnościowych.
Doc Brown
@DocBrown: Oczywiście, ale w każdym razie to klient decyduje, czy jest zbyt wolny, czy nie, nie programista.
JacquesB
Nigdy nie spotkałem wymagań biznesowych, które wyraźnie określają wymagania dotyczące wydajności.
errantlinguist
@errantlinguist: Z mojego doświadczenia wynika, że ​​jest to dość powszechne w firmach zorientowanych na klienta, takich jak sklepy internetowe. Jednak w przypadku narzędzi i aplikacji do użytku wewnętrznego w firmie doświadczenie użytkownika zwykle nie stanowi problemu dla właściciela projektu.
JacquesB,
4

Myślę, że pełny cytat w kontekście jest pouczający. Skopiuję z posta napisanego na Reddit na ten temat:

Nie ulega wątpliwości, że graal wydajności prowadzi do nadużyć. Programiści tracą ogromną ilość czasu na myślenie lub martwienie się o szybkość niekrytycznych części swoich programów, a te próby wydajności mają silny negatywny wpływ na debugowanie i konserwację. Powinniśmy zapomnieć o małej wydajności, powiedzmy około 97% czasu: przedwczesna optymalizacja jest źródłem wszelkiego zła.

Nie powinniśmy jednak tracić naszych szans w tak krytycznych 3%. Dobry programista nie uśpi się na skutek takiego rozumowania, rozsądnie przyjrzy się krytycznemu kodowi; ale dopiero po zidentyfikowaniu tego kodu.

- Donald Knuth, Programowanie strukturalne za pomocą go to Statement , ACM Computing Surveys, tom 6, nr 4, grudzień 1974, str. 268

Chodzi o to, że należy martwić się o wiele ważniejszymi rzeczami niż zbyt wcześnie zwracać uwagę na optymalizację. Oczywiście, powinieneś dokładnie rozważyć swoje struktury danych i algorytmy (jest to w 3%), ale nie powinieneś się martwić, czy odejmowanie jest szybsze niż modulo (to jest w 97%), dopóki nie stanie się jasne, że optymalizacja niskiego poziomu jest niezbędny.

Ten pierwszy niekoniecznie oznacza optymalizację w tym sensie, o czym myślą Twoi koledzy, ale jest optymalizacją w tym sensie, że źle dobrane algorytmy i struktury danych są nieoptymalne.

greyfade
źródło
2
Można dodać, że Knuth wyraźnie nie uważa, że ​​analiza złożoności czasowej algorytmów i dokonywanie wyborów projektowych na tej podstawie jest przedwczesną optymalizacją.
sdenham
3

Z mojego doświadczenia wynika, że ​​jeśli regularnie spotykasz się z takim sprzeciwem wobec optymalizacji , ludzie tak naprawdę nie narzekają na optymalizację. Narzekają na to, co poświęcasz w imię optymalizacji. Zwykle jest to czytelność, łatwość konserwacji lub aktualność. Jeśli Twój kod zostanie dostarczony w tym samym czasie i równie łatwo go zrozumieć, ludzie nie będą się przejmować, jeśli korzystasz z wydajniejszych struktur danych i algorytmów. Sugeruję w tym przypadku, aby uczynić kod bardziej eleganckim i łatwym w utrzymaniu.

Jeśli masz do czynienia z takim sprzeciwem w stosunku do kodu innych osób, zwykle dzieje się tak dlatego, że sugerujesz znaczną ilość przeróbek. W takich przypadkach naprawdę potrzebujesz rzeczywistych pomiarów, aby pokazać, że warto, lub spróbuj zaangażować się wcześniej na etapie projektowania, zanim zostanie napisany kod. Innymi słowy, musisz udowodnić, że wynosi on 3%. Gdybyśmy przepisali cały kod, który nie był dokładnie taki, jak nam się podobało, nigdy nie osiągnęlibyśmy niczego.

Karl Bielefeldt
źródło
Niestety, faktycznie zrobiłem odwrotny przypadek, w którym korzystam np. DequeZe standardowej biblioteki Java, aby zastąpić ogromną ilość logiki zbudowanej wokół ArrayListstosu podczas pracy nad kodem ... i to oznaczono dla zmiana w przeglądzie. Innymi słowy, recenzent chciał mieć więcej kodu, który jest również wolniejszy i bardziej podatny na błędy, ponieważ nie był zaznajomiony Deque.
errantlinguist
3
Niechęć do nauki czegoś, co mówi się w twoim języku od 10 lat, jest dla programisty toksycznym podejściem i znacznie głębszym problemem niż początkowo opisałeś. Osobiście w tej sytuacji odmówiłbym rady i w razie potrzeby przekazałbym ją kierownictwu.
Karl Bielefeldt
5
@errantlinguist: kiedy twój recenzent zaproponował wyraźnie gorsze (to znaczy bardziej skomplikowane) rozwiązanie w zamian za czyste i proste, powinieneś się o to spierać. Nie kłóć się o wydajność! Poważnie, nigdy nie używaj słowa „wydajność” w tej dyskusji. Spieraj się tylko o czytelność i łatwość konserwacji. A jeśli recenzent nalega na swój zły kod, eskaluj.
Doc Brown
+1 Nie jestem pewien, dlaczego ta odpowiedź ma głos pozytywny zamiast pozytywnego, a także odpowiedź akceptowaną. Sugeruje zarówno sposób rozwiązania problemu, jak i analizę tego, jaki może być prawdziwy problem (tzn. Że nikt nie chce, aby jego kod musiał zostać radykalnie przepisany).
Andres F.,
2

W istocie jest wiele nieporozumień dotyczących tego cytatu, więc najlepiej cofnąć się i spojrzeć na rzeczywisty problem. Problem nie jest tak duży, że nigdy nie powinieneś „optymalizować”. Chodzi o to, że „optymalizacja” nigdy nie jest zadaniem, które powinieneś podjąć. Nigdy nie powinieneś budzić się rano i mówić sobie „hej, powinienem dzisiaj zoptymalizować kod!”.

Prowadzi to do zmarnowanego wysiłku. Wystarczy spojrzeć na kod i powiedzieć „Mogę to zrobić szybciej!” prowadzi do wielu wysiłków, by stworzyć coś szybszego, co było wystarczająco szybkie. Możesz być dumny z mówienia sobie, że czterokrotnie przyspieszyłeś trochę kodu, ale jeśli ten kod był obliczeniem, które nastąpiło po naciśnięciu przycisku, i zajęło mu 10 milisekund, zanim wyświetlił się ludzkiemu użytkownikowi, nikt nie cholera.

Jest to „przedwczesna” w „przedwczesnej optymalizacji”. Kiedy to nie jest „przedwczesne”? Kiedy klienci mówią: „To jest zbyt cholernie wolne, napraw to!” Wtedy kopiesz kod i próbujesz go przyspieszyć.

To nie znaczy, że powinieneś wyłączyć mózg. Nie oznacza to, że powinieneś przechowywać 10 000 rekordów klientów na pojedynczo połączonej liście. Zawsze powinieneś rozumieć wpływ na wydajność tego, co robisz, i postępować odpowiednio. Ale chodzi o to, że nie spędzasz dodatkowego czasu celowo, próbując przyspieszyć. Po prostu wybierasz bardziej wydajny wybór spośród innych, równych wyborów.

Gort the Robot
źródło
To nie znaczy, że powinieneś wyłączyć mózg. Nie oznacza to, że powinieneś przechowywać 10 000 rekordów klientów na pojedynczo połączonej liście. > Chociaż zgadzam się z tobą w 100%, tak naprawdę widziałem powiązane listy używane w ten sposób i powiedziano mi „nie dotykać”.
errantlinguist
Chociaż jest to dobra informacja, nie odpowiada to na moje pytanie, jak pracować z ludźmi, którzy stonewall dyskusję w chwili, gdy ma to związek z wydajnością.
errantlinguist
3
Niestety „pojedynczo połączona lista” nie była przypadkowym przykładem, ale czymś, na co wpadłem osobiście.
Gort the Robot
1

Możesz albo robić rzeczy w niewłaściwy sposób, albo robić to we właściwy sposób.

Często rzeczy są robione w niewłaściwy sposób, a kod jest refaktoryzowany, aby działał we właściwy sposób. Jeśli masz zamiar napisać nowy kod i wiesz, że możesz robić rzeczy we właściwy sposób bez poważnej kary, popełniłbym błąd, robiąc to we właściwy sposób. (Pamiętaj, że po przetestowaniu wydajności itp. Niektóre rzeczy mogą wymagać zmiany - ale to jest w porządku. Alternatywnie, całkowicie naiwna implementacja rzadko, jeśli w ogóle, jest właściwa).

Optymalizacja niekoniecznie jest przedwczesna, jeśli a) wiesz, że to pomoże w przyszłości lub b) wiesz, że ścieżka nieoptymalna doprowadzi do problemów na drodze. To naprawdę gra w szachy.

Myślę, że ludzie będą chcieli robić rzeczy dobrze, a nie źle. Użyj tego, gdy omawiasz alternatywne strategie z rówieśnikami.

lunchmeat317
źródło
5
Nigdy nie ma „złej drogi” lub „właściwej drogi”. Na ogół istnieje nieskończona liczba sposobów, które biegną w kontinuum od „Mój Boże, jak to w ogóle działa !?” do „John Carmack i Donald Knuth nie mogli tego poprawić podczas programowania w parach”.
Gort the Robot
@StevenBurnap To prawda. Myślę jednak, że w przypadku osób fizycznych istnieje na ogół kilka właściwych sposobów i wiele niewłaściwych sposobów. (Gdy stajemy się lepszymi programistami, to spektrum zaczyna się zmieniać - nasze stare „właściwe sposoby” mogą czasem stać się naszymi nowymi „złymi sposobami”, podczas gdy nasze nowe właściwe sposoby są lepsze niż stare.) Myślę, że dobrze jest robić rzeczy w najlepszy, najbardziej odpowiedni sposób dla Ciebie . To prowadzi nas do stania się lepszymi programistami, stania się lepszymi kolegami z drużyny (mentoring ma znaczenie!) I pisania lepszego kodu.
lunchmeat317
Myślę, że ludzie będą raczej chcieli robić rzeczy dobrze, niż robić to źle ” - Problem polega na tym, że istnieją bardzo różne opinie na temat tego, co jest dobre, a co złe. Niektórzy nawet rozpoczynają święte wojny na ten temat (w dosłownym tego słowa znaczeniu).
JensG
1

Wydaje się, że to problem z komunikacją, a nie problem z programowaniem. Spróbuj zrozumieć, dlaczego ludzie czują się tak, jak robią, i spróbuj skrystalizować, dlaczego uważasz, że Twoja droga byłaby lepsza. Kiedy to zrobisz, nie rozpoczynaj sprzeczki, w której twoim celem jest powiedzenie innym, dlaczego się mylą, a ty masz rację. Wyjaśnij swoje myśli i uczucia i pozwól ludziom na to zareagować. Jeśli nie możesz osiągnąć żadnego konsensusu i uważasz, że jest to bardzo ważny problem, prawdopodobnie masz poważne problemy w zespole.

Bardziej skoncentrowany na rzeczywistym programowaniu, nie marnuj czasu na długie kłótnie o coś, co po prostu ma przeczucie, że jest „szybsze”. Jeśli zobaczysz, że ktoś pisze metodę, która jest wywoływana raz na żądanie w aplikacji internetowej i ma złożoność czasową O (n ^ 2), gdy WIESZ, że to naprawdę problem z czasem O (log (n)), to na pewno, jeśli jest taka bez zastanowienia, śmiało.

Pamiętaj jednak, że jako ludzie, my, programiści, jesteśmy naprawdę źli (i mam na myśli SŁUPIE) zgadywanie, które części naszych aplikacji będą wąskie gardło. Eric Lippert pisze o tym interesującym temacie w tym poście na blogu. Zawsze sprzyjaj łatwości konserwacji. Wszelkie problemy z wydajnością, które zostaną ostatecznie znalezione, można łatwo (cóż, względnie) naprawić, gdy masz więcej informacji.

sara
źródło
Przeredagowałem odpowiedź i dodałem trochę więcej informacji, czy downvoter może dodać jakieś uwagi? :)
sara
Chociaż nie jestem zwolennikiem, twój pierwszy akapit odnosi się bezpośrednio do omawianego pytania, ale reszta w rzeczywistości nie odpowiada na moje pytanie, jak pracować z ludźmi, którzy stonewall dyskusję od momentu, gdy ma to związek z wydajnością (chociaż nadal jest to dobra rada).
errantlinguist
w zasadzie to, co chcę omówić w dwóch ostatnich akapitach, to „te optymalizacje mogą nawet nie mieć znaczenia”. w takim przypadku lepiej wybrać swoje walki.
sara,