Od czego mój zespół powinien zacząć od „nowoczesności”? [Zamknięte]

106

Jestem stosunkowo nowym programistą, świeżo po studiach. Podczas studiów i późniejszych poszukiwań pracy zdałem sobie sprawę, że brakuje wielu „nowoczesnych” metodologii tworzenia oprogramowania, których brakuje w moim wykształceniu: testowanie jednostkowe, rejestrowanie, normalizacja baz danych, zwinne opracowywanie (w porównaniu z ogólnymi koncepcjami zwinnymi), styl kodowania przewodniki, refaktoryzacja, recenzje kodu, brak standardowych metod dokumentacji (a nawet wymagań) itp.

Ogólnie nie widziałem, że to problem. Spodziewałem się, że moja pierwsza praca obejmie wszystkie te pomysły i nauczy mnie ich w pracy. Potem dostałem swoją pierwszą pracę (tworzenie stron internetowych z pełnym stosem) w dużej korporacji i zdałem sobie sprawę, że nie robimy żadnej z tych rzeczy. W rzeczywistości ja, najmniej doświadczony w zespole, jestem tym, który przewodzi próbom przyspieszenia mojego zespołu dzięki „nowoczesnym” technikom programowania - ponieważ martwię się, że nie zrobienie tego jest zawodowym samobójstwem na drodze.

Najpierw zacząłem od oprogramowania do rejestrowania (log4J), ale potem szybko przeszedłem do pisania własnego poradnika stylów, a potem porzuciłem go w poradniku stylu Google - i wtedy zdałem sobie sprawę, że nasze oprogramowanie internetowe Java używało ręcznie napisanych kontrolerów, więc zdecydowałem się na nasze przyjęcie wiosny - ale potem zdałem sobie sprawę, że nie mieliśmy żadnych testów jednostkowych, ale już uczyłem się wiosny ... i jak widać, staje się ona zbyt przytłaczająca, szczególnie w połączeniu z normalną pracą programistyczną. Co więcej, trudno mi stać się wystarczająco „ekspertem” w tych metodologiach, aby uczyć kogokolwiek innego bez poświęcania zbyt wiele czasu jednemu z nich, a tym bardziej wszystkim.

Ze wszystkich tych technik, które uważam za „oczekiwane” w dzisiejszym świecie tworzenia oprogramowania, jak zintegrować je z zespołem jako nowy gracz, nie przytłaczając ani siebie, ani zespołu?

Jak mogę wpłynąć na mój zespół, aby stał się bardziej zwinny? jest powiązany, ale ja nie Agile deweloper jak Pytający tutaj, a ja patrząc na znacznie szerszy niż zbiór metodologii Agile.

WannabeCoder
źródło
92
"nowoczesny"? Odrzuć to zwinne modne hasło z listy i widzę tylko rzeczy w wieku> 20 lat.
Doc Brown
10
Być może „nowoczesny” w tym sensie, że ich powszechne przyjęcie jest nowoczesne, a nie geny pomysłów? Nie jestem też ekspertem w tej dziedzinie, to tylko moje wrażenie.
WannabeCoder
41
Zapewniam, że testy jednostkowe, logowanie, normalizacja bazy danych, przewodniki po stylu kodowania, kontrole kodu (= recenzje) są starsze niż 30 lat. Termin „refaktoryzacja” ma co najmniej 15 lat (Fowler napisał swoją książkę w 2000 r.). A brak formalnej dokumentacji lub pisemnych wymagań nie jest „nowoczesną techniką”, jest IMHO nawet „techniką”.
Doc Brown
69
@DocBrown przyznaje, że właśnie wysłałeś Marty'ego z powrotem, aby stworzyć wszystkie te rzeczy, zanim skomentujesz.
zera
17
Bardziej martwię się, że jego uczelnia nie uczy tych rzeczy z góry - nie chodzę do szkoły przez ponad 15 lat i większość z tych rzeczy była omawiana dość wcześnie. (Pomijając oczywiście modne słowa).
Allen Gould

Odpowiedzi:

165

Wydaje mi się, że stawiasz wózek przed koniem.

Jaki jest główny problem, przed którym stoi Twój zespół i jakie technologie pomogłyby go naprawić?

Na przykład, jeśli jest wiele błędów, szczególnie błędów typu regresja, testowanie jednostkowe może być punktem wyjścia. Jeśli Twojemu zespołowi brakuje czasu, być może ramy mogą pomóc (średnio- i długoterminowe). Jeśli ludzie mają trudności z czytaniem sobie nawzajem kodu, stylizacja może być przydatna.

Pamiętaj, że celem firmy, w której pracujesz, jest zarabianie pieniędzy, a nie tworzenie kodu.

