Pracuję jako programista iOS w małej firmie outsourcingowej w zespole 4 osób. Pracujemy nad projektem, który rozpoczął się kilka lat przed tym, jak ja i dwaj inni programiści dołączyliśmy do firmy. Wcześniej projekt był w większości wykonywany przez jedną osobę.

Kiedy zacząłem pracować nad projektem, był to kompletny bałagan. Było wiele powtórzeń kodu. Widziałem te same 500 kodów skopiowanych do 20 różnych plików z niewielkimi zmianami. Ponadto nie był dokładnie zorganizowany: cały kod tworzenia interfejsu użytkownika był mieszany w kontrolerach widoku wraz z logiką.

Starałem się jak najlepiej refaktoryzować rzeczy tu i tam, eliminować zbędne fragmenty kodu, poprawiać strukturę plików projektu i tak dalej. Wydawało się, że poprzedni programista tak naprawdę nie dbał o wszystkie te rzeczy lub nie miał doświadczenia. Był czas, kiedy przez kilka miesięcy pracowałem sam nad całkiem sporą funkcją. Ze względu na charakter tej funkcji musiałem dotknąć dużo kodu w całej aplikacji, więc próbowałem wprowadzić pewne ulepszenia.

Kiedy inni programiści dołączyli do projektu, zauważyłem, że używają innego stylu kodowania (czasem zupełnie innego stylu) i często nie używają nowoczesnych funkcji językowych, takich jak akcesoria własności (jest to stosunkowo nowe w Objective-C). Czasami wymyślają własne rowery zamiast korzystać z podobnych funkcji frameworka lub przenoszą koncepcje z innych języków programowania lub wzorców, których się nauczyli, do naszej bazy kodu. Często nie potrafią poprawnie nazwać metod lub zmiennych z powodu złego angielskiego (Objective-C to język, w którym tworzysz długie nazwy).

Czasami myślę, że gdyby nie IDE, myślę, że napisaliby cały kod bez wcięć i formatowania.

Zasadniczo nienawidzę kodu, który piszą. Jest źle sformatowany / zorganizowany, a czasem radykalnie różni się od reszty projektu. Czuję się bardzo zdenerwowany, gdy dodają swoje spaghetti do mojego dzieła sztuki, co wpływa na mój nastrój w pracy i wydajność.

Coraz bardziej wydaje się, że nie przeszkadza im nauka lub ich to nie obchodzi: po prostu robią to, co się od nich wymaga i wracają do domu. Próbowałem dać im kilka wskazówek, kiedy miałem okazję (np. Skomentowałem ich PR lub zatwierdza na GitHub). Kiedyś ładnie poprosiłem o przestrzeganie stylu kodowania i formatowania większości istniejącego kodu (niestety nie mamy formalnego dokumentu w stylu kodowania). Ale to nie działało ...

Jak poradzić sobie z tą sytuacją, nie skupiając się tylko na „złej kulturze firmy”, „niedoświadczonych absolwentach” itp. I faktycznie zacząć poprawiać sytuację.

Naucz i ćwicz to, co głosisz.

Wiesz, że to jest ważne. Znasz wadę, gdy nie jest to zrobione dobrze.

Teraz wyzwaniem jest przekonanie innych. Nie będzie to możliwe poprzez pojedynczą rozmowę, spotkanie, rozmowę na korytarzu, porady lub w ramach prośby Pull.

To wymaga:

• Publiczne uznanie przez kierownictwo, że te elementy są ważne
• Linters, aby ludzie mogli się spotkać, wymieszać i uzgodnić styl, a następnie pozwolić komputerom na kontrolę
• Wiodący programiści, którzy w pełni wpisują się i są gotowi uczyć innych
• Spotkania, pokazy, lunch i nauka itp., Aby nauczyć tych podejść
• Ludzie oceniani na podstawie przedmiotów wymienionych przez Ciebie podczas recenzji
• Udokumentowane i opublikowane standardy
• Wyciągnij wnioski o wielu recenzentów
• Żądania ściągania nie są scalane, dopóki jakość kodu nie będzie wysoka
• Częste parowanie kodów
• Recenzje kodów grup dla złożonych PR

