tl;dr

To nie jest problem techniczny, to problem ludzi. Potraktuj to jako takie.

Nic nie zmieniam!

Masz naprawdę zły początek i nie ma to nic wspólnego z kodem.

Wygląda na to, że brakuje twoich umiejętności interpersonalnych. Nie zaczynasz ładować się do nowej pracy, mówiąc obecnemu zespołowi, jacy są źli.

Ludzie nie lubią zmian. I naprawdę nie podoba im się to od „nowego faceta”.

Chcę zacząć od niskiego poziomu (np. „Ten fragment kodu jest wolny / źle / nieefektywnie ”), a następnie powoli przechodzą do wysokiego poziomu (np. iteracje vs. wodospad). Ale obawiam się, że pomyślą, że ich atakuję, co nie jest prawdą.

Nie jestem pewien, w jakiej kulturze żyjesz, ale mówię komuś „ten kod jest zły, ja jestem lepszy i powinieneś to zrobić w ten sposób „zawsze będzie atakiem.

Co robić?

1. Przestań myśleć„ ja kontra oni ”. silny> Jeśli nie planujesz odejść, jesteś częścią tego zespołu. To nie są ci „okropni deweloperzy” kontra „ja jestem supergwiazdą” i jeśli powiesz to swojemu zespołowi, będziesz miał problemy. Nikt nigdy nie uszanuje twoich pomysłów. Nie ma znaczenia, czy zespół pracuje indywidualnie. To wciąż zespół, a nawet opisujesz go jako taki.
2. Dowiedz się, czy spełniane są oczekiwania. Czy zespół spełnia oczekiwania / pragnienia menedżera? Jeśli tak, to nie znajdziesz od nikogo zbytniej motywacji do poprawy. "Jeśli to nie jest zepsute, nie naprawiaj tego." Ale jeśli zespół ma problemy z osiągnięciem celów związanych z wynikami, możesz podejść do tego w inny sposób i możesz przedstawić wszystko jako: „hej, nie dotrzymujemy terminów - czy chcecie spróbować to zmienić? pomóż nam to zrobić. ”
3. Nie Ty jesteś menedżerem, tylko Twój szef. Wygląda na to, że chcesz samodzielnie zarządzać całym procesem. To działa świetnie - dla menedżerów / liderów zespołów. Uzyskanie wkładu szefa jest ważne.
4. Ludziom bardziej zależy na wynikach niż na niewyraźnych uczuciach. Twój przełożony będzie bardziej dbał o Twoją perspektywę, jeśli rzeczywiście zademonstrujesz, dlaczego to, co mówisz, jest lepsze niż stan obecny. Nie tylko „dlatego, że tak powiedział internet!” ale w rzeczywistości poprzez demonstrowanie.
5. Poproś ludzi o pomoc. Znajdź sposoby na zbudowanie zaufania zespołu. Proszenie o pomoc / wskazówki to bardzo łatwy sposób na zrobienie tego. Nawet jeśli jest to niewielkie, zrób to ze swoim zespołem. Będą cię szanować znacznie bardziej, jeśli rzeczywiście pokażesz, że słuchasz ich opinii.
6. Daj przykład. Ludzie, którzy normalnie nie chcą się zmieniać, nie przyjmują nowych informacji i idź „wiesz, że masz rację. Nigdy nie uważałem, że sposób, w jaki to robiłem, był gorszy, teraz jestem oświecony i zmienię swoje postępowanie”. Ludzie zmieniają się, zmieniając małe rzeczy, powoli i trwale. Możesz to zademonstrować.
7. Mądrze wybieraj bitwy. Twój przykład brzmi tak, jakby Twoim podstawowym problemem było to, że zespół ma ludzi, którzy źle wykonują swoją pracę. Czy to naprawdę zły , jeśli kod jest nieefektywny? Czy faktycznie wpływa na wydajność końcową? Albo skupiłby się w następnym projekcie na iteracjach, a nie na kaskadzie (pamiętaj, że jeśli skupisz się na typach zwinnych i kaskadowych, na pewno lepiej zaangażuj swojego szefa).

To nie jest właściwe podejście. Jedyne, co zrobisz, to zrazić swoich współpracowników. Jak bardzo byś chciał, gdyby ktoś wziął na siebie analizę wszystkich twoich błędów?