Jaydee
źródło
35
Dosyć. Częściowo z pragmatycznego punktu, że trzeba gdzieś zacząć, a częściowo z punktu reputacji, że jeśli uda ci się rozwiązać problem dla zespołu, chętniej wysłuchają innych sugestii. Pamiętaj również, że firma zarabiała pieniądze, zanim dotarłaś do niej istniejącymi metodami, więc to, co wprowadziłeś, musi zwiększyć zdolność firmy do zarabiania pieniędzy.
Jaydee
6
Akceptuję to, ale byłbym wdzięczny za podjęcie dalszych działań w celu zaradzenia ryzyku związanemu z tym zawodowo (np. „Moje CV zawierałoby więcej rzeczy, ale moja stara praca nie obejmowała zmian zbyt dobrze”)
WannabeCoder
4
@WannabeCoder - Musisz zacząć go używać, zanim osiągniesz biegłość. Nadal możesz wprowadzić kod do produkcji. Czasami kodowanie jest jak bycie lekarzem. Wszyscy wciąż ćwiczymy.
JeffO
5
Świetna odpowiedź. Powinieneś wdrażać te rzeczy tylko w celu rozwiązywania problemów, a nie wytwarzania problemów.
Kik
5
@WannabeCoder Ważne jest, aby zdać sobie sprawę, że żadna z tych metod nie została stworzona w próżni. Stają się szeroko rozpowszechnione, ponieważ pomagają rozwiązywać problemy . Jeśli spróbujesz je wdrożyć, a one nie pomogą rozwiązać problemów, przed którymi stoi Twój zespół, to nic nie osiągnąłeś i być może całkowicie nie zrozumiałeś i nadużyłeś praktyk. Jako programista powinieneś skupić się na rozwiązywaniu problemów w każdym działaniu. Poszukaj małych wygranych, w których wprowadzenie tych praktyk jeszcze trochę poprawi sytuację. Pomaga to zbudować argument za ich rozszerzeniem.
jpmc26
77

Jawa? Nowoczesny?! Nie udało ci się przy pierwszej przeszkodzie. Jeśli chcesz być naprawdę nowoczesny i unikać „profesjonalnego samobójstwa”, musisz pisać kod Rust. Oczywiście, w przyszłym tygodniu wszystko się zmieni i będziesz musiał nauczyć się czegoś nowego, aby nadążyć!

Albo, można przyjąć, że żadna ilość modne technologii lub metod lub ramami lub jakakolwiek inna du jour zmieni to faktu, że chcesz zbudować wysokiej jakości produktów, które działają. Nie ma znaczenia, czy nie użyjesz zwinnego, jeśli z powodzeniem produkujesz właściwe wyjście. Oczywiście, jeśli nie jesteś, możesz chcieć to zmienić, ale szanse na to, że żadna konkretna praktyka nie rozwiąże problemów. Pozostaną ludzkimi problemami, które można rozwiązać na wiele różnych sposobów.

Jeśli chodzi o profesjonalne samobójstwo, jeśli wiesz, co robisz i jesteś elastyczny, nie potrzebujesz żadnej z wymienionych przez ciebie rzeczy. Ludzie będą wymyślać nowe sposoby wykonywania starej pracy i zawsze będziesz nadrabiał zaległości. Lub możesz po prostu użyć dowolnych technik, z których korzysta Twoja obecna firma. Zmieniając firmę, po prostu uczysz się i używasz technik, których używają.

Zbyt wiele dzieci odkłada słuchawki na wszystkie nowe narzędzia, których mogłyby użyć, zapominając, że narzędzia te są bezwartościowe w rękach nowicjusza. Najpierw naucz się praktyki, gdy będziesz doświadczonym programistą, możesz zacząć „naprawiać” praktyki programistyczne za pomocą „fajnych nowych rzeczy”, ale do tego czasu masz nadzieję, że zdasz sobie sprawę, że nie są one tak ważne, jak myślisz obecnie, i do użycia tylko wtedy, gdy są naprawdę potrzebne.

gbjbaanb
źródło
4
Bardzo ładna odpowiedź (+1), szczególnie ostatni akapit. Bardzo nowoczesna książka (nowoczesna w tym sensie, że uważam ją za bardzo aktualną), którą ostatnio czytam, to SICP.
Giorgio
1
+1 za wzmiankę o tym, jak szybko te modne słowa i popularne języki się zmieniają. Dobry programista wprowadzający dobry kod przebija każdą metodologię. Rób to, co działa i działa dobrze!
WeRelic
2
Chociaż masz rację, że muszą one być właściwie stosowane, nie zgadzam się z twierdzeniem, że „nie są one tak ważne, jak się obecnie wydaje”. Okej, pewnie, może tak być w przypadku niektórych praktyk (jestem nieco sceptyczny wobec testów jednostkowych), ale inne są niezwykle cenne. Miałem okazję zacząć wcześnie robić dużo CI i automatyzacji oraz dobrze korzystać z kontroli źródła, a teraz pracuję nad projektem, w którym ich nie ma, widzę wszystkie problemy, które chcieliśmy rozwiązać w działaniu: błędy, niespójności , nikt nie wie, gdzie jest kod, działa. Te praktyki mają ogromną różnicę.
jpmc26
6
Nikt nie mówi „nie rozwiązuj problemów”, problem pojawia się, gdy wprowadzane są rozwiązania szukające problemów do rozwiązania. Nie są tak ważni, jak wielu myśli, kultyści uważają, że narzędzia są ważną częścią, ponieważ w rzeczywistości są tylko narzędziami. Liczy się lekarz i narzędzia, które działają w odpowiednich miejscach, są tymi, które należy wybrać. Chodzi mi o to, aby nigdy nie wybierać narzędzia tylko dlatego, że jest ono w przyborniku.
gbjbaanb
2
Głupiec z narzędziem wciąż jest głupcem.
Pete Becker,
40

