Jak uniknąć dołączenia do stowarzyszenia Dead Java Code Society


Ile razy powtarzałeś sobie: „Muszę sprzątnąć tę szopę/poddasze/garaż”?

Wszyscy to powiedzieliśmy i zawsze mamy dobre intencje, ale bałagan wydaje się narastać, podobnie jak poczucie strachu, że sprzątanie zajmie jeszcze więcej czasu. Cóż, tak właśnie czuje się większość wiceprezesów ds. inżynierii, gdy zorientują się, ile kodu w ich aplikacjach tak naprawdę jest martwych. Podobnie jak bałagan zajmujący miejsce na poddaszu lub w garażu, nieużywany lub martwy Jawa kod stanowi problem za każdym razem, gdy idą do „garażu”, aby coś zrobić, ponieważ zamiast robić to, po co przyszli, w końcu grzęzną w bałaganie. Im dłużej jest to pozostawione, tym bardziej utrudnia produktywność zespołu inżynierów.

Wiosenne porządki

Stowarzyszenie Dead Java Code Society to jeden z najmniej pożądanych klubów, do którego przynależność wiąże się z konsekwencjami. Chociaż CIO może nie przejmować się tym, że jego inżynierowie będą musieli odfiltrować nieużywany kod, aby zapewnić funkcjonalność wymaganą przez organizację, w przypadku nie dostarczenia nowej funkcjonalności na czas pojawią się pytania. Nikt nie chce, aby zespół inżynierów był postrzegany jako powolny w dostarczaniu wartości dla firmy, ale stanie się tak, jeśli za każdym razem, gdy opracują nowy kod, będą musieli robić wiosenne porządki.

Podobnie kierownik inżynierii musi unikać marnowania czasu programistów przez przyziemne, powtarzalne zadania, takie jak przeglądanie martwego kodu. Na przykład w kwietniu 2024 r. nowo opublikowane badania wykazało, że 58% specjalistów IT doświadcza wypalenia zawodowego, więc wszystko, co zwiększa frustrację, może zwiększyć prawdopodobieństwo odejścia utalentowanych inżynierów. Na dzisiejszym, wysoce konkurencyjnym rynku pracy, niezwykle istotne jest unikanie takiej presji.

Ćwiczenia przeciwpożarowe z zakresu bezpieczeństwa

Inżynierowie chcą, aby ich aplikacje były bezpieczne, dlatego zwykle osiągają to we współpracy z zespołami ds. bezpieczeństwa, które skanują Typowe luki i zagrożenia (CVE). Niestety, te skany dają inne fałszywe alarmy, które pochłaniają czas, podobnie jak martwy kod. Przeciętna aplikacja Java zawiera nieużywane zależności, a skanery oznaczają te nieużywane zależności jako pilne ryzyko, co stanowi wyzwanie dla zespołów programistycznych.

Wszyscy wiemy, że zagrożenie cyberatakami rośnie, a Java stanęła ostatnio przed poważnym zagrożeniem w postaci Luka w Log4J. Każdy kierownik inżynierii byłby zainteresowany przeczytaniem Raport Veracode że ponad dwa lata po incydencie znaleziono 38 278 unikalnych aplikacji z systemem Log4j w wersjach od 1.1 do 3.0.0-alpha1 w 3866 różnych organizacjach.

Reklama

Częścią radzenia sobie z takimi zagrożeniami cybernetycznymi jest wiedza, na czym skoncentrować wysiłki. Co się stanie, jeśli narzędzie do wykrywania podatności wygeneruje fałszywy alarm? Za każdym razem, gdy zidentyfikuje lukę, należy ją zbadać, ale jeśli jest to nieużywany kod, nie stanowi to problemu. Jednak nadal trzeba będzie zbadać tę kwestię, aby spowolnić pracę zespołu inżynierów.

Rozwiązanie tego problemu jest podobne do wykrywania martwego kodu; śledź, co działa i skup się na tym.

Jak więc uniknąć członkostwa w Dead Java Code Society?

Uporządkowany kod, uporządkowany umysł

Radzenie sobie z nieużywanym kodem Java może stać się poważnym problemem związanym z produktywnością zespołu inżynierów. Choć nie ma uniwersalnych danych na temat potencjalnej skali martwego kodu w aplikacjach, jedno badanie akademickie zacytował raport, w którym badanie kodu systemu oprogramowania przemysłowego wykazało, że 30 do 50% całego kodu źródłowego nie zostało zrozumiane lub udokumentowane przez żadnego programistę aktualnie nad nim pracującego. Zostało to zidentyfikowane jako martwy kod. Jeśli Java jest tak szeroko stosowana w środowiskach korporacyjnych, dane te sugerują, że należy priorytetowo potraktować czyszczenie metaforycznego kodu.

