Czy powinienem stosować zły styl kodowania, aby przestrzegać ustalonych konwencji w moim miejscu pracy?

102

Pracuję w pracy od około roku. Pracuję przede wszystkim w interfejsie GUI, który wykorzystuje metody z zaplecza C, ale generalnie nie muszę sobie z nimi radzić, z wyjątkiem zwracanych wartości. Nasze GUI ma dość rozsądną strukturę, biorąc pod uwagę nasze ograniczenia.

Zadanie polegało na dodaniu funkcji do części wiersza poleceń programu. Większość z tych funkcji ma około 300 linii i jest trudna w użyciu. Próbuję zebrać ich fragmenty, aby uzyskać określone informacje o alarmie i mam problem z utrzymaniem porządku. Wiem, że komplikuję testowanie, wykonując je w jednej długiej funkcji.

Czy powinienem po prostu utrzymywać wszystko w wielkiej funkcji zgodnie ze stylem istniejących funkcji, czy też powinienem zawrzeć alarmy we własnych funkcjach?

Nie jestem pewien, czy należy postępować wbrew obecnym konwencjom kodowania, czy też powinienem po prostu ugryźć kulę i sprawić, że kod będzie dla mnie bardziej mylący.

Podsumowując, porównuję

showAlarms(){
    // tons of code
}

przeciwko

showAlarms(){
   alarm1();
   alarm2();
   return;
}

alarm1(){
    ...
    printf(...);
    return;
}

EDYCJA: Dziękuję za radę wszystkim, zdecydowałem, że zaprojektuję mój kod z uwzględnieniem faktów, a następnie zapytam, czego chcą, a jeśli chcą tego wszystkiego w jednym, mogę po prostu wyciąć z mojego kodu i przekształcić go z powrotem w 1 duża funkcja. To powinno pozwolić mi napisać i przetestować go łatwiej, nawet jeśli chcą całego kodu w jednej definicji.

AKTUALIZACJA: W końcu byli zadowoleni z faktorowanego kodu i więcej niż jedna osoba podziękowała mi za ustanowienie tego precedensu.

Justin
źródło
117
Jest wysoce wątpliwe, aby firma, dla której pracujesz, zajęła stanowisko, że twoje funkcje powinny mieć długość 300 linii, ponieważ „tak zawsze to robiliśmy”. To nie są „konwencje stylu kodowania”; to po prostu zły styl.
Robert Harvey,
64
Jest to rodzaj rzeczy, którą powinieneś omówić z innymi członkami swojego zespołu, aby dowiedzieć się, jakie praktyki widzisz, są to konwencje, które ich zdaniem są ważne dla wszystkich, i jakie są rzeczy, które ktoś zrobił tylko raz, a których nie trzeba naśladować. Bez wątpienia będzie ich trochę.
Servy,
17
@beginnerBinx To sprowadza się do tego, jak to wyrażasz. Nie frazuj tego tak: „X robi coś naprawdę głupiego, czy ja też muszę robić to głupie”. ale raczej jako coś w stylu: „Widzę, że X robi to jedno, czy jest jakiś konkretny powód, dla którego robi to tak, jak robi; czy byłby to problem, gdybym nie zrobił tego samego, pisząc Y?” Następnie decyduje, czy skasować stary kod, czy wyjaśnić, dlaczego musieli to zrobić w ten sposób (czy to niechętnie, czy entuzjastycznie).
Servy,
11
Dobry lub zły styl jest często dyskutowany i rzadko uzgadniany. Nauczanie uniwersyteckie polega na tym, że funkcje powinny być krótkie, ale jeśli to przesłania sens, nie rób tego. Test powinien być klarowny, a nie bezmyślny zgodnie z zestawem reguł.
szybko_now
9
Losowi ludzie w Internecie nie mogą czytać znajomych z twojego zespołu, więc wszystkie odpowiedzi, które tu otrzymujesz, są tylko osobistymi preferencjami. Powinieneś porozmawiać ze swoim zespołem. Czy długa funkcja jest celową zasadą projektowania? Czy chcieliby, abyś kontynuował styl długiej funkcji, czy też chciałby, abyś napisał to, co uważasz za najczystsze?
JacquesB

Odpowiedzi:

102