Wiele firm utknęło w ten sposób; możesz być nawet zaskoczony, gdy zauważysz, że niektórzy z twoich kolegów programistów są samoukami i zostali programistami bez formalnego doświadczenia. Ci programiści są często lepsi w swojej pracy, ponieważ to oni będą zmuszeni do uczenia się nowych umiejętności i osiągania sukcesów, zamiast po prostu wykonywać tę pracę. Niestety może to również oznaczać, że chociaż są znakomici w programowaniu, mogą nie być świadomi korzyści płynących z tych praktyk. Faktem jest, że są to najlepsze praktyki, a nie powszechne praktyki. Najlepiej je wykorzystać, ale nie są one na wszystkich wymagań, aby odnieść sukces, są one po prostu narzędzia, które pomogą uczynić sukces łatwiejsze.

Masz absolutną rację, próba wdrożenia wszystkiego naraz będzie przytłaczająca. Prawdopodobnie spalisz się (a może i twój zespół) próbując to zrobić, co zdemotywuje przyszłe naciski na przyjęcie nowych metod / technologii. Najlepszą rzeczą w takiej sytuacji jest wybranie jednejrzecz (logowanie jest prawdopodobnie dobrym początkiem, ponieważ prawdopodobnie masz trudną drogę do znalezienia błędów bez logowania, a na pewno będą błędy) i porozmawiaj o tym z zespołem. Nie musisz tego samodzielnie wdrażać; znacznie lepiej porozmawiasz o zaletach i wadach zespołu (i swojego szefa, który absolutnie MUSI być na pokładzie czegoś takiego) i wymyślisz plan jego wdrożenia. Będzie to musiało być jak najbardziej bezbolesne (pamiętaj, mówisz ludziom, że oprócz tego, co już robią , muszą teraz napisać dodatkowy kod).

I pozwól, że powiem jeszcze raz, upewnij się, że twój szef się kupuje . To jest kluczowe; prawdopodobnie zauważysz, że szybkość poprawek / wydań spowalnia, gdy wdrażasz nowe rzeczy. Chodzi o to, że płacisz z góry, aby uratować linię; MUSZĄ to zrozumieć i być po twojej stronie. Jeśli nie weźmiesz ich na pokład, w najlepszym wypadku stoczysz przegraną bitwę, aw najgorszym przypadku mogą oni uznać cię za aktywnie sabotującego zespół (zapytaj mnie, skąd to wiem).

Gdy przyniesiesz te przedmioty do stołu, przedyskutuj je z zespołem, zaplanuj, jak je wdrożyć, i wykonaj kolejne, trzecie, ósme itd. Będzie łatwiejsze. Mało tego, zespół i twój szef mogą zyskać szacunek dla ciebie, ponieważ Twoje sugestie są wdrażane i uznawane za wartość dodaną. Wspaniały! Tylko upewnij się, że zachowujesz elastyczność: naciskasz tutaj na bezwładność, a zmiana nie jest łatwa. bądź przygotowany, by powoli robić małezmiany i upewnij się, że możesz śledzić postęp i uzyskaną wartość. Jeśli wdrożysz logowanie do nowego procesu i pomoże to zaoszczędzić godziny na znalezieniu błędu w ciągu trzech tygodni, zrób z tego wielką sprawę! Upewnij się, że wszyscy wiedzą, że firma właśnie zaoszczędziła XXX USD, robiąc to, co należy. Z drugiej strony, jeśli dostaniesz odpowiedź zwrotną lub masz napięty termin, nie próbuj wymuszać problemu. Pozwól nowej zmianie przesunąć się na chwilę i zawróć. Nigdy nie wygrasz, próbując zmusić zespół do zrobienia czegoś, czego nie chce robić, i możesz być pewien, że pierwszą rzeczą, którą zasugerują porzuceniu, jest nowa „dodatkowa” praca (np. Zapisywanie dziennika lub śledzenie poradnik stylów zamiast po prostu „uruchomić”).

