Projekt jest prawie gotowy, ale proceduralny kod spaghetti. Czy przepisuję, czy po prostu próbuję go wysłać? [Zamknięte]

Jestem początkującym programistą internetowym (rok doświadczenia).

Kilka tygodni po ukończeniu studiów zaproponowano mi pracę nad aplikacją internetową dla firmy, której właściciel nie jest specjalistą od technologii. Zrekrutował mnie, aby uniknąć kradzieży jego pomysłu, wysokich kosztów rozwoju naliczanych przez firmę usługową i mieć kogoś młodego, któremu mógłby zaufać na pokładzie, aby utrzymać projekt na dłuższą metę (do tych wniosków doszedłem długo po tym, jak zostałem zatrudniony) ).

Zarozumiały jak wtedy, z dyplomem informatyki, przyjąłem ofertę myśląc, że mogę zbudować wszystko.

Wołałam strzały. Po kilku badaniach zdecydowałem się na PHP i zacząłem od zwykłego PHP, bez obiektów, po prostu brzydki kod proceduralny. Dwa miesiące później wszystko się popsuło i ciężko było poczynić postępy. Aplikacja internetowa jest ogromna. Postanowiłem więc sprawdzić środowisko MVC, które ułatwiłoby mi życie. Właśnie tam natknąłem się na fajnego dzieciaka ze społeczności PHP: Laravela. Uwielbiałem to, łatwo było się uczyć i od razu zacząłem kodować. Mój kod wyglądał na bardziej przejrzysty, lepiej zorganizowany. Wyglądało bardzo dobrze.

Ale znowu aplikacja internetowa była ogromna. Firma wywierała na mnie presję, aby dostarczyła pierwszą wersję, którą oczywiście chciała wdrożyć i zacząć szukać klientów.

Ponieważ praca z Laravelem była przyjemnością, przypomniało mi się, dlaczego wybrałem właśnie tę branżę - coś, o czym zapomniałem, tkwiąc w gównianym systemie edukacji.

Zacząłem więc pracować nocą nad małymi projektami, czytając o metodologii i najlepszych praktykach. Powróciłem do OOP, przeszedłem do projektowania i analizy obiektowej i przeczytałem książkę wuja Boba Clean Code .

To pomogło mi zrozumieć, że tak naprawdę nic nie wiedziałem. Nie wiedziałem, jak zbudować oprogramowanie PRAWIDŁOWY SPOSÓB. Ale w tym momencie było już za późno, a teraz już prawie skończyłem. Mój kod nie jest wcale czysty, po prostu kod spaghetti, prawdziwy ból, aby naprawić błąd, cała logika jest w kontrolerach, a projekt obiektowy jest niewielki.

Mam tę upartą myśl, że muszę przepisać cały projekt. Jednak nie mogę tego zrobić ... Ciągle pytają, kiedy to się skończy.

Nie mogę sobie wyobrazić tego kodu wdrożonego na serwerze. Ponadto nadal nie wiem nic na temat wydajności kodu i wydajności aplikacji internetowej.

Z jednej strony firma czeka na produkt i nie może już dłużej czekać. Z drugiej strony nie widzę, żebym szedł dalej z faktycznym kodem. Mógłbym skończyć, zawinąć i wdrożyć, ale Bóg wie tylko, co może się stać, gdy ludzie zaczną go używać.

Czy przepisuję, czy po prostu próbuję wysyłać, czy jest jeszcze jedna opcja, której mi brakowało?

Natknąłeś się na piętę achillesową większości edukacji CS: uczą cię narzędzi i technik, ale nie handlu. Tworzenie oprogramowania to rzemiosło, które nabywa się dopiero przez lata praktyki i doświadczenie w korzystaniu z oprogramowania (użytkownicy są znacznie ostrzejszymi krytykami niż nauczyciele). Oprogramowanie do budowania jest również często biznesem, w którym cele biznesowe mogą przeważyć ambicje techniczne.

Przede wszystkim statek. Jeśli pokażesz właścicielowi firmy oprogramowanie, a oni uważają, że jest gotowy do wysyłki, to wyślij. Jeśli to nie do tego momentu, ale blisko, dokończ. Jedyne oprogramowanie, które się liczy, to oprogramowanie, które jest faktycznie używane. Jedyny biznes zarabiający na oprogramowaniu to taki, który ma produkt.

