İlerleme, teknolojiyi ileriye taşır. Ancak ilerlemenin de bir maliyeti vardır: geliştirici topluluğu, yeni yetenekler ve özellikler ekleyerek yapı taşlarını sürekli olarak ayarlar. Bu, teknoloji çözümlerini kodlamak için kullanılan temel dilleri içerir.
Yapı taşları değiştiğinde, teknoloji çözümünün arkasındaki kod da değişmelidir. Kaynakları tüketen zorlu ve zaman alıcı bir alıştırmadır. Ama ya bir alternatif varsa?
Sorun: Başka birinin yazdığı kodu okumak
Bir adım geriye gidelim ve geliştirmedeki temel zorluklardan birine bir göz atalım: başka birinin kodunu düzenlemek. Yeni yazdığınız veya birkaç hafta önce yazdığınız kodu düzenlemek, gayet iyi. Ancak yıllar önce yazılmış kendi kodunuzu düzenlemek – başkasının kodunu boşverin – bu farklı bir hikaye.
Kurum içi kod stili kuralları yardımcı olabilir, ancak değişkenler ve işlevler için her zaman garip adlandırma kuralları veya algoritmalar için olağandışı seçenekler vardır. Muhtemelen, bir programcının kod okuma yeteneği önemli bir beceridir – ancak bu herkes için zordur.
Geliştiriciler, eski kodu düzenleme sürecini “yeniden düzenleme” olarak adlandırır ve bu, genellikle yeni hatalar veya performans sorunları ortaya çıkaran bir süreçtir. Bu nedenle, geri dönüp eski kodu düzenlemek, pek çok geliştirme ekibinin yapmak isteyeceği en son şeydir, özellikle de mevcut kod tabanı kararlı çalışıyorsa ve işini yapıyorsa.
Bu gerçek bir baş ağrısı, ama bazen alternatif yok
Yeniden düzenleme, her geliştiricinin mümkün olduğunca uzun süre kaçınmak istediği bir şeydir çünkü zaman kaybı gibi gelebilir. Bununla birlikte, geliştiriciler çeşitli nedenlerle zaman zaman yeniden düzenleme yapmalıdır ve en yaygın nedenlerden biri geliştirici yapı taşlarındaki değişikliklerden kaynaklanmaktadır.
Buna, yazılım oluşturmak için kullanılan ve zaman içinde kaçınılmaz olarak gelişen programlama dillerinde yapılan değişiklikler dahildir. Bir dilin yeni sürümleri, yeni özellikler sunarken genellikle eski iş yapma yöntemlerini kullanımdan kaldıracaktır. Geliştiriciler yeni dil sürümünü benimsemezlerse, yeni özellik setinden hariç tutulurlar.
Ancak, mevcut kodun genellikle dilin yeni sürümünde çalışması için ayarlanması gerekir ve bu, yeniden düzenleme sürecini gerektirir. İşte muamma: Bir dilin yeni, daha gelişmiş sürümünü benimsemek için geliştiricilerin yeniden düzenleme yapmaları gerekir ve bu süreçte çok fazla çaba harcarlar – ve her türlü beklenmedik şeyi kırarlar, bir uygulamaya yeni hatalar eklerler. gayet iyi koşuyordu.
Daha da kötüsü, yeniden düzenleme tek başına size yeni dil sürümünün avantajlarını sağlamaz, bunun yerine iyileştirmelerden yararlanmak için kod tabanınızı yeniden geliştirmeniz gerekir. Aksi takdirde, kodu yeni dil sürümüne uyacak şekilde ayarlamanıza rağmen, eskiden olduğunuz yerdesiniz: yeni bir dil sürümünde çalışan, ancak yeni özellikleri olmayan bir kod tabanı.
Satıcılar genellikle son kullanıcıların bununla ilgilenmesini sağlar
Bu anlamsız bir alıştırma gibi görünebilir, ancak teknoloji değişiminin istikrarlı yürüyüşüyle, bu konuda genellikle çok az seçenek vardır – teknoloji ortaklarınız sizin için seçim yapar.
Diyelim ki Python 2.7’den Python 3.0’a yeni geçtik. Uygulamalarınızı şirket içinde geliştiriyorsanız, tam kontrol sizdedir ve geçişi yapabilir veya yapamayabilirsiniz. Öte yandan geliştiriciler, işleri olduğu gibi bırakmaya karar verebilir. Bir uygulama Python 2.7 için geliştirildiyse ve üzerinde çalışıyorsa, geliştirici onu olduğu gibi bırakır ve kullanıcılara diğer sürümleri desteklemeyen Python 2.7 için bir uygulamanın geliştirildiğini söyler.
Kullanıcıları zor durumda bırakabilir – uygulamaya uyum sağlamak için Python 2.7’nin eski sürümünde kalın, ilerlemeyi geride bırakın veya Python 3.0’a geçin ve uygulamalarla bir dizi uyumsuzluk riskini alın.
Net sonuç: büyük bir güvenlik riski
Programlama dilleri (ve bunların çeşitli kitaplıkları) güvenlik açıklarına karşı bağışık değildir. Bu güvenlik açıkları ortaya çıktığında, geliştiriciler tarafından bir dil sürümü yükseltmesi sizi zorlayabilir.
Ancak bu yükseltmeler, basit hata düzeltmeleriyle sınırlı olmayacak – dil yapılarının, getirilen yeni yapılarla birlikte kullanımdan kaldırılmasını getirecek ve bu, geliştiricileri, yine olası tüm sorunlarla birlikte, mevcut kodda değişiklik yapma hareketlerinden geçmeye zorlayacaktır. getiriyor.
Dahil edilen kitaplıkların bileşik etkisini düşündüğünüzde durum daha da kötüleşir. Dil değişikliklerinden sonra bu kitaplıkların da güncellenmesi gerekir – ancak kullanımdaki kitaplıklardan biri yazarları tarafından güncellenmezse, geliştirici kodun geri kalanını daha yeni bir sürüme yükselttikten sonra onu kullanamaz ve yine bu daha fazla kod yazmak için.
Her şeyin nereye varacağını görmek kolaydır: daha fazla çaba, ek hata oluşturma riskleri… ve güncellemeleri karşılamak için yeniden düzenlemeye devam etme isteksizliği. Sonraki? Güncellemeler basitçe tamamlanmaz, bu da iş yüklerinin güvenli olmayan, eski yapı taşlarına dayandığı anlamına gelir.
Hikaye, eski ve savunmasız yapı taşları siber saldırılara açık kapı bıraktığından, teknoloji dünyasının her yerinde gördüğümüze benziyor. Bununla birlikte, ortaya çıkan bazı iyi haberler var.
Daha iyi bir çözüm var mı?
Örneğin, desteklenmeyen işletim sistemlerini ele alalım. Geçmişte, ne zaman bir işletim sistemi ömrünün sonuna ulaştı, tek seçenek daha yeni bir işletim sistemine geçmekti – büyük bir yatırım ve risklerle dolu. Net sonuç, birçok kuruluşun kritik iş yükleri için bile yama uygulanmamış, desteklenmeyen işletim sistemlerine güvenmesidir. Güncellenmiş uygulamalarınız yoksa, geliştiriciler eski kod tabanlarını yeniden düzenlemeyeceklerinden, uygulamalarınızı dilin eski sürümlerini desteklemeyen daha yeni işletim sistemlerine taşıyamazsınız ve böylece uygulamayı bozamazsınız.
Neyse ki, bu senaryo değişti yaşam sonu desteği artık birçok Linux işletim sistemi için bir gerçekbu, kuruluşların herhangi bir güvenlik riski almadan, desteklenmeyen bir işletim sisteminden resmi satıcı desteğine sahip bir işletim sistemine geçiş yapmak için zaman kazanabilecekleri anlamına gelir.
Dil sürümleri için benzer bir şey yapılabilir mi? Bir dil çalışma zamanını en son güvenlik düzeltmeleriyle etkin bir şekilde “yükseltmenin” ve aynı zamanda belirli dil sürümünün veya kitaplıkların çalışma şeklini değiştirmeden, böylece yeniden düzenleme ihtiyacını ortadan kaldırmanın bir yolu mu?
İşletim sistemleri için elde edilenleri tekrarlamak ve bunu dil sürümlerine uygulamak, geliştiricilere muazzam bir nefes alma alanı sunacak ve sürekli yeniden düzenleme ihtiyacını azaltacaktır. Buna karşılık, iş yüklerinin güvenli ve güvenli bir şekilde çalışma olasılığı daha yüksektir.
Mümkün mü? Peki, işletim sistemleri için elde edilenler diğer alanlara genişletilebilir. Bu alanı izle.