Pytanie:
Jak mam zareagować, gdy współpracownik twierdzi, że jego metoda 3000 linii jest zoptymalizowana? Czy powinienem zgłosić to mojemu szefowi?
Angel Q
2019-02-08 21:14:26 UTC
view on stackexchange narkive permalink

Mam współpracownika, który powiedział, że jego metoda 3000 linii jest najbardziej zoptymalizowana z możliwych. Jak mam na to profesjonalnie zareagować?

Czy mam przekazać to szefowi, który nic nie wie o programowaniu?

Zauważ, że jesteśmy małym zespołem składającym się tylko z trzech programistów, są na tym samym poziomie i każdy z nich ma swój własny fragment projektu, którym zarządzamy i kodujemy go tak, jak chcemy, podczas gdy ten fragment kodu robi to, co chce szef.

  • Mój Największym zmartwieniem jest to, że mój współpracownik może w pewnym momencie zakończyć relację z firmą i będę musiał zająć się tym elementem projektu, nad którym pracował. Jak do diabła mam przeczytać metodę 3000 linii?

Moją pierwszą myślą będzie rozpoczęcie od nowa od zera, a ponieważ już to zrobiłem z moim obecnym projektem, mając na uwadze że „szef” nic nie rozumie na temat programowania i obchodzi go tylko to, że program działa i ile czasu zajmuje nam jego uruchomienie. Jestem prawie pewien, że przynajmniej trochę się wkurzy.

  • Widziałem tę metodę, robi wiele rzeczy (dużo) i ma blok warunkowy (duże). że jeśli wywoła metodę z parametrem A = 1, pierwszy blok zostanie wykonany, a pozostałe zostaną zignorowane, i tak dalej ... Powiedziałem mu, że może podzielić te bloki na różne metody, aby łatwo było je odczytać i zrozumieć dostrzegłby z tego korzyści i zrobiłby to z resztą gigantycznej metody, ale nie sądzę, żeby dostrzegał korzyści. Powiedział tylko, że zrobił „coś” takiego, ponieważ każdy warunkowy blok jest wewnątrz regionu C #.

UWAGI Z KOMENTARZY:

  • Jak mój współpracownik powiedział, że jest to metoda krytyczna, ponieważ wykonuje wszystkie obliczenia dotyczące określonej części programu.

  • Językiem programowania jest C #.

  • Szybkość kodu nie ma tutaj znaczenia.

  • Przeglądy kodu nie istnieją tutaj. Jak powiedziałem, każdy z nas pracuje samodzielnie i dopóki wszystko działa, nikt nie dba o to, jak to działa.

  • Załóżmy że każdy wiersz z tych 3000 wierszy pochodzi z rzeczywistego kodu, a nie ze spacji czy komentarzy.