Po drugie, nauczyłeś się wielu cennych rzeczy, więc powinieneś docenić doświadczenie za to, czego cię nauczyło :

1. Kod procy bez planu lub architektury to przepis na katastrofę
2. Programowanie to coś więcej niż pisanie kodu
3. Nietechniczni właściciele firm często nie rozumieją wpływu decyzji technicznych (np. Tego, kogo zatrudnić), a deweloperzy muszą wyjaśnić im różne rzeczy.
4. Większość problemów jest już rozwiązana znacznie lepiej niż można by je rozwiązać w istniejących ramach. Warto znać istniejące ramy i kiedy z nich korzystać.
5. Ludzie świeżo po szkole, przydzieleni do dużego projektu z niewielką pomocą, zwykle produkują miskę kodu spaghetti. To normalne.

Oto kilka porad, jak postępować:

1. Komunikuj się, komunikuj się, komunikuj się. Musisz być bardzo otwarty i szczery na temat stanu projektu i swoich pomysłów na kontynuację, nawet jeśli nie masz pewności i widzisz wiele ścieżek. To pozostawia właścicielowi firmy wybór, co należy zrobić. Jeśli zachowujesz wiedzę dla siebie, pozbawiasz ich możliwości wyboru.
2. Oprzyj się pokusie pełnego przepisania. Podczas przepisywania firma nie ma produktu. Ponadto przepisywanie rzadko okazuje się tak dobre, jak sobie wyobrażałeś. Zamiast tego wybierz architekturę i migruj do niej bazę kodów. W ten sposób można nawet uratować okropną bazę kodów. Przeczytaj książki o refaktoryzacji, aby Ci pomóc.
3. Dowiedz się o automatycznych testach / testach jednostkowych . Musisz zbudować zaufanie do kodu, a sposobem na to jest objęcie go automatycznymi testami. To idzie w parze z refaktoryzacją. Dopóki nie masz testów, testuj ręcznie i kompleksowo (spróbuj złamać kod, bo zrobią to użytkownicy). Zaloguj wszystkie znalezione błędy, aby móc ustalić ich priorytety i je naprawić (nie będziesz mieć czasu na naprawienie wszystkich błędów, żadne oprogramowanie nie jest wolne od błędów w prawdziwym świecie).
4. Dowiedz się, jak wdrożyć aplikację internetową i zapewnić jej działanie. Książka Operacje sieciowe: Utrzymywanie danych na czas to dobry początek.

Brzmi jak każdy inny system, który został mi rzucony w celu naprawy.

Spokojnie, zdarza się to wielu ludziom. Młodzież wrzucona na głęboki koniec bez doświadczenia, która nie ma pomocy, wsparcia i wskazówek nie jest przepisem na sukces. Zatrudnianie i oczekiwanie, że młodszy programista zbuduje od podstaw zupełnie nowy system, który działa dobrze, działa dobrze i jest łatwy w utrzymaniu, nie jest w ogóle realistyczny. Do diabła, masz szczęście, jeśli wszystko to dzieje się ze starszym programistą.

Moim zdaniem musisz być czysty. To nie będzie zabawne. Powiedz im, że dałeś z siebie wszystko, to działa (głównie), ale martwisz się, że może nie działać dobrze i że będzie dużo błędów ( zawsze są błędy). Musi zostać sprawdzony przez starszego programistę, który powinien być w stanie dość szybko naprawić wszelkie rażące problemy z wydajnością / bezpieczeństwem. Lub mogą go wdrożyć i trzymać kciuki. Albo pójdzie dobrze, albo pójdzie w górę z dymem. Może uda ci się rozwiązać problemy, gdy się pojawią. Jeśli masz dużą bazę użytkowników, może nie.

Lub możesz zrobić to, co większość ludzi robi w tej sytuacji: weź pieniądze, zniknij i pozwól im to rozwiązać. Od ciebie zależy, czy wybierzesz etyczny wybór.

Edytuj (ponieważ to pytanie ma dużo głosów, równie dobrze mogę dodać więcej treści)

