Pomagasz młodym programistom pokonać swoje niedociągnięcia? [Zamknięte]

Jakie są twoje wspólne słabości do młodszych programistów, którzy dołączają do twojego zespołu lub z którymi musisz współpracować? Oczywiście są niedoświadczeni, więc nie można oczekiwać, że będą wiedzieli wszystko, ale jakich umiejętności często brakuje w niewytłumaczalny sposób - i w jaki konkretny sposób możemy im pomóc w rozwijaniu tych brakujących umiejętności?

Nie mam na myśli umiejętności interpersonalnych, takich jak „słuchanie rad”, mam na myśli kwestie techniczne, takie jak (jeśli dotyczy):

• „nigdy nie korzystałeś z SQL?”

• „nigdy nie napisałeś testu jednostkowego?”

• „nie wiesz, jak korzystać z wiersza poleceń systemu Unix?”

Rzeczy, które nie oczekują - Chciałbym usłyszeć wasze spostrzeżenia i technik nauczania nowych programistów ominąć tych konkretnych braków.

Nie wiem, co to jest kontrola wersji lub jak z niej prawidłowo korzystać .

Jeden z młodszych programistów, który był w mojej firmie od kilku miesięcy, musiał nauczyć się bardzo podstaw Subversion. To sprawiło, że zacząłem się kulić ... cały czas sprawdzała kod w celu realizacji projektów ... i nie miała pojęcia, co robi ...?

Niewystarczające zadawanie pytań

Wiem, że są juniorami, spodziewam się, że będą popełniać błędy i po prostu nie będą wiedzieć. Tak wielu królewskich pierdół można było uniknąć, zadając pytanie zamiast czegoś zakładać. Szczerze mówiąc, nie mogę być wystarczająco prześladowany.

Kiedy zaczynałem, miałem mnóstwo pytań - zadawanie im pytań kilkakrotnie ratowało mi tyłek. Do diabła, wciąż mam wiele pytań ... Po prostu lubię myśleć, że są to lepsze pytania.

Skopiuj wklej i wypróbuj i popełniaj błąd zamiast szukać podstaw

Wielu młodszych programistów kopiuje kod, który wygląda na zbliżony, a następnie prawie losowo wypróbowuje różne kombinacje modyfikacji za pomocą brutalnej siły, dopóki nie trafi na taki, który działa. Jeśli nie wiesz, dlaczego to działa, możliwe, że wprowadzasz błędy w przypadkach granicznych, że ktoś, kto to rozumie, będzie musiał później wyczyścić.

Zachowanie „pierwszego szkicu” kodu

Kiedy doświadczony programista pisze nową funkcję o określonej złożoności, zaczyna od kodu pośredniczącego, który nie robi nic poza kompilacją, a następnie przepisuje, aby dodać komentarze pseudokodowe wysokiego poziomu dla całego algorytmu, a następnie przepisywać te komentarze pojedynczo za pomocą rzeczywisty kod, dodając i usuwając fikcyjny kod zgodnie z potrzebami do testowania, a następnie przepisz, aby usunąć nadmiarowość, która pojawiła się podczas implementacji, i tak dalej w szeregu kolejnych i stopniowych ulepszeń.

Młodsi programiści mają tendencję do pisania go w jednym dużym kawałku, a następnie przeprowadzania masowego debugowania z użyciem brutalnej siły. Nie lubią usuwać wiersza kodu po wpisaniu go do edytora i są tak szczęśliwi, że w końcu udało mu się go uruchomić, że nie chcą przepisać poprawek niefunkcjonalnych, ale to oni muszą to zrobić więc najbardziej.

Wierząc, że pierwszy raz spotkasz się z sytuacją.

Każdy napotkany problem programowy został napotkany przez innych, w jakiejś ogólnej formie. Tyle można się nauczyć od doświadczonych programistów. Jestem wystarczająco dorosły, aby pamiętać programowanie przed Google, a to było do bani . Jeszcze gorzej było, gdy mieliśmy wyszukiwarki, ale w sieci nie było jeszcze tak dobrych informacji. Programowanie jest teraz o wiele bardziej produktywne, ponieważ masz dostęp do globalnej wiedzy w kilka sekund. Ludzie, którzy go nie używają, ignorują to na własne ryzyko.

Edytuj :

Żeby było jasne, nie opowiadam się za programowaniem kopiuj / wklej. Jestem jednak pewien, że musisz przejrzeć istniejącą wiedzę, zanim sam podejmiesz dobre decyzje.

Myśląc, że wiedzą wszystko.

Miałem jr. stażysta, który próbował rozwiązać wszystko za pomocą javascript. Próbował wyjaśnić kilka pojęć, ale zawsze myślał, że mógłby to zrobić lepiej. Teraz zrezygnował i pracuje nad dużym programem, który zbudował dla wydruków przy użyciu HTML zamiast technologii gotowej do drukowania, takiej jak PDF. Nie wspominając o stosie innych poważnych problemów.

