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ł?
coding
coding-standards
coding-style
company
TheBoyan
źródło
źródło
Odpowiedzi:
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.
źródło
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.
źródło
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.
źródło
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.
źródło
Myślę, że mówisz o problemach na bardzo różnych poziomach:
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ę.
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.
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.
źródło
Zaangażuj ich w ustalanie reguł. Zwykle pomaga to zachęcić ludzi do podążania za nimi.
źródło
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.
źródło
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:
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.
źródło