Radość bycia programistą polega na tym, że ludzie nietechniczni (prawdopodobnie twój manager, a na pewno cała reszta biznesu) nie mają pojęcia, co robisz. To jest dobre i złe. Część zła polega na tym, że musisz stale wyjaśniać, jak działają projekty rozwoju oprogramowania. Planowanie, wymagania, recenzje kodu, testowanie, wdrażanie i usuwanie błędów. Jest to zadanie wyjaśnić znaczenie badań, a także poświęcić czas na test. Musisz tu stanąć na swoim miejscu. Ludzie nie zrozumieją znaczenia ( „nie możemy po prostu zacząć z niego korzystać?”), ale kiedy zaczną testować (nie w środowisku na żywo!), szybko zrozumieją korzyści. Jednym z powodów, dla których cię zatrudnili, jest to, że nie wiedzą nic o tworzeniu oprogramowania, więc to od Ciebie zależy ich edukowanie. Musisz tutaj podkreślić znaczenie testowania i naprawiania błędów - pamiętaj, że nie są programistami, nie znają różnicy między dzieleniem przez zero a zepsutym znacznikiem HTML.

Często wiele problemów, które się pojawiają, nie są błędami. Będą to problemy z użytecznością, pominięte wymagania, wymagania, które się zmieniły, oczekiwania użytkowników (dlaczego nie mogę tego użyć na telefonie komórkowym?), A następnie rzeczywiste rzeczywiste błędy. Musisz je rozwiązać, zanim zaczniesz działać - często wiele błędów można obejść lub naprawić kilka dni później. Jeśli ludzie oczekują idealnego systemu, będą cierpieć z powodu dużego bólu. Jeśli spodziewają się błędów, Twoje życie będzie znacznie łatwiejsze w ciągu najbliższych kilku tygodni.

Aha, nie myl testowania użytkownika z testowaniem jednostkowym ani testowaniem systemu.

• Testowanie jednostkowe - czy moja funkcja kodu zwraca prawidłową wartość
• Testowanie systemu - czy generuje błąd po kliknięciu X
• Testy akceptacji użytkownika (UAT) - czy program spełnia wymagania? Czy robi to, o co cię prosili? Czy da się to uruchomić?

Jeśli nie spisałeś wymagań, o które cię prosili, UAT będzie o wiele, wiele trudniejszy. Tu upadło wiele osób. Zapisanie na papierze tego, co chcieli, będzie znacznie łatwiejsze. Oni powiedzą „Dlaczego nie robi X?” i możesz powiedzieć „Powiedziałeś mi, żebym to zrobił Y”. Jeśli program jest nieprawidłowy, napraw go. Jeśli wymagania są nieprawidłowe, napraw dokument, poproś o dodatkowy dzień lub dwa (nie, nalegaj na to), wprowadź zmiany, zaktualizuj dokumentację i ponownie przetestuj.

Po przejściu tego procesu kilka razy możesz zacząć szukać Agile… ale to inny świat :)

Testy TL; DR są dobre

Za każdym razem, gdy zaczynasz od zera, prawie na pewno popełnisz tyle samo błędów lub więcej z powodu Second System Syndromme . Twoje nowe błędy będą inne, ale ilość czasu potrzebnego na debugowanie będzie podobna, a więc rozpaczą, że to nie jest dobre dopasowanie. Opóźni to także wdrożenie do produkcji lub wdrożenie nowych funkcji, jeśli pierwsza wersja zostanie wdrożona, co będzie poważnym problemem dla firmy. Joel Spolsky nazywa to „jednym najgorszym błędem strategicznym”, który może popełnić każda firma lub programista.

Zalecanym podejściem jest zamiast tego czyszczenie początkowego bałaganu krok po kroku podczas konserwacji. I nawet nie próbuj go refaktoryzować tylko ze względu na to. Poza tym menedżerowie zwykle postrzegają to jako stratę pieniędzy (którą często jest) i niesie ze sobą niepotrzebne ryzyko wprowadzania nowych błędów. Po boleśnie debugowaniu kodu może nie być ładny, ale zadziała. Niech tak będzie, dopóki nie będzie trzeba go dotykać z innych powodów (może to być poprawka błędu, nowa funkcja lub tylko zmiana wymagana przez marketing). Następnie wyczyść części, które są najtrudniejsze w regulacji. Jest to często nazywane regułą skautową .

