Kendinize kaç kez “O barakayı/çatı katını/garajı boşaltmalıyım” dediniz?
Hepimiz bunu söyledik ve niyetimiz her zaman iyidir, ancak dağınıklık birikiyor gibi görünüyor, toparlanmanın daha da uzun süreceğini bilmenin verdiği korku duygusu da öyle. Pek çok mühendislikten sorumlu başkan yardımcısı, uygulamalarındaki kodların çoğunun aslında ölü olduğunu fark ettiklerinde böyle hisseder. Dağınıklığın çatı katında veya garajda yer kaplaması gibi, kullanılmayan veya ölü Java kodu da bir şey yapmak için “garaj”a gittiklerinde bir sorundur, çünkü yapmak için geldikleri şeyi yapmak yerine dağınıklığın içinde takılıp kalırlar. . Ve ne kadar uzun süre kalırsa, mühendislik ekibinin üretkenliği o kadar zorlaşır.
Bahar temizliği
Dead Java Code Society, üye olunması en az arzu edilen kulüplerden biridir, çünkü katılmanın sonuçları vardır. CIO, mühendislerinin kurumun ihtiyaç duyduğu işlevselliği sağlamak için kullanılmayan kodu filtrelemesi gerekip gerekmediğini umursamasa da, yeni işlevsellik zamanında sağlanmazsa sorular ortaya çıkacaktır. Hiç kimse mühendislik ekibinin işe değer katma konusunda yavaş olarak algılanmasını istemez, ancak her yeni kod geliştirdikleri zaman bahar temizliği yapmak zorunda kalırlarsa bu durum gerçekleşecektir.
Aynı şekilde mühendislik liderinin, geliştiricilerinin zamanının ölü kodu incelemek gibi sıradan, tekrarlanan görevlerle harcanmasını önlemesi gerekiyor. Örneğin Nisan 2024’te yeni yayınlanan bir araştırma, BT profesyonellerinin %58’inin tükenmişlik yaşadığını gösterdi; bu nedenle hayal kırıklığını artıran herhangi bir şey, yetenekli mühendislerin işten ayrılma olasılığını artırabilir. Günümüzün son derece rekabetçi iş piyasasında bu tür baskılardan kaçınmak çok önemlidir.
Güvenlik yangın tatbikatları
Mühendislik uzmanları uygulamalarının güvenli olmasını isterler, dolayısıyla bunu genellikle Ortak Güvenlik Açıklarını ve Etkilenmeleri (CVE’ler) tarayan güvenlik ekipleriyle koordineli olarak gerçekleştirirler. Ne yazık ki, bu taramalar tıpkı ölü kod gibi zaman tüketen başka yanlış pozitifler de üretir. Ortalama bir Java uygulaması kullanılmayan bağımlılıklar içerir ve tarayıcılar bu kullanılmayan bağımlılıkları acil risk olarak işaretleyerek geliştirme ekipleri için bir yangın tatbikatı oluşturur.
Hepimiz siber saldırı tehdidinin arttığını biliyoruz ve Java yakın zamanda Log4J güvenlik açığı şeklinde önemli bir tehditle karşı karşıya kaldı. Herhangi bir mühendislik lideri, Veracode’un, olaydan iki yıldan fazla bir süre sonra, 3.866 farklı kuruluşta Log4j 1.1’den 3.0.0-alpha1’e kadar sürümlerini çalıştıran 38.278 benzersiz uygulama bulduğunu belirten raporunu okuduğunda endişelenirdi.
Bu tür siber tehditlerle baş etmenin bir kısmı da çabaların nereye odaklanacağını bilmektir. Bir güvenlik açığı tespit aracı hatalı pozitif sonuç verirse ne olur? Bir güvenlik açığını her tespit ettiğinde araştırılması gerekir, ancak kullanılmayan kod varsa bu bir sorun değildir. Ancak yine de mühendislik ekibini yavaşlatacak şekilde araştırılması gerekecek.
Bu sorunun çözümü ölü kodun tespitine benzer; Neyin çalıştığını takip edin ve ona odaklanın.
Peki Dead Java Code Society üyeliğinden nasıl kaçınırsınız?
Düzenli kod, düzenli zihin
Kullanılmayan Java koduyla uğraşmak, mühendislik ekibi için önemli bir üretkenlik sorunu haline gelebilir. Uygulamalardaki ölü kodun potansiyel ölçeği hakkında evrensel bir veri bulunmamakla birlikte, bir akademik çalışma, endüstriyel bir yazılım sisteminin kod incelemesinde, toplam kaynak kodunun %30 ila %50’sinin şu anda herhangi bir geliştirici tarafından anlaşılmadığını veya belgelenmediğini ortaya koyan bir rapordan alıntı yaptı. üzerinde çalışıyorum. Bu ölü kod olarak tanımlandı. Java kurumsal ortamlarda bu kadar yaygın kullanılıyorsa, bu veriler metaforik kod kulübesinin temizlenmesine öncelik verilmesi gerektiğini gösteriyor.
İyi haber şu ki, bunun dikkatinizi diğer gereksinimlerden uzaklaştırmasına gerek yok, çünkü doğru çerçeve ve araçların birleşimi, sorunu çok fazla tüketmeden ortadan kaldırmanıza olanak sağlayabilir.
İlk adım bir kod envanteri oluşturmaktır. Hangi kodun kullanıldığını ve kullanılmadığını izlemeye yönelik araçlar mevcut olduğundan, bunun karmaşık bir süreç olması gerekmez. Bu, arka planda pasif olarak çalışabilir ve üzerinde çalışılabilecek bir kod envanteri oluşturabilir.
Bir sonraki adım, ölü kodun ne olduğuna karar vermeye yönelik bir politika ve onu kaldırmaya yönelik bir süreç üzerinde anlaşmaya varmaktır. Kodun uzun süre kullanılmaması gibi bariz göstergeler olsa da, Java ortamında başka bir yerde zincirleme bir etkiye sahip olması ihtimaline karşı kodu kaldırmanın sonuçlarını dikkate almak da önemlidir. Ayrıca kullanılmayan tüm kodun tek seferde kaldırılması yönünde bir baskı da yoktur. Mühendislik ekibi aktiviteye ne zaman odaklanılacağı konusunda anlaşmaya varmalıdır; örneğin her geliştirici sprintinde kodun birkaç bölümünü kaldırmalıdır.
Eğer bir kuruluş ölü Java koduna doğru yaklaşımını benimserse, mühendislik ekibi sonuçta daha üretken olacaktır.
Eski “düzenli masa, düzenli zihin” atasözü gibi, dağınıklığı ortadan kaldırmak, ekiplerin önemsiz şeyleri elemek yerine önemli olana odaklanabileceği anlamına gelir. Goldman Sachs’tan alınan bir örnekte, kuruluşun temel mühendislikten sorumlu başkan yardımcısı Darshan Mehta, kod tabanının boyutunu %67 oranında azaltmanın faydalarını vurguladı.
Bunun karmaşıklığı azalttığını ve kod tabanında gezinmeyi ve test etmeyi kolaylaştırdığını, bunun da test sürecine daha fazla güven sağladığını ve başka yerlere yatırılabilecek zamandan tasarruf sağladığını öne sürdü. Daha da önemlisi, statik analiz için daha az kod olduğundan ve daha az test gerektiğinden yapım ve teslimat hatları daha hızlıydı; bu da ürünün sürüm temposunun yılda 250 sürümün üzerine çıktığı anlamına geliyordu.
Üyeliğinizi iptal edin
Dead Java Code Society üyeliğinden kaçınarak, Java tabanlı ortamların yönetimindeki diğer tüm karmaşıklıklara uygulanabilecek bant genişliği yaratırsınız. Daha da önemlisi, geliştiricilerin yapmaktan hoşlandıkları şeyi yapmalarına olanak tanıyacak: gerçekten kullanılan yeni kod yazma.
Eric Costlow, Mastercard, Puma, Taboola ve Workday gibi müşterilere sahip bir Java platformu hizmetleri tedarikçisi olan Azul’da ürün yönetiminden sorumlu kıdemli direktördür. BT kariyerine Illinois’de öğrenci olarak başladı ve o zamandan beri hem teknoloji uzmanı hem de teknoloji yazarı olarak çalıştı. 2013 ve 2016 yılları arasında Oracle’da baş ürün yöneticisi olarak çalıştı ve burada bir dizi Java güvenlik sorununun ele alınmasına liderlik etti.