Kötü kod hala büyük sorunlara neden oluyor.
Son araştırmalar, Synopsys ve Bilgi ve Yazılım Kalitesi Konsorsiyumu’nun kötü yazılımın yılda 2,41 trilyon ABD dolarına mal olduğunu tahmin ettiğini gösteriyor. Bu maliyetler çoğunlukla siber suçlardan, teknik borçlardan ve yazılım tedarik zinciri sorunlarından kaynaklanmaktadır.
Bu büyük, pahalı bir meydan okuma. Ancak işlemleri bozan veya açık güvenlik açıkları bırakan kodu belirlemek ve ortadan kaldırmak her zaman kolay değildir.
Bu, özellikle kötü veya verimsiz kodların kontrol edilmeden kalabildiği, dolaylı olarak şirket gelirini tükettiği veya müşteri deneyimine zarar verdiği eski sistemler için geçerlidir.
Synopsys Software Integrity Group’ta güvenlik danışmanlığından sorumlu Başkan Yardımcısı Girish Janardhanudu, birçok şirketin “kod temelinizin ne kadar kötü olduğunu öğrenmenin reaktif bir yolu” olduğunu, çünkü sorunun çok büyük olabileceğini veya zaman içinde istikrarlı bir şekilde artabileceğini söyledi.
Mevcut yazılım sorunlarını düzeltmek önemlidir, ancak kötü kod oluşumunu önlemek de önemlidir. Bununla başa çıkmak, teknoloji borcunu kaldırma konusunda proaktif olmayı ve geliştirme hattının bir parçası olarak otomatik yazılım kontrollerini uygulamayı bir arada gerektirir. CIO’lar ayrıca geliştiricilere kötü kod sorunlarının peşine düşmeleri için kaynaklar sağlarken aynı zamanda onlara yeni kodu kullanıma sunuldukça gözden geçirmeleri için ihtiyaç duydukları zaman ve alanı sağlar.
Yerleşik kötü kodu bulma
Janardhanudu, kötü aktörler bir yazılım sistemine kötü kod enjekte edebilse de, bu durumların nadir olduğunu söyledi. Büyük olasılıkla, kötü kod, onu yazanların, bazen her şeyden önce son teslim tarihlerini doldurmaya zorlanması nedeniyle oluşur.
“Geliştiriciler her zaman daha fazla yeni özellik üretme baskısı altında olmuştur,” dedi, genellikle kısıtlı zaman çizelgelerinde.
Maliyet de bir kısıtlama olabilir – düzeltmeleri ertelerken uygulamaya odaklanmak, ancak bir düzeltme asla gelmez. Bunun yerine, bu kötü kod veya yama, diğer şeylerin üzerine inşa edildiği temel haline gelir.
Geliştiriciler her gün kodun içinde olduklarından, genellikle bir CIO’ya bir şeyin kötü veya yanlış olduğunu söyleyebilecek kişiler onlardır.
“Kötü kod önce geliştiricilere zarar verir. Forrester’ın kıdemli analisti Andrew Cornwall, “Bilmesi gerekenler onlar,” dedi. “Bir geliştiriciye kötü kodun nerede olduğunu veya dokunmak istemediğiniz kodun nerede olduğunu sorarsanız, bazen size söylerler ve ‘bunu düzeltecek vaktimiz yok’ derler.”
Bazen sorunu kazmaya nasıl başlayacaklarını bile bilemeyebilirler. Cornwall, “Orada 40 yaşında olan sistemler var” dedi. “Belki yazan kişi emekli oldu ve en son değişiklik yapan kişi 10 yıl önce emekli oldu.”
Geliştiriciler, sorunun ne kadar kötü olduğu konusunda bir fikir edinmeye yardımcı olmanın yanı sıra, tüm uygulamaları iyileştirmenin veya değiştirmenin doğru hareket olup olmadığı konusundaki herhangi bir konuşmanın parçası olmalıdır.
Kötü kod nedeniyle operasyonların temelleri sarsılsa bile, çok hızlı bir şekilde tamamen değiştirilirse tamamen çökebilir.
Janardhanudu, “İster CIO, ister geliştirme yöneticisi olsun, her şey risk yönetimine bağlı,” dedi. “Oluşturduğum şeyi nasıl dengeleyebilirim ve ardından yazılımımda zaten risklere yol açabilecek nelerin olduğunu gerçekten nasıl öğrenebilirim?”
Hatalı kodu düzeltme ve daha fazlasının olmasını önleme
Gemiyi düzeltmeye başlamak için geliştirme ekibinin birikmiş teknik borcun üstesinden gelmek için zamana ve kaynaklara ihtiyacı var.
“Sürekli olarak fazla çalışırlarsa, yeterli zaman yoksa ve yeterli kıdemli geliştirici veya kaynak yoksa, o zaman teknik borç ele alınmaz ve sonra birikip birikerek bir soruna yol açar.” dedi Cornwall.
Bir ekipte genç ve kıdemli geliştiricilerin bir karışımına sahip olmanın da kritik olduğunu ekledi. Küçük geliştiriciler muhtemelen gayet iyi kod yazabiliyor olsalar da, “kıdemli geliştiriciler bazı şeyleri gördüler ve neyden kaçınmaları gerektiğini biliyorlar” dedi.
BT işten çıkarma dalgaları sırasında bile deneyimli kodlayıcılara sahip olmak çok önemlidir. Cornwall, “Ya üst düzey geliştiricilere sahip olarak sorundan kaçınarak ya da küçük geliştiricilerin işleri ilerledikçe keşfetmelerini sağlayarak, bunun bedelini öyle ya da böyle ödersiniz” diye ekledi.
Otomatik kod denetleyicileri ve manuel kod incelemesinin bir kombinasyonu, kötü kodun bir veritabanına girmesini daha baştan durdurabilir. Cornwall, “Bu araçları üretim hattına yerleştirmek ve ‘bu önemli bir şey’ demek, geliştiricilere sorunların ne zaman olabileceğini tespit etmeleri için araçlar sağlıyor,” dedi.
Ancak Cornwall’a göre manuel kod incelemesi yeterli değil, çünkü geliştiriciler bir şeyi gönderme baskısına boyun eğebilir ve her şeyi akışına bırakabilir – ve sorun baştan başlar.