I w tym momencie nie musisz kłócić się z menedżerem. Wystarczy uwzględnić minimalne pożądane refaktoryzowanie w oszacowaniu dla żądania. Dowiesz się z doświadczenia, kiedy możesz sobie pozwolić na odrobinę zysków, ponieważ firma naprawdę jest w naprawie, a kiedy nie chcesz stwarzać problemów w przyszłości i po prostu nie dopuszczasz żadnej możliwości szybkiego zhakowania.

Na koniec jeszcze jedna zalecana lektura: Wielka Kula Błota .

Zapominam, gdzie go najpierw przeczytałem, ale chciałem tylko nieco mocniej powtórzyć to, co powiedzieli inni ludzie:

Wysyłka jest funkcją.

Nie ma nic gorszego niż ten jeden facet, który „ porządkuje ” istniejący (być może zhackowany, brzydki, brudny) kod, który działa doskonale , wprowadza nowe błędy itp. W prawdziwym świecie ważne jest wykonywanie pracy. Zrobiłeś to. Statek. Nie zgub się w przeprojektowaniu projektu, który działa idealnie, nawet jeśli jest brzydki pod maską. Kiedy to naprawisz, zrób to stopniowo i zrób sobie dobry zestaw testów, aby mieć jak najmniej regresji.

Każdy projekt sprawia, że ​​jesteś mądrzejszy niż byłeś wcześniej. Po każdym projekcie zdobędziesz więcej doświadczenia, które byłoby bardzo przydatne, gdybyś miał je od samego początku. Wiem, że trudno nie wrócić do wszystkiego i zastosować tego, czego się nauczyłeś. Ale pamiętaj:

Idealny jest wrogiem dobra.

Dla klienta zawsze lepiej jest mieć dobre oprogramowanie niż doskonałe oprogramowanie, które nigdy nie zostanie wydane.

To był twój pierwszy projekt. W przyszłości będzie o wiele więcej projektów, w których możesz zastosować wszystko, czego nauczyłeś się od samego początku.

Przeczytałem [...] czysty kod wuja Boba.

Mam tę upartą myśl, że muszę przepisać cały projekt.

Ta książka ma dział o nazwie, bardzo odpowiednio, „Grand Redesign in the Sky”.

Nie próbuj przepisywać wszystkiego, ponieważ w mało prawdopodobnym przypadku, gdy masz czas, aby to zrobić, i tak napotkasz te same problemy. Po zakończeniu przeprojektowania nauczysz się nowych rzeczy i zdasz sobie sprawę, że pierwsze części są bardzo nieprofesjonalne, więc będziesz chciał je ponownie napisać.

Przeprojektowanie i przepisywanie są dobre, ale tylko wtedy, gdy są wykonywane stopniowo w działającym systemie. Jak zauważył inny użytkownik, postępuj zgodnie z regułą skautową, stopniowo zmieniając kod podczas pracy.

Robisz dobrze.

Mówisz, że twój kod działa i jest prawie gotowy do wysyłki, prawda? Widzisz, że Twój kod może zostać znacznie ulepszony. Dobry.

Twój dylemat bardzo przypomina mi moje pierwsze doświadczenie z freelancingiem (zatrudnienie podczas drugiego roku studiów w uni, aby stworzyć wielojęzyczny system POS). Przeszedłem niekończące się pytania, ponieważ nigdy nie byłem zadowolony z kodu, chciałem skalowalności, chciałem wynaleźć lepsze koła ... Ale opóźniłem projekt (o około 12 miesięcy) i ... co? Po wdrożeniu rzecz nadal wymaga wiele prób, testów, łatania itp ...

Czy masz doświadczenie w pracy z profesjonalnymi bazami kodów? Wiele baz kodu jest pełna dziwacznych, trudnych do utrzymania kodów. Alternatywą dla odkrywania złożoności oprogramowania poprzez próbę samodzielnego zbudowania dużego programu byłoby utrzymanie / rozszerzenie równie niechlujnego kodu napisanego przez innych ludzi.

