Jestem zmuszony napisać zły kod. Jak zapisać twarz? [Zamknięte]

69

Jestem tylko młodszym programistą, ale moja praca zmusza mnie do pracy z naprawdę okropnym kodem PHP (pomyśl o najgorszym kodzie PHP, który widziałeś; następnie pomyśl o kodzie dwa razy gorzej). Zwykle staram się naprawiać błędy i walczyć z bazą kodu, aby dodać nowe funkcje. Czasami nakazuje mi, aby wszystko działało jak najszybciej, co najczęściej wiąże się z brudnymi hackami.

Produkt był wcześniej open source i obawiam się, że w przyszłości może być open source. Wstydziłbym się, gdyby ktoś (szczególnie potencjalni pracodawcy) mógł znaleźć moje imię obok niektórych zestawów zmian. Co mogę zrobić, aby chronić moje dobre imię?

Nie jestem pewien, czy jest to istotne, ale dodam, że ani mój szef, ani moi koledzy nie chcą przyznać, że kod jest zły, ale nie jestem pewien, czy mogę winić ich za to - dla wielu z nich jest to ich pierwsza praca.

Zawstydzony
źródło
21
Jak zmuszony jesteś pisać zły kod? Dlaczego nie możesz wstać, przestać kłaść swoje imię na złym kodzie i wyjaśnić problem, rozwiązanie, koszt pod względem czasu, wysiłku i pieniędzy, a także korzyści wynikające z rozwiązania problemów teraz u swoich przełożonych?
Thomas Owens
17
„zachęcanie do szybkich i brudnych hacków”? Zachęcający? Co jest gorsze. Twoja duma (i znalezienie nowej pracy) lub trzymanie się tej pracy. Nie jest źle bronić tego, co słuszne. Co cię powstrzymuje Zagrożenia przemocą? Szantaż? Postępowanie karne? Poważnie. Co powstrzymuje cię przed pisaniem dobrego kodu? Proszę, bądź konkretny . I szczerze.
S.Lott,
113
Jeśli to jakaś pociecha, nawet dobry kod, który napiszesz dzisiaj, będzie źle wyglądać za pięć lat.
Kyralessa,
7
face it PHP zachęca do „szybkiego i brudnego”, nie zniechęcając go i ułatwiając fakt. Powiedziałbym, że PHP przoduje w „qucik i brudny” lepiej niż jakikolwiek inny język, z wyjątkiem Perla, gdy tylko ten moment zostanie ustalony, to jest Trudno to zatrzymać, zwłaszcza jeśli kierownictwo zachęca również do takiego zachowania. W kodzie końcowym, który wydaje się działać, niezależnie od praktyk jest bardziej wartościowy dla firmy niż żaden kod.
7
Przepraszamy, ale dobre i złe sposoby pisania kodu. Właściwy sposób wykorzystuje standardowe praktyki branżowe; zły sposób łączy ze sobą gówno i mówi, że „działa”.
Wayne Molina,

Odpowiedzi:

132

Rzym nie został zbudowany w ciągu jednego dnia, ale możesz być dobrym „harcerzem”. Za każdym razem, gdy dotkniesz kodu, zostaw go lepiej niż wcześniej. Wykorzystanie rozsądnych nazw funkcji, dobrych standardów kodowania i rzetelnych komentarzy podczas pracy nie zajmuje dużo czasu.

Myślę, że niebezpieczeństwem jest myślenie, że to wszystko albo nic. To, że nie możesz poświęcić czasu na pisanie eleganckiego kodu, nie oznacza, że ​​musisz całkowicie się poddać i pisać śmieci.

