Jak wdrożyć proces rozwoju ze studentami


9

Podczas mojej pierwszej pracy jako programista mój zespół używał metodyki agile / scrum do zarządzania przepływem pracy w projekcie i działało to całkiem nieźle. Miałem doświadczonych mentorów, którzy postawili mnie na właściwej drodze - jestem im winien wielki dług wdzięczności. Pracowałem tam przez kilka lat, a kilka miesięcy temu przeszedłem na nową okazję.

Szybko przejdź do mojej obecnej pracy. Pracuję na uniwersytecie pod kierunkiem profesora. Ponieważ jestem na uniwersytecie, prawie każdy programista jest studentem (są tanie i obfite!) Mój szef ma doświadczenie w zarządzaniu, ale nie z programowaniem, a zespół oprogramowania nie zawsze jest na pierwszym planie . Te warunki stworzyły idealne środowisko do tworzenia oprogramowania o bardzo niskiej jakości. Projekty oprogramowania wydają się być nieco nieuczciwe, nie myślą o projektowaniu i stosują naprawdę przerażające praktyki. Wiem, że może być lepiej.

Chcę wdrożyć proces programowania, aby pomóc wszystkim w śledzeniu, zwiększyć jakość kodu i wdrożyć bardziej stabilne oprogramowanie. Po prostu nie jestem pewien, od czego zacząć.

Ja nie patrząc, na powiedzieć, odpowiedzi jak „Korzystanie Scrum”, „utwórz Tablica Kanban” lub „Spójrz na Agile!” (choć pomysły są doceniane). Mówiąc dokładniej, mam nadzieję uzyskać wgląd w to, jak wdrożyć proces programowania dla tego środowiska pracy. Pracownicy zwykle pracują od 1 do 2 lat przed przejściem, są na ogół niedoświadczeni, a codzienne spotkania z udziałem wszystkich są prawie niemożliwe do zaplanowania.

Jak sprzyja się jakości, wydajności i komunikacji w takim miejscu pracy?

Aktualizacja: po przeczytaniu niektórych odpowiedzi i komentarzy pomyślałem, że przedstawię dodatkowe informacje.

Nie uważam się mistrzem w sztuce tworzenia oprogramowania, ale ja jestem na tyle doświadczony, aby rozpoznać złe programowanie, gdy widzę go. Potrafię ustalić, czy programista jest utalentowany, czy nie po spędzeniu z nim zaledwie minuty lub dwóch. Czuję się dobrze z własnymi możliwościami znalezienia sposobu na inteligentne rozwiązanie problemu , jednak obszarem, w którym naprawdę brakuje mi doświadczenia, jest zarządzanie projektami, w które zaangażowani są inni programiści (dlatego właśnie tutaj proszę wszystkich o cudowne osoby o Rada).

Wydawało mi się, że każdy uczeń wchodzący do tego biura jest kompletnym durniem. Było tu trochę złych jaj, ale większość studentów, których spotkałam, jest inteligentna, chce się uczyć i pasjonuje się pracą. Niektórzy dopiero zaczynają i nie wiedzą, czego nie wiedzą. I w porządku. Kiedy zaczynałem programować, nie było mi lepiej!


Czy programiści są odpowiedzialni za własną kontrolę jakości?
svidgen

Gdy pojawia się projekt, programiści otrzymują zestaw wymagań i od tego momentu wszystko zależy od nich. Pytanie o to, czy twórcy są odpowiedzialni za własne pytania i odpowiedzi, jest jakby dawaniem dziecku broni i pytaniem, czy dziecko jest odpowiedzialne za bezpieczne obchodzenie się z bronią.
darksinge

Zakładam, że mówimy o zespole programistów studentów pracujących w niepełnym wymiarze godzin? A ty? ... Czy w zespole są programiści pełnoetatowi lub starsi (> = 10 lat) ?
svidgen

Jest kilku pełnoetatowych deweloperów, którzy pracują zdalnie, ale nie widzimy ich dużo (lub wcale). Tak, w biurze wszyscy pracownicy są studentami niestacjonarnymi. Obecnie pracuję na pełny etat, ale wkrótce rozpocznę program studiów magisterskich, więc może się to zmienić;) Mam 5-letnie doświadczenie, niewiele doświadczenia w zarządzaniu projektami.
darksinge