Słowem wymaga tego

Przywództwo

Dobrą wiadomością jest to, że wszystkie te działania są ogólnie uznawane za dobre praktyki, więc kiedy je promujesz lub zyskujesz poparcie od kierownictwa, powinieneś mieć spore szanse powodzenia i być w stanie bronić się, postępując właściwie. Jednak kierownictwo może jeszcze nie wkupić się, to kolejny temat i pytanie.

W przeszłości dużo pisałem na ten temat na SoftwareEngineering.SE i sam byłem w podobnych sytuacjach. Dlatego postaram się podać kilka wskazówek i podkreślić kilka problemów, które zauważyłem podczas czytania twojego pytania.

Ale najpierw porozmawiajmy o ważnym aspekcie: twojej roli w firmie.

Twoja rola

Możesz mieć wyraźny mandat od swojego szefa na ulepszenie rzeczy, a także miejsce w hierarchii, w którym inni programiści muszą słuchać twoich zamówień . Lub możesz być wśród rówieśników, pełniąc tę ​​samą rolę i ten sam autorytet, a twoją opcją jest tylko ... cóż ... opinia .

W obu przypadkach liczy się mniej miejsce w hierarchii i więcej:

• Co myślą o tobie inni programiści. Jeśli traktują cię jak irytującego faceta, który pyta ich o głupie rzeczy, nie zajdziesz daleko. Widziałem wiele przypadków, w których liderzy techniczni i kierownicy projektów nie mieli absolutnie żadnego wpływu na zespół, ponieważ zespół wiedział (lub myślał), że ci „liderzy” nie mają zaplecza technicznego wymaganego do podejmowania decyzji, które podejmują. Z drugiej strony widziałem kilku programistów, którzy byli faktycznie słuchani przez swoich rówieśników, ponieważ wiedzieli, że ci programiści są zręczni i doświadczeni.

• Jak solidny jest Twój zespół i co go motywuje. Wyobraź sobie firmę, w której każdy programista płaci za KLOC / miesiąc. Czy cokolwiek powiesz o stylu ma znaczenie dla twoich kolegów? Prawdopodobnie nie, ponieważ rzadkie są osoby, które chcą otrzymywać niższe wynagrodzenie. Ogólnie rzecz biorąc, jeśli nie jest to zespół, a tylko grupa osób pracujących nad tym samym projektem, nie będziesz w stanie niczego poprawić.

W zależności od tego możesz zdecydować, czy warto dokonać zmiany. Jeśli nie masz głosu i nie ma spójności zespołu, poszukaj innej pracy. Jeśli jesteś znany jako utalentowany, szanowany programista i masz silne poczucie zespołu, będziesz w stanie stosunkowo łatwo poprawić sytuację, nawet w obliczu wrogości ze strony szefa lub innych zespołów.

We wszystkich przypadkach bardzo ważne jest, aby nie wywierać presji na swój zespół. Pracujcie z nimi, a nie przeciwko nim. Nie wydawaj im rozkazów, ale prowadź ich do celu.

Teraz wskazówki.

Styl

Kiedyś ładnie poprosiłem o przestrzeganie stylu kodowania i formatowania większości istniejącego kodu (niestety nie mamy formalnego dokumentu w stylu kodowania). Ale to nie działało ...

Oczywiście, że tak nie było, ponieważ nie należy tak robić.

• Styl jest nudny .

• Kolejny styl jest nudny .

• Pisanie dokumentu w stylu kodowania jest nudne ( i cholernie trudne ; nawet nie próbuj go robić, chyba że pracujesz z tym językiem od ponad dziesięciu lat).

• Czytanie dokumentu w stylu jest nudne .

• Przeglądanie kodu pod kątem błędów stylu jest nudne .

