Jak przekonwertować program do kopiowania / wklejania / spaghetti, aby zobaczyć światło?

35

To pytanie zostało zainspirowane tym . Chociaż to drugie pytanie zostało uznane za zlokalizowane, uważam, że podstawowy problem jest czymś niezwykle powszechnym w naszej branży. Wiem, że są programiści, którzy to przeczytają i pomyślą, że to wymyślam, a następnie mogą odpowiedzieć, że wszyscy troszczą się o swoją pracę i chcą się uczyć, ale tylko patrząc na inne posty programistów SE ( przypadek ), Wiem, że to nie jest prawda.

Powiedzmy, że masz kogoś w zespole (a może większość), którego standardową procedurą jest kopiowanie / wklejanie i kto wierzy, że wszystko można rozwiązać, jeśli tylko dodasz wystarczającą liczbę wywołań funkcji i zmiennych. Ta osoba nigdy nie słyszała o TDD, SUCHYM lub SOLIDNYM, a poza 40 godzinami pracy, kiedy jest zajęta pracą, nigdy nie czytała ani jednej metodologii / praktyk / książki projektowej.

W przeszłości ja (i inni) pytałem, jak uczyć OOD . Ale teraz myślę, że to nie jest właściwe pytanie. Prawdziwe pytanie brzmi: w jaki sposób podchodzisz do takiej osoby / zespołu i sprawiasz, że ciekawi ich lepszy sposób działania? Jak inspirujesz ich do nauki? Bez tego wydaje się, że wszystkie nauczanie, spotkania, wykłady, dyskusje są bezużyteczne, jeśli są całkowicie szczęśliwi, wracając do biurka i robiąc to, co zawsze robili.

Pracuję z taką grupą ludzi. W rzeczywistości są to dość bystre osoby, ale nienawidzę, gdy słyszę: „Skończyłem kodowanie, wystarczy zrefaktoryzować i podzielić na wiele klas, aby uszczęśliwić DXM”. Nie refaktoryzują czystszego, czytelnego, łatwego do utrzymania kodu, ale tylko dlatego, że w przeciwnym razie zostaną skarceni. Wiem, że są w stanie się uczyć, wydaje się, że ogólny brak motywacji.

Kiedy dostarczam pracę, generalnie ma o wiele mniej błędów, a praca, którą posiadam, nigdy nie stała się potwornością 5000 linii. Inni komentowaliby: „Twój kod jest znacznie bardziej przejrzysty i czytelny niż nasze”, więc widzą różnicę. Ale jednocześnie czuję, że wierzą, że zarabiają 40 godzin bez względu na to, co robią, więc nie mają nic przeciwko temu, że spędzą 3 pełne dni na kontroli jakości, szukając błędu, którego nie powinien był wprowadzić pierwsze miejsce. Lub że modyfikacja jednej klasy zajmuje tydzień, ponieważ istnieje tak wiele zależności, że w końcu się dotykają. Jednak „może ta klasa powinna być napisana inaczej” nigdy nie wyskakuje.

Czy można coś zrobić w takich sytuacjach? Czy komuś się udało? A może najlepiej jest odizolować taki sposób myślenia od niekrytycznych części projektu i zminimalizować szkody?

UWAGA: Kiedy mówię „brak motywacji”. Nie sądzę, żeby brakowało motywacji do pracy lub dobrej pracy, ponieważ po prostu przestali się przejmować. Większość naszego zespołu jest wręcz przeciwnie. Z pewnością dbają o produkt. Mamy facetów, którzy będą pracować nocami i weekendami. Część, przez którą próbuję przejść, to ulepszone nawyki i umiejętności, w rzeczywistości nie musieliby tyle pracować. Wydaje mi się, że dzięki „40 godzinom” ten post brzmiał trochę zbyt negatywnie.

