A co z tymi wszystkimi zasadami kodowania?

Zawsze popierałem pomysł posiadania reguł kodowania dla programistów w firmie lub konkretnym projekcie. Zwłaszcza jeśli firma ma rozmiar większy niż 10. Im większa firma, tym większa potrzeba. Wiem, że wiele osób się nie zgodzi, ale widziałem projekty, które ich nie mają, a kod wygląda jak totalna katastrofa.

Prawdziwy problem z tym związany polega na tym, jak sprawić, by ci twardogłowi, którzy nie lubią używać nawiasów w instrukcjach if, lub używają tego samego ciągu połączeń w całym kodzie, czy cokolwiek innego, aby używali reguł kodowania bez przeciwstawiania się im pomysł?

Zaangażuj ich w rozwiązywanie problemu, a nie zasady walki. Osobiście wolę pomysł „przewodników po stylu”, „standardów kodowania” lub czegoś podobnego, w nadziei, że zapobiegnie to szarpnięciu kolan „reguła = zła” reakcja.

Ale nawet jeśli tak jest - wydaje mi się, że reguły obowiązują z jakiegoś powodu, a sposobem, aby skłonić twardych ludzi do zawracania, jest uświadomienie im, że postępując zgodnie z wytycznymi, pomagają ułatwić kodowi czytać dla wszystkich.

Czasami najlepszym rozwiązaniem jest presja otoczenia.

W mojej pracy wykorzystujemy wszystkie trzy z następujących rozwiązań:

1) Zastosuj moduł sprawdzania stylu kodu, taki jak doskonały Checkstyle (dla Java) lub StyleCop (dla C #). Są to łatwo konfigurowane narzędzia, które mogą automatycznie wyróżniać odchylenia stylu / reguły kodowania. Daje to wszystkim neutralną stronę trzecią w celu ustalenia, co jest i jest nie do przyjęcia.

2) Zastosuj szablon automatycznego formatowania kodu formatowania (oto przykład z użyciem Eclipse) (i inny dla Visual Studio), który automatycznie sformatuje kod po zapisaniu. Jest to świetne, ponieważ pozwala komuś zakodować, jak chce, ale cały kod należy sformatować w ten sam sposób przy zapisie / zatwierdzeniu. Naprawdę podoba mi się ten, a nasz kod nigdy nie był bardziej spójny.

3) Recenzje kodu. Mam nadzieję, że i tak je robisz, ale jedną z rzeczy, które powinny podkreślić, jest to, gdzie reguły / style kodowania łamią konwencję.

Oprócz powyższego ważne jest, aby wszyscy byli na tej samej łodzi i uzgodnili style / zasady, nad którymi pracują. Wyjaśnij, że nie uzyskasz zgody wszystkich na wszystko, ale poproś zespół o zaangażowanie, aby dotrzymać tego, co decyduje zespół. Pamiętaj, aby od czasu do czasu sprawdzać style / zasady wybrane w celu uwzględnienia rzeczywistego korzystania z nich i rotacji zespołu.

Prawdziwy problem z tym związany polega na tym, jak sprawić, by ci twardogłowi, którzy nie lubią używać nawiasów w instrukcjach if, lub używają tego samego ciągu połączeń wszędzie w kodzie, czy cokolwiek innego,

Czy są „twarde”, jeśli nie używają nawiasów, czy jest to „twarde” żądanie?

Wybierz bitwę. Wątpię, że jest to jeden z tych, które warto wybrać. Nie chciałbym korzystać w dowolnym miejscu pracy, które oczekiwane nigdzie w pobliżu tego poziomu szczegółowości na „pierwszej kontroli w kodzie”. Jest to wskaźnik czerwonej flagi, że zespół nie rozumie refaktoryzacji.

OO 101 : „Refaktoryzuj, gdy produkt robi to, co musi”. Nie przed.

Trudno jest usiąść na ramieniu każdego programisty w dużych zespołach, upewniając się, że umieszczają aparat na szynie tam , gdzie Twoim zdaniem powinni pójść - zaufaj mi w tym;).

Jeśli naprawdę przeszkadza ci to w rozwoju, będziesz potrzebować „strażnika”. Nie pozwól, aby ludzie się zameldowali bez recenzji kodu. Poproś architekta technicznego lub kierownika zespołu, aby przejrzał kod i odrzucił go, dopóki nie „poprawi” stylu kodu. Niedługo się tym zmęczy i dostosują do zasad, być może tylko tak długo, jak będą sprawdzane.