• Trollowanie, że mój styl jest lepszy od twojego, jest ekscytujące , szczególnie gdy absolutnie nie ma obiektywnej przewagi jednego stylu nad drugim. Poważnie, każda rozsądna osoba wie, że właściwym sposobem pisania if (x)jest sposób, w jaki ją napisałem, nie if(x)lub if ( x )!

W związku z tym:

• Nie rób recenzji stylu. To jest zadanie sprawdzania stylu. Te urocze aplikacje mają kilka zalet nad mózgiem: sprawdzają cały projekt w ciągu milisekund, a nie godzin lub dni, i nie popełniają błędów i nie pomijają błędów stylu.

• Nie pisz własnego standardu stylu. I tak zrobisz to źle, a twoi współpracownicy będą cię trollować, że dokonałeś złych wyborów.

• Nie zmuszaj programistów do naprawiania błędów w stylu 2000.

• Czy wymuszaj styl automatycznie po zatwierdzeniu. Kod z błędami stylu nie ma miejsca w kontroli wersji.

• Zrób to od początku projektu. Ustawienie kontroli stylu w istniejącym projekcie jest trudne do niemożliwego.

Dla bardziej na tym, czytać pierwszą część tej drugiej odpowiedzi na SE.SE .

Również:

• Nie bądź zbyt surowy. Na przykład pisanie jslintkodu zgodnego jest dość irytujące, więc powinno się to odbywać wyłącznie wtedy, gdy jest to absolutnie potrzebne (lub jeśli wszyscy członkowie zespołu są zadowoleni z jego używania). To samo dotyczy narzędzi do sprawdzania statycznego; na przykład Analiza kodu .NET na maksymalnym poziomie może być bardzo uciążliwa i przygnębiająca, przynosząc przy tym niewielkie korzyści; z drugiej strony ten sam zestaw narzędzi na umiarkowanym poziomie okazuje się bardzo pomocny.

Recenzje kodu

Teraz, gdy nie musisz przejmować się stylem podczas przeglądów kodu, możesz skupić się na ciekawszych rzeczach: ulepszaniu (a nie naprawianiu) kodu źródłowego.

Różne osoby różnie reagują na recenzje kodu. Niektórzy uważają to za okazję. Inni tego nie znoszą. Niektórzy słuchają wszystkiego, co im mówisz, robią notatki i nie dyskutują, nawet jeśli mogą mieć rację. Inni próbują kłócić się w każdym punkcie. Od Ciebie zależy znalezienie sposobu radzenia sobie z każdym deweloperem zgodnie z jego osobowością. Zazwyczaj pomocne jest:

• Rób recenzje kodu prywatnie, szczególnie gdy programista jest młodszy i pisze naprawdę zły kod.

• Pokaż, że nie ma nic osobistego: przeglądasz kod, a nie umiejętności danej osoby.

• Pokaż rzeczywisty cel przeglądu kodu. Celem nie jest pokazanie, jak zły jest programista. Celem jest zapewnienie możliwości poprawy.

• Nigdy się nie kłóć. Nie jesteś tu po to, by przekonać, ale po to, by zapewnić swoją wiedzę.

• Nigdy nie zakładaj, że recenzent jest jedynym, który może nauczyć się czegoś na podstawie recenzji. Ty też możesz się uczyć, czytając kod i prosząc o wyjaśnienie części, których nie rozumiesz.

Po sprawdzeniu kodu upewnij się, że osoba rzeczywiście poprawia swój kod. Miałem kilka przypadków, w których programiści sądzili, że przegląd kodu kończy się, gdy kończy się faktyczne spotkanie. Opuszczają i wracają do swoich nowych funkcji, próbując zastosować to, co im udostępniłeś, tylko dla nowego kodu. Posiadanie przyzwoitego narzędzia śledzącego do przeglądu kodu pomaga.

Pamiętaj, że niezależnie od twojej szczególnej roli w firmie i twojej wiedzy specjalistycznej w porównaniu do innych, twój kod powinien również podlegać przeglądowi. Nie powinieneś być jedynym, który przegląda kod innych osób.