DXM
źródło
Co to za kraj?
3
@ ThorbjørnRavnAndersen - USA. teraz musisz napisać odpowiedź, ponieważ jestem bardzo ciekawy, jak wpłynęła na to ta informacja :) Zawsze myślałem, że wszyscy jesteśmy ludźmi, a tego typu rzeczy były uniwersalne. I nie, to pytanie nie ma nic wspólnego z outsourcingiem.
DXM,
8
Różnice kulturowe między krajami mogą być znaczne i każda próba wprowadzenia zmian musi to uwzględnić. To, co działa w jednej kulturze, najprawdopodobniej nie zadziała w innej. W twoim przypadku uważam, że najlepszym sposobem jest oficjalne podniesienie przez kierownictwo poprzeczki tego, co jest dopuszczalne.

Odpowiedzi:

18

Znalazłeś sam powód: „Wiem, że są w stanie się uczyć, wydaje się, że istnieje ogólny brak motywacji”.

Są ludzie, którzy są pasjonatami swojej pracy. Są też inni, którzy czasami będąc wystarczająco kompetentni, pracują tylko dla pieniędzy . Znają się na rzeczy, ale nie lubią swojej pracy. Nie będą poświęcać dodatkowego czasu na dodatkowe refaktoryzowanie, aby kod był czytelny lub rozwiązywanie intrygującego problemu, gdy szybki i brzydki hack może wykonać zadanie.

Zjawisko to występuje w każdej pracy. Po prostu niektóre prace nie są wyjątkowo ekscytujące (czy widziałeś księgowego, który kocha swoją pracę i marzył o niej już jako dziecko?), Ale w programowaniu jest mnóstwo ludzi, którzy naprawdę kochają to, co robią (w przeciwnym razie Programmers.SE będzie całkiem pusty). Oznacza to, że jako namiętni programiści, którzy codziennie rozmawiają z innymi namiętnymi programistami, mamy większe szanse na zdziwienie widząc osobę, która programuje tylko dla pieniędzy.

Co możemy zrobić? Nie za dużo. We wszystkich przypadkach to nie do ciebie, ale do zasobów ludzkich wybierasz ludzi, którzy są naprawdę zmotywowani¹. I zwalniaj ludzi, którzy nie są.

Możesz spróbować zmotywować swoich kolegów, ale jest to niezwykle trudne. Jeśli dasz im książki do przeczytania, zwrócą je nieotwarte kilka tygodni później. Jeśli dasz im radę, nie będą słuchać, ponieważ ich to nie obchodzi².

Możesz:

  • Przekonuj swojego szefa, aby ustanowił w firmie szereg ścisłych zasad: wytyczne dotyczące stylu itp. Nie zmotywuje to tych ludzi do lepszej pracy, ale przynajmniej nie będzie w stanie zatwierdzić kodu źródłowego, który nie spełnia wymagań .

  • Pracuj nad wymaganiami, zwłaszcza wymaganiami niefunkcjonalnymi . Co z wymogiem, który mówi, że konkretny projekt musi zawierać mniej niż 5000 wierszy kodu IL (nie, nie mówię o bezsensownym LOC ) ³? Co z wymogiem uzyskania określonych wyników przy cykliczności złożoności lub sprzężeniu klas ?

  • Zwiększ liczbę godzin spędzanych w firmie na recenzowaniu kodu . Określ, co jest recenzowane: jeśli masz listę kontrolną, dodaj punkty związane z refaktoryzacją, czytelnością, czystymi i przydatnymi komentarzami itp. Jeśli nie masz listy kontrolnej, musisz.

  • Użyj [więcej] programowania par . Może to pomóc poprawić jakość kodu i zmotywować mniej zmotywowanych współpracowników.

  • Użyj systemu kompensacji podobnego do tego, który jest używany w Fog Creek.


¹ O to właśnie chodzi w rozmowach kwalifikacyjnych: przed zatrudnieniem zasoby ludzkie muszą zaspokoić nie tylko poziom techniczny, ale także motywację . Niestety niektóre firmy zapominają o drugiej części wywiadu i zatrudniają ludzi, którzy nie lubią programować zbytnio. Na szczęście w większości przypadków praca w tych firmach nigdy nie jest przyjemna, a test Joela rzadko przekracza 2.