Najlepiej jest współpracować z przełożonym i ważne jest, jak to robisz. Zamiast wskazywać wszystkie rzeczy, które Twoi współpracownicy robią niepoprawnie, powinieneś dokładnie przygotować listę sposobów, które Twoim zdaniem mogą zostać ulepszone i jakie korzyści przyniosłaby Twoja firma. Innymi słowy, nie atakuj ludzi - wskaż, co jest zepsute w twoich procesach i sposoby, które zespół mógłby poprawić, gdyby te rzeczy zostały naprawione.

Jeśli menedżer widzi i rozumie wartość stojącą za tym, co robisz ponownie mówisz, że prawdopodobnie podejmie działanie; może nie jest to działanie, które chcesz, ale sytuacja prawdopodobnie ulegnie poprawie. Jeśli nie, możesz nadal starać się kierować inspiracją i miejmy nadzieję, że sprawy same się poprawią. Jeśli jednak chcesz zachować jakiekolwiek relacje robocze z rówieśnikami, nie próbuj mówić im, jak mają pracować, jeśli nie jesteś odpowiedzialny.

W przeszłości starałem się trzymać następujących zasad i wydawało się, że mi się to udało:

• Zmusiłem się do rozpoczęcia „cichej nauki”: Przez około kilka miesięcy

  Cicho i ucz się. Nie oceniaj niczego. Zintegruj się z zespołem i firmą. Bądź produktywny. Buduj zaufanie i reputację. Pokaż swoje kompetencje.

  (Rozumiem, że próbowałeś już podobnego podejścia). Często widzisz rzeczy, które uważasz za złe, ale kilka tygodni później dowiadujesz się, dlaczego są one takie, jakie są.

• Jeśli zauważysz problemy lub napotkasz rzeczy, które Twoim zdaniem nie są optymalne,

  Zbierz dane: godziny spędzone na prostym zmiany, pojawiające się błędy, rozsyłane gniewne e-maile, itp.

  Każda zmiana, którą kiedykolwiek planujesz zasugerować, wymaga faktów, aby pokazać, że jest konieczna i pomocna. Lubię robić notatki w moim osobistym „pamiętniku” (jednej z tych starych, dobrych, czystych książek zrobionych z prawdziwego papieru).

  W jednym z moich projektów miałem wrażenie, że wprowadzenie zmiany jest szczególnie kosztowne ponieważ nie było testów automatycznych, a testy ręczne były bardzo uciążliwe. Więc prześledziłem godziny, które spędziłem na każdym zadaniu, oddzielając godziny dla rzeczywistego wdrożenia od godzin testowych.

• Po chwili twoje obserwacje (lub notatki) pomogą ci

  Uzyskaj jasny obraz głównych problemów. Dostrzeż je (tylko!)

  Nie wyobrażam sobie, że możesz to zrobić „oddolnie”, jak wspomniałeś. Jest raczej odgórny: problem pojawia się i próbujesz znaleźć jego podstawową przyczynę.

• Zajmij się tylko jednym problemem naraz. Skorzystaj z dostępnych danych i spróbuj

  Opracuj sugestię, jak poprawić ten jeden problem,

  przedstawiając problem i potencjalną wygraną, korzystając z Twoich danych. Skorzystaj z dobrej chwili i wybierz najmniej obrażający sposób. Spróbuj też zasugerować jak najmniejszą zmianę, która będzie miała największy pozytywny wpływ. Małe zmiany są dużo bardziej prawdopodobne, że zostaną zaakceptowane / zatwierdzone przez zespół niż duże.

• Nigdy nie wskazuj palcem. Stań się wartościowym przyjacielem każdego członka zespołu.

  Nawiasem mówiąc, popełniasz też błędy. I wydaje mi się, że najczęściej złe rzeczy, które napotykasz, nie zostały „stworzone” przez „złego faceta”. Ewoluowały, ponieważ nie zadbano wystarczająco o to, aby temu zapobiec. Zawsze dobrze jest nie winić ludzi za problem, ale zająć się procesami, sposobem współpracy zespołu itp.

Zdecydowanie nie zaczynałbym od niskiego poziomu - „ten kod jest nieefektywny” lub tym podobne. To po prostu spowoduje dużo defensywności przy niewielkich korzyściach.