To naprawdę jest między tobą a kolegami z drużyny. Nikt inny nie jest w stanie udzielić właściwej odpowiedzi. Jeśli jednak odważę się czytać między wierszami, fakt, że nazywacie ten styl „złym”, daje pewne informacje, które sugerują, że lepiej jest robić to powoli. Bardzo niewiele stylów kodowania jest w rzeczywistości „złych”. Są takie, których sam bym nie użył, ale zawsze mają rym lub powód. Sugeruje mi to, że w tej historii jest coś więcej niż do tej pory. Zapytanie byłoby bardzo mądrym telefonem. Ktoś może wiedzieć coś, czego ty nie wiesz.

Natknąłem się na to, osobiście, na mojej pierwszej wyprawie w kierunku kodowania krytycznego w czasie rzeczywistym. Widziałem taki kod:

lockMutex(&mutex);
int rval;
if (...)
{
    ...
    rval = foo();
}
else
{
    ...
    rval = bar();
}
unlockMutex(&mutex);
return rval;

Będąc jasnym i błyszczącym programistą OO C ++, od razu wezwałem ich na ryzyko błędów, które mieli, ręcznie blokując i odblokowując muteksy, zamiast używać RAII . Nalegałem, żeby było lepiej:

MutexLocker lock(mutex);
if (...)
{
    ...
    return foo();
}
else
{
    ...
    return bar();
}

O wiele prostsze i bezpieczniejsze, prawda ?! Po co wymagać od programistów pamiętania o odblokowaniu muteksów na wszystkich ścieżkach przepływu sterowania, gdy kompilator może to zrobić za Ciebie!

Cóż, dowiedziałem się później, że istnieje ku temu powód proceduralny. Musieliśmy potwierdzić, że tak, oprogramowanie działało poprawnie i istniała skończona lista narzędzi, których wolno nam było używać. Moje podejście mogło być lepsze w innym środowisku, ale w środowisku, w którym pracowałem, moje podejście z łatwością pomnożyłoby ilość pracy związanej z weryfikacją algorytmu dziesięciokrotnie, ponieważ właśnie włączyłem koncepcję RAII w C ++ do sekcji kodu trzymano się standardów, które były naprawdę bardziej podatne na myślenie w stylu C.

Więc to, co wyglądało na zły, wręcz niebezpieczny, kodujący styl, było właściwie dobrze przemyślane, a moje „dobre” rozwiązanie było w rzeczywistości niebezpieczne, które mogło powodować problemy na drodze.

Więc zapytaj. Na pewno jest starszy programista, który może z tobą współpracować, aby zrozumieć, dlaczego robią to w ten sposób. Lub istnieje starszy programista, który może pomóc Ci zrozumieć koszty i zalety refaktora w tej części kodu. Tak czy inaczej, zapytaj!

Cort Ammon
źródło
60
Prawdopodobnie bardziej niebezpieczną częścią przykładu muteksu jest pozorny brak komentarzy do kodu wyjaśniających, dlaczego nie mógł użyć RAII. To prawda, że ​​jeśli ta jawna blokada / odblokowanie jest w całej bazie kodu, dodawanie komentarza do każdej instancji może być niewygodne. W takim przypadku może być konieczne napisanie dokumentu podstawowego, z którym powinni zapoznać się nowi deweloperzy.
Kelvin
10
Jasne, rozmowa ze seniorem jest zawsze dobra, a refaktoryzacja musi być przeprowadzona z ostrożnością (i testowaniem). Oczywiście współbieżność / muteksy same w sobie są specjalną bestią. Ale widząc funkcje z> 300 liniami, nie poświęciłbym zbyt wiele czasu na poszukiwanie „ukrytego technicznego powodu”, dlaczego te funkcje są zbyt duże. Przyczyny, dla których funkcje stają się zbyt długie, są zawsze takie same i nie są techniczne.
Dok. Brown
8
@DocBrown To, że nie są techniczne, nie oznacza, że ​​nie są powodem. Ważne jest, aby programiści pamiętali, że są one częścią większej maszyny. (Nie mogę policzyć, ile razy musiałem ponownie uczyć się tej lekcji)
Cort Ammon
4
@DocBrown Tak czy inaczej, należy rozmawiać z wyższymi programistami. Wybrałem przykład, który zrobiłem, ponieważ łatwo znaleźć niezliczone argumenty za tym, dlaczego głupi kod jest głupi. Znalezienie argumentów, dlaczego kod, który wygląda głupio, nie jest głupi, jest trudniejsze.
Cort Ammon
3
@DocBrown Na podstawie twoich komentarzy i odpowiedzi sądzę, że mogę stwierdzić, że różnica w naszych opiniach polega na tym, że zaczynasz od założenia, że ​​kod jest już „zły” w oparciu o przedstawione przez ciebie dowody, a ja wolałbym wybierz ścieżki, które sprawdzą, czy kod jest „zły”.
Cort Ammon
84

