Ewolucja standardów kodowania, jak sobie z nimi radzić?

Jak radzisz sobie z ewolucją w standardach kodowania / przewodniku po stylu w projekcie istniejącej bazy kodu? Powiedzmy, że ktoś z twojego zespołu odkrył lepszy sposób tworzenia obiektów w języku programowania. Nie chodzi o to, że stary sposób jest zły lub wadliwy, po prostu nowy sposób jest mniej gadatliwy i wydaje się bardziej elegancki. I wszystkim członkom zespołu naprawdę się to podoba. Czy zmieniłbyś cały istniejący kod?

Załóżmy, że twoja baza kodu zawiera około 500 000+ linii kodu. Czy nadal chcesz zmienić cały istniejący kod? A może pozwoliłbyś, aby nowy kod był zgodny z nowym standardem? Zasadniczo stracisz spójność?

Jak radzisz sobie z ewolucją standardów kodowania w swoim projekcie?

Istnieją standardy kodowania, które zwiększają produktywność zespołów. Teoretycznie ułatwiają zrozumienie, modyfikację i testowanie kodu. W praktyce mogą stworzyć niebezpieczną ilość meta-pracy; zespoły wielokrotnie przepisują istniejący kod w poszukiwaniu najbardziej poprawnego i eleganckiego rozwiązania. Niestety problem meta-pracy wydaje się gorszy w zespołach, w których wszyscy są zaangażowani, pasjonaci i mają obsesję na punkcie robienia właściwych rzeczy.

Jako konsultant przechodzący od projektu do projektu odkryłem, że doskonała dyscyplina ze sztywnym standardem kodowania przyczynia się znacznie mniej do sukcesu projektu niż doskonali programiści, którzy są zainteresowani wynikami. Niespójne style kodowania są drobną uciążliwością dla niesamowitych programistów. Są wydajne z konsekwencją lub bez niej. To prawda, że ​​jeśli napotkają niespójny kod, zapytają o bieżącystandard i trzymaj się go. Nie będą jednak nalegać na aktualizację każdej linii kodu w projekcie do obecnego standardu. Nie nalegają, ponieważ widzieli, jak najlepsze praktyki przychodzą i odchodzą. Właściwy sposób robienia czegoś dzisiaj nie jest taki sam, jak właściwy sposób robienia czegoś jutro. Gdyby tak było, standardy kodowania nie ewoluowałyby. Tak więc, jeśli poprawny sposób zrobienia czegoś zmienia się z czasem, być może nasza definicja „poprawności” jest zepsuta.

Nie oznacza to, że standardy nie mają znaczenia. Pamiętaj tylko, że celem norm jest produktywność. Jeśli nie możesz zagwarantować, że ponowne napisanie do nowego standardu zwróci się w dłuższej perspektywie, nie marnuj na to czasu. O wiele łatwiej jest uzasadnić nowy standard w nowym lub zmienionym kodzie. Elegancja jest fajna, ale to nie to samo, co wyniki.

To, co robimy, to ewolucja (nie rewolucja) również dla podstawy kodu, użylibyśmy zaktualizowanego standardu, gdy;

• nowy kod został napisany
• kod jest refaktoryzowany
• błędy są naprawione
• nowe porcje są dodawane do istniejącej klasy

Ważne jest, aby baza kodów była spójna, więc jeśli zmiana stwarza możliwość pomylenia kodu w stylu „starym” i „nowym”, lepiej zarezerwować aktualizację standardu kodowania w następnym projekcie.

Przede wszystkim nie zawarłbym takich „najlepszych praktyk” w (obowiązkowej części) wytycznych dotyczących kodowania. Można je wymienić, na przykład w załączniku, jako przykład, jak można coś zrobić, ale nie dlatego, że należy to zrobić w ten sposób.

To powiedziawszy, są dwa przypadki do rozważenia w związku ze zmianami w standardzie kodowania:

1. Zmiany, które nie wpływają na czytelność, nawet jeśli stary i nowy kod są mieszane bez aktualizacji starego kodu.
   Zmiany te można natychmiast dodać do standardu kodowania i należy je uwzględnić w odniesieniu do całego nowego i zmodyfikowanego kodu. Stary kod powinien być dostosowywany stopniowo, gdy pozwala na to czas i wprowadzane są zmiany w tym obszarze.
   Przykładem tego rodzaju zmiany, z którą faktycznie się spotkałem, jest zmiana w oświadczeniu o prawach autorskich na początku każdego pliku.
2. Zmiany, które pogarszają czytelność, jeśli stary i nowy kod są pomieszane.
   Zmiany te powinny albo zostać zastosowane do całej bazy kodu za jednym razem, albo powinny być ponownie rozważone, jeśli są naprawdę potrzebne.
   Przykładem tego rodzaju zmiany jest zmiana wcięcia lub umieszczenia nawiasu klamrowego.

To naprawdę musi zależeć od rodzaju tworzonego produktu:

• W przypadku aplikacji komercyjnej napisanej we własnym zakresie i wdrażanej dla klientów głównym celem powinno być uzyskanie przychodów. Tak długo, jak stary kod nie jest wadliwy, nie ma znaczenia, że ​​ewoluowały nowe standardy kodowania, powinieneś koncentrować się na dodawaniu nowych funkcji do produktu i generowaniu przychodów. W każdym razie dostosuj nowe standardy kodowania do nowego kodu, ale zmiana całego istniejącego kodu byłaby stratą czasu.
• Jeśli opracowujesz produkt o otwartym kodzie źródłowym lub produkt, w którym wiele firm (może nawet twoi klienci) zobaczą i pracują na źródle, to czytelność kodu staje się znacznie ważniejsza, w takim przypadku należy podjąć rozsądną decyzję w zależności od dokładnie ile kodu należy zmienić i jakie będą korzyści na dłuższą metę. Chociaż wszyscy lubimy ładny kod, w rzeczywistości dla firmy komercyjnej zajmującej się zamkniętym kodem źródłowym, ciągłe dostosowywanie nowych standardów oznacza, że ​​na dłuższą metę stracisz przychody.

Osobiście wolałbym zachować stare kody w obecnej postaci i stosować się do nowych standardów, niezależnie od tego, co robisz. Mówiąc dokładniej, nie będę używał podwójnych standardów w old.c. Ale jeśli mam utworzyć new.c, można użyć nowszych, dopracowanych składni :)