Nie miałem jeszcze czasu na pełną odpowiedź. Ale tylko coś do rozważenia: piszę kod od około 20 lat. Co najmniej 10 lat w środowisku zawodowym, wśród innych dość wysokich rangą osób. Różnorodność tego, co doświadczeni twórcy oprogramowania nazywają „dobrym” i „złym” kodem, jest ogromna . Dobrym pierwszym krokiem może być wyrażenie tego, co czyni kod „dobrym” lub „złym” w sposób, który może wyznaczać granice, w których zachęca się do eksperymentowania, nagradza kreatywność i innowacje, a twoje doświadczenie i opinie są uznawane za cenne, ale ostatecznie ograniczone .
svidgen

Odpowiedzi:


4

Usunięcie pomyłki zajmuje więcej czasu niż sprawdzenie wstępne. Jeśli masz do czynienia z programistami (prawdopodobnie) niewykwalifikowanymi lub nieświadomymi dobrych praktyk, oznacza to, że nie powinni oni być w stanie zmienić bazy (master) kodu, dopóki ich kod nie zostanie sprawdzony przez kogoś doświadczonego.

Nie chciałeś wyjaśnienia metodologii, więc pozwól mi przejrzeć tę część: użyj zwinnych zadań, aby skonfigurować różne funkcje, które można opracować niezależnie.

Zacznij korzystać z gałęzi funkcji, aby wszyscy pracowali w osobnej gałęzi. Po zakończeniu zadania programista nie może scalić swojego kodu z gałęzią master. Jeśli korzystasz z Git, nadal mogą uruchomić żądanie ściągnięcia. W przeciwnym razie użyj dowolnej metody śledzenia zakończonych zadań (/ oddziałów), która Ci się spodoba.

Następnie przechodzimy do procesu recenzji . To, co zadajesz, jest nieco niejasne, czy są też doświadczeni programiści, którym można zaufać bardziej niż ocenom studentów. Pozwólcie więc, że rozwinę te kwestie:

Jeśli są doświadczeni programiści, powierz im przegląd kodu ukończonych zadań. Jeśli jest dobry, mogą połączyć go z gałęzią master. Jeśli tak nie jest, mogą albo sfaktoryzować go samodzielnie, albo przekazać deweloperowi informacje zwrotne na temat tego, co należy poprawić.

Jeśli nie ma doświadczonych programistów, zawsze będziesz mieć problemy. Jeśli nie ma nikogo, kto zauważyłby dobry kod ze złego kodu, niemożliwe jest utrzymanie jego jakości.
Najlepsze, co możesz zrobić, to spotkania przeglądowe, podczas których programiści przedstawiają i wyjaśniają ich implementację przed innymi programistami. Chociaż nie może to zagwarantować uniknięcia każdego problemu (np. Jeśli wszyscy programiści mają takie samo błędne przekonanie na temat dobrych praktyk, nadal zapobiegnie większości problemów (np. Jeśli co najmniej jeden programista ma właściwy pomysł i może go wyrazić; lub gdy problem występuje) od programistów, którzy inaczej rozumieją problem)

Jak sprzyja się jakości, wydajności i komunikacji w takim miejscu pracy?

  • Jakość - sprawdź kod przez doświadczonych programistów. W przypadku braku doświadczonych programistów, spraw, aby był to przegląd grupowy, aby przynajmniej objąć swoje bazy jak najlepiej.
  • Wydajność - prawidłowe ustawienie niezależnych zadań pozwala zminimalizować potrzebę wzajemnego oczekiwania. W środowisku, w którym nie wszyscy są dostępni jednocześnie, zakładam, że masz do czynienia z wieloma opóźnieniami „oczekiwania na osobę A”. Śledź programistów, którzy nie robią postępów, tylko po to, aby sprawdzić, czy potrzebują pomocy, a nawet po prostu pozwól im upust swoich frustracji (frustracje te mogą ujawnić błędne przekonania na temat problemów, których można uniknąć).
  • Komunikacja - Ustaw zasady otwartych drzwi, aby programiści mogli poprosić kogoś o pomoc, opinie lub inspirację. W przypadku braku wykwalifikowanego mentora staraj się ułatwiać interakcję w zespole (oczywiście możesz to zrobić, nawet jeśli masz dostępnego mentora, ale znaczenie takiego działania wzrasta w przypadku braku mentora). Zwłaszcza w sytuacji, gdy ludzie pracują zdalnie i według różnych harmonogramów, programiści często nie są blisko swoich współpracowników i zwykle nie komunikują się między sobą. Nawet kilka spotkań towarzyskich może w cudowny sposób usprawnić komunikację związaną z pracą.