DrewJordan
źródło
6
Wątpię, żebyś przez to wiele znaczył, ale trochę nie lubię gibów u takich deweloperów, jak ja, bez wykształcenia uniwersyteckiego. Moje doświadczenie (raczej niestety) było takie, że wykształcenie uniwersyteckie ma niewielką korelację z jakością programistów. Do tej pory w mojej karierze byłem jednym z tych, którzy opowiadają się za najlepszymi praktykami i wdrażają je. Twoja rada jest świetna.
djeikyb
5
Właściwie to miałem na myśli odwrotnie: OP byłby zaskoczony, ilu dobrych deweloperów jest tam bez formalnego wykształcenia. Wiele stanowisk technicznych otworzyło się w ciągu ostatnich 20/30 lat, które zostały obsadzone przez osoby chętne do nauki zamiast dzieci z dyplomem. A moje odkrycia odzwierciedlają twoje: doświadczenie jest zawsze lepsze niż edukacja. Dlatego OP musi zwalniać ... zbyt szybkie popychanie zespołu do przyjmowania nowych praktyk sprawi, że będą go urazić, a on nie będzie miał doświadczenia, by złagodzić te postawy. Należy również pamiętać, że niektóre zespoły nigdy nie będą korzystać z tych narzędzi; wtedy dostajesz nową pracę.
DrewJordan,
1
„Wiele firm utknęło w ten sposób; możesz być nawet zaskoczony, gdy zauważysz, że niektórzy z twoich„ programistów ”są samoukami i zostali programistami bez formalnego doświadczenia.” Często okazują się najcenniejszymi programistami ze względu na ich wiedzę specjalistyczną w dziedzinie.
pmf
Racja, całkowicie się zgadzam. Przeprojektowałem pierwszy akapit, aby brzmiał mniej protekcjonalnie. Chciałem tylko upewnić się, że OP wiedział, że spora część siły roboczej nie ma formalnego zaplecza. Zły wybór słów z mojej strony.
DrewJordan,
18

Mam nadzieję, że nie przedstawiliście problemów współpracownikom, tak jak nam to zrobili w swoim poście. TO byłoby profesjonalne samobójstwo.

Pierwszą kwestią jest to, że próbujesz uczyć technologii i metod, z którymi nawet nie masz doświadczenia, grupie programistów, które być może są trochę przestarzałe, ale wykonują zadanie. Możliwości tego odpalenia są nieograniczone i zapewne przyniosą wiele radości współpracownikom. Interesujące i godne podziwu jest to, że chcesz poprawić siebie i swój dział, ale unikaj używania terminów takich jak „spearheading”. Z poważaniem, nie używaj tego słowa.

Jako dodatkowy problem powyższego sprawdź, czy wykonujesz jakąś pracę . Od wielu lat pracuję jako samotny, samouczący się programista i wiem, jak łatwo jest odłożyć na bok rzeczywistą pracę w celu eksploracji obiecujących ram, technologii i tym podobnych. Upewnij się, że Twoje wyniki mieszczą się w oczekiwanych parametrach (nie, nikomu nie zależy na tym, że poświęcisz 20 godzin na badanie wiosny, jeśli raport, o który poprosili cię, nie został wykonany).

Z powyższego, unikaj bycia nauczycielem (chyba że jest to związane z dziedziną / technologią, w której faktycznie masz wystarczająco dużo doświadczenia). Bardziej neutralna prezentacja wskazywałaby na zalety, powiedzmy, zautomatyzowanego testowania i pozwoliłaby kierownictwu wybrać, kogo chcą zbadać zalety i wady tych praktyk.

Teraz, aby zaprezentować te „najlepsze praktyki”, istnieją dwa sposoby wyjaśnienia ich zespołowi:

  • Ponieważ mówię, że są to najlepsze praktyki i to wystarczy.
  • Ponieważ są przydatne i pomagają rozwiązać problem.

Używając pierwszego argumentu, chyba że jesteś szefem lub bardzo wysokim członkiem zespołu, jest mało prawdopodobne, aby zwrócili na ciebie uwagę. I „Czytam książkę Knutha, która tak mówi” lub „faceci z SE twierdzą, że” też nie wywrą wrażenia („ci faceci tutaj nie pracują, więc tak naprawdę nie wiedzą, co jest dobre dla tego sklepu IT” „). Mają swoje metody, procedury, procedury i „mniej więcej” działają, więc po co podejmować wysiłek i ryzykować zmianę?

Drugie podejście do pracy musi uświadomić sobie, że istnieje problem . Więc:

  • nie idź pchać dzień i noc dla automatycznych testów. Poczekaj, aż aktualizacja zepsuje niektóre funkcje, a zespół będzie musiał pracować w nadgodzinach, aby to naprawić, a następnie zaproponuje zbudowanie automatycznego systemu testowego.
  • nie pytaj o recenzje kodu. Poczekaj, aż Joe będzie na dłuższym urlopie i trzeba będzie zmienić ten moduł, o którym wie tylko Joe, i wskaż swojemu szefowi, ile czasu zostało stracone, próbując zrozumieć kod Joe.