Jedyne przypadki, w których widziałem, że kompletne przepisywanie przyniosło wiele dobrego, to to, że zespół jednocześnie przyjął nowy łańcuch narzędzi / framework.

Jeśli podstawowa logika (to, co robi program, a nie to, jak jest on ułożony jako funkcje, klasy itd.) Jest solidna, zadziała równie dobrze, więc myślenie, że to kod spaghetti, nie znaczy, że to nie powinien być wdrażany.

Musisz pozwolić klientowi mieć coś, z czego może skorzystać. Następnie, gdy proszą cię o ulepszenie / dodanie funkcjonalności, decydujesz, czy konieczny jest refaktoryzator, i możesz poinformować swojego klienta, że ​​„potrzebne są pewne prace techniczne w celu zintegrowania wspomnianej nowej funkcji”. Zrozumieją, że będzie to kosztowało ich więcej pieniędzy i będą musieli czekać dłużej. I zrozumieją (lub możesz to wyciągnąć).

Lepszym czasem na przepisanie wszystkiego byłby inny klient, który poprosiłby cię o stworzenie czegoś podobnego.

Krótko mówiąc, chyba że udowodnisz, że cała rzecz wybuchnie wszystkim w twarz, jeśli zostanie wdrożona, opóźnienie wdrożenia byłoby nieprofesjonalne i nie przyniosłoby korzyści ani Tobie, ani Twojemu klientowi. Naucz się robić małe refaktory podczas naprawy błędów lub dodawania nowych funkcji, które będą dla ciebie cennym doświadczeniem.

Większość tego, co powiedziałbym w odpowiedzi na twoje pytanie, zostało powiedziane przez innych. Przeczytaj „Rzeczy, których nigdy nie powinieneś robić, część I” Joela Spolsky'ego (wraz z innymi jego postami na temat „astronautów architektury”). Pamiętajcie, że „ideał jest wrogiem dobra”. Naucz się refaktoryzować stopniowo. Wysyłka jest ważna itp.

Chciałbym dodać, że masz za zadanie coś, co zostało uznane za wykonalne przez jednego świeżego absolwenta pracującego z małym budżetem / przedziałem czasowym dla początkujących. Nie powinieneś potrzebować niczego bardziej zaawansowanego niż dobre, ustrukturyzowane, proceduralne programowanie. (I, FYI, „programowanie proceduralne” nie jest złym słowem. W większości przypadków jest to konieczność na pewnym poziomie i jest w pełni odpowiednie dla wielu całych projektów.)

Tylko upewnij się, że rzeczywiście zrobić strukturyzowanego programowanie proceduralne. Powtarzanie w kodzie niekoniecznie oznacza, że ​​potrzebujesz wielkich, polimorficznych struktur. Może to być po prostu znak, że musisz pobrać powtarzający się kod i umieścić go w podprogramie. „Kontrola spaghetti” może być po prostu okazją do pozbycia się globalnego.

Jeśli istnieją aspekty projektu, które zgodnie z prawem wymagają polimorfizmu, dziedziczenia implementacji itp., Sugerowałbym, że być może nie doceniono wielkości projektu.

Jeśli naprawdę interesuje Cię dylemat, powinieneś również przeczytać „Lean Startup”. Wiele porad, które tu otrzymujesz, będzie bardziej rezonować z tobą, jeśli przeczytasz tę książkę. Zasadniczo szybkość spalania zasobów jest twoim największym wrogiem i nic nie jest bardziej wartościowe dla ciebie i twojej organizacji niż opinie użytkowników końcowych / klientów. Tak więc, ustaw swój produkt w żywotnym stanie (Minimalny Produkt Żywny - lub MVP), a następnie wyślij go za drzwi (niezależnie od tego, jak naprawdę wygląda kod). Pozwól swoim klientom decydować o twoich przyszłych zestawach zmian i wersjach, a nie na odwrót. Jeśli skupisz się na tym podejściu, zarówno ty, jak i twój szef będziecie szczęśliwi na dłuższą metę.

Z powodów, które inni dokładnie wyjaśnili, czas zakończyć projekt i wysłać go, choć może to być bolesne.