Było kilka dobrych odpowiedzi, ale to było najbardziej dokładne i bezpośrednie, dzięki!
darksinge

1
Jest blisko, ale nie do końca. Zgadzam się z recenzjami kodu, ale nie zgadzam się namiętnie z doświadczonym programistą, który robi poprawki, które tworzą wyjątkowo złą pętlę sprzężenia zwrotnego, w której najbardziej niechlujni koderzy zalewają doświadczonego programistę pracą szybciej, niż potrafią go wyczyścić. Zdecydowanie lepiej jest wysłać recenzje z powrotem do oryginalnego programisty i zlecić im wykonanie pracy. Osiąga to cel, jakim jest nauczenie ich, jak lepiej kodować, ale ma także tę zaletę, że spowalnia niechlujne kodery, pogrążając je w przeróbce, dopóki nie wyprodukują oprogramowania w akceptowalnym standardzie.
mcottle,

@mcottle Przeciwdziałasz punktowi, którego nigdy nie uczyniłem. Refaktoryzacja to nie to samo, co ustalanie. Jeśli kod nie działa, należy go odesłać, jak powiedziałeś. Jeśli problem jest drobnym argumentem stylistycznym, nadal ważne jest, aby zwrócić się z powrotem do programisty, ale czasami łatwiej jest go poprawić, niż trzeba szczegółowo wyjaśniać. Zaletą jest to, że możesz pokazać deceloperowi ulepszony kod, aby zobaczył, co masz na myśli.
Flater,

8

Największą rzeczą w tego rodzaju środowisku, w którym ludzie są nowi i prawdopodobnie odejdą, są obowiązkowe przeglądy kodu.

Pomagają rozpowszechniać wiedzę o tym, co należy zrobić. Pomagają zapobiegać przedostawaniu się najgorszego kodu do bazy kodu. Promują spójność we wdrażaniu.

Ponieważ przy tak dużym obrocie i braku doświadczenia komunikacja jest ważniejsza niż zwykle.


2
Jestem trochę sceptyczny. Nie zgadzam się, że recenzje kodu powinny być wymagane ... Ale mówisz o grupie nieświadomych programistów, którzy proszą o opinie od innych nieświadomych programistów - chyba że sądzisz, że OP ma czas na sprawdzenie i pozostawienie komentarzy na wszystko . .. Mam na myśli. Może to nie jest tak daleko idące. Zależy od napływu. Ale „recenzje kodu” nie wydają mi się (jak dla mnie) niczym więcej niż jedną czwartą rozwiązania. W najlepszym razie mam na myśli .
svidgen

@svidgen: Nie sądzę, by opowiadał się za recenzjami innych twórców. Nigdy nie sprecyzował wyraźnie (więc może pójść w jedną stronę), ale z mojego doświadczenia wynika, że ​​opinie pojawiają się częściej zarówno przez doświadczonych kolegów, jak i osoby w łańcuchu (lead dev), szczególnie w przypadkach, gdy niektóre umiejętności programistów są nierówne lub niepotwierdzony.
Flater,

1
@svidgen - na początku może to być konieczne, ale problem polega na posiadaniu dużej liczby łodzi lub programistów bez wiedzy. Nie rozwiązujesz tego, nie robiąc pewnych nieświadomości. Idealnie byłoby, gdyby było kilku deweloperów, którzy go zdobędą, a następnie pomogą w przeprowadzeniu recenzji kodu w mniej krytycznych sprawach.
Telastyn

2

Bardziej pomysł niż rozwiązanie, ale znajdź jedną krytyczną sekcję bazy kodu, która zawiera podobne funkcje i elementy do projektów, które mogą zrobić Twoi studenci, i wyczyść ją BARDZO dobrze. Jednym z dużych problemów z nowymi programistami jest to, że nie znają norm i konwencji bazy kodu i będą patrzeć na inny kod, aby dowiedzieć się, jak skonfigurować własny. Posiadanie wielu nowych programistów pracujących w nieporządnej bazie kodu oznacza, że ​​zobaczą bałagan i będą myśleć, że jest to akceptowalny lub najlepszy sposób na zrobienie czegoś. Złe praktyki utrwalają się nawet w środowisku o wysokich obrotach.