Oczywiście zmiany będą powolne i postępujące (bardziej w dużej korporacji). Jeśli za pięć lat wprowadzisz przegląd kodu i automatyczne testowanie, powinieneś pogratulować dobrze wykonanej pracy. Ale, chyba że nastąpi całkowite przepisanie z przyczyn zewnętrznych, zapomnij o jakiejkolwiek fantazji, że zamieniają one rdzeń IS na powiedzmy Spring ( Joel wyjaśnił to o wiele lepiej niż kiedykolwiek, nawet zanim się urodziłeś 1 ); w tym czasie można było co najwyżej umieścić Spring na liście obsługiwanych platform do pisania niekrytycznych systemów.

Witaj w świecie IT dla przedsiębiorstw, chłopcze! :-p

1 : Ok, może trochę przesadzam, ale nie za dużo.

SJuan76
źródło
1
Przeważnie się nie zgadzam. Jedyny sposób, aby uzyskać jakąś zmianę w zespole, to jeśli ktoś jest skłonny przeprowadzić badania i przeciągnąć resztę. Oczywiście powinieneś pozostać produktywny, ale jeśli wszyscy utrzymają nisko głowę, staniesz się „trochę przestarzały, ale wykonasz pracę”. I całkowicie wypalony z nudów.
winkbrace
@winkbrace Nie twierdzę, że nie powinieneś próbować poprawiać (w rzeczywistości twierdzę inaczej). Jednak popychanie tych zmian bez wsparcia kierownictwa i bez uprawnień niektórych osób starszych może być dość trudne i wywołać pewien opór; dodaj do tego, że PO sam nie jest ekspertem i może mieć problemy z faktyczną realizacją. Byłoby miło, gdyby PO mógł zgłosić się na ochotnika do zespołu badawczego / prototypującego w celu właściwego wprowadzenia zmian; ale zabronił, aby ostrożnie wybrał właściwe podejście, aby je promować i być cierpliwym.
SJuan76
@winkbrace na nudę, to zależy od twojej osobowości i tego, czego szukasz w pracy. Rozsądnie jest spróbować znaleźć pracę na satysfakcjonującym cię stanowisku, zamiast iść gdziekolwiek i spróbować zmienić organizację według własnych upodobań. I zwykle duże korporacje (z wyjątkiem działów R&D) nie są miejscem dla ludzi, którzy lubią testować nową technologię co kilka miesięcy.
SJuan76
Trochę zawstydzone jest powiedzenie „upewnij się, że faktycznie wykonujesz pracę”. Pewnie, że powinieneś wykonać pracę, ale musisz także myśleć długoterminowo i każdego dnia powinieneś się poprawiać. Zajęło mi to 5 miesięcy, aby przekonać naszego menedżera do faktu, że testy jednostkowe pomagają nawet, gdy próbujemy kodować „szybko”. Ale musiałem wziąć 10 minut tu i tam co kilka dni, aby tak się stało.
Rudolf Olah
@omouse Podczas badania właśnie wskazywałam na ryzyko, które czasem mnie uderzyło. Z pewnością nie widzę tego ryzyka w opisywanej przez ciebie sytuacji, ale forma, w której OP opisuje swoje badania („najpierw zacząłem ... potem szybko się przeprowadziłem ...”) zmusiło mnie do dodania tej ostrożności. Zauważ, że nie twierdzę, że OP nie wykonuje należycie swojej przydzielonej pracy (to jest coś, czego po prostu nie wiem, i to jest jego szefowa), po prostu ostrzegam go, aby upewnić się, że nie zostanie zbyt pochłonięty .
SJuan76
12

Powinieneś zacząć od książki Efektywnie działający z kodem Legacy autorstwa Michaela Feathersa. Ze wstępu do książki: „Chodzi o przyjęcie splątanego, nieprzejrzystego, zwiniętego systemu i powoli, stopniowo, kawałek po kawałku, krok po kroku, przekształcając go w prosty, ładnie skonstruowany, dobrze zaprojektowany system”. Zaczyna głównie od automatycznego testowania, abyś mógł bezpiecznie refaktoryzować (będziesz wiedział, jeśli coś zepsujesz), a on zawiera wiele strategii wprowadzania trudnego kodu do automatycznego testowania. Jest to przydatne w przypadku każdego projektu, który jest jeszcze w fazie rozwoju. Po ustaleniu podstawowego porządku możesz zobaczyć, z jakich innych nowoczesnych technologii Twój projekt może skorzystać - ale nie zakładaj, że potrzebujesz ich wszystkich.