Szczerze mówiąc, czy uważasz, że posiadanie trudnych w użyciu funkcji z 300 liniami to tylko kwestia stylu? Więc pójście za złym przykładem może utrzymać ogólny program w lepszym stanie ze względu na spójność? Chyba w to nie wierzysz, inaczej nie zadałbyś tego pytania tutaj.

Domyślam się, że te funkcje są tak długie, ponieważ w naszej firmie jest wielu miernych programistów, którzy po prostu nakładają funkcje na funkcje, nie dbając o czytelność, jakość kodu, prawidłowe nazewnictwo, testy jednostkowe, refaktoryzację i nigdy nie nauczyli się tworzyć odpowiednich abstrakcji . Musisz sam zdecydować, czy chcesz śledzić to stado, czy chcesz być lepszym programistą.

Dodatek, z uwagi na komentarze: „300 linii” i „trudny w użyciu” są silnymi wskazaniami IMHO na zły kod. Z mojego doświadczenia wynika, że ​​jest bardzo mało prawdopodobne, aby istniał jakiś „ukryty techniczny powód”, dla którego takiego kodu nie można zaimplementować w bardziej czytelny sposób, porównywalny z przykładem odpowiedzi Cort Ammon. Zgadzam się jednak z Cortem, że powinieneś omówić to z odpowiedzialnymi w zespole - nie po to, by znaleźć niejasne powody, dla których kod lub ten „styl” nie może zostać zmieniony, ale aby dowiedzieć się, w jaki sposób można bezpiecznie refaktoryzować kod bez zepsucia rzeczy .

Doktor Brown
źródło
127
Nawet kompetentni programiści popełniają te przestępstwa w napiętych terminach.
ogrodnik
13
@gardenhead, rozumiem, że nie refaktoryzuję funkcji 300-liniowej w celu zaoszczędzenia czasu, ale nie ma możliwości, aby napisanie funkcji 300-liniowej pozwoliło ci zaoszczędzić czas.
Dangph
39
@gardenhead: kiedy idę do chirurga, ponieważ potrzebuję pilnej pomocy, nadal oczekuję, że poświęci trochę czasu, aby umyć ręce, zanim zacznie na mnie występować. Jest to coś, czego wiele osób musi nauczyć się w naszej firmie, aby osiągnąć prawdziwe kompetencje: zawsze zostawiaj kod w lepszym stanie niż był wcześniej, a to poprawi również zdolność do dotrzymywania terminów. 300 funkcji linii zwykle rośnie z dnia na dzień, przez ludzi, którym to nie obchodzi, i zawsze będą używać „terminu” jako wymówki.
Dok. Brown
17
@ Dangph oszczędza czas, gdy dodasz tylko 5 wierszy do funkcji zamiast go refaktoryzować. Te zwykle rosną, gdy początkowa funkcja jest długa (ponad 30 linii), a następny programista myśli „to nie jest mój kod, nie będę refaktoryzować, aby go nie złamać, po prostu dodaj kilka linii tu i tam”.
Džuris,
7
@Juris, jak rozumiem, pytanie dotyczy utworzenia nowej funkcji, a nie refaktoryzacji istniejących. Jeśli piszesz nową funkcję, nie zaoszczędzisz czasu, przekształcając ją w funkcję pojedynczego potwora.
Dangph
42

Nie.

W książce Pragmatic Programmer autor mówi o teorii rozbicia okna .

Ta teoria stwierdza:

Rozważ budynek z kilkoma wybitymi oknami. Jeśli okna nie zostaną naprawione, wandale mają tendencję do wybijania kilku kolejnych okien. W końcu mogą nawet włamać się do budynku, a jeśli nie jest zajęty, może stać się squatters lub zapalić ogień w środku.