Chciałbym tylko podkreślić, że testowanie aplikacji jest również częścią jej „ukończenia”. Jeśli znaczące funkcje nie zostały dokładnie sprawdzone i potwierdzono prawidłowe wyniki, masz uzasadnione obawy, że ludzie będą mieli problemy z tą aplikacją po jej wdrożeniu.

Testy jednostkowe i zautomatyzowane testy wyższego poziomu są świetne i są to rzeczy, które powinieneś mieć jak najwięcej, zanim spróbujesz przeredagować (lub przepisać) tę aplikację. Ale teraz musisz go głównie przetestować , nawet jeśli musisz uruchomić każdy test „ręcznie” i potwierdzić prawidłowe działanie „na oko”. Jeśli później dowiesz się, jak zautomatyzować te testy, pomoże to w rozpoczęciu pracy nad kolejną wersją produktu.

Niektórzy ludzie mają talent do siedzenia przed nowym projektem oprogramowania jako użytkownik testów alfa i sprawiania, by coś poszło nie tak. To znaczy, są dobrzy w łamaniu rzeczy. Jeśli masz szczęście, że tak utalentowana osoba pracuje z tobą, pozwól jej najpierw wypróbować aplikację, abyś mógł wcześniej naprawić wszelkie oczywiste błędy. Jeśli musisz wykonać to zadanie samodzielnie:

• Bądź metodyczny.
• Wypróbuj każdą funkcję.
• Udawaj, że jesteś użytkownikiem niedoświadczonym w swojej aplikacji. Popełniaj głupie błędy i zobacz, jak oprogramowanie je obsługuje.
• Zapisz to, co robisz, abyś mógł spróbować ponownie po pomyśleniu, że rozwiązałeś problemy.

Twoje pytanie brzmi: „Zacząłem źle, powinienem zacząć od nowa”, podczas gdy dodatkowy tekst w rzeczywistości mówi „Zakończony projekt, ale zrobił to źle, powinienem zacząć od nowa”. W przypadku samego nagłówka pytania: jeśli ilość pracy programistycznej, którą wykonałeś, jest niewielka w porównaniu z całkowitą potrzebną pracą, wtedy rozpoczęcie od nowa będzie miało sens. Dzieje się tak często, gdy problem jest złożony i źle zrozumiany, a sporo czasu zajmuje zastanawianie się, na czym polega problem. Nie ma sensu kontynuować złego startu, jeśli wyrzucisz go i zaczniesz od nowa, tym razem z dobrym zrozumieniem problemu oznacza to, że faktycznie skończysz szybciej.

To właśnie zrobiłbym osobiście:

1. Zrezygnuj, usprawiedliw się i poddaj się (możesz nawet zwrócić część swojej pensji, aby nie wyglądać źle)
2. Wyczyść swój kod tak bardzo, jak to możliwe
3. Twórz dokumentację wszystkich dobrych części swojej pracy, takich jak dobry projekt, dobre pomysły itp.

Dlaczego sugeruję ci to wszystko?

Ponieważ pomyśl o przyszłości. W przyszłości nadejdzie czas, kiedy pewne osoby zdobędą ten kod. Dokonają wszelkiego rodzaju przypuszczeń i osądów na temat ciebie i twoich umiejętności. Nie obchodzi ich, kiedy to napisałeś, nie obchodzą ich okoliczności. Chcą tylko zobaczyć w nim to, co chcą zobaczyć, aby potwierdzić wszystko, co chcą potwierdzić.

Będziesz oznaczony jako jakikolwiek zły termin, termin, który mogą wymyślić, aby negatywnie na ciebie wpłynąć. I chociaż ty w przyszłości równie dobrze możesz być zupełnie inny pod względem umiejętności technicznych, umiejętności, wiedzy, stylu, a sytuacja będzie tak inna, ten kod będzie używany przeciwko tobie w każdy możliwy sposób. To jest jak sąd, w którym mogą powiedzieć wszystkie złe rzeczy o tobie, twoim kodzie i projekcie, a ty nawet nie zdajesz sobie z tego sprawy, więc możesz się wyjaśnić i bronić. (i możesz bardzo często dowiadywać się, że wielokrotnie się głęboko mylą) Więc nie rób tego. Poddać się.