Dobra wiadomość jest taka, że ​​nie musi to odwracać uwagi od innych wymagań, ponieważ połączenie odpowiedniego frameworka i narzędzi może umożliwić rozwiązanie problemu bez nadmiernego obciążania go.

Pierwszym krokiem jest utworzenie spisu kodów. Nie musi to być skomplikowany proces, ponieważ dostępne są narzędzia do monitorowania, który kod jest używany, a który nie. Może to działać pasywnie w tle i tworzyć inwentarz kodu, nad którym można pracować.

Następnym krokiem jest uzgodnienie polityki decydowania, który kod jest martwy i procesu jego usuwania. Chociaż mogą istnieć oczywiste oznaki, takie jak nieużywanie kodu przez dłuższy czas, ważne jest również rozważenie konsekwencji jego usunięcia, na wypadek gdyby mógł wywołać efekt domina w innym miejscu środowiska Java. Nie ma też presji, aby od razu usunąć cały niewykorzystany kod. Zespół inżynierów powinien uzgodnić, kiedy skoncentrować się na działaniu – na przykład na usunięciu kilku sekcji kodu podczas każdego sprintu programisty.

Jeśli organizacja odpowiednio podejdzie do martwego kodu Java, ostatecznie zespół inżynierów będzie bardziej produktywny.

Podobnie jak stare powiedzenie „posprzątane biurko, posprzątany umysł”, usuwanie bałaganu oznacza, że ​​zespoły mogą skupić się na tym, co ważne, zamiast musieć przesiewać śmieci. Na jednym przykładzie z Goldman SachsDarshan Mehta, wiceprezes organizacji ds. inżynierii podstawowej, podkreślił korzyści płynące ze zmniejszenia rozmiaru bazy kodu o 67%.

Zasugerował, że zmniejszyło to złożoność i ułatwiło nawigację i testowanie bazy kodu, co również dało większe zaufanie do procesu testowania, a także pozwoliło zaoszczędzić czas, który można było zainwestować gdzie indziej. Co ważniejsze, procesy kompilacji i dostarczania były szybsze, ponieważ było mniej kodu do analizy statycznej i wymaganych mniej testów, co oznaczało, że częstotliwość wydawania produktu wzrosła do ponad 250 wydań rocznie.

Zwolnij swoje członkostwo

Unikając członkostwa w Dead Java Code Society, tworzysz przepustowość, którą można zastosować do wszystkich innych złożoności zarządzania środowiskami opartymi na Javie. Co ważniejsze, umożliwi programistom robienie tego, co lubią: pisanie nowego kodu, który jest faktycznie używany.

Eric Costlow jest starszym dyrektorem ds. zarządzania produktami w firmie Azul, dostawca usług platformy Java, obsługujący takich klientów jak Mastercard, Puma, Taboola i Workday. Rozpoczął karierę w branży IT jako student w Illinois i od tego czasu pracuje zarówno jako technolog, jak i autor tekstów technicznych. W latach 2013-2016 pracował jako główny menedżer produktu w Oracle, gdzie zajmował się szeregiem problemów związanych z bezpieczeństwem Java.



Source link

Advertisment

Więcej

Advertisment

Podobne

Advertisment

Najnowsze

Mattel przypadkowo zamieścił link do strony pornograficznej na opakowaniu lalek Wicked

Producent Barbie Mattel przeprosił po tym, jak klienci ją zauważyli Podły edycja dolls umieściła na opakowaniu stronę internetową dla dorosłych. Zabawka omyłkowo kierowała...

Proces 3 nm GAA drugiej generacji firmy Samsung wykazuje wydajność na poziomie 20%, a cele produkcyjne nie są realizowane

Najnowsza technologia produkcji półprzewodników firmy Samsung nie spełnia oczekiwań, ponieważ firma ma trudności z osiągnięciem akceptowalnych wskaźników produkcji swoich najnowocześniejszych chipów 3 nm....

Gigabyte wprowadza na rynek swoją pierwszą płytę główną Mini-ITX X870, X870I Aorus Pro Ice

Kiedy ogłoszono pierwszą partię płyt głównych AMD X870/E, nie było żadnych oznak płyt głównych Mini-ITX, ale teraz Gigabyte wypuściło na rynek swoją pierwszą...
Advertisment