Amy Anuszewski
źródło
2
+1. Nie musisz poświęcać wszystkiego, w co wierzysz, aby szybko to naprawić.
tdammers
4
+1: za wszystko albo za nic - bardzo prawda.
Umber Ferrule,
3
Zasada Boy Scout w niewłaściwych rękach może być dokładnie tym, co powoduje problem, ponieważ definicją „rozsądnej nazwy funkcji” jego przełożonego może być „bolChkLst” (węgierski zapis, aby spotkać się z poradnikiem stylu, ChkLst zamiast listy kontrolnej, ponieważ „krótszy jest lepszy ”). Oto niektóre implementacje reguły skautów, które napotkałem w różnych zadaniach, których starałem się nie stosować: „Połącz funkcje, aby mieć jak najmniej”, „nie noś argumentów za pomocą 3 wywołań, zamiast tego użyj globałów”, „użyj wbudowanego SQL w widokach, aby zrób to szybciej ”
keppla,
40
+1 zaEvery time you touch the code, leave it better than it was before.
Qwerky,
3
+1. Jeśli popełnisz wiele wyraźnych ulepszeń, każdy, kto faktycznie spojrzy na twój wkład, nie będzie myślał, że jesteś gównianym programistą. Potencjalni pracodawcy, którzy uważają, że jesteś gówniany, ponieważ projekt jest gówniany, nie są ludźmi, dla których chcesz pracować.
Mateusz
59

Zgadzam się z S.Lott z komentarzy * (choć raz :) Nikt nie zmusza cię do napisania złego kodu. Chodzi o to, Junior Dev. często (ta strona też jest za to winna) zagubić się w najlepszych praktykach, „pięknym kodzie”,… jakkolwiek chcesz to nazwać… i nie robią wiele; albo zrobią to, ale zmarnują dużo czasu. Mówiąc im, aby napisali zły kod (który jest także kodem, który również działa), dostaje to niż „przez to”, po prostu sprawia, że ​​coś dostarczają. Z biegiem czasu to powoduje, że (już nie :) junior dev bardzo szybko wymyśla szybkie i brudne rozwiązanie, ale spędza resztę czasu na jego ulepszaniu. Z biegiem czasu uczysz się więcej, a w pewnym momencie zaczynasz dostarczać szybkie i brudne rozwiązania, które w rzeczywistości są dobrym kodem.

Ale gdybyś poszedł swoją drogą i próbował od razu napisać idealny kod, najprawdopodobniej spędziłbyś dużo czasu i prawie nic nie zrobiłeś.

Więc ... napisz zły kod, ... dużo tego ... kod, który ledwo działa, a następnie POTWIERDŹ. Każda iteracja jest trochę lepsza!

Za pierwszym razem nikt nie napisał idealnego rozwiązania.

* to, gdyby był krótszy, byłby komentarz.

Wieża
źródło
1
+1 Zdecydowanie zgadzam się z tą odpowiedzią. Głosowałbym za tobą dwa razy.
Vitor Py
3
Zgadzam się. Jest to świetny sposób na przebicie się przez „paraliż analizy”, który może się przydać, gdy próbujesz znaleźć „idealne” rozwiązanie problemu. Napisałem coś podobnego na StackOverflow .
Kyralessa
4
+1. Przeczytałem to już o programistach (ale nie znam źródła): dwie grupy otrzymały zadanie stworzenia ceramiki w określonym czasie. Jeden, aby stworzyć produkt najlepszej możliwej jakości, a drugi, aby stworzyć jak najwięcej przedmiotów. Ostatecznie ta ostatnia grupa dostarczyła przedmioty lepszej jakości, ponieważ powtarzanie jest drogą do mistrzostwa. Sama kontemplacja nigdzie cię nie zaprowadzi. W końcu wszyscy uczymy się przez działanie, a strach przed zrobieniem czegoś złego powstrzymuje nas od prób, być może porażek, ale zdecydowanie uczenia się na własnych błędach.
back2dos,
1
Jako następstwo skorzystaj z repozytorium! Nawet jeśli jest to tylko osobisty skonfigurowany na własnym komputerze. Po rozpoczęciu korzystania z nich zdajesz sobie sprawę, jak wyzwalające jest wprowadzanie wielu zmian, przekonanie się, że to nie zadziałało, i wycofanie zmian. Moją osobistą ulubioną jest skamielina
Spencer Rathbun,
„Więc… napisz zły kod,… dużo tego… kod, który ledwo działa, a następnie POTRZEBUJ. Każda iteracja jest trochę lepsza!” Co jeśli nigdy nie będziesz w stanie iterować, ponieważ wciąż pojawiają się nowe projekty ... i zaczniesz zdawać sobie sprawę, że to, co wypychasz jako alfa, ma tendencję do pozostawania, aż do śmierci projektu. Co oczywiście jest przyspieszane w wyniku początkowo gównianego kodu i braku aktualizacji. Myślę, że właśnie w takich sytuacjach wielu młodych deweloperów uświadamia sobie, że od samego początku muszą pisać „piękny kod” ...
Serhiy
40