W ostatnim projekcie, w którym pracowałem jako lider techniczny, miałem trudności z wyjaśnieniem moim współpracownikom, że ich rolą jest wzajemne sprawdzanie kodu, w tym mojego. Strach przed stażystą, który ma zamiar przejrzeć kod swojego lidera technicznego, znika, gdy tylko znajdzie on pierwsze problemy w kodzie - a kto z nas napisze bezbłędny kod?

Trening

Przeglądy kodu są świetną okazją do uczenia i uczenia się niektórych aspektów programowania i projektowania oprogramowania, ale inne wymagają szkolenia.

Jeśli jesteś w stanie szkolić swoich współpracowników, zrób to. Jeśli twoje kierownictwo jest wrogo nastawione do szkolenia, zrób to nieformalnie. Przeprowadziłem takie szkolenia w formie nieformalnych spotkań, a czasem nawet jako zwykłe dyskusje, czasem przerywane przez kierownictwo i kontynuowane później.

Oprócz bezpośredniego szkolenia, upewnij się, że znasz wystarczająco dużo książek, takich jak Kod Kompletny McConnela , i porozmawiaj o nich z kolegami. Zaproponuj, aby przeczytali kod źródłowy projektów open source, podaj konkretne przykłady kodu wysokiej jakości. I oczywiście sam napisz kod wysokiej jakości.

Skoncentruj się na kontekście, a nie na osobach

Jak poradzić sobie z tą sytuacją, nie koncentrując się jedynie na „złej kulturze firmy”, „niedoświadczonych absolwentach” itp.

Ci absolwenci mają cel: zdobyć doświadczenie, uczyć się rzeczy, stać się bardziej zręcznymi. Jeśli rok po roku piszą kiepski kod i nie wiedzą nic o programowaniu, to prawdopodobnie dlatego, że Twój zespół lub firma nie daje im takiej możliwości.

Jeśli skupiasz się na tym, że twój zespół ma niedoświadczonych absolwentów, to nie pomoże. Zamiast tego skup się na tym, co możesz dla nich zrobić i z nimi. Przegląd kodu i szkolenie to dwie techniki poprawy sytuacji.

Zła kultura towarzystwa to inna bestia. Czasami można to zmienić. Czasami nie może. We wszystkich przypadkach należy pamiętać, że są częścią tej firmy, dzięki czemu są częścią kultury firmy. Jeśli nie możesz go zmienić i okaże się, że jest z natury zły, prędzej czy później będziesz musiał wyjść.

Popraw swoje dane

Jak dokładnie mierzysz teraz kod? Czy mierzysz liczbę zatwierdzeń dziennie na programistę? Czy KLOC miesięcznie na programistę? A może zasięg kodu? Lub liczba znalezionych i naprawionych błędów? Czy liczba potencjalnych błędów wykrytych podczas testów regresji? Lub liczba powrotów wykonanych przez serwer Continuous Deployment?

Rzeczy, które mierzysz, mają znaczenie, ponieważ członkowie zespołu dostosowują swoją pracę do mierzonych czynników. Na przykład w jednej firmie, w której musiałem pracować kilka lat temu, jedyną rzeczą, która została zmierzona, był czas spędzony w biurze. Nie trzeba dodawać, że nie zachęcało to do dostarczania lepszego kodu, do inteligentniejszej pracy lub ... cóż, do pracy w ogóle.

Wykrywanie pozytywnych i negatywnych wzmocnień oraz dostosowywanie mierzonych czynników w czasie jest zasadniczo efektem dźwigni dla członków zespołu. Właściwie wykonane pozwala osiągnąć wyniki, których nie osiągnie prosta hierarchia.

Rzeczy, które ci przeszkadzają, czynią je mierzalnymi. Zmierz je i upublicznij wyniki. Następnie współpracuj z innymi członkami zespołu, aby poprawić wyniki.