Mieszanie i dopasowywanie projektu zwinnego i kaskadowego jest niesamowicie trudne. Ludzie z wodospadu chcą z wyprzedzeniem ustanowić interfejs między Twoimi projektami (format pliku, układ tabeli, interfejs API, cokolwiek), a następnie odejść i pisać do tego interfejsu. Chcesz po prostu zacząć od najprostszego możliwego interfejsu, elementów, które na pewno będziesz potrzebować, a następnie podejść do nich, mówiąc, że musisz coś dodać lub zmienić i poprosić o reakcję. Dla ciebie jest to odpowiedzialne, zwinne i szybkie, ponieważ nie spędzałeś wieczności na kłótniach o projektowaniu w czasie, gdy nie mogłeś znać odpowiedzi. Dla nich to kowboj, szarpanie nimi dookoła, ciągłe zmienianie gruntu pod nimi. To przepis na katastrofę.

Sugeruję, abyś przedstawił tę trudność następnej osobie, z którą będziesz musiał pracować. Przedyskutuj to i wspólnie zdecyduj , czy najpierw w pełni zaprojektujesz swoje nakładanie się / interakcję, czy też zaczniesz od prostego i przygotuj się na zmianę w miarę postępów. Naprawdę posłuchaj oporu, jaki otrzymujesz od innego programisty. Nie mylą się automatycznie. Zwinność jest świetna, gdy masz wszystkie swoje granice, ale może spowodować dodatkową pracę, gdy nie masz. W przypadku niektórych projektów ta dodatkowa praca jest wciąż krótsza niż dni lub tygodnie spekulacji i sporów, które doprowadziły do ​​stworzenia nieoptymalnego projektu, z którym utknąłeś. Ale nie we wszystkich projektach. W tym przypadku sensowne może być pełne zaprojektowanie granicy między Tobą a innym deweloperem, zanim ktokolwiek zacznie. Następnie idź dalej i bądź zwinny w swoim silosie.

W przypadku większego problemu, który Twoim zdaniem (a) piszą kiepski kod, (b) powinien być zwinny, (c) powinien używać spójnej i nowoczesnej bazy narzędzi oraz (d) powinien wykonywać więcej testów i więcej dzielenie się kodem między projektami - postępuj tutaj bardzo ostrożnie. Próbowałeś po prostu być świetny i zobaczyć, czy chcą cię naśladować, a oni nie. Nie jest dla mnie wcale jasne, czy widzisz korzyści płynące z trzymania się tego, co wcześniej. Nigdy nie przekonasz ich do zmiany postępowania bez zrozumienia, dlaczego (poza bezwładnością) tego nie robią. Prawdopodobnie będziesz również potrzebować wyraźnego wsparcia swojego menedżera, aby poprowadzić akcję „najlepszych praktyk”, która radykalnie zmienia istniejący kod i uczy tych programistów, jak robić to od teraz. Robisz to samodzielnie? Będą cię po prostu odrzucać, bo nie mają na to czasu, mają kod do wykopania.

Witamy w świecie biznesu.

Zmiana wymaga czasu. W dużej firmie może minąć dziesięciolecia, jeśli to, co mają, działa wystarczająco dobrze (i rzeczywiście mogło być liderem w branży lata temu, kiedy przyjęli te praktyki). Pracując dla IBM, nadal używam niektórych narzędzi, których back-endy sięgają ery „zielonego ekranu”, ponieważ DZIAŁA , są silnie zintegrowane z innymi narzędziami (a przez to trudne do zastąpienia indywidualnie ) oraz ponieważ nikt nie znalazł wystarczających środków i czasu, aby zainwestować w przejście w sposób, który nie wiąże się z niedopuszczalnym ryzykiem.

Podobne kwestie dotyczą również praktyki biznesowej. Zmiana narzędzi wiąże się z ryzykiem ... albo ryzyko niedoszacowania kosztów i niewywiązania się ze zobowiązań, albo ryzyko ich przeszacowania i wyglądania, jakbyś nie był wystarczająco agresywny. Kierownictwo chce mieć możliwość przewidywania, więc może bać się zaangażowania w obie strony i trzymać się tego, co ma.