Komentarze do kodu są tutaj Twoimi przyjaciółmi.

Ilekroć czujesz, że musisz napisać jakiś tani hack z powodu presji, po prostu powiedz coś w stylu: „Ten kod robi X z powodu ograniczeń czasowych. Idealnie zrobiłbym Y zamiast tego - Ashamed One, 5 lipca 2011 r.”

Jeśli potencjalni pracodawcy to zobaczą, zdadzą sobie sprawę, że wolisz pisać dobry kod, ale możesz też dostosować swój styl kodowania do potrzeb biznesowych. Większość pracodawców będzie uważać obie te rzeczy za dobre.

Bob Murphy
źródło
4
Dokładnie. Komentarze i wiadomości zatwierdzające. Nigdy tego nie robiłem, ale byłoby interesujące ocenić programistę na podstawie niczego innego niż przypisane im zestawy zmian z przypisami w niektórych vcs.
timdev
cóż, możesz powiedzieć coś o kimś, kogo komentarze są „naprawione”, „zrobione”, „blahblahblah” :)
gbjbaanb
+1 Zrobiłem to kilka razy, aw przypadku deweloperów równorzędnych to po prostu działa.
Jacek Prucia
7
Zazwyczaj usuwam takie komentarze za każdym razem, gdy je spotykam. Komentarz oznaczony jako TODO lub PRZYSZŁOŚĆ-ULEPSZENIE może zasługiwać na pozostanie, ale przeprosiny są po prostu śmieciami.
Kristopher Johnson
1
Zgadzam się z wyjaśnieniem, dlaczego zaimplementowano mniej niż optymalne rozwiązanie (i jakie to może być rozwiązanie), robię to od czasu do czasu. Jednak nie sądzę, żeby było się czego wstydzić lub przeprosić. Oznacza to po prostu, że w czasie pracy nad tym fragmentem kodu były ważniejsze rzeczy do zrobienia i że dana implementacja była wystarczająca.
Justin Ohms,
10

To zależy od tego, jak cię zmuszają.

Z mojego doświadczenia wynikają dwie możliwości:

Czujesz się zmuszony przez napięty harmonogram, starszy kod itp.

W tym przypadku, jak już większość innych odpowiedzi już mówi, od Ciebie zależy „optymalizacja pod kątem chłodu”. Być może nie masz czasu na przepisanie bazy kodu do MVC, ale na przykład możesz na przykład przestać ręcznie kleić SQL i zamiast tego napisać fajny execute_sql($query, $params), który stanowi podstawę dla takich abstrakcji fetch_customer($filter_params)itp. Pamiętaj, wszystkiego najlepszego ostatecznie istnieją praktyki, że twój szef dostaje produkt wcześniej, więc istnieje tylko konflikt, ile czasu zainwestować w przyszłość w porównaniu z teraźniejszością.

Kiedy ustawisz właściwy kontekst („w ciągu 6 miesięcy, bez dodatkowego czasu, zmieniłem kod monolityczny na MVC”), powinieneś zostawić swoje nazwisko w kodzie i starać się być dumnym jak terapeuta, który uczy ofiarę udaru mózgu powtórz pojedyncze słowa.