Rozważmy na przykład, że członkowie zespołu popełniają zbyt wiele błędów ortograficznych w nazwach klas, członków klasy i zmiennych. To denerwujące. Jak mogłeś to zmierzyć? Za pomocą analizatora składni możesz wyodrębnić wszystkie słowa z kodu i za pomocą modułu sprawdzania pisowni określić stosunek słów zawierających błędy i literówki, na przykład 16,7%.

Następnym krokiem jest uzgodnienie ze swoim zespołem docelowego współczynnika. Może to być 15% na kolejny sprint, 10% na następny, 5% za sześć tygodni i 0% za dwa miesiące. Dane te są przeliczane automatycznie przy każdym zatwierdzeniu i wyświetlane na dużym ekranie w biurze.

• Jeśli nie osiągniesz docelowego współczynnika, Twój zespół może postanowić poświęcić trochę więcej czasu na naprawę błędów ortograficznych. Lub twój zespół może uznać, że lepiej jest obliczyć współczynnik na programistę i wyświetlić te informacje również na dużym ekranie. Albo twój zespół może uznać, że cel był zbyt optymistyczny i że powinieneś go zweryfikować.

• Jeśli osiągniesz docelowy współczynnik, następnym krokiem jest upewnienie się, że liczba błędów i literówek nie wzrośnie z czasem. W tym celu możesz utworzyć dodatkowe zadanie w swojej kompilacji, które sprawdza błędy ortograficzne i kończy się niepowodzeniem, jeśli przynajmniej jeden błąd zostanie znaleziony. Teraz, gdy pozbyłeś się tego problemu, duży ekran może zostać ponownie wykorzystany do wyświetlenia nowych odpowiednich statystyk.

Wniosek

Uważam, że każdy aspekt wymieniony w pytaniu można rozwiązać za pomocą technik, które zawarłem w mojej odpowiedzi:

• Kiedy inni programiści dołączyli do projektu, zauważyłem, że używają innego stylu kodowania (czasem zupełnie innego stylu)

  Trzeba było wymusić styl automatycznie po zatwierdzeniu.

• i często nie używają nowoczesnych funkcji językowych, takich jak akcesoria do nieruchomości (jest to stosunkowo nowa funkcja w Objective-C).

  Zarówno przeglądy kodu, jak i szkolenia są tutaj, aby przenieść Twoją znajomość języka.

• Czasami wymyślali własne rowery zamiast korzystać z podobnych funkcji ramy

  Zarówno przeglądy kodu, jak i szkolenia są tutaj, aby przenieść twoją wiedzę na temat frameworka.

• lub przenieś koncepcje z innych języków programowania lub wzorców, których się nauczyli, do naszej bazy kodu.

  To jest doskonała rzecz. Wydaje się, że możesz się od nich uczyć.

• Często nie potrafią poprawnie nazwać metod lub zmiennych z powodu złego angielskiego

  Przeglądy kodu powinny również koncentrować się na właściwym nazywaniu. Niektóre IDE mają również sprawdzanie pisowni.

• Czasami myślę, że gdyby nie IDE, myślę, że napisaliby cały kod bez wcięć i formatowania.

  Oczywiście, że tak. Styl jest nudny i powinien być zautomatyzowany.

• Zasadniczo nienawidzę kodu, który piszą.

  Pamiętaj o części z recenzji kodu: „Celem nie jest pokazanie, jak zły jest programista. Celem jest zapewnienie możliwości poprawy. ”

• Jest źle sformatowany / zorganizowany, a czasem radykalnie różni się od reszty projektu.

  Zautomatyzowane sprawdzanie stylu .

• Czuję się bardzo zdenerwowany, kiedy dodają swoje spaghetti do mojego dzieła sztuki

  Czekaj, co?! Dzieło sztuki?! Zgadnij co? Niektóre osoby (w tym ty za sześć miesięcy) mogą uznać twój kod za daleki od dzieła sztuki. Tymczasem zrozumcie, że uznanie waszej pracy za dzieło sztuki, a ich praca za bzdury, nikomu nie pomoże. Włączając Ciebie.