Oczywiście niektóre firmy całkowicie odbierają uprawnienia do odprawy młodszym programistom. Kiedy w końcu poznają zasady kodowania firm, otrzymują przywilej.

Myślę, że mówisz o problemach na bardzo różnych poziomach:

jak zrobić te twardogłowe, które nie lubią używać nawiasów w instrukcjach if,

Jest to głównie kwestia stylu / czytelności, chyba że występuje wyraźny problem z pierwszeństwem operatora. Ten ostatni nie powinien być bardzo powszechny i ​​i tak można go testować jednostkowo, a zatem łatwo go naprawić. Ten pierwszy może łatwo cofnąć się do Świętej Wojny, z niewielkim zyskiem, ale poważnymi negatywnymi konsekwencjami dla morale drużyny. Uważaj więc - wypychaj wypróbowane i przetestowane reguły, które zostały zaakceptowane przez co najmniej niektóre zespoły / społeczności i sprawdziły się.

lub użyj tego samego ciągu połączeń wszędzie w kodzie,

Jeśli masz na myśli Magic Constants, jest to rzeczywiście problem z utrzymaniem (i potencjalnie bezpieczeństwem), i jako taki IMHO każdy doświadczony programista zrozumie i zaakceptuje, że jest to Zła Rzecz.

czy cokolwiek innego, aby użyć zasad kodowania bez zmuszania ich do sprzeciwiania się temu pomysłowi?

Nie możesz zmusić ludzi do zgodzenia się z jakimikolwiek zasadami kodowania - jedyną szansą jest porozumienie i akceptacja członków zespołu poprzez dyskusję i (czasem zaciętą) debatę . Musisz użyć logicznych i przekonujących argumentów , pokazujących wartość każdej reguły i wyjaśniających, w jaki sposób przestrzeganie jej zapłaci za niedogodności związane z dostosowaniem zakorzenionych nawyków. Z drugiej strony staraj się, aby przejście było jak najłatwiejsze , np. Poprzez wprowadzenie automatycznego formatowania kodu przy odprawie, zgodnie z przyjętymi zasadami.

Jednak czasami trzeba po prostu zaakceptować fakt, że ludzie mają różne opinie , dlatego zasady kodowania, które każdy może zaakceptować, będą łagodne pod pewnymi względami. Zaakceptuj to i skup się na obszarach, w których możesz poprawić rzeczy przy mniejszym wysiłku.

Zaangażuj ich w ustalanie reguł. Zwykle pomaga to zachęcić ludzi do podążania za nimi.

Do tego służy przegląd kodu. Recenzenci kodu nie powinni pozwalać na przekazywanie kodu, który nie spełnia standardów. Pamiętaj, aby nie rozluźniać zasad dotyczących pilnych poprawek. Ponowne wykonanie kilku czynności pod presją, aby to zrobić, naprawi niechęć do poprawnego wykonywania zadań za pierwszym razem.

Ten sam ciąg połączenia wszędzie? Rozwiązaniem tego jest refaktoryzacja do momentu usunięcia całej duplikacji. Kodery kopiuj-wklej powinny przejść do więzienia programisty. (Nie śmiej się! Steve Ballmer jest naczelnikiem.)

Ale prawdziwym problemem jest twój czasownik „make” . Nie możesz zmusić programistów do zrobienia czegokolwiek, a jeśli to zrobisz, zmarnujesz ich najcenniejszą cechę: głębokie zaangażowanie intelektualne wynikające z pracy nad czymś, na czym ci zależy.

Sposób, w jaki to rozwiązałem:

1. Nalegaj, aby zespół miał wspólny standard kodowania. Może mieć 5 linii, ale wszystkie muszą się zgodzić.
2. Za każdym razem, gdy zauważysz argument, nalegaj, aby uzgodnili go razem i umieścili w standardzie kodowania. Jeśli zauważysz, że ludzie zmieniają format rzeczy w tę iz powrotem, potraktuj to jako argument.
3. Za każdym razem, gdy zostanie uzgodniony standardowy element, sprawdź, czy istnieje narzędzie, które od razu wyczyści całą bazę kodu.
4. Co kilka miesięcy zapoznaj się ze standardem kodowania i sprawdź, które z nich są nadal prawdziwe i odpowiednie. Standard po prostu dokumentuje to, co ludzie robią. I nie ma sensu utrzymywać przedmiotów w standardzie, które stały się oczywiste.

Programowanie to sport zespołowy lub wspólne dzieło artystyczne. To, na co ludzie się zgadzają, nie ma znaczenia tak bardzo, jak się zgadzają, i są dobrzy w zawieraniu nowych umów w razie potrzeby.