Lub rozważ chodnik. Niektóre śmieci gromadzą się. Wkrótce gromadzi się więcej śmieci. W końcu ludzie zaczynają nawet zostawiać torby z odpadkami z restauracji na wynos lub nawet włamać się do samochodów.

W książce autor pisze analogię między tą teorią a kodem. Gdy znajdziesz taki kod, przestajesz zadawać sobie to samo pytanie.

Odpowiedź brzmi: nie.

Gdy opuścisz to zepsute okno - w naszym przypadku zły kod - spowoduje to, że każdy pozostawi po sobie zepsute okno.

I pewnego dnia kod się zawali.

Daj wszystkim kopię Clean Code i Clean Coder .

Podczas gdy jesteś w temacie, kopia TDD jest również dobra.

linuxunil
źródło
6
Co jeśli baza kodów jest szklarnią z niczym innym, jak tylko wybitymi oknami?
Alan Shutko
8
@AlanShutko Więc upewnij się, że twoje CV jest aktualne? Znajdź innego pracodawcy teraz .
David Montgomery,
12
Kod rzadko „zwija się”. Dodawanie nowych funkcji jest coraz trudniejsze, zajmuje coraz więcej czasu, a szacunki dotyczące czyszczenia kodu wzrosną - co oznacza, że ​​coraz trudniej jest uzyskać budżet na niezbędne czyszczenie.
Dok. Brown
8
Wow, jaką arbitralną analogią wydaje się teoria „wybitego okna”.
Samthere,
4
TDD nie ma z tym nic wspólnego. Niezależnie od tego, czy wybierasz się do projektowania sterowników Business / Domain / Test / Nothingness, które niczego nie zmieniają, postępuj zgodnie z podstawami czystego kodu. Przepraszam, ale to naprawdę męczące, gdy „TDD” jest cytowane wszędzie, nawet w temacie
Walfrat,
25

Tak, idź po to. Struktura! = Styl

Mówisz o strukturze, a nie o stylu. Wytyczne stylu (zwykle) nie określają struktury, ponieważ struktura jest wybierana na ogół ze względu na jej odpowiedniość dla konkretnego problemu, a nie odpowiedniość dla organizacji.

Bądź ostrożny

Po prostu bądź pewien, że nie wywołujesz negatywnych konsekwencji w innych obszarach, które mogły ci nie przynieść. Na przykład,

  • Upewnij się, że nie komplikujesz różnic ani scalania kodu, ponieważ zatarłeś wszelkie podobieństwa do istniejącego kodu.
  • Upewnij się, że przepływy wyjątków poprawiają się, a ślady na stosie nie są zanieczyszczone ogromną kupką nieczytelnych bzdur.
  • Upewnij się, że nie ujawniasz przypadkowo publicznych punktów wejścia, które wywołałyby problemy, gdyby zostały wywołane bezpośrednio (nie umieszczaj ich na mapie i / lub nie eksportuj ich).
  • Nie zaśmiecaj globalnej przestrzeni nazw, np. Jeśli wszystkie twoje mniejsze funkcje wymagają pewnego rodzaju globalnego kontekstu, który został wcześniej zadeklarowany w zakresie funkcji lokalnych.
  • Pamiętaj, aby spojrzeć na dowolne dzienniki i zadać sobie pytanie, czy byłeś w zespole wsparcia, czy dzienniki wygenerowane przez Twój kod byłyby mylące, gdyby były widoczne wplecione w dzienniki z dowolnego kodu, którego nie dotykasz.
  • Upewnij się, że stosujesz się do istniejącego stylu, np. Nawet jeśli używają oldskulowej notacji węgierskiej i powoduje to krwawienie oczu, pozostań spójny z ogólną bazą kodu. Jedyną rzeczą bardziej bolesną niż czytanie notacji węgierskiej jest czytanie kodu, który wykorzystuje tuzin różnych rodzajów notacji w zależności od tego, kto co napisał.

Bądź łagodny

Pamiętaj, że należysz do zespołu i chociaż dobry kod jest ważny, bardzo ważne jest również, aby członkowie Twojego zespołu mogli zachować to, co napisałeś podczas wakacji. Staraj się trzymać strumienia, który będzie miał sens dla osób przyzwyczajonych do starego stylu. To, że jesteś najmądrzejszym facetem w pokoju, nie oznacza, że ​​powinieneś mówić ponad głowami wszystkich!