² Naprawdę ich to nie obchodzi, nawet jeśli zarabiają mniej pieniędzy. Jestem bardzo blisko jednego z moich klientów (jestem freelancerem), który uważa, że jego praca polega na tworzeniu stron internetowych dla własnych klientów. Ma także projektanta. Wiele razy opowiadałem im o sposobach zwiększenia produktywności o 2 lub więcej. Gdyby po prostu zatrudnili kogoś kompetentnego, zwiększyliby swoje przychody o co najmniej 3. Ale mają wystarczająco dużo pieniędzy i nie dbają o jakość ani o ile kosztują nieświadomych klientów w porównaniu z kimś produktywnym.

³ Mam na myśli liczbę wierszy kodu IL widoczną w Code Metrics w Visual Studio , metrykę, która faktycznie coś znaczy. Prawdziwy LOC nie ma znaczenia i nie trzeba go mierzyć; to jedna z najgłupszych miar w historii. Egzekwowanie wierszy kodu IL oznacza, że ​​programiści będą zmuszeni do faktoryzacji kodu, a nie tylko do zwinięcia dziesięciu wierszy kodu w jednym nieczytelnym wierszu.

Arseni Mourzenko
źródło
3
Nie zgadzam się: Motywacja do pracy i motywacja do nauki to dwie całkowicie odrębne rzeczy. Na przykład, niektórzy ludzie uwielbiają swoją pracę i pracę, ale mogą myśleć, że „SOLID” to po prostu inne bzdurowe hasło „TDD” lub „TDD” to jakaś koncepcja wieży z kości słoniowej, bezużyteczna w świecie rzeczywistym.
nikie
5
@maple_shaft ma rację: niektórzy pracują 70 godzin tygodniowo i produkują najgorszą ilość kodu spaghetti bez żadnych testów (nie mają czasu na takie bzdury!). Chociaż są pasjonatami i ciągle doskonalą swoje umiejętności, ale wracają do domu po 40 godzinach, ponieważ wiedzą, że i tak nie mogą dłużej być produktywni. Nie pomieszaj tych dwóch rzeczy!
nikie
13
Nie nie nie. Gotowość do wykorzystania przez pracodawcę! = Umiejętność tworzenia kodu jakości. Jest o wiele za dużo tego „zostań do 2 w nocy, żeby to zrobić”, bzdury, które zdarzają się już w naszej branży, bez pogodzenia tego z jakimś mitycznym Idealnym Deweloperem. Jeśli lubisz pracować przez 80 godzin tygodniowo, masz dla ciebie więcej mocy. Mam rzeczy, które są dla mnie ważne oprócz pracy. Podsumowując, jestem zły w tym, co robię, ponieważ jest to w najlepszym razie fałszywe. Żadna inna branża nie unika tego, co nasze, i to zależy od nas, jeśli to się zmieni.
Dan Ray
6
Konieczność pracy do 2 nad ranem, aby pracować nad projektem, jest bardzo skutecznym sposobem na zabicie jakiejkolwiek miłości do tego projektu, szczególnie dla osób mających obowiązki rodzinne.
2
Myślę, że wszystkie przedstawione tutaj uwagi są prawidłowe, ale niektórzy z was mogli źle zrozumieć MainMa. Nigdy nie powiedział pracy do drugiej w nocy, ponieważ jesteś zmuszony z powodu terminów. Zamiast tego odniósł się po prostu do ludzi, którzy tak bardzo pochłonięci są podekscytowaniem widząc, że coś działa, że ​​czasem wolą to zrobić niż iść spać. Mogę się z tym odnosić. Dla mnie jednym ekstremalnym przykładem było zadanie, nad którym pracowałem, aby dodać obsługę tunelowania do naszej biblioteki przesyłania strumieniowego wideo. Szacowano na 5 dni, ale dzięki naszej nowej architekturze rurociągów wszystko układało się tak dobrze, że zacząłem w piątek po południu ...
DXM,
12

