Yıllar sonra da çalışacak kod yazma
Programlama dilleri değişir. Kütüphaneler değişir. 5, 10 ve hatta 20 yıl önceki bazı kodlar yine de çalışıp beklenen sonuçları üretebilirken, 2 yıllık bazı kodlar sözdizimi hatasıyla başarısız olabilir. Bu diller kaçınılmazdır, çünkü diller gelişmektedir (en azından çoğu). Geliştiricilerin kodlarını koruma sorumluluğu vardır. Ancak bazen, kararlılık üretim kodunda önemli bir gereksinimdir ve kod, her yıl kod değişikliklerinden birinin dil değişikliklerine adapte olması gerekmeden 10 yıl boyunca çalışmalıdır. Ya da örneğin bilimsel veri analizi için yıllarca dokunmadan tekrar ziyaret etmem gereken küçük senaryolarım olabilir. Örneğin, meteoroloji bürolarında, hıza bağlı olmayan parçalar için bile çok sayıda operasyonel Fortran kodu vardır ve kod kararlılığı bunun nedenlerinden biridir. BEN' dengesizlik korkusunun, Python'a taşınmaya karşı sahip oldukları nesnelerden biri olduğunu duydum (elbette dil ataleti dışında; sadece eski koda bağımlı olmayan yeni kodlar için mümkündür). Elbette, kararlı kod için bir strateji tüm işletim sistemini dondurmaktır. Ancak bu her zaman mümkün değildir.
Örnek olarak Python kullanıyorum, ancak sorun özellikle Python ile sınırlı değildir.
Python uyumluluğu ile ilgili belgeler
Python söz konusu olduğunda, geriye dönük uyumsuz değişiklikler politikasını özetleyen birkaç belge vardır.
PEP-5
PEP 5'e göre :
Python'un geçiş versiyonunun yayınlanması ile geriye dönük uyumsuz versiyonun yayınlanması arasında en az bir yıllık bir geçiş dönemi olmalıdır. Kullanıcıların programlarını test etmek ve kullanımdan kaldırılmış yapıyı kullanmaktan alternatif olana geçirmek için en az bir yılı olacaktır.
Şahsen, bir yılın oldukça kısa olduğunu düşünüyorum. Bazı kodlar yazabileceğim anlamına geliyor ve bundan 1½ yıl sonra artık çalışmayacak.
PEP 291
PEP 291 , geriye dönük uyumluluğu korumak için kaçınılması gereken şeylerin eksik bir kılavuz listesini içerir. Ancak, sadece Python 2.x ile ilgilidir. Python 2.7 2.x serisinin son sürümü ve Python 2.7 sadece hata düzeltmesi olduğundan, bu PEP artık sadece tarihsel ilgi içindedir.
PEP 387
Geriye dönük uyumsuz değişikliklerde de PEP 387 vardır . PEP 387 resmi bir politika değil taslaktır. Haziran 2009'da, bu Python-ideas posta listesinde tartışıldı . Tartışmanın bir kısmı, geliştiricilerin dil değişikliklerine karşı sağlam kod nasıl yazabileceklerine odaklandı. Bir gönderide ne yapmamanız gerektiğine dair bazı tavsiyeler listelenmiştir :
Bununla birlikte, çoğu zaman doğru olabilecek çıkarım yapabileceğiniz birkaç kural vardır: başlangıçtan bir şeyleri çağırma
"_", hiçbir şeyi maymun yamalama, kendi sınıfınız dışındaki sınıflardaki nesnelerde dinamik sınıf değiştirme kullanma , miras hiyerarşilerinin derinliğine bağlı kalmayın (örneğin, hayır".__bases__[0].__bases__[0]"), testlerinizin herhangi bir DeprecationWarnings üretmeden çalıştığından emin olun, diğer kütüphanelerden miras alan sınıflara öznitelik eklerken potansiyel ad alanı çakışmalarına dikkat edin. Bütün bunların tek bir yerde yazıldığını sanmıyorum.
Buna ek olarak, "maden sahaları" (değişmesi muhtemel yeni özellikler) ve "donmuş alanlar" (çok satılan API'lerin neredeyse değişmemesi garanti edilen) hakkında bazı noktalar vardı. Antoine Pitrou'dan alıntı :
"Donmuş alan" negatif (açık bir "mayın alanı" yerine, olumlu (açık ortak API'ler ve açıkça garanti davranış) tanımlanması gerektiğini düşünüyorum. Aksi takdirde, mayın tarlasına bazı önemli şeyleri koymayı ve daha sonra geriye dönük uyumsuz bir şekilde değiştirmemiz gerektiğinde ısırılmayı unutacağız.
Bu iş parçacığından herhangi bir sonuç yok gibi görünüyor, ancak aradığım şeyin çekirdeğine oldukça yaklaşıyor. İplik neredeyse dört yaşında, bu yüzden belki de durum değişti veya iyileşti. Ne tür bir kodun hayatta kalması muhtemeldir ve ne tür bir kod daha kırılgandır?
Taşıma yönergeleri
Yukarıda belirtilen belgelerin yanı sıra, her bir Python sürümü Taşıma işlemi kılavuz ile birlikte: Python 3.2 için taşıma , Python 3.3 taşıma vs.
Yararlı uyumluluk
PEP 3151 beni kullanışlı uyumluluk kavramıyla tanıştırdı . Kendi sözlerimle, bu sadece kod dikkatlice yazılmışsa dil geliştiricilerin uyumluluğu korumak için dikkatli olmaları gerektiği fikrine dayanır. Gerçekten kullanışlı bir uyumluluk tanımlamıyor , ancak yukarıdaki PEP 387 tartışmasından alıntıladığım fikirlere benzediğini düşünüyorum.
Programcıların bakış açısından
Bir programcı olarak, Python'un gelecekte değişeceğini ve insanların - en önemlisi kendimin - belki birkaç yıl sonra bir, iki veya belki de üç küçük sürüm olan bir Python sürümünde çalıştırmaya çalışacağını biliyorum. Her şey uyumlu olmayacak ve aslında başarısız olacak kod ile gelmek kolay (bir kez kod belirleme ile karşılaştım if sys.version[:3] != '2.3': print 'Wrong version, exiting'). Ne aradığım üzerinde kurallar kümesidir ne yapacağını ve hangi değil yapmak benim kod hala gelecekte değiştirilmemiş çalışacağı şansını artırmak için.
Bu tür yönergeler var mı? Gelecekte hala çalışacak Python kodunu nasıl yazarım?
Sorum standart kütüphanesine değil, aynı zamanda sık kullanılan, Python çekirdeğine hem ilgilidir eklenti kütüphanelerde, özellikle numpy, scipy, matplotlib.
DÜZENLEME : Şimdiye kadar cevapların ikisi python2 ile python3 arasındadır. Demek istediğim bu değil. Python2'den Python3'e taşınacak araçları biliyorum. Sorum henüz gelecek dil değişiklikleri ile ilgili . Daha kararlı olan kodlama kılavuzlarını bulmak için kristal bir toptan daha iyisini yapabiliriz . Örneğin:
import moduledaha geleceğe dönüktürfrom module import *eğer ikincisi kodu kırabilecek çünkümodulebir veya daha fazla yeni işlevleri / sınıfları yetişir.Belgelenmemiş yöntemlerin kullanılması, belgelenmemiş yöntemlerin kullanılmasından daha az geleceğe dönük olabilir, çünkü belgelenmemiş bir şey henüz kararlı olmayan bir şeyin işareti olabilir.
Benim peşimde olduğum bu tür pratik kodlama önerileri. Şimdiki → gelecekle ilgili olduğundan, kendimizi Python3 ile sınırlayabiliriz, çünkü Python2 artık değişmeyecek.