Jeśli chcesz nauczyć się nowego frameworka (lub czegoś takiego) z powodów zawodowych, a nie dlatego, że twój obecny projekt go naprawdę potrzebuje, powinieneś użyć go w jakimś osobistym projekcie (w swoim czasie).

użytkownik3067860
źródło
Zgadzam się z tematami w Efektywnej pracy ze starszym kodem, ale nie jest on zbyt kompaktowy. Weź to jako odniesienie i rzuć okiem na rozdziały, zamiast oczekiwać, że przeczytam je jak powieść.
Lukas
10

Kontrola źródła.

Nie wspomniałeś o tym, mam nadzieję, że jest już na miejscu, ale jeśli nie, zacznij od tego.

Kontrola źródła ma największą zaletę, z wyjątkiem rzadkich okoliczności patologicznie potrzebujących czegoś innego.

I możesz zacząć sam, jeśli początkowo nikt nie kupuje.

Emilio M. Bumachar
źródło
1
Największy huk za grosza przypomina raczej kilka ASSERTÓW we właściwych miejscach.
Peter Mortensen
@PeterMortensen Prawda, ale tylko wtedy, gdy wiesz, jakie są właściwe miejsca.
Emilio M Bumachar
Pobiłeś mnie do tego. Bez względu na to, w którym kierunku OP poprowadzi swój zespół, dotarcie tam z Git będzie znacznie łatwiejsze i bardziej produktywne niż bez niego.
dotancohen
6

Bezpośrednia odpowiedź

Inne odpowiedzi stanowią dobre „meta-punkty” na temat przyjmowania lepszych praktyk, ale tylko po to, aby dać ci bezpośrednio istotne wskazówki, oto przybliżone uporządkowanie najlepszych praktyk, które sugerowałbym Twojemu zespołowi (lub dowolnemu zespołowi) przyjęcie (po pierwsze):

  1. Kontrola źródła
  2. Śledzenie problemów (zarządzanie projektami i zadaniami)
  3. Zautomatyzowane kompilacje 1
  4. Zautomatyzowane wdrożenia

1 Bardzo pokrewną praktyką jest automatyzacja, a przynajmniej dokumentowanie , konfigurowanie środowiska kompilacji i rozwoju każdej aplikacji lub projektu oprogramowania, który tworzysz lub utrzymujesz. Jest to o wiele mniej przydatne, ponieważ (miejmy nadzieję) robisz to rzadko lub rzadko.

Wszystko inne

Wspominasz o kilku innych dobrych praktykach - „testowaniu jednostkowym, logowaniu, normalizacji bazy danych,… refaktoryzacji,… dokumentacji” - ale są to wszystkie praktyki, które można i należy stosować stopniowo i stopniowo. Żadne z nich nie musi być adoptowane naraz i prawdopodobnie lepiej w ogóle je adoptujesz, adoptując je ostrożnie i uważnie.

Cztery wymienione powyżej praktyki sprawią, że przyjęcie i eksperymentowanie z nowymi praktykami będzie tak proste, jak to możliwe. Na przykład testy jednostkowe można włączyć do zautomatyzowanych kompilacji, a dokumentację można opublikować jako część zautomatyzowanych wdrożeń.

Niektóre z innych praktyk, o których wspominasz - „zwinne programowanie,… przewodniki po stylach kodowania,… przeglądy kodu,… znormalizowane metody dokumentacji” i frameworki (np. Spring) - są naprawdę opcjonalne lub mają wątpliwą wartość. Dotyczy to wielu (większości?) Możliwych praktyk, które odkryjesz lub napotkasz.

Zwinne programowanie nie jest oczywiście lepsze niż jakakolwiek inna stosowana metodologia. I wiele osób (w tym ja) miało z tym okropne doświadczenia. Ale wielu ludzi też to lubi (lub uwielbia). Spróbuj!

Przewodniki stylu kodowania mogą być pomocne, szczególnie w przypadku dużych projektów lub w dużych zespołach, ale egzekwowanie tych wytycznych jest również bardzo pracochłonne i może to nie być najlepsze wykorzystanie czasu tego, kto to robi.

Bardzo pomocne mogą być również recenzje kodu - czy poprosiłeś współpracowników o sprawdzenie kodu? Pamiętaj, że nie potrzebujesz formalnego procesu wdrażania dobrych praktyk!

Dokumentacja jest świetna - czy w ogóle ją masz? Jeśli tak, to dobrze dla ciebie! Czy napotykasz wiele dodatkowej pracy, której można by zapobiec dzięki (bardziej) „znormalizowanej” dokumentacji? Jeśli tak, to prawdopodobnie warto to zrobić. Powiedzmy jednak, że jeśli twoje oprogramowanie jest używane przez niewielką grupę osób, możesz nie potrzebować żadnej dokumentacji. (Lub możesz bezpośrednio dołączyć dokumentację do swojego oprogramowania. To zawsze moja preferencja.)