• Coraz bardziej wydaje się, że nie przeszkadza im nauka lub ich to nie obchodzi: po prostu robią to, co się od nich wymaga i wracają do domu.

  Oczywiście zrobią to, co jest od nich wymagane. Pamiętaj: kontekst, a nie osoby i odpowiednio dobieraj swoje dane . Jeśli kontekst wymaga od nich bycia najlepszym w tym, co robią, zrobią to. Jeśli kontekst wymaga wyprodukowania jak największej liczby KLOC miesięcznie i nic więcej, zrobią to również.

Wdrażaj standardy kodowania i trzymaj się ich, wzorców projektowych, biblioteki fragmentów kodu, które można wykorzystać jako wytyczne itp.

Standardy kodowania mogą wahać się od decydowania o tym, czy użyć spacji czy tabulatorów, jakich wzorców projektowych użyć, konwencji nazewnictwa itp. To będzie długa droga, nawet jeśli wszyscy kodują inaczej.

Jeśli możesz, zaimplementuj standardy kodowania i recenzje kodu - aby rozpocząć sprawdzanie każdego meldowania. W małym zespole będzie to trudna sprzedaż dla osób, które nie rozumieją, że wydanie dodatkowych 2x lub 3x na kod z góry pozwoli ci zaoszczędzić 20 lub 30 razy na ogólnym czasie programowania, ale to kolejna koncepcja, którą warto kupić -w dniu

Nie starałbym się wdrożyć wszystkiego na raz i starałbym się, aby wymyślił również standardy - nie tylko wcięcia, ale starają się, aby zastanowili się nad rzeczami, które napotkali w kodzie, które mają ich życie stało się łatwiejsze lub trudniejsze.

Zastanów się, czy jeden dzień w tygodniu nie odbędzie się spotkanie w celu przeglądu tego, co poszło dobrze lub źle dla każdej osoby w tym tygodniu - możesz również zaoferować każdej osobie możliwość powiedzenia, co zrobiła inna osoba, co było najbardziej pomocne w tym tygodniu - takie rzeczy . Możesz spojrzeć na książki XP / Agile, by znaleźć więcej takich pomysłów. Będąc małym zespołem, może to być trudna sprzedaż.

Wspomniałeś o problemach językowych. Jeśli ci pracownicy są lokalni (zarówno kontrahenci na miejscu, jak i zatrudnieni w pełnym wymiarze godzin), nie powinno to stanowić większego problemu, ale jeśli są to zagraniczni kontrahenci pracujący zdalnie - pozwólcie, że powiem tylko, że z mojego osobistego doświadczenia nie wynika to nigdy zostanie naprawiony, albo jeźdź nim, aż kierownictwo stwierdzi, że to nie zadziała, albo rozważ odejście z firmy. Nie wpadaj w sytuację, w której jesteś odpowiedzialny za ich pracę i nie trać czasu na próby naprawienia praktyk rozwoju zespołu. Najprawdopodobniej twoja praca przekształci się w spędzanie 100% twojego czasu na tworzeniu kodu. Nawiasem mówiąc, wielu zagranicznych kontrahentów to świetni programiści, mam na myśli przypadek, w którym firma kontraktowa przesłała ci opisany przez ciebie talent.

Opisane przez ciebie objawy zdecydowanie sugerują brak spójności zespołu .

W takiej sytuacji standardy kodowania, szkolenia, procedury lub narzędzia nie będą srebrną kulą, która może znacznie poprawić jakość. Najpierw musisz rozwinąć ducha zespołu, otwartą i konstruktywną komunikację oraz współwłasność produktu.

Objawy:

• „po prostu robią to, co jest wymagane i wracają do domu”: dźwięk, że są zdemotywowani. Czy nie byli bardziej entuzjastyczni, kiedy przybyli?
• „oni” przeciwko „nam” / „mnie” / „ja”: brak wzajemnego zaufania?
• „Dałem kilka wskazówek: skomentowałem PR na Git”: ton krytyki pisanej jest czasem źle interpretowany jako agresywny lub arogancki, pomimo konstruktywnych intencji. Dlaczego nie porozmawiać o tym osobiście?