Użytkownik jest wyraźnie zobowiązany do wprowadzenia go w sposób, który uznamy za nieodpowiedni

Próba oddzielenia widoku od modelu nie przetrwała przeglądu, ponieważ „jest zbyt skomplikowane, dlaczego nie robisz zwykłych zapytań SQL?”. Twoja execute_sqldostaje w puszkach, ponieważ „koder z dyscypliną nie potrzebuje, że”.

Ta skrzynka jest do bani. Z mojego doświadczenia wynika, że ​​zwykle dotyczy to mikrozarządzania i kierowników zespołów, którzy awansowali tam z powodów politycznych, a nie ze względu na swoje sukcesy. Prawdziwy problem polega na tym, że kierujesz czymś (kodem), nad którym nie możesz kontrolować (musisz to zrobić po swojemu). Najlepszym rozwiązaniem byłoby rozwiązanie pierwotnej przyczyny (tzn. Że jesteś traktowany jak chrząknięcie). Drugim najlepszym (i z mojego doświadczenia, zwykłym) rozwiązaniem jest wyjście.

Plusem jest to, że w tym scenariuszu twoje nazwisko i tak prawdopodobnie nie zostanie opublikowane, ponieważ lider zespołu przypisuje sobie sukces.

keppla
źródło
8

Jestem całkiem pewien, że twój szef wymaga, abyś dostarczył coś szybko, ale nie dlatego, że dokładasz wszelkich starań, aby celowo było to złe. Co oznacza, że ​​ilekroć masz wybór między naprawdę złym kodem a nieco mniejszym kodem, a obie opcje zajęłyby tyle samo czasu na wdrożenie, wybierasz nieco mniej złą opcję. To rozwiązanie krótkoterminowe i nie wymaga żadnego wysiłku.

Na dłuższą metę porozmawiaj z szefem. Wyjaśnij, jak zainwestowanie 15 minut tutaj może zaoszczędzić tam godziny. Upewnij się, że masz przekonywujące przykłady - nie typ „gdybym to zrobił i to tutaj, mam nadzieję, że będę mógł zrobić to samo w przyszłym roku”, ale raczej: „spójrz, tutaj to zrobiłem, i ponieważ tego problemu zajęło mi trzy godziny, aby znaleźć problem; gdybym to zrobił w ten i tamten sposób, błąd byłby widoczny od razu ”. Ostrzeżenie tutaj: chociaż elegancki i łatwy w utrzymaniu kod wydaje się znacznie lepszy i wydajniejszy, czasem tak nie jest. Zdarzają się sytuacje, w których niechlujna szybka poprawka jest całkowicie uzasadniona: czasami piszesz kod jednorazowy, czasem utrzymujesz przy życiu przestarzałe śmieci, czekając na prawdziwe; czasami korzyść z właściwego rozwiązania nie „

Jeśli wszystko inne zawiedzie, znajdź inną pracę.

tdammers
źródło
3

Nikt nie zmusza cię do pisania złego kodu. Możesz odwrócić tę sytuację i uczynić ją pozytywną. Pionierska zmiana zasad i procedur. I nie zawsze możesz być „tak” mężczyzną / kobietą. Jeśli powiedzą, że potrzebują funkcjonalności x przed końcem dnia, powiedz im, że jest to niewykonalne, ale uzasadnij, dlaczego tak naprawdę nie jest. W razie problemu zaoferuj rozwiązania. Nie tylko ślepe oko, albo co gorsza ... powiększające.

Twój sklep deweloperów nie jest pierwszym, który ma ściśle określone terminy, a jednocześnie pragnie utrzymać dobrze zaprojektowany kod.