Zmiana może nadejść , ale musi się zacząć małe i zbudowane na zewnątrz. Zaczynasz od dania przykładu tego, jak nowe podejście pomaga CIEBIE przez dłuższy czas. W końcu masz wystarczająco dużo dowodów, aby przekonać lidera zespołu do wypróbowania tego w małej grupie (lub zostaniesz liderem zespołu, który może to zrobić) w sposób, który nie wpłynie negatywnie na resztę firmy. Buduj stamtąd na zewnątrz. Spodziewaj się, że zmiana zajmie trochę czasu; pancerniki nie startują, nie zatrzymują się ani nie obracają bardzo szybko.

Podobnie jak jakość kodu i praktyki w zakresie kodowania. Pamiętaj, że spójność (możliwość wzajemnego czytania i utrzymywania kodu) jest atrakcyjna i naucz się pracować z preferowanym stylem kodowania. (Dobry programista potrafi czytać prawie każdy styl - chociaż facet, który uważał, że średniki powinny znajdować się na początku instrukcji, mógł być wyjątkiem.) Pamiętaj, że jeśli utrzymujesz istniejący kod produktu, musisz zminimalizować ryzyko wprowadzenia nowego błędy, co oznacza, że ​​lokalne łatki są preferowane, chyba że możesz wykazać MOCNE powody, dla których większe będą łatwiejsze do stworzenia, łatwiejsze w utrzymaniu i przyniosą korzyści klientom. Aby to spojrzeć z innej perspektywy, pamiętaj, że wielu klientów używa starego kodu zamiast najnowszej wersji i aktualizuje go tylko wtedy, gdy jest to absolutnie konieczne, właśnie dlatego, że nie chcą ryzykować, że nowy błąd spowoduje upadek ich firmy.

I tak, minimalne poprawki składają się na brzydki kod. W końcu zostanie to naprawione, ale nie przed kolejną główną wersją i nie wcześniej, chyba że wystąpi rzeczywisty problem ze starym kodem.

Gdy nadarzy się okazja do zaimplementowania czegoś nowego, WTEDY możesz rozważ naciskanie na korzyści płynące z nowego podejścia. Ale konserwacja z definicji wiąże się ze starymi procesami i zmienia się bardzo powoli. Niestety, przyjęcie najlepszych praktyk akademickich zajmuje dużo czasu ... i często, zanim się pojawią, coś innego jest najnowszym i najwspanialszym.

Stosuj jedną małą zmianę naraz , dopóki / chyba że jesteś w stanie wprowadzić większe zmiany. Pokaż, nie tylko mów. Bądź cierpliwy i wytrwały. Pamiętaj, że wszystko jest takie, jakie jest, ponieważ DZIAŁA, i naucz się obsługiwać obecny system na tyle dobrze, abyś mógł dokładnie wyjaśnić korzyści i ryzyko zmiany.

Lub zrób ryzykowną rzecz, zakładając własną firmę i robiąc rzeczy po swojemu ... co szybko nauczy Cię, dlaczego wszyscy są tak zdenerwowani ryzykiem, którego jeszcze nie potrafią określić ilościowo; jakiś młody punk przyjdzie z modnym podejściem tego tygodnia i będziesz musiał mu wytłumaczyć, że firma musi poczekać na dobrą okazję, aby się przełamać ... a tymczasem potrzebujesz go do pracy nad tym, co masz teraz , a jeśli nie może tego zrobić, nie ma przyszłości w firmie.

Jak dotąd dobre odpowiedzi, zwłaszcza od Rogera, enderlandu ♦ i Kate Gregory, ale chciałbym to dodać.

TLDR

Zacznij od wysokiego poziomu metodologie, ponieważ będą skutkować wyższą jakością części niskiego poziomu. Pokaż przełożonemu i współpracownikom, jakie korzyści przyniosą im dodanie metodologii wysokiego poziomu, spraw, aby chcieli, aby to się zmieniło , jedynym sposobem na zmianę ich kultury jest skłonienie ich do tego to zmienić .

Oryginalna odpowiedź

Sugeruję, aby zamiast krytykować nieefektywny kod pracodawców, zacząć powoli, współpracując z przełożonym, z nowymi metodami , jeden po drugim, gdzie każdy krok jest dokładnie wyjaśniony. Kultura firmy może się zmienić tylko wtedy, gdy pracodawcy chcą, aby się zmieniła , rozumiejąc dlaczego powinna się zmienić , kończąc na tym, że chcą, aby to się zmieniło .