„Skończyłem kodowanie, wystarczy zrefaktoryzować i podzielić na wiele klas, aby uszczęśliwić DXM”.

Ten sposób myślenia jest rakiem w każdej drużynie i zabije motywację całego zespołu, jeśli nie zostanie natychmiast załatwiony. Mówię oczywiście o tym, że ze względu na staż pracy i / lub zasługi jesteś na stanowisku władzy technicznej, co daje ci siłę, aby wpływać i wprowadzać dobre praktyki w zespole.

To wszystko dobrze i dobrze, jednak gdyby twój zespół został wyraźnie sprzedany w ramach tych procesów, nie wyróżnialiby cię w takich oświadczeniach, które wyraźnie pokazują brak szacunku dla procesu i brak szacunku w tobie. Nadal postrzegają te najlepsze praktyki jako przeszkodę spowodowaną przez ciebie, a nie proces będący własnością zespołu, którego twój zespół będzie bronił według własnych zasług.

Wspomniałeś w poprzednich komentarzach, że inni członkowie zespołu rzeczywiście przestrzegają tych praktyk i standardów i stosują je prawidłowo. Najpierw skoncentruj się na wspieraniu ich, zapytaj, co działa, co nie działa, co im się podoba i co chcieliby zmienić. Jeśli to zrobisz i poważnie podchodzisz do ich opinii, będą oni postrzegać standardy zupełnie inaczej, jakby to była decyzja społeczności, a nie procedura przekazana im przez przełożonego.

Wspierasz wsparcie najlepszych praktyk i standardów, wskazując zespołowi, w jaki sposób poprawili proces tworzenia oprogramowania lub jego jakość.

Oddaj głos w sprawie do dyskusji i udokumentuj wyniki, najlepiej każda decyzja powinna być jednomyślna ze względu na legalność, ale jeśli masz do czynienia z twardymi przeszkodami, może to być niemożliwe i może po prostu zablokować każdą kwestię. W takiej sytuacji użyj większości głosów. Jeśli większość jest przeciwna twoim proponowanym standardom i praktykom, oznacza to, że już straciłeś pokój, po prostu zrezygnuj w tym momencie.

Będą właścicielami tych standardów i procedur i będą je egzekwować , abyś nie musiał. Jako lider technologiczny nie powinieneś ogłaszać dekretów i dekretów, to zły sposób na bycie liderem.

Gdy zespół poczuje się, jakby był właścicielem procedur, członkowie zespołu, którzy zaczną przypisywać ci określone procedury i najlepsze praktyki, uznają to za nieuprawnione. Twój zespół pomoże poprawić to nastawienie u innych.

wałek klonowy
źródło
1
+1 za nacisk na
skupianie
5

Dobre pytanie! Myślę, że odpowiedź zależy od tego, dlaczego ludzie nie chcą doskonalić swoich umiejętności. Możliwe odpowiedzi to:

  • Myślą, że są zbyt zajęci, aby nauczyć się czegoś nowego lub myślą, że nowy sposób robienia rzeczy (np. Pisanie wszystkich tych testów) zajmie im to dłużej i nie mają na to czasu. Wtedy oczywistą odpowiedzią byłoby: dać im więcej czasu. Uczenie się czegoś lub próbowanie czegoś takiego jak TDD, kiedy zawsze robiłeś coś inaczej , zajmie więcej czasu za pierwszym razem. Jeśli twoi programiści nie mają tego czasu, nie możesz ich winić za to, że nie próbowali.
  • Mają odmienne zdanie na temat własnych umiejętności, tzn. Myślą, że są bardzo dobrymi programistami produkującymi wysokiej jakości kod. To trudny teren psychologiczny, ponieważ zniszczenie tego przekonania może być bardzo demotywujące. Może może pomóc nieformalna konkurencja (kto produkuje najmniej wad / funkcji? Najkrótszy kod? Najmniej WTF / minutę w przeglądzie kodu?).
  • Może istnieć faktyczny problem z motywacją (tzn. Po prostu chcą „poświęcić czas i zostawić się w spokoju” do czasu zamknięcia). Na szczęście jest to zbyt ogólne / niezwiązane z programowaniem, ponieważ tak naprawdę nie mam na to odpowiedzi.
  • Są początkujący i nie wiedzą lepiej. W takim przypadku pomocne mogą być szkolenia, recenzje kodu lub „klub książki”, w którym członek zespołu musi co miesiąc omawiać nową książkę techniczną.
  • Widzieli już srebrne kule (i byli bardzo rozczarowani) i myślą, że cokolwiek próbujesz sprzedać, to tylko nowe modne hasło, które brzmi dobrze w teorii i jest mało przydatne w praktyce. W takim przypadku wykazanie zalet podczas przeglądów kodu i sesji programowania par może być skuteczne. Staraj się nie być całkowicie wszechwiedzącym, kiedy to robisz.