źródło
4
-1: W USA, jeśli twój szef powie „Napisz szybki, gówniany kod”, a ty nie zrobisz tego, może cię zwolnić. Nieprzestrzeganie bezpośredniego polecenia zrobienia czegoś, co jest legalne, jest podstawą do mimowolnego wypowiedzenia. Więc chociaż może to nie „zmuszać” ciebie, alternatywy do robienia tego, co mówi twój szef, mogą być znacznie gorsze.
Bob Murphy,
Wszystko zależy od twojego podejścia. Idealnie byłoby, gdybyś miał lepszą postać, która ceniłaby twoją wiedzę fachową, a twój osąd powinien być wysoko oceniany. Często ludzie dyktujący harmonogramy nie są programistami i powinni wziąć pod uwagę, co jest możliwe, a co nie. Oczywiście możesz napisać „kiepski” kod pod okładkami, ale wypychanie może być wystarczające, aby wszyscy byli zadowoleni: dobre wyniki z dobrego kodu.
1
Idealne lepsze liczby, dla których tak naprawdę nie pracujesz, są świetne, ale osoba, która podpisuje Twoją wypłatę, jest tą, którą musisz zadowolić. Posiadanie kolekcjonerów rachunków dzwoni o każdej godzinie, kiedy jesteś naprawdę bez pracy, naprawdę do bani.
Bob Murphy,
1
Jest w tym coś więcej niż surowy interes własny. Jestem menedżerem i przedsiębiorcą i zapewniam cię, że jeśli cały klient płaci za to szybko i brudnie, wykonanie dobrej pracy, która straci pieniądze, doprowadzi do zwolnienia ludzi. Musiałem raz zwolnić całą firmę i nigdy więcej nie chcę tego robić. Tak więc, chociaż zdecydowanie opowiadam się za przyjęciem postawy moralnej ... pisanie gównianego kodu zwykle nie jest kwestią moralną, a w pewnym momencie należy wybrać między osobistymi preferencjami a praktycznymi kwestiami ludzi mających lub nie mających pracy.
Bob Murphy,
1
Prawie nigdy nie zalecałbym przepisywania na dużą skalę dużego systemu, ale to nie znaczy, że kod, który napiszesz w przyszłości, musi być okropny.
PeterAllenWebb
3

Każda firma musi znaleźć równowagę między pisaniem doskonałego kodu, obszerną dokumentacją i testami jednostkowymi, a wprowadzaniem produktów na rynek w rozsądnym budżecie i czasie.

Najlepszy kod na świecie nie ma znaczenia, jeśli jest przestarzały przed wydaniem.

Pragnienie polega na próbie znalezienia równowagi. Szybkie naprawianie funkcji może być w tej chwili niezbędne z handlowego punktu widzenia, nie oznacza to jednak, że zawsze będzie.

Potrzeba dużo doświadczenia (więcej niż większość programistów kiedykolwiek ma), aby uzyskać równowagę. Bardzo łatwo jest przejść na skrajność. Znalezienie środkowej drogi jest trudniejsze.

Nie twierdzę, że twój szef ma rację. Jako programista istnieje pokusa, aby stale tworzyć piękny kod, który nie jest opłacalny z handlowego punktu widzenia. Świadomość pokusy może pomóc ci zrozumieć, że niektóre z tych hacków nie są takie złe.

Większość kodu po wystarczającym czasie będzie zawierała hacki dla określonych sytuacji, które były zbyt kosztowne, aby zmienić je w ogólne ramy.

Jeremy French
źródło
2

Chciałbym dodać, że nie powinieneś tak po prostu kontynuować, tak jak robisz to teraz, nic nie mówiąc, tylko hakując i hakując.

Musisz wstać i wskazać konkretny kod i powiedzieć im, co jest do bani. Bądź konkretny i używaj wskaźników kodu, aby utworzyć kopię zapasową swoich roszczeń. Nie ma nic bardziej zawstydzającego niż twierdzenie, że kod jest zły, podczas gdy w rzeczywistości tak nie jest, po prostu nie rozumiesz, co zostało zrobione.