Ramy są ... (bardzo ostrym) obosiecznym mieczem. Ładnie zamknięte i dobrze utrzymane rozwiązanie dla nie-podstawowej funkcji oprogramowania jest świetne ... dopóki tak nie jest. Nie jestem pewien, czym dokładnie są „ręcznie napisane kontrolery frontowe”, ale nie ma oczywistego wyjaśnienia, dlaczego są gorsze od kodu wykorzystującego Spring. Czy zastanawiałeś się nad zawarciem wspólnej logiki we wszystkich tych kontrolerach we własnej strukturze wewnętrznej? Przyjęcie Spring i przepisanie całego istniejącego kodu może być ogromnym projektem refaktoryzacji (lub, co bardziej prawdopodobne, przepisaniem), i może nie być najlepszą zmianą, jaką możesz wprowadzić w kodzie . Oczywiście nie powinieneś pisać całego używanego oprogramowania - frameworki (i biblioteki) są świetne!Ale może nie musisz używać Spring (lub alternatywy) do pisania świetnych (lub dobrych) aplikacji internetowych.

Kenny Evitt
źródło
Umieściłbym tam automatyczne testy regresji z automatyczną kompilacją i wdrożeniem. Ma również tę zaletę, że jest to coś, nad czym można stopniowo pracować.
sdenham
Testy jednostkowe powinny być najpierw, zaczynając od ręcznego uruchamiania zawsze lokalnie (lub przy każdym kasie / meldowaniu), a następnie zachęć resztę zespołu do zakupu zautomatyzowanych testów regresji. Naprawdę istnieją deweloperzy, którzy z jakiegoś powodu boją się ciągle przeprowadzać testy.
Rudolf Olah
5

Rozejrzyj się wokół zespołu, którego jesteś częścią. Czy widzisz jakieś dowody na to, że rozwój oparty na testach lub normalizacja baz danych poprawi jakość pisanego oprogramowania lub zwiększy produktywność ludzi?

Czy próbowałeś porozmawiać o tym z jednym z kierowników ds. Rozwoju lub kierownikiem ds. Rozwoju? Naprawdę nieformalny czat byłby dobrym początkiem. Co sprawia, że ​​myślisz, że ludzie powyżej ciebie nie mieli takich samych pomysłów, ale nie mogą / nie będą ich wdrażać, ponieważ firma na to nie pozwoli?

Uważam, że dobrym przykładem jest dawanie przykładu. Ludzie są znacznie mniej odporni, jeśli ktoś już wykonał pracę i może im pokazać, jak ją powielić. Wprowadź TDD do projektu, nad którym pracujesz. Poproś o prezentację dla reszty zespołu, a nawet kilku innych i pokaż im, co zrobiłeś. To, co @DrewJordan powiedział o uzyskaniu wpisu od szefa, jest ważniejsze, niż się zapewne zdajesz.

markp3rry
źródło
5

Znajdź wadę. Napraw błąd. Pokaż poprawkę.

Najpierw weźmy normalizację *. I rzeczywiście, sugerowałbym, abyś wziął to najpierw, ponieważ brak normalizacji może skutkować faktycznymi błędnymi danymi, które inaczej nie istniałyby, podczas gdy pozostałe to przypadki, w których najlepsza praktyka mogłaby pomóc, ale trudniej powiedzieć „Bug” Przyczyną było nieprzestrzeganie zasady X ”. Jeśli masz bazę danych, która nie jest znormalizowana, masz miejsce, w którym dane mogą być niespójne.

To dobry zakład, że będziesz w stanie znaleźć rzeczywisty przypadek niespójnych danych. Znalazłeś teraz dwie rzeczy:

  1. Błąd w Twoich danych.

  2. Błąd w schematach bazy danych.

Właściwie najpierw wiedziałeś o drugim błędzie, ale pierwszy jest łatwiejszy do wykazania, a także coś, co powoduje prawdziwy problem, a nie coś, co teoretycznie mogłoby.

Niestety jedną z prawdziwych przyczyn oporu wobec normalizacji zdenormalizowanej bazy danych jest to, że pytanie, co zrobić z takimi błędnymi danymi, nie zawsze jest łatwe, ale znajdziesz prawdziwy błąd.

(Pamiętaj jednak, że istnieją powody, dla których czasami celowo można zdenormalizować niektóre dane. Nie myl świadomego łamania reguły z nieznajomością reguły; jeśli znormalizujesz tabelę celowo zdormalizowaną pod kątem szybkości wyszukiwania, wygrałeś nie zdobywaj żadnych pochwał. Nawet tutaj denormalizacja bycia obarczonym jest czymś, co powinno być zrobione proceduralnie, więc jeśli zdormalizowana tabela nie jest tworzona automatycznie na podstawie zawartości znormalizowanych tabel, nadal jest wiele do zrobienia).