Dysponując co najmniej jedną nieskazitelną, dobrze napisaną sekcją kodu (lub nawet tylko jednym plikiem), możesz powiedzieć programistom-uczniom, aby wykorzystali to jako przykład najlepszych praktyk. Powiedz im, że będziesz zachwycony, jeśli będą mogli napisać kod podobny do tego, a znaczna część innego kodu może nie być dobrym przykładem właściwego sposobu robienia rzeczy.

Dodanie komentarzy lub innej dokumentacji z wyjaśnieniem, dlaczego pewne czynności są wykonywane w określony sposób, pomoże również nowym programistom szybciej przyśpieszyć działanie dzięki lepszym praktykom kodu.


2

Ciągła integracja -

Jest to praktyczne i koncepcyjne ramy dla stopniowego i elastycznego wdrażania narzędzi, umiejętności i procesów zespołu.

CI jest ideą przepływu pracy od pisania kodu do wdrożenia. Te zadania są koncepcyjnie i faktycznie niezależne.

CI to w szczególności automatyzacja. Ma to głęboki wpływ na jakość i produktywność, poczynając od momentu wpisania kodu na ekranie.

  • Realizacja zadania CI może być realizowana niezależnie, szczegółowo i jednocześnie. Ostrość może się zmieniać w razie potrzeby.
  • Nie wprowadzaj narzędzia CI zupy do orzechów
    • Wszyscy będziecie rozpraszani przez proces i mają tendencję do wybielania zamkniętych umiejętności zadania.
  • Przedstawiaj rzeczy na haju na zasadzie złotówki
  • Spodziewaj się, że będziesz pełnoetatowym agentem zmian. Zostań liderem; nie tylko menedżer, nie tylko starszy programista.

  • Bądź strategiczny

    • Holy Graal of CI to bezproblemowa kompilacja do automatyzacji wdrażania. Nie mogą FUBAR, jeśli nie mogą tego dotknąć.
    • Szkolenie i materiały szkoleniowe.
      • Przetwarzanie dokumentów.
      • Utwórz Podręcznik programisty , niech ewoluuje organicznie.
      • Obowiązkowy.
      • Eksploracja przedstawia ukierunkowane na określone umiejętności i samą bazę kodu.
    • Zaszczepić wartości profesjonalnego programisty, takie jak:
      • TDD absolutnie tworzy jakość
      • Przegląd kodu obejmuje wszystkie artefakty: komentarze, skomentowany kod, testy jednostkowe itp.
      • „Wstydzę się, ile błędów znaleziono”
      • Obiektywizm nie jest tłumiony poczuciem posiadania osobistego kodu i obawą przed „obrażeniem” właściciela.
  • Bądź taktyczny

    • Dyskretne zadania CI można same zautomatyzować, na przykład zatwierdzenie kontroli wersji wyzwala kompilację i testy jednostkowe.
    • Reguły wymuszone przez automatyzację, takie jak formatowanie kodu.
      • Uważaj na zbyt pedantyczne minucje. Narzędzie zacznie być ignorowane. Moduluj wymuszanie reguł, aby nie było przytłaczające.
    • Wdrażaj od razu testowy rozwój
    • Priorytet i podkreśl każdą zmianę
      • Nie zakładaj, że kluczowa wiedza i skoki umiejętności po prostu się zdarzają.
    • Nie pozwól, aby pilne zakłócenia prawidłowej realizacji
    • Poprowadź zmianę i podążaj dalej
      • Konieczna jest orientacja nowego faceta i minimalne szkolenie.
      • Wyraźne szkolenie i jednoznaczne wskazówki dotyczące nowych rzeczy
      • Trenuj co najmniej do pewnych minimalnych, hipotetycznych standardów. Nie musi to być prawdziwa formalność, ale przypadkowy spacer po YouTube nie jest treningiem. Weryfikuj osobiście - ponownie unikaj formalności.
    • Bądź recenzentem kodu, przejrzyj cały kod.
      • Wyraźnie prowadź trudne poprawki błędów i dziel się znaczącymi doświadczeniami edukacyjnymi.
    • Sztywna elastyczność. Przepraszam, musiałem to powiedzieć. Ale to prawda.
  • Twórz kulturę
    • Miej profesjonalne oczekiwania
    • Standaryzuj narzędzia
    • Nacisk na naukę zamiast wskaźników produkcji
    • Bądź mentorem
    • Wprowadzając zmiany, po prostu w zależności od inicjatywy poszczególnych osób ”, aby„ subtelnie podważyło rozwój zespołu. Tożsamość spójnego zespołu obejmuje jego cechy wspólne: narzędzia, wiedzę i poziom umiejętności. Wzajemny szacunek rośnie w miarę, jak każdy członek przyjmuje tezy jako wartościowe wartości. Lider zespołu jest modelem, jest nieunikniony; nie modeluj postawy i oczekiwań „cokolwiek”.