Jestem pewien, że istnieje wiele bezpłatnych narzędzi do analizy kodu php http://en.wikipedia.org/wiki/Code_analysis

Oczywiście, to http://en.wikipedia.org/wiki/Code_smell

Przeczytaj to, podsumuj, co możesz znaleźć w swojej aplikacji, i oczywiście wymień alternatywy . Złą praktyką jest po prostu wstawanie i krzyczenie „Nie podoba mi się, jak to się robi” bez przedstawiania alternatywnego (najlepiej) lepszego sposobu na zrobienie tego.

Szybkie włamania kosztują pieniądze. I nie postrzegaj tego jako całkowicie negatywnego - możesz teraz wiele nauczyć się z tej pracy i czerpać korzyści z doświadczeń, które teraz zdobędziesz podczas następnej.

hth

UrbanEsc
źródło
0

Przede wszystkim korzystasz z kontroli źródła, prawda? Jeśli nie, zacznij od tego. Pomoże ci to najpierw i zostanie szybko adoptowany przez resztę zespołu.

Jeśli masz kontrolę źródła, nie powinieneś wpisywać swojego nazwiska w kodzie, wystarczy podać nazwę swojej firmy. W złym kodzie często umieszcza się historię zmian w komentarzach u góry plików, lepiej przekazać to kontroli źródła.

Teraz, jeśli chodzi o jakość kodu, nie będzie można go zmienić jako podejście wielkiego wybuchu. Powoli, jeden po drugim, dodawaj nowe podejścia do różnych problemów. Jeśli zrobisz to dobrze, OSZCZĘDZA to trochę czasu i wykorzystasz go, aby poprawić ogólną jakość.

Aby dać wam przykład, pewnego razu znalazłem się w środku projektu z aplikacją Perl / CGI, w której cały kod HTML był w kodzie. Cała aplikacja była w jednym pliku bez wyraźnej struktury. Nic nie było wersjonowane. Zacząłem od skonfigurowania repozytorium CVS (w tej chwili brak SVN), umieściłem na nim interfejs WWW dla klienta. Na początku sam zajmowałem się zobowiązaniami od moich kolegów. Następnie podzieliłem wszystkie metody na różne moduły (pliki). W tym momencie koledzy zaczęli stosować CVS. Następnie usunąłem HTML z kodu. Następnie za każdym razem, gdy musiałem dokonać zmiany w jakiejś części kodu, poświęciłem trochę czasu na przeredagowanie części. Ostatecznie prędkość rozwoju wzrosła tak bardzo, że klient był bardzo szczęśliwy. Poprosiliby o kosmetyczną zmianę i zamiast nas mówić im „zajmie to 2 dni”,

Takie podejście będzie jednak działać tylko wtedy, gdy opanujesz wystarczająco dobrze cały kod. Jeśli nie rozumiesz dużego obrazu, jeśli niektóre części wniosku pozostaną niezrozumiałe, to naprawdę utrudni ci pracę.

I ostatnia rzecz, całkowite przepisanie jest czasem jedynym rozwiązaniem, ale zazwyczaj bardzo trudno jest uzasadnić koszty zarządzania.

Eric Darchis
źródło
0

Ponieważ jesteś młodszym programistą, to naprawdę dobra rzecz. Wrzucenie w sam środek wielkiego bałaganu kodu nauczy Cię znacznie więcej o tym, czego nie robić, niż tylko praca nad idealnie „czystym” kodem. Skorzystaj z sytuacji i naucz się, jak refaktoryzować zły kod i powoli przekształcić go w coś łatwiejszego do zarządzania. I nie narzekaj, że musi to być JAK NAJSZYBCIEJ. O to chodzi - naucz się refaktoryzować i wyczyścić kod, robiąc rzeczy w napiętym terminie. W końcu każdy może napisać idealny kod, jeśli ma nieograniczony czas.

Grandmaster B.
źródło