Standardy kodowania w języku Python a wydajność

Pracuję dla dużej organizacji humanitarnej nad oprogramowaniem do tworzenia projektów, które może pomóc ratować życie w nagłych wypadkach, przyspieszając dystrybucję żywności. Wiele organizacji pozarządowych rozpaczliwie potrzebuje naszego oprogramowania, a my jesteśmy opóźnieni o kilka tygodni.

Jedną z rzeczy, która mnie martwi w tym projekcie, jest nadmierne skupienie się na standardach kodowania. Piszemy w python / django i używamy wersji PEP0008, z różnymi modyfikacjami, np. Długości linii mogą wzrosnąć do 160 znaków, a wszystkie linie powinny iść tak długo, jeśli to możliwe, bez pustych linii między importami, reguły zawijania linii, które dotyczą tylko niektórych rodzajów klas, wiele szablonów, których musimy użyć, nawet jeśli nie są najlepszym sposobem rozwiązania problemu itp. itp.

Jeden główny programista spędził tydzień przepisując większą część systemu, aby spełnić ówczesne nowe standardy kodowania, wyrzucając kilka pakietów testów w tym procesie, ponieważ przepisywanie oznaczało, że były one „nieprawidłowe”. Spędziliśmy dwa tygodnie przepisując wszystkie utracone funkcje i naprawiając błędy. Jest głównym twórcą, a jego słowo ma znaczenie, więc przekonał kierownika projektu, że te standardy są konieczne. Młodsi deweloperzy robią, co im powiedziano. Wyczuwam, że kierownik projektu ma silne poczucie dysonansu poznawczego w związku z tym wszystkim, ale mimo to zgadza się z nim gwałtownie, ponieważ nie ma pewności, co zrobić dalej.

Dzisiaj miałem poważne kłopoty, ponieważ zapomniałem wstawić spacje po przecinkach w argumencie słowa kluczowego. Podczas rozmowy przez Skype dosłownie krzyknęło na mnie dwóch innych deweloperów i kierownik projektu. Osobiście uważam, że standardy kodowania są ważne, ale myślę też, że marnujemy dużo czasu na ich obsesję, a kiedy to zwerbalizowałem, wywołało to wściekłość. Jestem postrzegany jako osoba sprawiająca problemy w zespole, który szuka kozłów ofiarnych za swoje wady. Od czasu wprowadzenia standardów kodowania produktywność zespołu znacznie spadła, ale to tylko wzmacnia obsesję, tj. Główny programista po prostu obwinia nasze nieprzestrzeganie standardów za brak postępu. Uważa, że ​​nie możemy czytać sobie nawzajem kodu, jeśli nie będziemy przestrzegać konwencji.

To zaczyna się kleić. Teraz próbuję zmodyfikować różne skrypty, autopep8, pep8ify i PythonTidy, aby spróbować dopasować się do konwencji. Obsługujemy również pep8 w stosunku do kodu źródłowego, ale jest tak wiele domyślnych poprawek do naszego standardu, że trudno jest je wszystkie wyśledzić. Lead dev simple wybiera błędy, których skrypt pep8 nie odbiera i krzyczy na nas podczas następnego spotkania stand-up. Co tydzień pojawiają się nowe dodatki do standardów kodowania, które zmuszają nas do przepisywania istniejącego, działającego, przetestowanego kodu. Dzięki niebiosom wciąż mamy testy (cofnąłem niektóre zatwierdzenia i naprawiłem kilka z tych, które usunął).

Cały czas narasta presja dotrzymania terminu.

Uważam, że podstawową kwestią jest to, że główny programista i inny główny programista odmawiają zaufania innym programistom do wykonania swojej pracy. Ale jak sobie z tym poradzić? Nie możemy wykonywać naszej pracy, ponieważ jesteśmy zbyt zajęci przepisywaniem wszystkiego.

Nigdy nie spotkałem się z tą dynamiką w zespole inżynierii oprogramowania. Czy błędnie kwestionuję ich przestrzeganie standardów kodowania? Czy ktoś jeszcze doświadczył podobnej sytuacji i jak sobie z nią poradził? (Nie szukam dyskusji, tylko rzeczywiste rozwiązania, które ludzie znaleźli)

Standardy kodowania nie stanowią problemu. Problem polega na tym, że kierownictwo nie może ustalić, na czym polega problem. To prowadzi do „Zrób coś… cokolwiek!” tryb. Szukasz racjonalnego rozwiązania, ale jest to irracjonalny problem. Najlepsze, co możesz zrobić, to:

• Konstruktywnie krytykuj swoje pomysły, ale gdy zapadnie decyzja, nie narzekaj na ten temat.
• Zrób wszystko, aby ułatwić przepisywanie.
• Przestań się stresować. Przegrane terminy to problem zarządzania, a nie twój. Staraj się, ale nie bierz odpowiedzialności za ich złe decyzje.
• Jeśli wiesz coś, co może pomóc, powiedz im. Twoja wzmianka o standupach sprawia, że ​​brzmi to tak, jakbyś próbował robić zwinnie, ale reszta nie brzmi zbyt zwinnie. Sprawdź, czy możesz dostarczyć wcześniej ograniczoną funkcjonalność zamiast starać się dotrzymać jednego wielkiego terminu ze wszystkim. Twórz historie użytkowników dla przepisywania, aby było jasne, jak wpływają one na zaległości.
• Zacznij szukać innej pracy. Poważnie. Firmy w takim stanie nie są daleko od rozpoczynania strzelania do ludzi.
• Wydrukuj t-shirty „tak Ci powiedziano” :-)

Ktoś musi zdecydować, czy wysyłka lub niewolnicze przestrzeganie standardów kodowania jest prawdziwym priorytetem. Wiem, jakie byłyby moje preferencje; jeśli przejdzie testy jednostkowe i akceptacyjne, mówię statek. Po wysłaniu firma może zdecydować, czy poświęcić czas i pieniądze na naprawę długu technicznego.

Problemy ze spacjami po przecinkach można łatwo rozwiązać za pomocą narzędzia do wstępnego kodowania. Znajdź narzędzie, które egzekwuje wszystkie konwencje kodowania, i uruchom to narzędzie na całym zmodyfikowanym kodzie przed kompilacją i testowaniem. Przyzwoite IDE już to robi, pisząc kod.

Czy błędnie kwestionuję ich przestrzeganie standardów kodowania?

To zależy od grupy. Osobiście uważam, że wszystko należy kwestionować. Niektórzy uważają to pytanie za obrazę; że im nie ufam.

Czy ktoś jeszcze doświadczył podobnej sytuacji i jak sobie z nią poradził?

Zapytałem, w jaki sposób te standardy poprawiają wydajność. Zmierzyłem czas, który spędziłem na wygłupianiu się ze standardami w porównaniu z „załatwianiem spraw”. Ostatecznie moce, które zostaną postanowione, będą trzymać się standardów. Zdarza się. Narzekałem na nich głośniej niż zwykle, gdy były przyczyną, dla której nie załatwiłem spraw, ale w inny sposób skupiłem się na wykonaniu mojej pracy. Ciągła walka o rzeczy również nie jest dobra dla wydajności ...

Jeśli, jak mówisz, sytuacja jest znacznie gorsza ze względu na standardy, wówczas przestrzeganie standardów powinno unieważnić argument potencjalnego klienta i pozostawić twój. Jeśli ludzie nie widzą tej (w dużej mierze) obiektywnej korelacji między wdrożeniem standardu a spadkiem wydajności, wówczas niewiele można zrobić. Naucz się sobie z tym radzić, a jeśli nie możesz, poszukaj czegoś mniej biurokratycznego.

Normy są czymś, czego nie należy wprowadzać w późny projekt z nadejściem terminu. Jest to coś, co powinno być wdrożone na początku projektu lub gdy w harmonogramie projektu jest trochę czasu (najlepiej po początkowej wysyłce) dla (potencjalnie) dużego naruszającego kod refaktora.

Jeśli tak naprawdę zostało to wprowadzone w późnej fazie projektu, to jest to błąd popełniany przez twojego kierownika (IMHO).

Nie oznacza to jednak , że jeśli nie zgadzasz się ze swoim tropem, powinieneś po prostu zacząć bunt. To twoja praca . Pracujesz jako zespół . Masz trop . W zespole zdecydowanie powinien istnieć pewien poziom demokracji, ale na końcu główną rolę pełni dyktator. Jeśli on mówi, żeby coś zrobić, ty to zrób.

W końcu, spełniając jego prośby i standardy, nie zapewniasz mu łatwego kozła ofiarnego za niedotrzymanie terminów.

Ponadto jestem wielkim zwolennikiem standardów kodowania (zwłaszcza, gdy rośnie wielkość zespołu), ale należy je wdrożyć, gdy ma to sens.