Sugerowana kolejność metod:

Stand-upy - Zaczynamy bardzo wolno

Zacznij od stand-upów. Jeśli potrafisz uświadomić swojemu przełożonemu i pracownikom, że migracja informacji o tym, co jest robione oraz przez kogo i w którym projekcie '', to mniej prawdopodobnie zostanie oszukany, jeśli ktoś nagle nie będzie w stanie kontynuować swojej pracy, co sprawia, że ​​jest to wrzód na dupie dla następnego pracodawcy, który musi odebrać swoją pracę. Jeśli Twoi współpracownicy uważają, że łatwiej będzie im przejąć czyjąś pracę, migrując informacje, poświęcając na to tylko pięć minut dziennie, to jest to potencjalny początek.

TDD - Nadal są mogą robić swoje, ale w bardziej uporządkowany sposób

Myślę, że to dobry następny krok. Wykonywanie testów jednostkowych starszego kodu jest trudne i prawie bezcelowe (w rzeczywistości definicja, według niektórych ekspertów, starszego kodu to baza kodu, która nie ma lub kilka testów jednostkowych), ale pisanie testów jednostkowych dla nowych metod gwarantuje, że nowe metody faktycznie będą robić to, czego się od nich oczekuje - co skutkuje mniejszą liczbą błędów, o których muszą pomyśleć programiści, mniejszym wydatkom dla firmy (Twój menedżer tego) i kształtuje przepływ systemów, a nie odwrotnie. Przeczytaj artykuł o rozwoju opartym na testach (TDD) i dowiedz się, jak TDD ułatwi życie Twoim współpracownikom i ostatecznie to zrobią, zwłaszcza że mogą robią to samodzielnie i nie muszą wchodzić w interakcje z nikim, którzy to robią. Najważniejsze jest to, że test jednostkowy można napisać w ciągu kilku sekund lub minut, jeśli zostanie wykonany wcześniej, dzięki czemu nie będzie brzmiał tak nudno, a właściwie nieefektywny i bezcelowy, jeśli zostanie napisany później.

Wymyśl koncepcję SOA - pozbądź się ściśle powiązanych systemów

Architektura zorientowana na usługi (SOA) zapewni luźno powiązane architektura, która umożliwia łatwą wymianę i konserwację modułów przez każdego, bez konieczności posiadania wiedzy na temat innych części systemów. Zapytaj współpracowników, czy są skłonni utrzymywać czyjeś bardzo ściśle powiązane systemy po pięciu latach opracowywania i utrzymywania i zapytaj ich, czy są bardziej zainteresowani koniecznością zrozumienia każdej koncepcji w systemie, czy też woleliby wystarczy zrozumieć bardzo małe podzbiory systemu, a nawet pozwolić im przepisać tę bardzo konkretną część od zera, jeśli chcą, ponieważ jest to możliwe tylko w przypadku architektury super zorientowanej obiektowo lub SOA.

Przegląd kodu - przenieś wiedzę bez konieczności zbyt dużej interakcji z innymi osobami

Możesz zapytać współpracowników, czy chcieliby być bardziej wartościowi. Posiadanie wiedzy na temat różnych systemów, które są wokół, czyni je bardziej wartościowymi. To migracja ryzyka, które bardzo spodoba się Twojemu pracodawcy, i daje Twoim współpracownikom dużą przewagę, jeśli jeden z nich nie jest w stanie kontynuować swojej pracy. 15 minut dziennie bardzo by się zmieniło, i pozwoliłbyś im wskazywać swoje wady, nie sprawiając, że wyglądasz na złego faceta , chyba że teraz twoja kolej do przejrzenia, to w porządku, bo cóż, miałeś przejrzeć kod.

Lista jest długa.

Chodzi o to, aby zacząć od najwyższej -poziomowe rzeczy; skończy się na wyższej jakości rzeczy niższego poziomu.

To, co powiedziałem o każdej rzeczy, prawdopodobnie nie przekona wszystkich, ale kluczowe jest, aby Twoi współpracownicy chcieli się zmienić, w przeciwnym razie nie . Niech zobaczą, dlaczego powinni się zmienić, znajdując chwytliwe części metodologii wysokiego poziomu, a rzeczy ulegną poprawie.