Najlepsze rozwiązanie naprawdę zależy od głównego problemu: na przykład formalne wytyczne dotyczące kodowania, metryki i recenzje mogą działać dla początkujących, ale ludzie w „złym postrzeganiu własnych umiejętności” - ludzie mogą walczyć z nimi lub grać w metrykę, ponieważ widzą jako negatywne biurokratyczne przeszkody w wykonywaniu ich pracy.

nikie
źródło
Słuszne uwagi. Szczególnie podoba mi się ten pierwszy - i nawet uogólniam: najpierw musisz wyjaśnić, że nauka w pracy jest zachęcana i że można wyraźnie na to poświęcić czas.
sleske
Jeśli ludzie mają odmienne zdanie na temat swoich umiejętności, może mierzą sukces w różnych parametrach? Jeśli mierzysz jakość kodu i zastanawiają się, jak szybko można go utworzyć, oczywiście wynik będzie inny - w takich przypadkach należy zapytać, w jaki sposób mierzą sukces. Różni ludzie mają różne sposoby myślenia o tym.
tp1,
3

Prawdziwe pytanie brzmi: w jaki sposób podchodzisz do takiej osoby / zespołu i sprawiasz, że ciekawi ich lepszy sposób działania? Jak inspirujesz ich do nauki? Bez tego wydaje się, że wszystkie nauczanie, spotkania, wykłady, dyskusje są bezużyteczne, jeśli są całkowicie szczęśliwi, wracając do biurka i robiąc to, co zawsze robili.

To jest to! To rzeczywiście prawdziwe pytanie.

Żeby dać trochę otuchy, po prostu nie mamy czasu na wiele formalnych szkoleń - ale czasami, jeśli to zrobię - nadal nie widzę światła. Należę również do firm, w których formalne szkolenie staje się procesem, ale i tak często jestem świadkiem, że ledwo uczą ich myślenia.

Pytanie, które zadaję im, nie polega na tym, jak ich uczyć - ale jak sprawić, by się uczyły? Różnica jest subtelna, ale to właśnie ją zmieni.

Nie wiem czy mam rację; ale często wierzę w okno dialogowe filmu Matrix - „To pytanie nas napędza!” Najważniejsze jest, aby zmusili ich do myślenia, aby zapytali dlaczego! I oczywiście większość osób, które myślą, że już wiedzą wszystko o niektórych wzorach projektowych, ponieważ uzyskały dobre oceny na studiach uniwersyteckich - są tam najtrudniejsze.

Jak możesz zadać im takie pytania? Moje ogólne podejście brzmi: „wrzucają je do stawu, jeśli chcesz, żeby nauczyły się pływać” . Zgadzam się, że ludzie mogą się nie zgadzać; i chętnie się z nimi nie zgadzam. Kiedy wrzucasz je do stawu - tak naprawdę nie uczą się pływać automatycznie; ale pobudza instynkt przetrwania, który skłania ich do myślenia - kiedy to nastąpi, naturalnie pomyślą, JAK i DLACZEGO.