Zaufaj mi, są ludzie, którzy przyjęli wiele założeń o tobie, ponieważ zrobiłeś coś w dowolnym celu w dowolnym momencie. Dla nich, jeśli zrobiłeś to w sytuacji A, zrobisz to w sytuacji B. Myślą bardzo prosto.

Jeszcze dwie sugestie, założę się, że przynajmniej jedną z nich nie zrobiłeś.

1) Umieść narzędzie do śledzenia błędów i naucz go, jak go używać. Może to być część rozmowy na temat tego, jak spieprzyłeś, nauczyłeś się lepiej i zamierzasz to naprawić w zaplanowany sposób

2) Zacznij korzystać z kontroli wersji, choć mam nadzieję, że już to robisz.

Istnieje mnóstwo hostowanych systemów, które zapewniają oba powyższe za darmo na małych kontach. Szczególnie podoba mi się FogBugz, który ma również świetny system szacowania i wykonywania zadań, który da twojemu szefowi jeszcze większą pewność, że radzisz sobie z problemami w dobrze zarządzany sposób.

edytować

Wow, komuś się to nie podobało - głosowanie negatywne ORAZ usunięcie flagi? Dlaczego?

Tworzę oprogramowanie od ponad trzydziestu lat, w tym dużo pracy konsultingowej i dziedziczenie kodu innych osób. Ogromna liczba systemów problemów, które widziałem, były miejscem, w którym ludzie wykopali dół i nie mieli szczegółowych notatek o tym, jak się tam dostali, ani nie mieli kontroli wersji.

Aby odpowiedzieć na twoje pytanie: jak wielu innych powiedziało, nie. Wyślij i oczyść go krok po kroku w trakcie naprawiania błędów.

Ponadto, podczas gdy książki / StackExchange / webforums są dobrymi materiałami do nauki, prawdopodobnie przekonasz się, że nic nie dorówna uczeniu się podczas pracy (lub nawet po prostu dyskusji na temat pracy) z innymi programistami. Znalezienie i uczestnictwo w lokalnej grupie w technologii, której używasz lub chciałbyś się nauczyć, to wspaniała inwestycja twojego czasu. Oprócz wiedzy technicznej, którą należy zdobyć, jest to łatwy sposób na połączenie w sieć, który jest nieoceniony, gdy czeka się na przyszłe koncerty.

Twój szef był świadomy twojego poziomu doświadczenia, kiedy cię zatrudnił. Wyraź swoje obawy i daj mu do zrozumienia, że ​​się tym denerwujesz. Daj mu również znać, ile się nauczyłeś i o ile lepiej możesz wykonać następny projekt.

Jesteś początkującym programistą, bez dobrego programisty, który by Ci doradził, twój szef zatrudnił cię, doskonale o tym wiedząc. Myślę, że masz się tak dobrze, jak ktokolwiek mógłby się spodziewać. W rzeczywistości fakt, że masz wgląd w to, że praca mogła być lepsza, i że nauczyłeś się rzeczy, które pozwoliłyby ci to zrobić lepiej, oznacza, że ​​radzisz sobie lepiej niż większość. Pamiętaj, dla własnego zdrowia psychicznego, że wersja ciebie, która rozpoczęła pracę, nie mogła zrobić tego lepiej. Ktoś bardziej doświadczony (a więc lepiej opłacany) lub ty z doświadczeniem wartym jednego projektu, mógł zrobić to lepiej.

Co teraz zrobić : ciesz się, że jesteś lepszym programistą niż rok temu. Kolejny projekt wykonasz lepiej (a na koniec będziesz bardziej doświadczony i nie będziesz zadowolony z tego, co zrobiłeś; to normalne). Zmiana lub przepisanie ostatniego projektu przyniesie firmie bardzo niewielką korzyść z kosztów. Co możesz zrobić, to zastąpić zły kod dobrym kodem, kiedy i tak musisz wprowadzić zmiany; ma to sens, ponieważ modyfikowanie źle obsługiwanego kodu może być trudniejsze niż zastąpienie go dobrym kodem. A jeśli poprosisz o pomoc nowego niedoświadczonego programistę, powiedz mu, że ten kod nie jest przykładem, który powinni skopiować.