Droga do jakości

  • Testów jednostkowych

    • klucz do rozwoju opartego na testach
      • Czytanie całych książek na ten temat nie jest konieczne
      • To powinno stać się paradygmatem kodowania
      • Jako lider musisz trzymać się tego, dopóki wszyscy nie dokonają „jednostkowego skoku wiary”. Ten paradygmat zmienia się z „Piszę dwa razy kod!” do wykorzystania swojej niesamowitej wydajności.
    • Testy jednostkowe były obowiązkowe w naszym sklepie. Ale wielu tego nie zrobiło, ponieważ nie chcieli. Brak przekonania kierownictwa wysłał wiadomość, że testy jednostkowe i tak naprawdę nie działają.
  • Kontrola wersji

    • Po pierwsze, testowanie jednostkowe jest łatwiejsze
    • nie opóźniaj innych inicjatyw, ponieważ kontrola wersji nie jest tak łatwa
    • Stwórz plan kontroli wersji.
      • Musisz to zapisać.
      • Zrób to, nawet jeśli jest to tak proste, jak „wrzuć wszystko do bagażnika i nie rozgałęziaj się”.
  • Recenzje kodu

    • Ma to największy potencjał do szczegółowej poprawy jakości kodu.
    • Użyj procesu weryfikacji 2.
      • Byłem bardzo zaskoczony, jak wiele błędów wykrywa druga recenzja.
      • Ufaj ale sprawdzaj. Uruchom kod. Dlaczego powinieneś w ogóle to mówić? Zobacz bezpośrednio powyżej.
      • Początkowo będziesz jedynym recenzentem. Niech zespół obejrzy, jak oceniasz „na żywo”. Nigdy nie nauczą się myśleć inaczej.
      • Wkrótce będziesz tylko drugim recenzentem. Ponieważ poszczególne umiejętności wymagają ich przeglądu; ostatecznie obaj recenzenci. Oczywiście zawsze będziesz patrzeć na kod, bez wyjątku.
  • Refaktoryzacja

    • To odrębna, formalna dyscyplina.
    • Refaktoryzacja: Ulepszenie projektu istniejącego kodu autorstwa Martina Fowlera
      • Skodyfikowane przepisy refaktoryzacji, które zapewniają bezbłędną zmianę kodu.
      • Rozpocznij profesjonalną bibliotekę dzięki tej książce.
    • Odkładając na bok formalność, wprowadź ją ad hoc poprzez recenzje kodu
  • Uchwyć swoje środowisko

    • Podstawowe konfiguracje narzędzi: kontrola wersji, IDE, narzędzie CI, system operacyjny itp.
    • Kod źródłowy, dokumentacja, konfiguracje powinny być zsynchronizowane w kontroli wersji.

Słowo o procesie

Zwinny (i jego podgatunki, takie jak Scrum): Zapomnij. „Jesteś zwinny, nie zwinny”. Zobacz je Dave Thomas, jeden z pierwszych sygnatariuszy Agile Manifesto .

Biorąc pod uwagę małe, niedoświadczone zespoły, mój pająk traci sens, gdy widzę narzędzia do integracji zespołu, takie jak Visual Studio Team Services. Moje doświadczenie jest tu ograniczone, ale wyczuwam, że to oszałamiające, zbędne, sztywne narzucanie procesu. Wiem, że wielu używa tych rzeczy z wielkim skutkiem, ale strzeż się potencjalnie zakupu rozwiązania szukającego problemu.


Słowo o narzędziach

Tylko ja. Nie z tych „Najlepszych narzędzi programowych teraz ...” przynęt z miodem.

Jenkins

Narzędzie do integracji CI. Internetowy, szeroko stosowany. Zasadniczo za pośrednictwem internetowego interfejsu GUI konfigurujesz i automatyzujesz różne zadania i kolejność wykonywania, takie jak kompilacja, uruchamianie testów jednostkowych, aktualizacja kontroli wersji. Jest bardzo A-La Carte, więc można go dostosować do rodzącego się środowiska CI.