Jeśli chodzi o resztę, przedstaw je, gdy pomagają w perspektywie krótkoterminowej, aby później je wykorzystać w perspektywie długoterminowej. Np. Jeśli otrzymasz mały fragment kodu do napisania, napisz dla niego test jednostkowy. Co więcej, jeśli otrzymasz błąd do naprawienia, napisz test jednostkowy, który nie powiedzie się z powodu błędu, a następnie, gdy naprawisz błąd, wspomnij o tym, że przechodzi on po zamknięciu błędów (lub wyślij e-mail z informacją, że został naprawiony , lub cokolwiek).

* Nawiasem mówiąc, niezbyt nowoczesny. Powodem, dla którego nazywa się to normalizacją, a nie normalizacją lub czymś innym, jest to, że w tamtym czasie był to aktualny żart polegający na przyklejeniu do końca rzeczy, aby wyśmiewać nazwę polityki wietnamskiej Richarda Nixona .

Jon Hanna
źródło
4

Mam zamiar pójść na całość i powiedzieć: znajdź nową pracę po tym, jak spędzę trochę czasu w tym miejscu, aby trochę zbudować swoje CV. Celuj przez około rok. Chociaż wiele rzeczy to „modne słowa”, problemy takie jak całkowity brak testów jednostkowych są trudne do rozwiązania dla pojedynczego programisty, i są szanse, że jeśli programiści tam pracujący nie będą chcieli testować, nigdy nie dostaniesz zakupu, a może nawet zagrozić twojej pozycji w firmie, sprawiając, że ludzie myślą o tobie jak o twardej krwi. Musisz być w miejscu, w którym możesz uzyskać mentoring, a nie próbować popychać kulturę do podstawowych kompetencji.

asthasr
źródło
3
Właśnie to zrobiłem. Był tylko jeden raz (z ~ 5 prób w różnych miejscach), kiedy z powodzeniem wprowadziłem nową „dobrą praktykę” lub dokonałem znaczącej zmiany w istniejących praktykach, i wtedy zespół był świeży i większość projektów zaczęliśmy od zera . We wszystkich innych przypadkach dobre praktyki były albo wprowadzane z góry (kierownicy zespołu), albo po prostu zawiodły, ponieważ nikt inny nie uczestniczył. Wierzę, że wszystko sprowadza się do zdolności do wymuszenia decyzji przez bycie liderem / szefem.
scriptin
1

Było wiele propozycji ulepszenia paradygmatu programowania . Najgorętsze modne słowa wydają się teraz zwinne i zorientowane obiektowo. Albo czy oni? Oba zniknęły znacznie w porównaniu z tym, czym były zaledwie pięć lat temu.

Możesz być całkiem pewny, że każda zastosowana metodologia stara się osiągnąć ten sam rezultat końcowy: pomóc inżynierom w ekonomicznym wytwarzaniu produktu końcowego, który jest wystarczająco dobry.

Jest jeden paradygmat, który został kontrowersyjnie wprowadzony w 1960 roku: Programowanie strukturalne : używać tylko „wysoki poziom” konstruuje jak while, for, repeat, if/ then/ else, switch/ caseoświadczenia zamiast silnie stosowanego gotooświadczenia, które zostały zaakceptowane przez domyślnie. Nadal trwają debaty na temat tego, czy gotoma jakiekolwiek uzasadnione zastosowanie.

Przyjmuję do wiadomości, że minimalizowanie użycia gotojest dobrą rzeczą, ale podobnie jak wszystkie dobre rzeczy, można posunąć się za daleko.

Wspominasz agilemetodologie jako coś pozytywnego. Przez około sześć miesięcy pracowałem w jednym zespole programistów, który celowo przestrzegał przepisanego schematu zwinnego. Odkryłem, że jest to tak samo jak światłe metodologie zarządzania projektami sprzed dziesięcioleci, tyle że wszystko zmienia nazwę. Być może poprzez ponowne pakowanie i odsprzedaż pomysłów na komunikację z kimś zarabia na życie, a firmy mogą czuć się dobrze, widząc nowe ubrania cesarza .

Najcenniejszą lekcją Agile, znaną dawno temu, jest to, że elastyczność w znalezieniu lepszej ścieżki do gotowego produktu jest dobrą rzeczą, a możliwość znalezienia tej ścieżki może pochodzić od każdego - nie tylko od wyższej kadry kierowniczej.


Z pisma przywódcy anty-goto Edsgera Dijkstry:

Sztuka programowania to sztuka organizowania złożoności, opanowywania mnóstwa i unikania chaotycznego chaosu tak skutecznie, jak to możliwe.

—Dijkstra, w: Dahl, Dijkstra i Hoare 1972, str. 6. (patrz strona 6 tutaj .)

wallyk
źródło