Podałeś trzy problemy. Większość z nich brzmi jak akceptowalne najlepsze praktyki (nie ma w tym nic złego), ale jest jedna, na której myślę, że powinieneś się skupić, ponieważ może to być główny problem, ponieważ wszyscy w firmie to zauważą: „Ogólny proces rozwoju jest powolny ... "Podajesz również powód, nieefektywny.

Słowo „agile” jest często używane, ale podobnie jak to wszystko jest względne. Powinieneś skupić się na prawdziwych problemach, które każdy ma. Jak długo trwa żądanie zmiany? Czy zmiany są niekompletne, tj. „Nowa poprawka pojawiła się w sekcji A, ale nie w sekcji B. Dlaczego nie?” To są rzeczy, na których zależy użytkownikom. Otrzymasz większe poparcie od reszty firmy, jeśli wyniki sugerowanych zmian będą dla nich korzystne. Oczywiście szybsza implementacja może być lepsza dla wszystkich.

Wspomniałeś o zduplikowanym kodzie. Jest to nie-nie wśród programistów, ale w przypadku większych projektów, a zwłaszcza tych z dużą ilością starszego kodu, refaktoryzacja nie będzie łatwa. W teorii brzmi świetnie, dopóki nie odkryjesz, że nikt nie da zespołowi czasu na zrobienie tego kosztem bieżących wniosków. Argumentowanie przeciwko długowi technicznemu nie jest łatwe.

Na początku spróbuj zebrać zespół i przedyskutować opracowanie standardów kodowania. Jesteś nową osobą, więc od razu to rozpoznałeś. Zobacz, jaka jest reakcja wszystkich. Możesz otrzymać odpowiedź, ponieważ nie mogą się zgodzić lub „próbowaliśmy, ale nikt nie zastosował się”. Może obecny bałagan jest wystarczającą motywacją, aby wszyscy chcieli coś z tym zrobić. Ponownie, możesz nie mieć czasu.

Jeśli zauważysz, że ta grupa ma trudności z dogadaniem się, zacznij od czegoś podstawowego; idźcie razem na lunch. W takich nieformalnych sytuacjach możesz dowiedzieć się, jakie są prawdziwe problemy. Może to być brak wiedzy, a może środowisko stworzone w tej firmie jest bardziej zainteresowane gaszeniem codziennych pożarów.

Nie poddawaj się, ale nie oczekuj też, że zmieni się to z dnia na dzień. Masz przed sobą ważne zadanie, przyjacielu.

O ile Twoim zadaniem nie jest zmiana ich praktyk pracy ORAZ masz to na piśmie, nie rób tego, ponieważ jak powiedzieli inni, to nie zadziała.

Osobą, która powinna to robić, jest Twój kierownik. To facet, którego musisz przekonać. Spróbuj pragmatycznego odwołania się do wydajności z przykładami.

Jeśli nie jest zainteresowany? Naucz się z tym żyć (i upewnij się, że twój tyłek jest przykryty) lub znajdź inną pracę. Wiem, że to okropne. Byłem tam.

(Prawdopodobnie nie chodzi o ludzi, ale o politykę - albo ktoś dawno temu złapałby ich na tych praktykach.)

Wygląda na to, że naprawdę wiesz, co robisz, ale uważaj, aby nie zaszkodzić swoim nowym współpracownikom. Jeśli jesteś tak dobry, powinieneś być w stanie wnieść pozytywny wkład do repozytoriów każdej osoby. Lepsi programiści prawdopodobnie nie będą mieli nic przeciwko ulepszaniu ich kodu, więc jeśli możesz z nimi pracować, zrób to. Te, które odrzucają twoje ulepszenia, prawdopodobnie nie są typami, z którymi chcesz pracować.

Ale słowo ostrzeżenia: bądź absolutnie pewien, że Twój wkład nie ma negatywnych kompromisów. Jeśli twoje sugestie mają wady, będziesz winny, jeśli coś pójdzie nie tak.

Moim osobistym standardem jest to, że nalegam, aby wszelkie zmiany, które wprowadzam w kodzie opracowanym przez innych, gdzie nie projektuję rzeczy, nie mają absolutnie żadnych wad (lub jeśli istnieją potencjalnie niematerialne, tj. „czy to bardziej czytelne? ”, że są minimalne.) Używając tego jako mojego standardu, nadal mogę:

• refaktoryzować kod, pisać i ulepszać unittesty, zgłaszać bardziej szczegółowe wyjątki
• popraw błędy powstałe w wyniku użycia przestarzałego kodu i zamień wycofywane struktury na nowsze konstrukcje
• zmniejsz liczbę wierszy kodu za pomocą wbudowanych funkcji i metod, które obejmują przypadek użycia, popraw wydajność kodu eliminując materializację struktur danych, które są niepotrzebne, i zastępując niewygodny przepływ kontroli bardziej usprawnionym przepływem kontroli.
• popraw dokumentację (od pisowni po semantykę) i ulepsz styl kodu (tak jak mamy przewodnik po stylu! )

I robię wszystko powyższe bez zmiany wejść i wyjść ustala kod, więc nic w produkcji się nie psuje.

W ten sposób możesz zbudować reputację, wiedząc, co robisz. Robiąc to, będziesz budować wiarygodność dzięki pracownikom wiedzy, z którymi pracujesz. Jeśli jesteś w stanie zastąpić niezgrabne lub złe komponenty lepszymi, docenią Cię jeszcze bardziej. Budując swoją wiarygodność, będziesz w stanie przekonać ich do stosowania praktyk, które Twoim zdaniem przyniosą duże korzyści.

Dwa razy byłem w podobnej sytuacji i tak samo jak wielu innych odkryłem, że nie ma absolutnie żadnego sposobu na poprawę sytuacji, chyba że Twoi koledzy chcą zmienić.

Istnieje prosty sposób sprawdzenia, czy nie chcą, zasugeruj zespołowi udanie się na konferencję lub udział w kursie z odpowiednich tematów programistycznych. mogą nawet istnieć grupy użytkowników, a nawet grupy ogólnych zainteresowań programistycznych, które od czasu do czasu mają otwarte spotkania, które Twój zespół mógłby odwiedzić. materiały do ​​czytania lub filmy do obejrzenia (filmy Wujka Boba działają wspaniale w tej sytuacji).

Dzięki temu nie musisz wskazywać żadnych problemów ani błędów, które Twoim zdaniem robią, Odpowiedź zespołu na te sugestie powie ci wszystko, co musisz wiedzieć o tym, jak bardzo są zainteresowani ulepszaniem rzeczy. Jeśli są entuzjastycznie nastawieni do próbowania tych rzeczy, masz szansę, jeśli nie są zainteresowani, powinieneś oszczędzić sobie cierpienia i wyjść stamtąd jak najszybciej.

Musisz pomyśleć o tym, co motywuje ludzi. „Byłoby mi łatwiej zastąpić cię w pracy, gdybyś przestrzegał następujących praktyk:” nie jest wielkim motywatorem: większość ludzi nie chce być zastępowana. Poświęcenie dodatkowego wysiłku na kodowanie w sposób, który przejmuje ktoś inny ma swoją wartość nawet poza filozofią zatrudniania i zwalniania, ponieważ kod niepowiązany z konkretnymi osobami pozwala na większą elastyczność reagowania na zmieniające się obciążenia pracą .

Ale w sytuacji "nikt oprócz $ x i tak nie dotknie tego kodu przed zakończeniem projektu", pytanie o możliwość utrzymania przez każdego kontra nakład ma różne odpowiedzi.

Odnośnie ponownego wykorzystania kodu: jedną z filozofii C ++ jest zapewnienie narzędzi do tworzenia ogólnych rozwiązań. 95% „kodu wielokrotnego użytku”, który tworzą początkujący programiści, nie jest ponownie wykorzystywanych. Powodem tego jest to, że w przypadku wielu prostych zadań koszt „ponownego użycia” jest wyższy dla doświadczonego programisty niż zwykłe spisanie mankietu, specjalnie w odniesieniu do danego kodu.

Jeśli powiesz bestsellerowemu autorowi, że może podwoić swoje wyniki, używając szablonów tekstowych, które są już wstępnie sprawdzone pod kątem błędów ortograficznych i gramatycznych, a on po prostu musi dopasować odpowiednie właściwe rzeczowniki i czasowniki, a także sparametryzowałeś liczba miejsc na przysłówki - czy możesz sobie wyobrazić, jak będzie podekscytowany?