Praktycznym przykładem, który daję ludziom, jest zaangażowanie ich w znacznie bardziej skomplikowany projekt niż to, na co liczyli, aby wziąć go w swoje ręce i pozwolić im stoczyć własną bitwę. Gdy zaczęli rozwikłać kod i trudno go prześledzić - zdajesz sobie sprawę, że zaczynają zadawać dobre pytania.

Może to zabrzmieć nieco ekstremistycznie, może to oznaczać marnowanie zasobów . I jestem pewien, że jest wielu innych, którzy udzielą mi rady, aby tego nie robić. Ale to zadziałało dla mnie!

Bez względu na to, jakie pakiety wynagrodzeń i tagi HR przypisujesz, nie rozwiąże to podstawowego problemu motywacyjnego . Bo ta jedyna droga polega na tym, że są kwestionowani; Jeśli iskrzysz w tym podstawowym ludzkim duchu - wszystko inne działa. Jeśli nie możesz, to luźna, luźna gra.

PS: Tak na marginesie, opublikowałem tutaj odpowiedź https://softwareengineering.stackexchange.com/questions/127021/how-do-you-train-freshers/127034 - i dostałem całe bzdury; przede wszystkim większość ludzi uważa, że ​​firmy nie mogą sobie pozwolić na marnowanie zasobów! Jestem pewien, że ta odpowiedź może zostać potraktowana podobnie. Ale prawda jest taka, że ​​zmuszanie ludzi do pracy i przekonanie ich, że wykonują dobrą pracę, jest przedmiotem psychologii człowieka w kwestii tego, jak stworzyć program kursu.

W każdym razie zadanie, które tutaj opisujesz, sprowadza się do rozpalenia wewnętrznej pasji dokonywania wielkich zmian. A większy system staje się trudniejszy. Rozpocznij od młodszych ludzi, którzy nadal mają ducha „ nie będę robić dobrze”, i rzuć wyzwanie status quo.

Dipan Mehta
źródło
dzięki za przywołanie matrycy, teraz muszę spędzić 2 godziny życia, oglądając ją ponownie :) To zabawne, ale odkryłem, że „odświeżacze” to te, które pochłoną wszystko, co na nie rzucisz. Będąc absolwentem dobrego programu CS, jasno wyjaśniam, co myślę o ich „edukacji” i w większości się ze mną zgadzają. Uważam, że największymi problemami są faceci, którzy robili to od 10, 15, 20+ lat. Zgadzam się również z podejściem opartym na „próbie ognia”. Właśnie tak nauczyłem się, czego nie robić. Problem polega na tym, że a) zajmuje dużo czasu, na które większość zespołów nie może sobie pozwolić, oraz b) podczas pracy w zespole ...
DXM,
.. ustawienie (odważę się powiedzieć „częściowo zwinny”, nie nienawidź mnie S.Lott :)), nie mamy wyłącznej własności, czego wymaga próba ognia. Jeśli napiszą coś, co się nie powiedzie, ktoś wkroczy i to naprawi. Jako ktoś, kto był w stawie i w większości go zrozumiał, chciałbym pomyśleć. Byłem ciekawy, czy można coś zrobić, aby przenieść ten sposób myślenia bez konieczności przepuszczania całego zespołu przez staw.
DXM,
@DXM Zgadzam się z twoimi obawami, że lepiej nie rzucać całego zespołu na raz. Tak. Chodzi o to, aby zacząć rzucać niektóre z nich jeden po drugim! Przynajmniej jest to dobra umowa między nami. Myślę, że sposób myślenia, który wyrósł przez wiele lat - zajmie trochę czasu i wytrwałości, aby się zmienić.
Dipan Mehta
@DXM, aby dać Ci więcej konkretów - wypróbuj małe inicjatywy na raz - pokaż przypadek osiągnięć i pokaż, że zarządzanie oznacza biznes dla wykonywania dobrej pracy tutaj. I promuj zestaw umysłów - krok po kroku. wytrwałość byłaby koniecznością, ale osiągnąłem coś takiego w mojej ostatniej firmie. Z czasem kierownictwo podawało mojemu zespołowi jako przykład tego, jak zrobić to dobrze.
Dipan Mehta
1
Podoba mi się twoja odpowiedź, szczególnie jeśli to działa dla ciebie, dlatego poniższe stwierdzenie nie jest krytyką, ale tylko notatką: niestety nie zawsze tak jest. Miałem kilka przypadków, w których niemotywowani programiści rozpoczęli duże projekty. Za każdym razem kończyło się to samo: projekt nie powiódł się, a oni obwinili kierownictwo lub ich współpracowników lub fakt, że nie było wystarczająco dużo czasu lub zasobów lub że wymagania nie były wystarczająco jasne. Zastanawiam się, jaka jest różnica między tymi, którzy nauczą się pływać, a tymi, którzy prawdopodobnie obwinią wodę.
Arseni Mourzenko
2