Twoje pytanie brzmiało: „Czy mam rację kwestionując ich przestrzeganie standardów kodowania?”. http://c0x.coding-guidelines.com/Introduction.pdf (dla języka programowania C) zawiera kilka odnośnych badań na temat wartości wytycznych dotyczących kodowania. Patrz sekcja 9 od strony 39.

Standardy kodowania są wdrażane z określonego powodu. Jedną z rzeczy, która wydaje się brakować w pierwotnym pytaniu, jest zrozumienie powodu tych szczególnych standardów dla konkretnego projektu (lub konkretnej organizacji). Decyzja o ich wdrożeniu na istniejącym kodzie była oparta na pewnej logice. Bez znajomości logiki trudno jest skomentować „dobroć” tej decyzji.

Po drugie, ktoś powiedział, że standardy są wdrażane w celu zapewnienia „długoterminowej produktywności” - takich problemów, jak możliwość utrzymania kodu. Być może wydarzyło się jakieś zdarzenie, które poważnie cofnęło projekt z powodu zamieszania i błędnej interpretacji.

Wygląda na to, że po obu stronach jest dużo emocji - spróbuj przejść do uzasadnionej dyskusji.

Jak zapewne widzieliście w innych odpowiedziach i komentarzach, wasz projekt ma duże problemy, więc to, co zasugeruję, nie ma dużej szansy na sukces, ale jest to coś, co można wypróbować bez zbyt dużego ryzyka w odniesieniu do twoja własna skóra.

Poproś o spotkanie czwórki oczu z głównym deweloperem. Powiedz, że jesteś zainteresowany dogłębnym zrozumieniem korzyści wynikających z bycia tak rygorystycznym wobec standardu kodowania i dlaczego baza kodów była w tak złym stanie przed ich wprowadzeniem. Bardzo ważne jest, aby podczas tej dyskusji zachować otwartość i postawę „Próbuję się nauczyć”. Twój główny programista jest już prawdopodobnie bardziej zestresowany niż ty lub ktokolwiek w twoim zespole i prawdopodobnie będzie bardzo defensywny, gdy tylko poczuje jakąś krytykę.

Postaraj się popchnąć dyskusję w kierunku prób znalezienia sposobów osiągnięcia wspólnego celu; szybkie dostarczanie działającego i możliwego do utrzymania oprogramowania.

Na przykład niektóre nisko wiszące owoce nie dodają nic więcej do wytycznych dotyczących kodowania. Za każdym razem, gdy to się dzieje, kod, który wcześniej był zgodny z wytycznymi, już tego nie robi, a to powoduje, że musisz przepisać fragmenty kodu. Mam nadzieję, że twój główny programista zauważy, że nawet jeśli dodana reguła dodaje wartości (z jego punktu widzenia), może nie być tak dobra, jak motywowanie do przepisywania na tym etapie późnego projektu.

Jeśli to zadziała, możesz poprosić go o usunięcie bardziej arbitralnych reguł, których nie można automatycznie sformatować za pomocą jakiegoś narzędzia.

Standardy kodowania są dobre. Zmiana standardów kodowania jest kosztowna (no cóż, droga, jeśli sprawisz, że będą mniej liberalne; jeśli zmiana standardu pozostawia cały istniejący kod nadal zgodny, nie stanowi problemu), więc należy to zrobić tylko wtedy, gdy jest to absolutnie potrzebne.

Być może jedną z rzeczy jest sprawdzenie wiodącego kodu przed zatwierdzeniem / scaleniem / czymkolwiek, aby upewnić się, że jest on zgodny ze standardem, ponieważ najwyraźniej istniejący łańcuch narzędzi wydaje się nie być w stanie sprawdzić go automatycznie.

oprogramowanie, które może pomóc ratować życie w nagłych wypadkach, przyspieszając dystrybucję żywności

Wierzę w dobre standardy kodowania, ale wierzę również, że ratowanie życia jest o wiele ważniejsze.

Twoim największym priorytetem musi być ratowanie życia ludzi . Wyobraź sobie, że to oprogramowanie dystrybuuje żywność dla twojej rodziny lub zespołu. Wszystko inne może przyjść później.

Dobra wiadomość: masz testy. Testy pomogą ci zachować zgodność ze standardami kodowania bez naruszania funkcjonalności, ale powinno to nastąpić po wysyłce , a nie wcześniej.