Zoptymalizowane i „zgodne z najlepszymi praktykami” to różne rzeczy, semantycznie może mieć rację.
Jak konkretnie możesz wykazać, że * nie * jest zoptymalizowany?
Komentarze nie służą do rozszerzonej dyskusji;ta rozmowa została [przeniesiona do czatu] (https://chat.stackexchange.com/rooms/89461/discussion-on-question-by-angel-humberto-how-should-i-react-when-a-co-powiedz pracownik).
Czy masz metryki kodu, może to świetny moment na wprowadzenie go… przynajmniej sprawiłoby to, że ludzie pomyśleliby, dlaczego metryki mają taką a taką wartość… Zmiana opinii ludzi jest trudna i konfrontacyjna…
Proponuję zespołowi i szefowi porozmawiać o łatwości utrzymania kodu.Jeśli wokół nie ma kultury, trudno będzie prosić o zmiany i lepiej pilnuj własnego biznesu.Musisz także zrozumieć, że musisz trzymać się z daleka od zarzutów typu „nic nie wie”.Idealnie byłoby, gdybyś zaoferował warsztat / rozmowę na temat czystego kodu, a inni proszą Cię o pomoc.
To może być interesujący problem, o który można zapytać na [softwareengineering.se] (ale zapytany w taki sposób, że nie jest to duplikat, może coś w rodzaju „czy jest możliwe, że metoda 3000 linii jest optymalna?”).
jaki jest twój proces radzenia sobie z długiem technicznym
To pytanie można przeformułować jako: „co mam zrobić, gdy kolega wykonał zadanie w sposób, który nasz szef uzna za akceptowalny, ale nie zrobiłbym tego, gdybym był szefem.Jeśli otrzymam zadanie związane z podobnym problemem, uważam, że będę musiał powtórzyć pracę przed rozpoczęciem własnej ”.
Jak podzielona jest metoda na karty?Funkcja, w której masz cały ekran białych znaków, chyba że przewijasz (co miałem), bardzo różni się od funkcji, w której każda linia jest bezwarunkowa.
`` Mam współpracownika, który powiedział, że jego metoda 3000 linii jest najbardziej zoptymalizowana z możliwych.Jak zawodowo na to zareaguję? '' - Czy tak?
Jak wygląda to programowanie w parach tagowanych?Czy zaprogramowałeś razem z nim te 3000 linii?Może nie programujesz w parach, ale robisz przegląd kodu?Ale potem mówisz, że przegląd kodu nie istnieje.Jestem zmieszany
Jeśli prędkość nie ma znaczenia, dla jakich danych jest zoptymalizowana?
@thomas, biorąc pod uwagę, że (1) jest to jedyny tag w pytaniu i (2) S.E.demand jako przynajmniej jeden tag, myślę, że tagowanie zostało zrobione tylko po to, aby opublikować Q bez zwracania uwagi na system.Społeczność (Ty lub ja lub każda zarejestrowana osoba) może edytować i ponownie tagować pytanie.Co sugerujesz?
Niedawno znalazłem metodę 2,5kloc w naszej bazie kodu i z dumą przedstawiłem ją koledze.Zakwestionowany moim odkryciem, znalazł krótszą metodę, ale z 19 poziomami wcięć.Nieźle się z tego pośmialiśmy i ruszyliśmy dalej.
Zapytaj swojego szefa, co myśli o twoim współpracowniku wdrażającym ten przewodnik: https://github.com/Droogans/unmaintainable-code: p
Pracowałem z programistą, który miał doświadczenie w matematyce;a dla niego więcej funkcji oznaczało więcej możliwych ścieżek przez kod - a więc bardziej złożonych.W konsekwencji miał tendencję do pisania bardzo długich funkcji.Jego logika była solidna, mimo wszystko, co w niej było, ale była też niekompletna.
„• Przeglądy kodu tutaj nie istnieją” - a co z recenzjami projektów?Dokumentacja projektowa?Test jednostkowy?Nie?Co zamierzasz zrobić, gdy zaczniesz pracować z programistami, a nie z kowbojami?Jeśli nie zostaniesz tam do emerytury, prędzej czy później będziesz pracować z profesjonalistami.Wcześniej byłoby lepiej.
Dziewiętnaście odpowiedzi:
#1
+116
Ethan The Brave
2019-02-08 21:32:21 UTC
view on stackexchange narkive permalink

Jeśli jesteś tym zaniepokojony, powinieneś przeczytać kod i zaproponować sugestie (brzmi to jak świetna okazja, aby naciskać na przegląd kodu!). Może to być 3000 linii poza potrzebą. Decyzja, że ​​tylko dlatego, że jest 3000 linii, oznacza, że ​​jest źle lub źle, jest arbitralna.

[Edytowano na podstawie aktualizacji]

Mówisz, że szybkość kodu nie ma znaczenia. W tym momencie brzmi to jak brzydki kod. Najlepszym sposobem działania, ponieważ już dałeś im sugestie (ponieważ nie jesteś ich przełożonym itp.), Prawdopodobnie byłoby po prostu zaakceptowanie tego i przejście dalej. Jeśli kiedykolwiek będziesz musiał popracować nad ich kodem, wygląda na to, że jest na tyle podzielony, że można go łatwo podzielić na wiele funkcji, ale działa tak, jak jest i być może nigdy nie będziesz musiał go dotykać.

Pracuj nad nad tym, nad czym chcą, aby pracowali Twoi szefowie, oraz przedstawiać sugestie i ulepszenia tam, gdzie możesz je dopasować. Jeśli spróbujesz naprawić wszystko źle, zobaczysz wszystko naraz, zestresujesz się bez powodu.

Komentarze nie służą do rozszerzonej dyskusji;ta rozmowa została [przeniesiona do czatu] (https://chat.stackexchange.com/rooms/89499/discussion-on-answer-by-ethan-the-brave-how-should-i-react-when-a-współpracownik - mówi).
Wszystko, co nieznane, może wyglądać brzydko.Mogą również istnieć powody, dla których jest to nieznane.
+1 za ewentualną konieczność pójścia dalej, ale sugerowałbym, aby najpierw wysłał szybki e-mail dotyczący CYA, w którym powiedziałbym, że osobiście uważasz, że nie jest to styl kodu do utrzymania, naprawdę powinien zostać podzielony na mniejsze fragmenty i jesteś szczęśliwy, że możesz w tym pomóczadanie.W ten sposób, jeśli kiedykolwiek trafi do wentylatora później, możesz zauważyć, że próbowałeś coś zmienić.
Zgadzam się, że są przypadki, w których stary kod, nawet jeśli jest brzydki lub niezgodny z dobrymi praktykami, nie musi być refaktoryzowany, jeśli prawdopodobieństwo konieczności wprowadzenia zmiany jest bardzo niskie lub jeśli istnieją inne priorytetylista.Jednak nadal istnieje świadomość, że ten pracownik będzie ** nadal pisać nowy kod ** w tym samym monolitycznym stylu, i jest to problem, który należy rozwiązać, a nie tylko zignorować.
Zgadzam się z odpowiedzią, z tym że jest to zapominanie o odpowiedzialności profesjonalnego specjalisty domenowego.Jeśli OP został zatrudniony jako hydraulik i była zardzewiała rura, powinni poinformować o tym swojego szefa.Jako programista czuję, że obowiązkiem OP jako profesjonalisty jest poinformowanie o tym szefa.„_To działa teraz, ale [gdy tylko współpracownik zostanie potrącony przez autobus] (https://en.wikipedia.org/wiki/Bus_factor), wprowadzenie zmian w tej części zajmie komuś innemu bardzo dużo czasu ._„Wtedy to szef musi ustalić priorytety.
Czy sugestie dotyczące jego kodu nie są po prostu tworzeniem procesu przeglądu kodu?
`ale tak jak jest, to działa i być może nigdy nie będziesz musiał go dotykać` -> zakładając, że robi ASS z U i ME.To jest podstawa do powstania [długu technicznego] (https://en.wikipedia.org/wiki/Technical_debt).Zdecydowanie powinno to zostać zgłoszone, a wszyscy programiści pracują _muszą_ zostać poddane wzajemnej weryfikacji.Jak zauważył Schmitz, jeśli ten facet zostanie potrącony przez autobus, to spaghetti nadal trzeba pielęgnować.Co więcej, jeśli nie wyczyścisz czegoś takiego od razu, później będziesz musiał przeczytać, co to było zamierzone, coś, co koder powinien wiedzieć podczas pracy nad tym.
Funkcja 3000 linii jest ** nigdy ** konieczna [linie kodu;mogą istnieć uzasadnione przypadki 3000 wierszy danych].Ta świadomość nie jest arbitralna;wręcz przeciwnie, jest to fundamentalna i uniwersalna prawda współczesnych kompilatorów.Jest to jeszcze bardziej widoczne w językach takich jak Java lub C #, które nie mają granic jednostki tłumaczeniowej C / C ++ i dlatego łatwo optymalizują wywołania funkcji w różnych plikach.
@everyone Może to być pierwszy krok w tworzeniu procesu, ale jeśli OP nie ma konkretnego procesu (lub należy opracować zakup szefa w tym procesie), współpracownik może po prostu wzruszyć ramionami i przejść dalej bez zmiany czegokolwiek.
Podoba mi się ta odpowiedź, ponieważ utrzymuje odpowiednią wielkość OP.OP mógłby iść do szefa z płonącymi pistoletami ... ale to chyba nie jest na to odpowiedni moment.Wyobrażam sobie, że brak przeglądu kodu to nie jedyny problem z tym środowiskiem.Szef może się czegoś nauczyć na własnej skórze, np.„Niestety, metoda 3000 linii ma inny błąd”.
W odpowiedzi na wiele, wiele komentarzy - znowu moja odpowiedź opiera się na „skoro już dawałeś im sugestie”, a także na „nie jesteś ich przełożonym”.Robienie więcej w tej chwili brzmi, jakby wykraczało poza granice jego pracy.
#2
+65
Simon Richter
2019-02-08 22:03:41 UTC
view on stackexchange narkive permalink

Skupiłbym się na problemie z utrzymywalnością.

W zależności od okoliczności, 1000-liniowa funkcja, która robi jedną rzecz i jest dobrze udokumentowana, może być bardziej czytelna i łatwiejsza w utrzymaniu niż 20-liniowa funkcja, która decyzja do dziesięciu wywołań głębokiego stosu funkcji narzędziowych, z których każda miała zaszczepione specjalne przypadki z upływem czasu, gdy zmieniły się wymagania (dziwnie konkretna rant, wiem).

Lista kontrolna dotycząca dużych funkcji:

  • Eliminacja konieczności pełnego zrozumienia funkcji przez użytkowników: powinna istnieć dokumentacja traktująca funkcję jako czarną skrzynkę i opisująca jedynie jej zachowanie. Kod użytkownika nie polega na niczym, co nie jest udokumentowane w tej specyfikacji, co musi być wyraźnym punktem przeglądu kodu dla funkcji wywołującego.

  • Zautomatyzuj weryfikację funkcjonować. Wszystkie obecne przypadki użycia powinny istnieć jako testy jednostkowe, więc jeśli kiedykolwiek zajdzie potrzeba zmodyfikowania tej funkcji, możesz to zrobić szybko, mając pewność, że nic innego się nie zepsuje.

  • Długość funkcji często koreluje z tym, jak łatwo ją zrozumieć, ale nie jest to sztywna i szybka reguła.

    Naprawdę nie zgadzam się, że każda 1000-liniowa funkcja będzie jaśniejsza i bardziej czytelna niż jej odpowiednik podzielony na mniejsze funkcje.Wydaje mi się, że jest naprawdę mało prawdopodobne, aby funkcja 1000 nie miała zduplikowanych bloków kodu, które można by wyciągnąć do funkcji.Naprawdę nie chcę czytać 1000 wierszy, aby dowiedzieć się, co robi funkcja.
    Funkcja linii 3k jest praktycznie niemożliwa do przetestowania.Prawdopodobnie równie dobrze jest 1k-liniowa funkcja, chyba że robi dosłownie JEDNĄ rzecz.Zautomatyzowany zestaw testów musi zostać przekazany szefowi nietechnicznemu w celu zwiększenia stabilności produkcji, co zmniejsza przestoje i skargi klientów, co daje więcej czasu na rozwój większej funkcjonalności.Krótsze przestoje, szczęśliwsi klienci i szybszy rozwój nowych funkcji = więcej pieniędzy.
    Nie ma mowy, żeby funkcja liniowa 1k zrobiła jedną rzecz.
    @DaveG Wygląda na to, że jeszcze nie spotkałeś się z 10-poziomowym głębokim pośrednim rozłożeniem na 50 alternatywnych plików.Czasami czytelna, dobrze nazwana funkcja 1000-liniowa może wywołać odetchnięcie z ulgą, że nie była zbyt ciężka w kierunku pośrednim.Jest to szczególnie ważne, gdy wdraża złożony, wieloetapowy przepływ pracy.(Nie oznacza to, że ostrożna abstrakcja nie byłaby nieco lepszą alternatywą).
    Myślę, że to coś w rodzaju fałszywej dychotomii.Refaktoryzacja ponad 1000 funkcji liniowych nie wymaga znacznych poziomów pośrednich.Ponadto, naprawdę nie ma możliwości, aby funkcja linii 1000+ nie mogła zostać rozsądnie podzielona na co najmniej kilka mniejszych funkcji, które obejmują spójne sekcje większej.
    @Dancrumb To całkowicie zależy od funkcji.Jeśli to kod spaghetti, to jasne.Ale jeśli jest to maszyna stanu, zrób z niej jedną 1000-liniową funkcję, zwłaszcza jeśli masz dla niej również diagramy.Wszyscy możemy to przeczytać i utrzymać.Mój horror to "ekspert" od wzorców CS prosto z uniwersytetu, który chce podzielić to na tuzin połączonych plików i funktorów i Bóg wie co, tylko dlatego, że hej, wzorce projektowe.Nie nie nie nie.Nie. Nie.Do diabła, nie.
    @DaveG, pojedyncza gigantyczna instrukcja przełącznika, która obsługuje wysyłanie zdarzeń.Tak, przypuszczam, że można go było podzielić na grupy powiązanych wydarzeń lub coś w tym rodzaju, ale ponad 250 prawie identycznych czterowierszowych bloków kodu posortowanych alfabetycznie według nazwy zdarzenia jest wystarczająco łatwe do zrozumienia.
    @ajacian81 Właściwie widziałem ponad 1k kodu, który zrobił jedną rzecz.To był ogromny przełącznik.W dzisiejszych czasach najprawdopodobniej byłby obsługiwany w sposób bardziej obiektowy, ale było to w latach 80.Przeszedłem również do kilkuset wierszy wartych przełączenia podczas czytania pliku konfiguracyjnego.
    @Dancrumb Simon nie mówi ani nie sugeruje, że istnieje dychotomia.Mówi, że dogmatyczny nacisk na krótkie funkcje może również prowadzić do słabego kodu.Pytanie, czy jest długie czy krótkie, to niewłaściwe pytanie.Pytanie, które należy zadać, brzmi: „Czy funkcja zapewnia dobrą abstrakcję?”I chociaż ma to korelację z długością, jest niezależne od długości.Używaj długości jako metody heurystycznej, aby wywołać dokładniejszy przegląd, zamiast być dogmatycznym.
    Ciekawy komentarz.Czy ktoś ma przykład 1000 wierszy kodu w pojedynczej funkcji, którego nie można przełożyć na bardziej czytelny i łatwiejszy w utrzymaniu kod?Może są, ale nie przychodzi mi do głowy żadna potrzeba takiej okropnej funkcji.Właśnie wygooglowałem C #, aby sprawdzić, czy ma klasy (tak jak myślałem);to nie jest tak, że jesteś zmuszony używać globali, aby zrekompensować okropny język ... Być może oryginalny plakat mógłby znaleźć jeden lub dwa konkretne przykłady rzeczy, które można by refaktoryzować, a następnie zacząć od tego?
    ** Nigdy ** nie widziałem ponad 1000 funkcji liniowej, której nie można by znacznie ulepszyć poprzez podzielenie funkcjonalności.Narusza większość standardów jakości w branży.W latach 70. istniały uzasadnienia, ponieważ brakowało narzędzi.W dzisiejszych czasach to po prostu okropna jakość kodu i rodzaj długu technicznego, który zabija firmy.
    @Mark Jedyny raz, kiedy widziałem jedną gigantyczną instrukcję przełącznika, pochodzi z wygenerowanego kodu, takiego jak wyjście yacc.W takim przypadku nigdy nie patrzyłem na przełącznik, po prostu zmodyfikowałem gramatykę.Niedawno odziedziczyłem garść kiepskiego kodu i rozpadałem się, przepisałem, aw niektórych przypadkach całkowicie wyrzuciłem kilka ogromnych funkcji i klas, aw każdym przypadku wynik jest mniejszy, czystszy, łatwiejszy w użyciu.
    Instrukcja przełączania tysięcy linii nie robi nic poza podjęciem jednej decyzji.Nie ma to nic wspólnego z problemem OP, który składa się z 3000 linii faktycznie działającego kodu, a nie instrukcji przełącznika.
    Czytając / debugując czyjś kod, używam jednej gigantycznej metody na [kod jo-jo] (https://en.wikipedia.org/wiki/Yo-yo_problem), gdzie muszę nawigować między AbstractModulatorFactoryAdapters (prawdopodobnieużywane tylko raz w bazie kodu) każdego dnia;[ten kawałek Carmacka] (http://number-none.com/blow/john_carmack_on_inlined_code.html) jest również szczególnie pouczający.
    To niepokojące, że ta odpowiedź ma 30 głosów za.
    @RoyTinker Pośrednictwo i delegowanie utrudniają zrozumienie rzeczy tylko wtedy, gdy musisz zrozumieć wszystkie ich działania.Wywołanie funkcji o nazwie `f ()` jest DUŻO trudniejsze do odczytania niż `delete_browser_history ()`, ponieważ trzeba przejść i przeczytać zawartość `f ()`.Celem takiego podziału kodu jest _ zaoszczędzenie_ czytelnikowi myślenia o tym, jak to działa.
    @AdamBarnes, to twoim problemem jest głupie nazewnictwo funkcji, odpowiednikiem byłaby funkcja 1000-liniowa o nazwie "f".Rozsądnie podzielisz 1000-liniową funkcję „deletePrivacyData” na małe funkcje, nawet jeśli nie ma powielania kodu, takiego jak „deleteCookies”, „deleteHistory”, „deleteCachedData”.
    @Darkwing, chodzi mi o to, że nie zawsze jest to możliwe.Całkowicie się zgadzam, że zwykle tak jest, ale ważne pytanie nie brzmi „czy ta funkcja jest za długa?”ale "czy ta funkcja jest możliwa do utrzymania?"Funkcja, o której myślałem, kiedy pisałem swoją odpowiedź, dotyczy taktowania łańcucha DSP w stałym układzie scalonym, jest długa, ponieważ łańcuch DSP jest długi, a każda część zależy od poprzedniej, więc musiałbym przekazać wiele stanów dookołagdybym chciał zrobić wiele funkcji.Mógłbym to podzielić, tworząc strukturę ze wszystkimi moimi zmiennymi lokalnymi i przeglądając listę funkcji, aby ją zmodyfikować, ale dlaczego?
    @SimonRichter W tym konkretnym przypadku _modelowałbym_ go jako łańcuch.Konstruujesz łańcuch z kontekstem i samą listą funkcji, a następnie wprowadzasz łańcuch, który wywołuje po kolei każdą funkcję z kontekstem i wynikami poprzedniej funkcji.
    #3
    +25
    Dan
    2019-02-09 01:11:18 UTC
    view on stackexchange narkive permalink

    Pracowałem wcześniej nad starszym kodem, w którym cała witryna jest obsługiwana w jednym pliku, który składa się z około 100 000 linii kodu. Zgadza się. Wszystko w serwisie jest zawarte w jednym pliku, jednej funkcji. Doszło do punktu, w którym dodanie lub zmodyfikowanie czegoś oznaczało, że przewinąłeś całą drogę do samego dołu i po prostu zmodyfikowałeś bufor wyjściowy, aby zmienić rzeczy. Na przykład, gdyby ktoś powiedział, że chce zmienić zdanie, robimy regex, aby przeszukać zdanie i po prostu zastąpić je nowym zdaniem.

    W końcu doszliśmy do punktu, w którym stało się tak rozdęte, że tylko kilka osób było „ekspertami” w modyfikowaniu bufora wyjściowego. Ostatecznie zdecydowano się po prostu podrzucić plik i przerobić całą witrynę z nowoczesnym podejściem.

    Myślę, że właśnie to się tutaj stanie. Utrzymaj funkcję 3k, a jeśli pójdzie, po prostu wrzuć kod. To właśnie bym zrobił, zamiast tracić czas na przekonywanie kogoś, że coś jest lepsze. To działa, tak brzmi argumentacja i może to być prawda. Bez szefa, który zna kod lub ma dobre umiejętności miękkie, prawdopodobnie nie zajdziesz daleko, próbując przekonać równorzędnego współpracownika do zmiany.

    To wszystko prawda i to jest świetna odpowiedź.Jednak MOŻESZ wyjaśnić to w prosty sposób szefowi w kilku słowach.W mojej odpowiedzi wyjaśniłem, jak.
    Tak prawda.Chodzi mi o to, że sprowadza się to do umiejętności miękkich tak naprawdę w wyjaśnianiu wydatków pieniężnych nie-programiście.Nie brzmi to obraźliwie, ale w oparciu o problem opisany przez OP, nie sądzę, aby go miał.Jednak w świecie programistów często zdarza się, że wielu programistom brakuje umiejętności miękkich potrzebnych do wyjaśnienia rzeczy od programisty do nieprogramisty iz powrotem do programisty.Ja włącznie.
    Z jego wyjaśnień wynika, że funkcja jest zorganizowana w duże bloki warunkowe.Więc wyobrażam sobie, że byłoby całkiem możliwe, aby refaktoryzować tę metodę 3000 linii.
    Chociaż twoja sugestia może zadziałać, nie mogę tak pracować.Fakt, że muszę spędzić dzień na szukaniu tej funkcji, aby naprawić mały problem lub dodać kolejny błąd o nazwie „funkcja”, sprawiłby, że moje oczy krwawiły.Dziękuję za odpowiedź
    To jest dobra odpowiedź.Jedyną rzeczą, którą OP mógłby teraz zrobić, jest wymyślenie kilku przypadków testowych dla tej ogromnej funkcji, więc gdy nadejdzie czas, aby ją wyrzucić, można sprawdzić, czy nowa wersja robi to, co stara.
    (na bok) „dodanie lub zmodyfikowanie czegoś oznaczało, że przewinąłeś całą drogę do samego dołu i po prostu zmodyfikowałeś bufor wyjściowy, aby zmienić rzeczy”.- Często tak właśnie działa ewolucja biologiczna (na poziomie „funkcjonalnym”).Ten kod ewoluował sam, zamiast być `` inżynierią '' :)
    Ponieważ jesteśmy na SO, pozwólcie mi sprzeciwić się „podrzuceniu i przepisaniu”.Joel raz przedstawił [przekonujący argument za refaktoryzacją] (https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/), ponieważ stary kodzawiera dużą wiedzę ekspercką i szczegółową, która będzie wymagała ponownego nauczenia się na nowo, jeśli i kiedy funkcja zostanie ponownie zakodowana od zera.
    #4
    +16
    The Gilbert Arenas Dagger
    2019-02-09 04:10:37 UTC
    view on stackexchange narkive permalink

    Długa metoda to z pewnością zapach kodu, ale nie oznacza to jednoznacznie, że coś jest nie tak. W rzeczywistości uważałbym, że nie należy rozdzielać metody wyłącznie na podstawie długości, to jest arbitralne. Na przykład, widziałem kilka długich metod dla różnych zadań ETL (Extract / Transform / Load), w których długość jest naprawdę zależna od ilości danych.

    Nie zgłaszaj tego szefowi w tym momencie. Znajdź namacalny powód, dla którego można ulepszyć metodę, a następnie poinformuj o tym dewelopera w konstruktywny sposób.

    W tym przypadku mogę się założyć, że kod można podzielić na prostszą funkcję, która byłaby łatwa do odczytania i zmodyfikowania
    @angelhumberto - Twój szef nie dba o to, na co jesteś skłonny postawić.Jeśli chcesz go przekonać, musisz zademonstrować konkretny problem (a „funkcja jest za długa” to _nie_ konkretny problem) i być w stanie wyjaśnić, w jaki sposób proponowane przez Ciebie zmiany rozwiązują ten problem.
    @DaveSherohman „Nie rozumiem tej funkcji, ponieważ jest za długa” to specyficzny problem.Niestety jest to ten sam problem, który miałem podczas czytania Jamesa Joyce'a i nie został sformułowany jako problem z kodem.
    #5
    +14
    gnasher729
    2019-02-09 00:57:48 UTC
    view on stackexchange narkive permalink

    Nie martw się o to. To nie jest twój problem (w tej chwili). To on jest odpowiedzialny za utrzymanie kodu, a nie twój. Nie dotykaj tego. Jeśli szef poprosi Cię o dotknięcie go teraz lub później, powiedz mu, dlaczego tego nie zrobisz.

    Jeśli twój kolega odchodzi, kupujesz książkę o refaktoryzacji. To jest punkt, w którym mówisz swojemu szefowi, że ta funkcja nie jest możliwa do utrzymania.

    Nie jestem tego pewien, w zasadzie wiesz, kiedy i jak umrzesz i nie robisz nic, aby temu zapobiec
    Zdecydowanie się z tym nie zgadzam.Naprawienie problemu teraz może kosztować tydzień pracy.W porównaniu do roku, w którym kod się zmienił i coś do niego dodano, koszt refaktoryzacji (w połączeniu z kosztem próby zapamiętania, co zrobił kod) może być znacznie wyższy.
    #6
    +11
    Johns-305
    2019-02-08 21:30:32 UTC
    view on stackexchange narkive permalink

    Jak mam na to profesjonalnie zareagować?

    „Świetnie, dzięki!”

    Teraz, jeśli uważasz, że kod nie jest optymalny, niezależnie od liczby linii , możesz przetestować go z boku, aby sprawdzić, czy spełnia jakiekolwiek wymagania dotyczące wydajności. Daje to znaczące, przydatne informacje.

    Jeśli uważasz, że kod jest zgodny ze złymi praktykami, możesz o tym poruszyć podczas przeglądu kodu.

    Recenzje kodu nie istnieją
    @angelhumberto Więc teraz masz powód, aby je uruchomić.
    Nie sądzę, żeby to zadziałało, ponieważ powiedziałem, że jesteśmy małym zespołem składającym się z zaledwie 3 programistów, którzy pracują nad swoimi projektami.Chcę wiedzieć, co robić, wiedząc, że współpracownik robi takie rzeczy
    @angelhumberto Dobrze, ale przeczytaj odpowiedzi.Jeden wspólny motyw jest taki, że 3000 linii samo w sobie nie stanowi problemu.Zanim cokolwiek zrobisz, musisz zidentyfikować rzeczywisty problem.
    Pytanie zostało rozwiązane w opisie.Znam problem, co mam z tym zrobić?Powinienem powiedzieć szefowi?
    #7
    +10
    William Jockusch
    2019-02-10 10:26:21 UTC
    view on stackexchange narkive permalink

    Poproś go o napisanie testów, aby udowodnić, że to działa. Sprawdź zakres testów. Jeśli jest mniej niż 100%, to jest problem.

    W takim razie przynajmniej, jeśli będziesz musiał to utrzymać pewnego dnia, będziesz mógł wprowadzić zmiany bez obawy, że coś schrzanisz, nie zdając sobie z tego sprawy. / p>

    Nawet to może być zasłoną dymną, ponieważ złe testy mogą dotknąć kodu, którego nie oceniają.
    #8
    +10
    user44108
    2019-02-08 21:29:30 UTC
    view on stackexchange narkive permalink

    Z jednej strony powiedziałeś, że każdy programista jest odpowiedzialny za swój własny kod, a mimo to chcesz zgłosić swojemu kierownikowi jednego ze współpracowników za to, że nie działa zgodnie z Twoimi standardami.

    Jeśli kod działa zgodnie z oczekiwaniami, nie trzeba o tym mówić, dopóki nie pojawi się problem lub nie zostaną ustalone standardy kodowania dla zespołu jako całości.

    Przeczytaj moją pierwszą zmianę, aby zrozumieć, dlaczego martwię się o to, czy powinienem, czy nie powinienem tego zgłosić
    @angelhumberto: i czy opuścisz firmę przed współpracownikiem?YAGNI jest wyrażeniem biznesowym i oznacza, że nie działa, dopóki nie musisz.Jeśli i kiedy będziesz musiał go przejąć, wkrótce go przejmiesz.Do tego czasu nie musisz nic z tym robić.
    #9
    +8
    Omar Martinez
    2019-02-09 01:41:46 UTC
    view on stackexchange narkive permalink

    Masz tutaj dwa punkty:

    • Na Twoim obecnym stanowisku to nie twój problem , powiedziałeś, że Twój szef prosi tego współpracownika o dokończenie kodował szybko, więc tak zrobił, zostawiając te 3000 linii z dużym długiem technicznym , możesz o tym wspomnieć swojemu szefowi (on nie rozumie programowania, ale pojęcie długu jest czymś, co każdy wie) po prostu wyjaśnij, że chociaż kod działa, jeśli coś się zepsuje lub współpracownik, który go pisze, opuści firmę, zrozumienie tego, co zrobił, zajmie trochę czasu, może to zrozumieć, ale prawdopodobnie nawet jeśli to zrozumie, powie, że to nie jest problem teraz, ponieważ to nie jest problem, przynajmniej nie twój, co prowadzi nas do następnego punktu.

    • Tak więc współpracownik opuszcza firmę i teraz jest twój problem (wspominasz, że jest 3 programistów, więc nawet w tym przypadku nie mógłbyś być twoim problemem), cóż, (mogę rozmawiać z mojego doświadczenia) nie dotykaj tego, chyba że jest to konieczne, porozmawiaj ze swoim b ponownie oss, pamiętaj o jego pierwszej rozmowie, ale nie zaczynaj refaktoryzacji tego kodu, dopóki twój szef nie zatwierdzi lub s #! t trafi do wentylatora, ponieważ jeśli zaczniesz refaktoryzować ten kod, może to być łatwe, ale istnieje duże prawdopodobieństwo że zajmie Ci trochę czasu, zanim szef będzie oczekiwał, że skupi się na czymś innym.

    Kilka rzeczy do rozważenia, nawet jeśli jest to mała firma z szefem, który nie nie rozumiem, jak działa programowanie:

    • Jak wspomina inna odpowiedź, Twój szef nie wie o programowaniu, ale wie o biznesie (mam nadzieję), więc najlepszy sposób, aby go zrozumieć dlaczego przeglądy kodu, testy jednostkowe i inne praktyki są konieczne, to poinformowanie go, że są to inwestycje, mniej błędów, mniej przestojów w produkcji itp.
    • Nie wiem, kto jest starszym członkiem zespołu, jeśli jest tym, który ma 3000 linii, możesz mieć trudności z przekonaniem szefa, że ​​to, co robi, nie jest najlepszym podejściem. Dotyczy to sytuacji, gdy jesteś osobą z mniejszym doświadczeniem.
    • Możesz porozmawiać ze swoim współpracownikiem i spróbować zrozumieć, dlaczego to zrobił. Wspomniał, że jest zoptymalizowany , może to oznaczać, że kod działa, jak mówisz, i jest szybki ( możesz nie brać pod uwagę szybkości, ale w biznesie czasami jest to ogromna sprawa), ale wie, że ma dług techniczny i planuje to naprawić, po prostu postępuj zgodnie z poleceniem szefa, aby tak szybko zakończyć.
    #10
    +7
    cybernard
    2019-02-09 04:45:01 UTC
    view on stackexchange narkive permalink

    Myślę, że przykład autobusu może być najlepszy.

    Poszedłbym do twojego szefa i powiedziałbym: „Mam obawy co do możliwości utrzymania kodów, jeśli pracownik zostanie potrącony przez autobus lub w inny sposób niedostępny, zajmie mi to ## tygodni, aby to rozgryźć. Czy zgadzasz się, że nie będę mógł pracować nad innym projektem przez ## tygodnie, jeśli ten projekt kiedykolwiek będzie wymagał konserwacji, jeśli inna osoba nie będzie dostępna? ”

    Pozwól swojemu szefowi podjąć ostateczną decyzję, co jest ważniejsze dla tego projektu „gotowe” czy „możliwe do utrzymania”?

    Z tego, co wiemy, szef może być w porządku, klient będzie musiał zapłacić nam 2x więcej, ponieważ jeśli zechce wprowadzić modyfikacje, będzie musiał za to zapłacić.

    To oznacza, że ​​najważniejsze dla szefa jest to, za co zapłaci klient.

    Gdyby mój szef nie rozumiał programowania, wątpię, bym im powiedział, że „Mój współpracownik wykonuje swoją pracę dobrze i prawdopodobnie mógłby stosunkowo łatwo przejąć mój projekt. Jednak miałbym dużo trudności, gdybym musiał to zrobićjego praca."
    Podoba mi się część, w której powiedziałeś: „Pozwól swojemu szefowi podjąć ostateczną decyzję, co jest ważniejsze dla tego projektu”, czy „jest gotowe”, czy „da się go utrzymać”?Ogólnie dobra odpowiedź dzięki za poświęcony czas
    #11
    +6
    Anonymous Coward
    2019-02-09 01:25:20 UTC
    view on stackexchange narkive permalink

    Zapobieganie problemom jest tańsze niż czekanie na ich wystąpienie, a następnie ich rozwiązywanie. Twój szef lubi tanio.

    Zapytaj swojego szefa, czy oczekuje, że Twój Twój kod będzie używany przez długi czas i czy prawdopodobne są zmiany, jeśli klienci za nie zapłacą.

    Prawdopodobnie jeśli otrzymasz odpowiedź tak dla obu, zasugeruj, że chciałbyś, aby nowy kod, który piszesz, został sprawdzony przez innych. Nie zajmie im to dużo czasu, a dodatkowy czas zostanie zapłacony dziesięciokrotnie, ponieważ błędy są znacznie tańsze, im wcześniej zostaną wykryte. Błąd znaleziony w świeżo zapamiętanym kodzie jest łatwiejszy do naprawienia niż błąd znaleziony przez klienta za pomocą zwykłych mniej niż pomocnych raportów o błędach od klientów. Zapewnij go, że nie będziesz prosić o dużo przeglądu kodu, może raz na parę tygodni. Jeśli zapyta, czy nie masz pewności co do jakości Twojego kodu, zapewnij go, że wcale tak nie jest. Ale 6 oczu ma szersze spojrzenie niż 2, a przegląd kodu jest standardową praktyką branżową, ponieważ korzyści znacznie przewyższają minimalne koszty.

    Jeśli się z tym zgadza, gdy Twoi znajomi znajdą błędy w Twoim kodzie, poinformuj o tym szefa. Wspomnij, ile więcej czasu musiałbyś poświęcić na debugowanie problemu, gdyby kod wszedł do produkcji. Albo utrata zaufania klienta. Wspomnij, jak bardzo praca tego zespołu ulepsza produkt, nawet jeśli pracujesz nad różnymi projektami.

    Jeśli przejdzie do tego kroku, z łatwością zrobi sobie następny: przegląd kodu wszystkich.

    Jeśli nie chce zaakceptować kogoś, kto zgłasza się na ochotnika do przeglądu jego kodu, nie ma szans, żebyś pozwolił ci przejrzeć kod twojego kumpla.

    Miła odpowiedź dziękuję za poświęcony mi czas, który wezmę pod uwagę przy podejmowaniu ostatecznej decyzji
    #12
    +4
    JeffC
    2019-02-09 02:05:31 UTC
    view on stackexchange narkive permalink

    Z tego, co opisujesz, masz górę do zdobycia i zespół, który ją przeciągnie.

    Nie sądzę, żebym mówił konkretnie o metodzie 1k linii, zacznę od wprowadzenia wypracuj najlepsze praktyki z szefem w stosunku 1: 1. Zapytaj go, czy zespół ma jakieś wytyczne dotyczące kodowania lub najlepsze praktyki, których przestrzega. Zakładając, że odpowiedź brzmi nie, zbierz kilka linków do artykułów na temat najlepszych praktyk dla dowolnego języka programowania, którego używasz. Staram się pozostać przy przewodnikach po programowaniu od dużych firm ... firm, o których wszyscy słyszeli, takich jak Google, Microsoft itp., I zacznij od ich przewodników po kodowaniu.

    Przynieś je swojemu szefowi wraz z kilkoma artykułami na temat jak wdrażanie najlepszych praktyk pomaga ... jakie są korzyści itp. Nie przynoś swojej wiadomości, jesteś posłańcem. Przynosisz radosne wieści o sposobach zwiększenia wydajności, oszczędzania pieniędzy, mniejszej liczby usterek, a lista jest długa ...

    Myślę, że Twój szef zareagowałby lepiej na takie podejście. A kiedy już go wciągniesz (miejmy nadzieję), dyskutujesz o nich w zespole i zacznijmy ich śledzić. (Dorzuciłbym kilka najlepszych praktyk proceduralnych, takich jak przeglądy kodu i tym podobne, a nie tylko wskazówki dotyczące kodowania). Następnie, jeśli uda Ci się ich skłonić do zakupu, zacznij stosować te wytyczne i przeglądać nowy kod (i stary kod jako napotkasz).

    „Hej, znalazłem tę obszerną metodę, zgodnie z którą zgodnie z ABC najlepszą praktyką powinniśmy podzielić na mniejsze metody, które mają tylko jedną odpowiedzialność itd.” i idź stamtąd.

    Szczerze mówiąc, wątpię, czy zajdziesz daleko w tym wszystkim, ale tak bym do tego podszedł.

    Podoba mi się twoja odpowiedź i zgadzam się z tobą, kiedy powiedziałeś, że mam górę do zdobycia, ale jest to góra z 90 °, bez sprzętu i gdyby to nie wystarczyło, powiedziałbym, że góra jest zamarznięta i chroniona przez gigantyczny smoczy xD
    #13
    +3
    ChrisW
    2019-02-09 15:20:41 UTC
    view on stackexchange narkive permalink

    Oprócz "3000 LOC" w PO zwróciły moją uwagę 3 inne frazy:

    • Czy mam przekazać to szefowi, który nie wie nic o programowaniu ?
    • Moim największym zmartwieniem jest to, że mój współpracownik może kiedyś zakończyć współpracę z firmą i będę musiał zająć się tym elementem projektu, nad którym pracował.
    • Przeglądy kodu tutaj nie istnieją.

    Odejście kogoś to ryzyko biznesowe, być może takie, które jest łatwe do zrozumienia dla osoby nie będącej programistą, oraz ryzyko, które jest ograniczone poprzez przegląd kodu.

    Możesz powiedzieć swojemu szefowi, że programiści powinni (przynajmniej) rozumieć swoją pracę - co robi i jak jest zaimplementowana - na wypadek, gdyby któryś z nich wpadł pod autobus. Możesz dodać, że to normalne / profesjonalne.

    Następnie zapytaj kolegę podczas przeglądu kodu: „jak to działa?”

    Powiedziałeś, że martwisz się ...

    Jak do cholery mam czytać metodę 3000 linii?

    ... więc przegląd kodu powinien to wyjaśniać - tj. jak wyjaśniają, jak to czytają .

    Możesz chcieć nalegać „powinieneś użyć podprogramów”, ale jeśli kolega jest niechętny zmianom (dołączony do istniejącej implementacji), być może nie ma sensu nalegać. Po prostu upewnij się, że go rozumiesz, aby móc go zmienić, gdybyś musiał (np. Jeśli go odziedziczyłeś).

    Przeglądy kodu mają inne zalety ...

    • Wykrywanie błędów (ale zauważasz błąd podczas inspekcji kodu)
    • Transfer wiedzy (możesz uczyć się od siebie nawzajem czytając swój kod i omawiając go)
    • Lepsza integracja między modułami (zobacz także prawo Conwaya)
    #14
    +3
    Stephen
    2019-02-08 21:21:55 UTC
    view on stackexchange narkive permalink

    Jeśli szef nie wie nic o programowaniu, nie zawracałbym mu głowy mówieniem mu. Słyszysz, że twój współpracownik zrobi to dla siebie, zwłaszcza że się z tobą przechwala.

    Kod musi działać, to wszystko, na czym zależy Twojemu szefowi. Oczywiście rozmiar i szybkość są ważnymi czynnikami, jeśli jest to duży projekt, ale jeśli jest mały lub średni, praca jest wystarczająco dobra.

    Poproś współpracownika, aby pokazał działający kod lub kod abyś mógł to sprawdzić.

    Przeczytaj moją pierwszą edycję, aby zrozumieć, dlaczego obawiam się metody 3000 linii
    #15
    +2
    Samjongenelen
    2019-02-09 02:01:39 UTC
    view on stackexchange narkive permalink

    Aby to zrobić, próbuję użyć analizatora statycznego. Informacje zwrotne z komputera nie mogą być błędne, dzięki czemu nie musisz osobiście konfrontować się ze współpracownikami. Musisz tylko uzgodnić zasady kodu lub wziąć podstawowy zestaw istniejących reguł.

    * Opinie z komputera nie mogą być błędne * Uhhh ... [pewnie, że tak] (https://money.cnn.com/2018/03/19/technology/uber-autonomous-car-fatal-crash/index.html).
    Blednie tylko w porównaniu z opiniami z internetu;)
    #16
    +1
    Czar
    2019-02-11 14:27:19 UTC
    view on stackexchange narkive permalink

    Wyczuwam tutaj dwie główne wady:

    • Czy oferujesz rozwiązanie problemu? Samo powiedzenie „ten kod jest okropny” nie praca. To mogłaby być opinia, nie wnosi wartości do firmy; szefowie i biznes chcą rozwiązań.

    • Czy masz proces recenzowania? Wzajemne oceny kodu powinny być dokonywane niezależnie od wielkości zespołu: faktyczne podanie szczegółowych informacji o tym, w jaki sposób można refaktoryzować kod, jest lepsze niż jakakolwiek ewentualna reklamacja, a także rozwiązuje powyższy problem.

    Z twoich zmian wynika, że ​​odpowiedź na drugie to „nie”, więc być może właściwą rzeczą, na którą należy zwrócić uwagę szefowi, jest omówienie procesu i nie wskazywanie pojedynczych „błędów kodu”, których nie jest w stanie odpowiednio ocenić, chyba że ufa Ci bardzo długo.

    Jeśli powiesz szefowi:

    Słuchaj, mam pomysł, aby nasza praca była bardziej produktywna: możemy napisać lepszy kod, lepiej dostosować się do zmiana w biznesie, redukcja błędów i posiadanie możliwej do utrzymania bazy kodu, która jest łatwiejsza do opanowania także dla nowicjuszy

    może posłuchałby uważniej. Proponujesz rozwiązania, a nie wskazujesz na problem.

    #17
      0
    520 says Reinstate Monica
    2019-02-08 21:42:19 UTC
    view on stackexchange narkive permalink

    Co ta funkcja próbuje zrobić? Jak złożone jest to zadanie? Do jakiej kategorii optymalizacji dążyli (szybkość, dokładność, użyteczność)? Bez tych informacji trudno będzie orzec. Zawsze możesz rzucić okiem na kod. Jeśli są jakieś nieefektywności, wskaż je w stylu „Kod jest dobry! Quickie [oszczędzenie czasu / zwiększenie wydajności / cokolwiek], zawsze możesz zrobić X, aby uniknąć [wąskiego gardła] '

    #18
      0
    Peter Cordes
    2019-02-11 09:19:28 UTC
    view on stackexchange narkive permalink

    Być może uda Ci się przekonać współpracownika z przyczyn technicznych, że kompilator może je wbudować, więc ta „optymalizacja” na poziomie źródła nie jest pomocna.

    Mam nadzieję, że przesadzasz z jego wypowiedziami o tym, że jest to cała metoda 3000 linii najbardziej zoptymalizowana z możliwych , inaczej twój współpracownik prawdopodobnie nie ma pojęcia o optymalizacji wydajności i po prostu chwyci się czegoś, co przeczytał raz. Ludzi, którzy myślą, że coś wiedzą, ale naprawdę nie rozumieją, czasami najtrudniej jest przekonać. Kilka razy wymieniłem się komentarzami dotyczącymi przepełnienia stosu, z ludźmi, którzy nie chcieli uwierzyć, że się mylili, ale nie byli w stanie podać spójnego technicznego wyjaśnienia, które miałoby jakikolwiek sens.

    Jako ekspert ds. Optymalizacji asm [x86], [assembler], [performance], [sse] tagi itp.), mogę powiedzieć, że jest prawie niemożliwe, aby ta funkcja była „najbardziej zoptymalizowana z możliwych”, nawet jeśli Twój współpracownik spędził lata na profilowaniu i dostosowywaniu ( na jakimś konkretnym sprzęcie? z określoną wersją systemu operacyjnego i kompilatora?). Tak duża funkcja zawsze będzie miała miejsce na drobne poprawki (lub nowe pomysły na duże zmiany), które mogą ją przyspieszyć lub zmniejszyć (kod maszynowy) z tą samą prędkością (być może bardziej przyjazna dla hiperwątkowości, aby wykonać tę samą pracę w mniejszej liczbie instrukcji) .

    Nie sądzę, żeby kompilator C # + JIT był tak zły, że nie może wywołać metody wbudowanej, zwłaszcza jeśli mają tylko jedną witrynę wywołań . Nie znam języka C # (głównie C i C ++), ale czy ma coś takiego jak statyczna wbudowana funkcja niebędąca składnikiem, którą kompilator może wbudować zamiast emitować stojak -samodzielna definicja dla i zrobi to, nawet jeśli funkcja jest duża? Lub coś takiego jak GNU C __attribute __ ((always_inline)) ? Twój współpracownik może to wykorzystać, aby poczuć, że uzyskuje optymalizację, którą uważa za ważną, bez powodowania nieprzyjemnego bałaganu w źródle.


    Ale co ważniejsze, „optymalizacja” jest warta kompromisu w zakresie czytelności tylko wtedy, gdy prosta wersja bazowa (którą napisałeś jako punkt wyjścia i do porównania z wersją zoptymalizowaną) jest wolniejsza niż chcesz silny>. Nie możesz stwierdzić, czy faktycznie optymalizujesz cokolwiek, jeśli nie masz punktu wyjścia, z którym mógłbyś porównać, a tym samym ocenić jakąkolwiek kompromis w zakresie czytelności lub rozmiaru kodu maszynowego / pamięci podręcznej instrukcji w porównaniu z przyspieszeniem.

    Pisanie mniej czytelnej „zoptymalizowanej” wersji bez prostej linii bazowej jest zwykle błędem , chyba że już myślisz, że wiesz z doświadczenia, jak skompilowałaby się prosta wersja i że nie byłaby wydajna dość. Zwykle masz prostą wersję jako część testu jednostkowego dla ręcznie rozwiniętej / zwektoryzowanej wersji. (Ten przypadek wstawiania ręcznego może być jednak inny. Nie sprawia, że ​​żaden pojedynczy element logiki nie jest bardziej złożony ani „dziwnie” zaimplementowany. A może tak jest? Czy istnieje ręczna optymalizacja między blokami?)

    bardzo często jest tego wart w przypadku małych funkcji, ale wywołanie dużego bloku kodu z wielu witryn wywołań tylko raz wykorzystuje ślad pamięci podręcznej instrukcji. Jednak za każdym razem płaci narzut wywołania funkcji, więc mikroznakowanie tylko jednej funkcji, bez pełnego kontekstu programu, może sprawić, że nadmierne wstawianie i rozwijanie będzie wyglądać dobrze. Zwykle nie ma problemu, pozostawiając decyzję nowoczesnej heurystyce kompilatora; są zwykle dość dobrze dostrojone, zwłaszcza jeśli potrafią przeprowadzić optymalizację sterowaną profilem, aby znaleźć pętle, które są naprawdę gorące. (Kompilatory JIT działają w czasie wykonywania, więc mają dane do profilowania, jeśli chcą ich używać. Zwykle od stworzenia nie w pełni zoptymalizowanej wersji lub najpierw zinterpretowania, a następnie użycia danych profilowania do spekulatywnego wbudowania metod wirtualnych i tym podobnych.) / p>

    Czasami optymalizacja nie szkodzi czytelności, ale w tym przypadku wyraźnie tak.

    W C ++ często piszę małe statyczne inline funkcje pomocnicze, które będą wbudowane w większą funkcję Optymalizuję bzdury za pomocą wewnętrznych elementów SIMD. Kiedy patrzę na asm wygenerowany przez kompilator, widać dokładnie zero wady w wydajności kodu maszynowego i niezły plus w czytelności źródła. Żadna samodzielna definicja nie pojawia się nigdzie w pliku wykonywalnym dla tych funkcji pomocniczych, więc nawet nie nadużywają pliku wykonywalnego.


    Jeśli chcesz wcisnąć problem, zapytaj współpracownika, czy przyjrzeli się wynikom asm kompilatora JIT pod kątem ich metody i sprofilowali je, i stwierdzili, że te duże bloki warunkowe pozwoliły kompilatorowi na optymalizację w sposób, w jaki nie byłby w stanie tego zrobić przy wstawianiu.

    Świadomość tego, co + + kompilator sprzęt może działać wydajnie nie zawsze jest złą rzeczą, jeśli pozwolisz, aby informowało to o wyborach kodowania, gdy nie szkodzi to czytelności.

    Kuszące jest wciągnięcie w optymalizację czegoś, co nie wymaga optymalizacji . Zwłaszcza jeśli myślisz tylko o optymalizacji szybkości tej jednej funkcji, jeśli została wywołana w gorącej pętli , gdy nie będzie ona w gorącej pętli. Jeśli jest wywoływany rzadko, pamięć podręczna kodu może być zimna, więc kompaktowy jest lepszy. (Mniej wierszy kodu w pamięci podręcznej do załadowania z pamięci głównej.)

    Ten rodzaj argumentów pomaga tylko wtedy, gdy można rozliczyć typowe funkcje pomocnicze z tej 3000-liniowej metody. Umieszczenie każdego bloku w osobnej funkcji nie zmniejszy kodu maszynowego. Może to wpłynąć na logikę decyzyjną, dla której funkcji należy wysłać do bardziej zlokalizowanej, co skutkuje mniejszym zużyciem pamięci podręcznej I-cache. I może mniej stron 4k dotkniętych / załadowanych z dysku / i-TLBfootprint.

    #19
      0
    Brandon
    2019-02-11 23:08:58 UTC
    view on stackexchange narkive permalink

    Kilka uwag:

    • Twój przełożony mógłby prawdopodobnie zapewnić rozwiązanie konfliktu i mediację, ale tak naprawdę nie może ocenić zalet technicznych, więc będzie musiał polegać na Twoich ekspertyza. Jeśli sprowadza się to do Twojej wiedzy, myślę, że możesz to rozwiązać.
    • Martwisz się konsekwencjami pozostawienia kodu w spokoju. Jeśli konsekwencją są koszty utrzymania, czy jest lepszy sposób dla Twojego współpracownika na nauczenie się tej lekcji niż ciężka praca, gdy następnym razem będzie musiał zmienić funkcję? Doświadczenie może być dobrym nauczycielem.
    • Prawdziwymi korzyściami z rozbijania kosztów są czytelność, sprawdzalność i prostota. Bez zrozumienia tych korzyści przez współpracownika, poproszenie go o rozbicie spowoduje utworzenie sztucznych granic kodu. Pokazywanie im lepszego sposobu będzie pomocne.

    Spojrzenie na to inaczej: Przywództwo

    Moim zdaniem , gdy Twój menedżer nie jest liderem technicznym, udanie się do niego w celu rozwiązania tego problemu zminimalizuje szansę na naukę Twojego współpracownika i spowoduje ryzyko powstania rozdźwięku między Tobą a nim.

    Jeśli tego nie zrobisz mieć lidera technicznego, do którego to eskaluje, a następnie być liderem, pomagając swojemu koledze z zespołu wyrosnąć na lepszego programistę.

    Możemy to wszystko sprowadzić do dwóch możliwych podejść:

    Zostaw to

    Pozwól im zrobić to po swojemu, a kiedy ten kod stanie się problemem, pomóż im zrozumieć, dlaczego jest to problem i pomóż im znaleźć kilka kluczowych bloków kodu, które mogą oddzielić. Nauczą się. Poważnie, w porządku. Robiłem to na stanowiskach kierowniczych. To tylko kod. Można to później zmienić.

    Pokaż drogę

    Pokaż im alternatywę, ze wszystkimi uzyskanymi korzyściami . Albo przepisz ich kod w gałęzi, rozkładając go na odpowiednie warstwy, spraw, by kod był krystalicznie czysty (dobre nazwy funkcji i zmiennych) i napisz bardzo dobre testy jednostkowe. Napisz testy, których nie dałoby się napisać przy starym kodzie. Przedstawiając ten kod swojemu koledze, wymyśl dowolną zmianę wymagań, którą chcesz udawać, przeprowadzić ich implementację, aby zobaczyli, jak łatwo jest ją zaimplementować i upewnij się, że działa .



    To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 4.0, w ramach której jest rozpowszechniana.
    Loading...