Czy możesz sobie wyobrazić, jak będzie podekscytowany, jeśli ktoś inny będzie w stanie utrzymać jego powieść, jeśli jest tylko odpowiednio udokumentowana i sparametryzowana?

I nikt nie chce sięgać do podręczników i dokumentacji, aby znaleźć jakieś trywialne rzeczy, które mógłby zapisać, przy czym przynajmniej wydaje się , że zajmuje mniej czasu, a na pewno wymaga mniej wysiłku umysłowego.

Jeśli masz wysoko wykwalifikowany zespół organistów pracujących na jednym instrumencie, przekonasz się, że wszyscy h jako swój osobisty zestaw narzędzi doskonalił przez lata. Każdy ma swoje specjalizacje i charakterystyczny styl pracy.

Jeśli powiesz: „Oto zarządzanie. Zdecydowaliśmy, że zamierzamy ujednolicić narzędzia Paula. Kupiliśmy / stworzyliśmy 20 zestawów narzędzi dokładnie takich, jak Paul i teraz wszyscy będą z nimi pracować w przyszłości”. Nawet jeśli wszyscy zgodzą się, że Paul jest najlepszym konstruktorem organów w firmie, niewielu będzie zadowolonych z tej zmiany. Narzędzia prawdopodobnie nie będą działać dobrze dla niedoświadczonych budowniczych, a będą działać inaczej niż ich własne narzędzia dla doświadczonych.

Nawet Paul nie będzie zadowolony, ponieważ wszyscy będą do niego biegać i go obwiniać.

Celem zespołu nie jest to, że każdy może zostać zastąpiony, ale że udaje mu się pracować na spójnej całości. Jeśli próbujesz sprowadzić procesy do najniższego wspólnego mianownika, z którego czujesz się zadowolony, nie poprawiasz wydajności ani morale pracy.

Rozwijaj swój styl. Odegraj swoją rolę w zespole. Jeśli robisz to dobrze i przekonująco, w końcu doprowadzi to do „zapytajmy użytkownika1807, to brzmi jak coś, co mógł zapakować w torbę sztuczek”.

Co powinieneś sprawdzić po przybyciu około połowy rok to nie sposób wykonywania pracy, ale raczej sposób jej komunikowania: czy uważasz, że spotkania komunikacyjne / zespołowe odbywają się w taki sposób, że naprawdę znaczącym kołom nie grozi wymyślenie na nowo bardzo kosztownych?

Ale możliwość określenia tego w sposób, w którym ludzie zgodzą się z Tobą, włączając w to „moglibyśmy i zrobimy lepiej”, jest czymś, do czego potrzeba lat.

Rób rzeczy jako gracz zespołowy po swojemu. Zobaczysz, jak to pomaga projektom lub nie, inni zobaczą, jak to pomaga projektom, czy nie. Ludzie się uczą i to dotyczy również Ciebie. I zarządzanie.

Robienie rzeczy konsekwentnie inaczej niż jest się skłonnym jest kwestią dyscypliny. Samodyscyplina jest w porządku, ale nie jesteś w sytuacji, gdy dyscyplinujesz innych.

Jeśli kierownictwo stanie się jasne, że może to być dobry krok, w pewnym momencie zostaniesz kierownikiem zespołu. Nie ma sensu próbować nakłaniać kierownictwa do takiego wyniku: lider zespołu, który nie zostanie zaakceptowany przez zespół, nie osiągnie niczego niepopularnego. Miałbyś kamienne ściany. Więc bądź dobrym liderem zespołu dla siebie i dobrym członkiem zespołu dla innych.

Problem nr 1: zbiór osób

Jeśli programista może zapewnić i utrzymywać spójny interfejs API, po co dbać o konwencje? To osoba, która zna kod. Nikt inny nie zajmie się wdrożeniem. Dbaj głównie o API.

Problem nr 2: wymyśl na nowo koło

Rzeczywiście, jest to problem. Wspólny kod należy rozdzielić w repozytorium firmy lub zespołu. Należy o tym zdecydować w trakcie kilku dedykowanych spotkań z całym zespołem.

Problem nr 3: brak agile

Pamiętaj, że agile nie jest jedynym najlepszym możliwym podejściem do tworzenia oprogramowania. Zapewnia przeciętnych programistów.