Jak zauważyłeś, jego motywacja. Nie myl ich, nie troszcząc się o niewiedzę. Oni wyraźnie wiedzą, co robić. Po prostu ich to nie obchodzi . Jeśli tak, to prawdziwe pytanie brzmi ... co robi twoje kierownictwo źle, co sprawia, że ​​są tak niemotywowani? Czy jesteś najnowszym członkiem zespołu? Być może już to wszystko przeszli, ponieważ prowadziło to tylko do problemów z zarządzaniem. Więc po prostu trzymają się najmniejszej ilości pracy potrzebnej do utrzymania ich pracy, ponieważ nie sądzą, że na więcej pracy zareaguje pracodawca.

Grandmaster B.
źródło
Jestem liderem zespołu i jestem z nim od prawie 9 lat, ale rok temu zostałem liderem. Myślę, że istnieje różnica między „nie przejmuj się pracą lub jakością mojego kodu” a „nie przejmuj się uczeniem się nowych umiejętności”. W rzeczywistości dokonaliśmy wielu ulepszeń po stronie zarządzania, a wielu naszych kolegów z drużyny jest teraz bardzo zadowolonych. Jednak niektórzy są zadowoleni z robienia tego, co zawsze robili. W rzeczywistości poświęcają dodatkowe godziny bez pytania, są bardzo responsywni, ale nadal wydają się całkiem zadowoleni z debugowania własnych błędów w 75% przypadków.
DXM,
1
Cóż, więc jak w każdym zawodzie, nie wszyscy będą w górnej części krzywej dzwonowej. Możliwe, że masz tylko kilku ludzi do wypłaty.
GrandmasterB,
Wiesz, co roku wybieramy cytat z zespołu, a rok 2011 brzmiał „tak jest”, ale niedługo rozpoczniemy nowy rok i przynajmniej na razie odmówię zaakceptowania tego, co to jest, chociaż zgadzam się z tobą, że tak naprawdę jest przez większość czasu. Zastanawiam się więcej nad tym pytaniem i mam pomysł, który może mieć potencjał. Ponieważ nie mogę odpowiedzieć na własne pytanie (sprawa osobista, nie ograniczenie systemu), jeśli 2 kolejne osoby zagłosują na ponowne otwarcie programistów.stackexchange.com/ questions/
127080
2

Wydaje mi się, że jest to problem z zarządzaniem i przywództwem - jeśli to twój zespół, możesz pracować nad tym, aby doskonalenie (osobiste i kodu) było podstawowym atrybutem twojego zespołu, pytanie brzmi: czy będzie ono wspierane przez twoje zarządzanie - ponieważ będziesz chciał robić rzeczy, które będą wymagały czasu (otrzymają wygraną netto, ponieważ powinieneś zmniejszyć nowy dług techniczny i spłacić istniejący dług techniczny).

Zapewniasz więc, że chcesz ulepszyć zespół, zgadzasz się, że to dobra rzecz (zespół jako całość pracuje nad poprawą jakości kodu), a następnie uruchamiasz program, aby to zrobić zdarza się - to brzmi tak łatwo ... Wiem, że nie!