Jesteś małym zespołem: wykorzystaj tę przewagę! Kilka pomysłów na początek:

• Podejmuj ważne decyzje wspólnie. Dyskutuj otwarcie nieporozumienie. „Dyskusja” nie polega na narzucaniu jednego punktu widzenia, ale na słuchaniu i próbowaniu znalezienia wspólnej płaszczyzny.
• Przeprojektowałeś ważne części kodu, więc masz naprawdę silną własność. Niech kupią. Niech mają słowo do powiedzenia.
• W przypadku bardzo wrażliwych, ale bardzo subiektywnych tematów, takich jak formatowanie kodu, wystarczy zlecić zadanie automatycznej ładnej drukarce, która ponownie sformatuje zgodnie ze standardem i bez wyczucia przy każdej odprawie.

Cytat dnia:

Jeśli chcesz iść szybko, idź sam. Jeśli chcesz iść daleko, idź razem

Odpowiedź na twoje pytanie brzmi „Zmień firmę lub zmień firmę”. Dla tych, którzy nie wiedzą, oznacza to, że zostajesz i walczysz o zmianę, którą chcesz zobaczyć w swojej firmie, lub zmianę firmy, w której pracujesz (tj. Odejść i pracować w innym miejscu).

Druga część jest najprostsza. Odchodzisz i znajdujesz firmę, która podziela te same wartości, którymi kierujesz się. Pierwszy nie jest taki prosty z powodu ... ludzi.

Musisz zmienić ludzi. Myślenie, że są zepsute i trzeba je naprawić, nie zadziała. Ludzie są istotami emocjonalnymi. Może to łatwo przerodzić się w wojny osobiste. Więc...

Przede wszystkim musisz dowiedzieć się, dlaczego sytuacja jest taka, jaka jest. Porozmawiaj ze wszystkimi. Dowiedzieć się. To, co teraz widzisz, jest wynikiem decyzji podejmowanych przez lata (a może nie podjęcia ważnych decyzji we właściwym czasie). Nie oceniaj i nie wyciągaj pochopnych wniosków.

Czy było to spowodowane niedoświadczonymi programistami? Czy było to spowodowane tym, że kierownictwo próbowało obniżyć koszty, zatrudniając tanich absolwentów zamiast bardziej doświadczonych i kosztownych programistów? Czy chodzi o to, że ludzie są leniwi i mają złe zamiary lub ludzie pokonani przez zepsuty system? Czy terminy zmuszają cię do zrobienia „tego, co należy zrobić”, aby działało, czy ludzie po prostu marnują czas i nie przejmują się zbytnio tym, nad czym pracują? itp.

Problem z tą dziedziną rozwoju oprogramowania polega na tym, że ludzie uczą się w pracy. Jeśli pracują w gównianym środowisku, nabiorą złych nawyków. A przyzwyczajenia mają tendencję do trzymania się i są trudne do potrząśnięcia. Wtedy nie wiedzą lepiej, bo to wszystko, co wiedzą. Nie wszyscy programiści pasjonują się tym, co robią, aby zainwestować czas w poprawę lub szukanie ulepszeń. Niektórzy zajęli się tą sprawą z różnych innych powodów. Dowiedz się, dlaczego ludzie są tacy, jacy są.