John Wu
źródło
„Staraj się trzymać strumienia, który będzie miał sens dla osób przyzwyczajonych do starego stylu”. - więc, czy radzisz programować w taki sam sposób, jak wcześniej zrobił to niekompetentny klaun? Dodanie funkcji 300 linii nie ułatwi tego.
BЈовић
11
Nie powiedziałem, żeby trzymać się podobnego przepływu. Powiedziałem, że trzymaj się przepływu, który zrozumieją.
John Wu
2
Dobra rada. Kiedy przełożyłem pojedyncze polecenie na 5 funkcji w tej odpowiedzi, subtelnie zmieniłem semantykę, wstępnie obliczając wartości wewnątrz wyrażenia logicznego, które pierwotnie były obliczane tylko warunkowo. Recenzenci to jednak złapali ;-). Poważna rada to dokładne sprawdzenie i przetestowanie. Każda zmiana może wprowadzać błędy, co może być głównym powodem, dla którego nikt ich nie popełnił.
Peter A. Schneider,
6

Nie uważam tego za konwencję kodu. Widzę to jako kogoś, kto nie rozumie, jak napisać łatwy do utrzymania kod, który można łatwo utrzymać. Rozbiłbym twój kod na różne funkcje, gdy sugerujesz i edukuję Twój zespół w zakresie korzyści płynących z tego, próbując zrozumieć, dlaczego ich zdaniem funkcje 300-liniowe są dopuszczalne. Byłbym bardzo zainteresowany usłyszeniem ich uzasadnienia.

Bernard
źródło
1
Nie ma powodu, to tylko nasza polityka.
5

Odpowiedź znajduje się w przeglądzie kodu.

Prawdziwe pytanie brzmi: czy jeśli wprowadzisz dobrze zindywidualizowany kod, czy będziesz jedynym, który będzie chciał z nim pracować?

Ja, jak większość ludzi tutaj, wierzę, że 300 funkcji linii jest obrzydliwością. Jednak zabranie Windex na wysypisko nie przyniesie wiele dobrego. Problemem nie jest kod, to kodery.

Sama racja nie wystarczy. Musisz sprzedawać ludzi w tym stylu. Przynajmniej po przeczytaniu. Jeśli nie skończysz jak ten biedny facet: zwolniony, ponieważ twoje umiejętności są zbyt daleko ponad twoich współpracowników

Zacznij od małego. Zapytaj i dowiedz się, czy ktoś preferuje mniejsze funkcje. Lepiej jeszcze przeszukuj bazę kodu i sprawdź, czy możesz dowiedzieć się, kto pisze te najmniejsze (może się okazać, że najbrzydszy kod to najstarszy kod, a obecni koderzy piszą lepszy kod). Porozmawiaj z nimi na ten temat i sprawdź, czy masz sojusznika. Zapytaj, czy znają kogoś, kto czuje to samo. Zapytaj, czy znają kogoś, kto nienawidzi małych funkcji.

Zbierz tę małą grupę i porozmawiaj o wprowadzaniu zmian. Pokaż im kod, który chcesz napisać. Upewnij się, że potrafią to przeczytać. Potraktuj poważnie wszelkie zastrzeżenia. Dokonaj zmian. Uzyskaj kod zatwierdzony. Masz teraz moc spotkania za sobą. Jeszcze kilka takich i możesz stworzyć jednostronicowy dokument, który wyraźnie zaakceptuje nowy styl, który wprowadziłeś.

Spotkania to zaskakująco potężne rzeczy. Mogą wytwarzać siłę przebicia. Siła służy do walki z przeciwnikami tego ruchu. I to właśnie w tym momencie. Ruch. Walczysz o prawo do poprawy status quo. Ludzie boją się zmian. Będziesz musiał słodko porozmawiać, zachęcić i prod. Ale przy odrobinie szczęścia zmienisz się w prawo do bycia zaakceptowanym.