Myślę, że składają się na to dwie części - edukacja i praktyki pracy.

  • Edukację możesz rozpocząć jeden raz w tygodniu na lunch - wszyscy jedzą razem, prowadzisz 20 ~ 30 minutową prezentację z pytaniami i odpowiedziami. Zaczynasz od podstaw, które chcesz - SOLID może zająć pierwsze 2 ~ 4 tygodnie - z czasem sprawisz, że zespół zacznie mówić w rotacji i możesz dowiedzieć się, jak zdecydować, kto mówi o tym, co między wami. Daj mówcom trochę czasu na przygotowanie się do pracy. Poza tym zachęcają do uczestnictwa w lokalnych grupach użytkowników (poprzez uczynienie go przynajmniej częściowo społecznym, jeśli to możliwe)
  • Praktyki pracy ... cóż, zależy to od tego, co teraz robisz i jakie masz narzędzia, ale możesz przyjrzeć się uzgodnionym standardom kodowania, wprowadzeniu recenzji kodu równorzędnego (czy to solidne), testowaniu jednostkowym (niekoniecznie najpierw test) , prowadzenie ciągłego serwera integracyjnego i analizowanie bardziej zautomatyzowanych testów (oprócz testów jednostkowych). Ale należy je zasadniczo wprowadzić za zgodą / zgodą (nie serwer kompilacji / CI!) I musisz dążyć do poprawy jakości jako zespołu. Zawsze można coś ulepszyć (Kaizen)

Warto również przyjrzeć się Kanban (który jest postrzegany jako czynnik napędzający zmiany / ulepszenia).

Ostatnia myśl - jestem programistą zawodowym i chciałbym, aby mój zespół był taki sam, ale praca przez ponad 40 godzin tygodniowo nie jest tak naprawdę dobrą rzeczą, więc celem powinno być stworzenie zespołu, który wykona swoją pracę skutecznie i dobrze w normalnym tygodniu roboczym, a w związku z tym argumentem za poprawą praktyki pracy jest to, że bardziej prawdopodobne jest np .: dodanie testów jednostkowych w celu wykazania niepowodzenia, gdy (przed) naprawieniem błędu daje pewność, że tak jestnaprawiony; posiadanie serwera kompilacji daje pewność, że możesz w czysty sposób budować swoje rozwiązania - jeśli ta kompilacja generuje również pakiety wdrożeniowe, oznacza to, że wdrożenie jest znacznie uproszczone; Kod SOLID jest z definicji łatwiejszy do modyfikacji; i ogólnie rzecz biorąc, im mniej zaciągniesz dług techniczny, tym mniej będziesz musiał spłacić ...

Murph
źródło
0

Przypadkowo zająłem się programowaniem ~ 30 lat temu. Byłem zmotywowany do nauki podstawowych zasad inżynierii oprogramowania, ponieważ miałem za zadanie utrzymywać / wspierać kod innej osoby. W tych zadaniach nauczyłem się, jak czytnik kodów doświadcza kodu - jak wczuć się w czytnik kodów. Nie chciałem zadawać innym bólu mojego źle napisanego kodu!

Ta praktyka przypisywania nowych programistów do obsługi / obsługi kodu innych ludzi nie jest magiczną kulą i wydaje się motywować do uczenia się, jak tworzyć solidne kody częściej.

David Pointer
źródło
1
Zacząłem w ten sam sposób, choć nie przez przypadek. Jest to bardzo podobne do tego, co powiedział Dipan Mehta w swoim poście. Wrzucasz osobę do stawu, upewniając się, że nie jest zbyt głęboko i pozwalasz mu pływać. Byłeś jednym z tych, którzy nauczyli się pływać, ale to nie jest uniwersalne (patrz jego odpowiedź z komentarzami). Uważam również, że tego rodzaju podejście działa lepiej dla nowych ludzi niż tych, którzy mają już nawyki. Następnie nie tylko muszą pływać, ale także wbrew obowiązującym praktykom.
DXM