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

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.

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.

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.

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.

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.

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

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.

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.

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

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.

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.