candied_orange
źródło
5
Jeśli potrzeba tyle spotkań towarzyskich i wielu spotkań, aby przekonać programistów, że metoda 300 linii jest zbyt długa, nie sądzę, aby rozmowa pomogła. Problem z powyższym podejściem polega na tym, że jeśli poprosisz o pozwolenie na napisanie dobrego kodu, jesteś w defensywie. Ale jeśli po prostu napiszesz dobry kod i poświęcisz trochę czasu na przeredagowanie istniejącego kodu, wtedy każdy, kto sprzeciwia się, jest w defensywie, aby wyjaśnić, dlaczego metoda 300-liniowa jest dobra i uzasadnić poświęcenie czasu na jej przywrócenie.
Brandon
3
Mogę powiedzieć, że gdybym został zaproszony na serię spotkań w celu omówienia linii kodu dla limitów funkcji, znalazłbym sposób na uniknięcie takich spotkań. Nie ma poprawnej liczby i nigdy nie uda ci się zgodzić ludzi. Czasami trzeba pokazać ludziom lepszy sposób.
Brandon
Czasami podzielenie ogromnej funkcji (i lepsze nazywanie rzeczy oraz dodawanie komentarzy i dokumentacji, jak to wymyślam , jest koniecznym pierwszym krokiem przed oszczędnym sprawdzaniem zmian
JDługosz,
@Brandon Prawdopodobnie nie masz na myśli, że to brzmi w ten sposób, ale słyszę, że masz rację i wszyscy inni mogą sobie z tym poradzić. Tak długo, jak Twój kod działa, nie ma znaczenia, czy reszta zespołu go nie rozumie. Na pewno nie warto poświęcać czasu na naukę czegokolwiek. Z przyjemnością obserwujesz, jak nadal tworzą 300 funkcji wiersza podczas pisania kodu po swojemu.
candied_orange
1
@CandiedOrange Na pewno nie miałem na myśli walczyć z drużyną. Miałem na myśli to, że niektórych tematów najlepiej się uczy, widząc je w działaniu, ale próba zmuszenia zespołu do podjęcia demokratycznej decyzji o stylu nie przyniesie rezultatu. Widziałem spójność wykorzystywaną jako wymówkę do pisania nieczytelnego kodu. Wynik? Bardziej nieczytelny kod. Mógłbym zorganizować serię spotkań, aby o tym porozmawiać, lub po prostu to naprawić, a następnie pokazać ludziom wyniki.
Brandon
3

Czasami musisz iść z prądem.

Tak jak powiedziałeś, masz za zadanie zaimplementować funkcję w istniejącej bazie kodu.

Niezależnie od bałaganu i rozumiem, że to kuszące, aby go posprzątać. ale w świecie biznesu nie zawsze masz szansę na zmianę kodu.

Powiedziałbym, po prostu rób to, o co cię poproszono i przejdź dalej.

Jeśli uważasz, że warto je przeredagować lub przepisać, to musisz porozmawiać z zespołem.

meda
źródło
2
Jeśli poprosisz o pozwolenie przy każdym drobnym refaktoryzacji, na zawsze będziesz mieć niemożliwy do utrzymania kod, który jest niebezpieczny dla firmy. Menedżerowie patrzą tylko na koszt zmiany, ale rzadko na koszt braku zmiany.
Brandon
5
OP został poproszony o napisanie funkcji niemodyfikującej setek wierszy kodu
med
2
@meda dokładnie! Jestem w tej samej sytuacji. Rozwijam nowe moduły dla firmowego intranetu i znajduję coś, co można by określić jako „lata zaniedbania nie do naprawienia”, a oprogramowanie serwera i biblioteki nie były w ogóle aktualizowane od 2006 roku. Nie powinienem sprzątać tego bałaganu , ale kodowanie zajmuje mi więcej czasu z powodu ograniczeń. (Wyobraź sobie MySQl 5.2, MySQL 5.0). Nie mogę nic zaktualizować, ponieważ prawdopodobnie istniejący kod nie będzie działał w nowszych wersjach z powodu przestarzałego kodu.
roetnig
3
„Jeśli się nie zepsuło, nie naprawiaj go”. Mam 20-letni samochód, który przecieka trochę oleju. Warto wydawać pieniądze? Nie. Niezawodny? Tak.
3

Przed stwierdzeniem, że praktyki są złe, najpierw zrobię krok w kierunku zrozumienia przyczyny dużych metod i innych praktyk, które mogą okazać się złe.

Następnie musisz upewnić się, że zasięg testu jest dość wysoki lub naprawdę wysoki (o ile możesz to zrobić bez większego refaktoryzacji). Jeśli tak nie jest, starałbym się, aby zasięg był naprawdę wysoki, nawet jeśli nie napisałeś kodu. Pomaga to budować relacje, a nowy zespół traktuje cię poważniej.

Gdy te bazy zostaną już omówione, nikt przy zdrowych zmysłach nie rzuci ci wyzwania. Jako przedmiot dodatkowy wykonaj mikro-testy porównawcze, które naprawdę dodadzą ci efektu.

Często sposób, w jaki to wypowiadasz, znacznie zmienia kulturę kodu. Dawaj dobry przykład. Albo jeszcze lepiej, poczekaj na kawałek kodu, który możesz napisać - refaktoryzacja i testowanie jednostki, do diabła - i usłyszysz altówkę - usłyszysz.

skipy
źródło
Nie refaktoryzuję obecnego kodu, piszę tylko nową funkcję, nie jestem pewien, czy powinienem postępować zgodnie z „konwencją” i zakodować ją w ponad 300-liniowej potworności, czy podzielić ją na logiczne części, tak jak normalnie, ale ma nie zostało to zrobione w tej części bazy kodu.
Justin
1
czy mają zasady zapewniające pisanie nowych metod w ponad 300 liniach? jeśli nie, napisałbym to we właściwy sposób. ale absolutnie zrobię wszystko, aby przetestować je, w tym gałęzie. Przeżyłem podobne doświadczenia i zazwyczaj wygrywasz je. Sztuką jest zrobienie tego z czasem i zbudowanie relacji.
skipy
3

Tego rodzaju pytanie jest w zasadzie „ proszę, przeczytajcie moich kolegów z zespołu ”. Losowi ludzie w Internecie nie mogą tego zrobić, więc wszystkie odpowiedzi, które otrzymasz, to tylko osobiste opinie na temat stylu kodowania. Konsensus jest taki, że preferowane są krótsze metody, ale wydaje się, że już tak myślisz, więc nie musisz tego powtarzać.

Tak więc obecna baza kodu wydaje się używać innego stylu kodowania niż ten, który preferujesz. Co powinieneś zrobić? Najpierw musisz dowiedzieć się:

  1. Czy jest to celowa decyzja projektowa poparta przez Twój obecny zespół?
  2. Czy chcą, żebyś postępował zgodnie z tym stylem?

Jest tylko jeden sposób, aby się przekonać. Zapytać .

Może istnieć wiele przyczyn posiadania długich funkcji. Może tak być, ponieważ zespół uważa, że ​​długie funkcje są lepsze niż wiele krótkich funkcji. Może to być również spowodowane tym, że jest to starszy kod, a zespół woli, aby nowy kod był bardziej przejrzysty. Więc albo wybór może wylądować cię w kłopoty jako deweloper, jeśli nie rozmawiać z zespołem i zrozumieć ich rozumowania.

JacquesB
źródło
1
Całkowicie się zgadzam i dodaję: „Czy możesz zostać zwolniony lub w inny sposób mieć kłopoty z powodu nieprzestrzegania tego, co zrobili inni?” Zatem odpowiedź brzmi tak! Po każdej złej rzeczy firma wymaga, abyś to zrobił i sobie z tym poradził.
Rob
1

Istnieją różne poziomy „stylu”.

Na jednym poziomie, zwykle będącym częścią konwencji kodowania, oznacza to, gdzie należy umieścić białe spacje, puste linie, nawiasy i jak nazywać rzeczy (małe litery, podkreślenia itp.).

Na innym poziomie znajduje się model programowania, czasem rzeczy takie jak unikanie statyki lub używanie interfejsów zamiast klas abstrakcyjnych, jak ujawniać zależności, a może nawet unikać niektórych ezoterycznych cech języka.

Potem są biblioteki i frameworki używane w projekcie.

Czasami będzie maksymalny limit wielkości funkcji. Ale rzadko istnieje minimalny limit! Powinniście więc dowiedzieć się, które z tych mocy należy uznać za ważne, i starać się to uszanować.

Musisz dowiedzieć się, czy zespół nie chce zrefaktoryzować istniejącego kodu, co należy zrobić niezależnie od dodania nowego kodu, jeśli to możliwe.

Jednak nawet jeśli nie chcą one refaktoryzować istniejącego kodu, możesz być w stanie wprowadzić niektóre warstwy w abstrakcjach dla nowego kodu, który dodajesz, co oznacza, że ​​z czasem możesz opracować lepszą bazę kodu i migrować stary kod jako jego utrzymanie wymaga.

Erik Eidt
źródło