Nie jesteś już Juniorem - jesteś Senior.

Gratulacje z powodu awansu!

Jeśli jeszcze nie był, podziel zadania projektowe na małe kawałki pracy. Przeanalizuj każdy z nich i oceń, czy rozumiesz wystarczająco dużo, aby go w pełni zrozumieć, ile czasu ci to zajmie. Weź te szacunki czasowe i dodaj co najmniej 50%.

Jeśli te szacunki nie mieszczą się w wymaganym terminie, musisz potraktować to jako ryzyko - albo potrzebujesz pomocy, albo coś musi być usunięty z projektu.

Musisz także podnieść ryzyko w przypadku każdego zadania, którego nie jesteś pewien. Dostaniesz więcej punktów za myślenie przyszłościowe i bycie uczciwym niż ukrywanie wszystkiego i niepowodzenie na końcu.

Jeśli potrzebujesz pomocy, zbuduj rozsądny powód biznesowy i poproś o pomoc.

Potraktuj to jako wspaniałe doświadczenie edukacyjne, niewielu juniorów ma taką możliwość.

Jako jedyny programista front-end możesz być najbliżej eksperta. Ekspertyza jest względna, więc nawet jeśli czujesz, że nie wiesz tak dużo, być może będziesz musiał posiadać rozwiązanie. Od konsultantów oczekuje się, że będą w stanie rozwiązywać problemy i może to być Twoja okazja, aby zabłysnąć.

Daj z siebie wszystko, korzystając z umiejętności i wiedzy, które posiadasz. Poszukaj informacji na temat struktury i najlepszych praktyk korzystania z niej. Jeśli framework jest w ogóle używany, powinno być wiele badań, które możesz przeprowadzić w Internecie, albo od dostawcy, grupy roboczej lub jakiejś witryny, takiej jak StackOverflow.

Upewnij się, że udokumentowałeś swoje badania i jak doszedłeś do decyzji, które musiałeś podjąć. Udostępnij tę dokumentację swojemu przełożonemu technicznemu i / lub administracyjnemu, aby wiedział, co zrobiłeś i mógł zarządzać ryzykiem.

Jeśli po badaniu uważasz, że istnieje ryzyko związane z harmonogramem, poinformuj go o tym wcześniej. sytuacja się pogarsza. Skorzystaj z przeprowadzonych badań, aby przedstawić harmonogram, który możesz utworzyć, i pozostaw to im, aby następnie zarządzali harmonogramami projektu na wyższym poziomie.

Obawiam się, że mogę [stworzyć] kod, który działa TERAZ, ale JUTRO będzie zawierać błędy lub coś podobnego z powodu mojego braku doświadczenia [.]

Tak, będziesz pisać błędy. Naprawisz znalezione błędy. Jestem pewien, że już tego doświadczyłeś.

Możesz zmniejszyć to ryzyko, budując zestaw testów automatycznych. Nie musi to być wyrafinowany zestaw testów zapewniający 100% pokrycia. Musi tylko być w stanie wychwycić błędy, które już znalazłeś, abyś wiedział, że się nie poślizgnąłeś i nie popełnisz ponownie tego samego błędu. Jeśli obejmuje również standardowe szczęśliwe ścieżki, zaoszczędzi ci to trochę zakłopotania.

Jeśli czujesz się komfortowo z uprzężą testową na poziomie interfejsu użytkownika, taką jak Selenium lub Coded UI Tests firmy Microsoft, świetny. Ale możesz uzyskać przyzwoite pokrycie testami jedną warstwę w dół w systemie, sprawdzając, czy model generuje rozsądne dane wyjściowe, biorąc pod uwagę rodzaje danych wejściowych, których oczekujesz od interfejsu użytkownika.

Będziesz musiał przejść przez złe projekty, aby osiągnąć dobre. To jest kluczowy punkt tego problemu, z którym musisz żyć.

Teraz: czy „zły” kod spali mosty? Mało prawdopodobne. Nigdy nie widziałem, żeby to się stało. Co gorsza, zostaniesz poproszony o podanie powodu takiego postępowania i możesz to uzasadnić.

W branży programistycznej wszyscy rozumiemy ograniczenia i motywy jakiegoś złego kodu. W przyszłości nauczysz się:

Idealny kod nie istnieje.

Kod z czasem traci jakość, a historia programistów można zobaczyć w kodzie i pogarsza się, dopóki koszt utrzymania programu nie stanie się wyższy niż napisanie nowego, czyli wtedy, gdy ludzie to robią.

Jak możesz pomóc w podejmowaniu najlepszych decyzji? Jeśli naprawdę zależy Ci na tym, aby Twój kod był jak najlepszy (zakładając, że nie wpłynie to na ograniczenia czasowe, ale tak czy inaczej). Odpowiedź jest prosta. Spójrz na przykłady online i dyskusje na ten temat ... WIELE z nich! Spróbuj postępować zgodnie z konsensusem na wielu forach.