Kontrola wersji

Wolę Mercurial niż Git. Ten post na blogu jest powodem, dla którego pierwotnie wybrałem Mercurial: Git to MacGyver, Mercurial to James Bond

Subversion jest dobre. Mercurial & Git mają inną architekturę, która jest lepsza niż Subversion.

Zintegrowane środowisko programistyczne

Oto wielka uwaga, jeśli wszyscy używają różnych narzędzi do kodowania: Nie ma czegoś takiego jak zwykły tekst


Słowo o profesjonalnej bibliotece

Internet jest szeroki, płytki i niezorganizowany.

  • Kompletny kod Steve McConnell
    • Niech wszyscy przeczytają środkową trzecią.
    • Zawiera dodatek sugerowanych profesjonalnych książek.
  • Refaktoryzacja: Poprawa projektu istniejącego kodu
    • Skodyfikowane przepisy refaktoryzacji, które zapewniają bezbłędną zmianę kodu.
  • Awarie oprogramowania. Brak konkretnych zaleceń, ale powinny to być historie dotyczące traktatu.

0

proponuję zastosować inną metodologię do zarządzania twoim procesem, ponieważ, jak mówisz, nie można zaplanować spotkań (co jest absolutnie ważne dla scrum!). Nadal nie ma nic złego do stworzenia dobrej koncepcji, więc wszyscy wiedzą, co się dzieje (prawdopodobnie również za pomocą prototypu vert) i używają modelu wodospadu. Tak czy inaczej komunikacja jest największą częścią pracy.


1
czym jest prototyp vert; możesz rozważyć poszerzenie swojej odpowiedzi, jest ona raczej zwięzła.
esoterik

Przepraszam, nie miałem dziś rano czasu. Po pierwsze, [prototyp pionowy] (tutorialspoint.com/sdlc/sdlc_software_prototyping.htm) jest rodzajem prototypowania, co oznacza, że ​​całkowicie budujesz oprogramowanie bez implementacji jakiejkolwiek funkcjonalności. Zaletą jest to, że po pierwsze domniemany klient może zobaczyć, jak może wyglądać produkt, po drugie daje programistom dobre wyobrażenie o tym, jaka funkcjonalność „powinna być” / jakie dane musi dostarczyć.
gkhaos,

co rozumiesz przez „raczej zwięzły”? Rodzaj zarządzania projektem jest raczej trudny do ustalenia, ponieważ zależy od różnych rzeczy, na przykład o czym jest twój projekt? Jak duży jest twój zespół? Również np. W scrumie potrzebujesz mistrza scrum, który powinien mieć głęboką wiedzę na temat scrum. Próbowałem tylko wziąć pod uwagę, że scrum nie jest jedyną odpowiedzią na zarządzanie projektami.
gkhaos,

0

Zachęcam do korzystania z kontroli źródła, jeśli jeszcze tego nie zrobiłeś. Pozwala to zobaczyć, co zostało zameldowane przez każdego programistę i umożliwia regresowanie tam, gdzie został wprowadzony błąd.

Ustawiłbym jakiś zestaw testów. Może to być programowanie oparte na testach, w którym piszesz testy dla każdej zatwierdzanej funkcji, lub może to być zautomatyzowany sposób uruchamiania aplikacji i wysyłania wyników do pliku, który można porównać z pożądanym wynik. Jeśli jest to uruchamiane po każdym zatwierdzeniu lub uruchamiane przynajmniej raz na noc, szybko znajdziesz regresje.

Ostatnią rzeczą, którą bym zrobił, to zaimplementować 2 zasady: 1) wszystkie kompilacje muszą mieć ostrzeżenia ustawione na błędy i wszystkie błędy włączone 2) Cały kod musi przejść przez analizator statyczny bez generowania jakichkolwiek błędów lub ostrzeżeń przed zatwierdzeniem. Uczyniłbym to nawet działaniem poprzedzającym zatwierdzenie. Te 2 rzeczy zapobiegną szybkiemu zepsuciu kodu na wiele typowych sposobów. (Nie łapią wszystkiego, ale dużo łapią.)

To również przygotuje twoich uczniów do pracy w „prawdziwym świecie” i zaszczepi im w miarę dobre nawyki.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.