Potem jest zarządzanie. Czy kierownictwo nie zdaje sobie sprawy z sytuacji, czy po prostu jej to nie obchodzi? Dowiedzieć się. Absolutnie potrzebujesz wsparcia zarządzania, jeśli chcesz coś ulepszyć. Jeśli coś, co nagle zajęło 3 miesiące, zaczyna się nagle 4 miesiące, ponieważ teraz musisz pisać testy, robić recenzje kodu, dyskutować na tablicy z zespołem, aby zdecydować o dobrych rozwiązaniach, sparować program itp., Możesz być upewnij się, że kierownictwo zauważy różnicę czasu. Coś, co zmienia się z 3 do 4 miesięcy, jest łatwe do zaobserwowania i zmierzenia. Mając solidną bazę kodu, łatwy do utrzymania produkt, dobrą stabilną architekturę, rzeczy, które sprawiają, że lepsza struktura produktu nie jest tak łatwa do zmierzenia. Ile czasu kupują najlepsze praktyki na dłuższą metę, nie może być mierzone z góry, może nawet po fakcie. Z drugiej strony, miesięczne opóźnienie nie jest żadnym problemem. Poproś o wsparcie w tym zakresie. Przygotuj się na trudną wyprzedaż.

Spójrz także na kontekst firmy. Czy to wpływa na twój sposób pracy? Czy masz możliwości, które należy wykorzystać za wszelką cenę, w tym poświęcenie jakości kodu lub najlepszych praktyk?

Zmieńmy na chwilę perspektywę.

Czuję się bardzo zdenerwowany, gdy dodają swoje spaghetti do mojego dzieła sztuki, co wpływa na mój nastrój w pracy i wydajność.

Przepraszam ... co? Sztuka? Wiem, że większość z nas jest tutaj dla uznania od naszych rówieśników i dostajesz to tylko, jeśli jesteś dobrym programistą, ale czy Twój kod jest wyświetlany w muzeum obok obrazu? Czy to musi wywoływać emocje u ludzi, którzy na to patrzą? Łzy radości i szczęścia? Tak, jestem sarkastyczny i celowo przesadzam, bo chcę powiedzieć, żeby zachować poczucie rzeczywistości. Nie przywiązuj się emocjonalnie do swojego kodu.

Pracowałem z facetem, który chętnie rzuciłby zespół, projekt i firmę pod autobus, aby narzucić wszystkim swoją sztukę. Był „posiadaczem prawdy” i, z definicji, wszyscy byli niedoświadczeni, ślepi, nie chcieli się uczyć, nie dbali o to, lub po prostu głupi. Nie zostań tym facetem. Jako programista Twoim zadaniem jest napisanie dobrego kodu, przetestowanego kodu, łatwego do utrzymania kodu, kodu, który dodaje wartość biznesową i może nadal to robić przy ciągłych zmianach w przyszłości. I musisz to wszystko robić w ramach ograniczeń budżetowych i czasowych. To właśnie oznacza być profesjonalnym programistą. Jeśli nie jesteś galerią sztuki, sztuka jest szkodliwa dla biznesu. Bądź pragmatyczny i zachowaj zrównoważony pogląd na wszystko. „ Jak zignorować zły kod, który piszą moi współpracownicy i skupić się na pracy„Twoje pytanie zostało zamknięte z powodu sposobu, w jaki ułożyłeś problem. Cofnij się i spójrz na całość.

Jak poradzić sobie z tą sytuacją, nie skupiając się tylko na „złej kulturze firmy”, „niedoświadczonych absolwentach” itp. I faktycznie zacząć poprawiać sytuację.

TL; DR: Uważnie przyjrzyj się sytuacji, aby dowiedzieć się, dlaczego sytuacja się w niej znalazła. Zaakceptuj, że sytuacja jest podobna i zobacz, jak możesz ją poprawić. Dowiedz się, co sądzi na ten temat wszyscy. Wybierz bitwę. Wymuszanie zmiany nie działa. Współpracuj, aby wprowadzić zmiany. Powinieneś spróbować pokazać, jak można poprawić rzeczy, a nie wskazać, jak bardzo są złe. Przekonaj wszystkich, że to, co chcesz zrobić, jest na dłuższą metę dla większego dobra. Weź ich na pokład.

I rób to małymi krokami.

Jeśli wprowadzisz zbyt wiele zmian naraz, ludzie poczują się zniechęceni i poddadzą się. Zmiany wymagają czasu. Zmień firmę lub zmień firmę. Powodzenia!