Lekcja polega na zwróceniu się do seniorów o główne wskazówki na wczesnym etapie projektu, nie odchodź od architektury bez pomocy. Możesz napisać sam kod i szczegóły, ale upewnij się, że przynajmniej używasz odpowiedniej technologii.

Rzadko denerwuję się, gdy juniorzy nie znają podstaw, nie uczą się umiejętności branżowych, takich jak SCC na uniwersytecie. Nauczanie ich to praca dla starszych deweloperów. Denerwują mnie tylko starcia osobowości. Ale najbardziej denerwują mnie starsi deweloperzy, którzy nie znają podstaw.

Nie chcą poszerzać swojej wiedzy - zamiast tego podążają ścieżką najmniejszego oporu.

Pewnego dnia stażysta wraz z grafikiem (który jest zaskakująco wykwalifikowany w programowaniu) poprosił o pomoc, ponieważ mieli problemy z implementacją czegoś w jQuery - zamknięcie może być bolesne, jeśli nie widzisz, że nadchodzi.

Usiadłem ze stażystą i wyjaśniłem dokładnie, co poszło nie tak i dlaczego. Naprawiliśmy błąd, a następnie wskazałem kilka dodatkowych ulepszeń, które można wprowadzić („ponieważ tu jestem”), i ostatecznie przepisaliśmy funkcję winy w 10 liniach zamiast 20 i bez błędów. Po udzieleniu odpowiedzi na jakiekolwiek pytania, zadowolony, że wszystko na świecie jest OK, odszedłem.

Następnego dnia stażysta przyszedł z pytaniem, które ujawniło, że „hmm, chciał wprowadzić pewne zmiany i przepisać tę funkcję po swojemu, ponieważ trudno mi było ją zrozumieć” (w większości cofając moje ulepszenia).

Mógłby zamiast tego bardziej się postarać (zadawać dodatkowe pytania, czytać o pojęciach, o których wspomniałem) - tak krótki kod nigdy nie może być tak trudny do zrozumienia - lub skorzystać z łatwego rozwiązania. Zasmuca mnie za każdym razem, gdy widzę, że ktoś to robi.

Nie rozumiem OOP. Niestety jest to o wiele bardziej powszechne, niż większość z nas prawdopodobnie zdaje sobie sprawę.

Umiejętność tworzenia klasy, klasy abstrakcyjnej, interfejsu, a nawet znajomość polimorfizmu to jedno; zrozumienie, jak właściwie z nich korzystać na korzyść programu, to kolejna sprawa .

Jeśli chcesz tego uniknąć, znalazłem następujące pytania i odpowiedzi na nie pouczające:

• Code Smell: Inheritance Abuse - Niebezpieczeństwo dziedziczenia
• Skąd bierze się ta koncepcja „faworyzowania kompozycji nad dziedziczeniem”? - Niebezpieczeństwa mantr związane z unikaniem dziedziczenia

Nie wiedząc, czego nie wiesz, i myśląc w ignorancji, wiesz wszystko.

(I jego bliski kuzyn, nie chcący pytać.)

Częściowo jest to kwestia organizacyjna - odpowiednia indukcja przychodząca znacznie przyczyniłaby się do uniknięcia problemów z niektórymi z tych rzeczy. Ale bardzo niewiele firm ma czas lub ludzi na nadchodzące wprowadzenie - coś, co powinno zająć od kilku dni do kilku tygodni i zabiera programistom pracę. Zamiast tego musimy zgasić pożary.

Dziwi mnie, ilu młodszych programistów stosunkowo świeżo po programie CS ma słabe algorytmy. Niewłaściwy wybór algorytmu może nie wyróżniać się na tle aplikacji biznesowych, ale przetwarzanie miliardów żądań usług internetowych dziennie ma znaczenie.

Oto pytanie, z którego korzystam, że prawie wszyscy programiści juniorów tęsknią, który podkreśla ten problem:

Napisz kod, który oblicza N-tą liczbę Fibonacciego .

Prawie zawsze wybierają najbardziej, pisząc oczywiste, ale nieefektywne

int Fib(int n)
{
    if (n == 0) return 0;
    if (n == 1) return 1;
    return Fib(n-2) + Fib(n-1);
}

Poproszony o wypowiedzenie się na temat złożoności algorytmu, zwykle otrzymuję „jest gorzej niż O (N) ... uhm ... O (N logN)”. To jest (znacznie) gorsze niż to ...

Wykonanie wcięcia kodu wstecznego!

Oczywiście nie jest to zbyt „typowe”. Nigdy nie mogłem uwierzyć, że to w ogóle możliwe, ale jak napisałby normalny programista

try {
    switch(action){
        case case1:
            ...
            break;
        case case2:
            ...
            break;
        default:
            break;
    }
}
catch(Exception e) {
    e.printStackTrace();
}

pisałaby jak (Boże, wciąż wydaje mi się to niemożliwe!)

            try {
        switch(action){
    case case1:
...
break;
    case case2:
...
break;
    default:
break;
        }
            }

Frustrujące, prawda?