Dinamik diller çevik gelişim için dezavantajlı mıdır?

Çevik gelişimi okuduğumdan genellikle yeniden düzenleme veya mühendislik kodunu diyagramlara dönüştürmeyi içerir. Elbette bundan çok daha fazlası var, ancak bu iki yönteme dayanan uygulamaları düşünürsek, dezavantajlı olarak dinamik olarak yazılmış diller mi?

Statik olarak yazılan diller yeniden düzenleme ve tersine mühendislik işlemlerini çok daha kolay hale getirecek gibi görünüyor.

Dinamik olarak yazılan dillerde imkansız değilse, yeniden düzenleme veya (otomatik) tersine mühendislik zor mu? Gerçek dünya projeleri, çevik metodoloji için dinamik olarak yazılan dillerin kullanımı hakkında ne anlatıyor?

Dinamik diller teorik olarak dezavantajlıdır, diğer her şey eşittir, çünkü kodun nasıl çalıştığı hakkında (kısıtlamaların ne olduğu) daha az belirtirler ve bu nedenle yeniden düzenlemenin daha azı otomatik olarak yapılabilir ve ortaya çıkan problemler de otomatik olarak algılanamaz .

Fakat diğer her şey eşit değildir. En popüler dinamik diller, oldukça kompakt ancak anlaşılabilir bir kod sağlar, bu da genellikle bunları daha hızlı geliştirir ve mantığı (yeniden düzenlemede değişebilir) görsel olarak fark etmeyi kolaylaştırır. Dinamik bir dilde çalışmanın göreceli avantajlarından bazılarını kaybedebilmenize rağmen, özellikle de yeniden düzenlemenizi yine de elle yapmayı planlıyorsanız, yine de öne çıkabilirsiniz.

Öte yandan, dinamik dillerle aynı avantajlara sahip statik olarak yazılmış diller vardır (yani kompakt ve anlaşılabilir - çoğunlukla çıkartılan türlerle, ancak orada çok fazladır): Haskell belki de önde gelen örnektir, ancak OCaML / F #, Scala, ve diğerleri de bu kategoridedir. Ne yazık ki, en popüler statik olarak yazılan dillerden daha az kullanıldıkları için, onlar için (örneğin yeniden düzenleme için) kapsamlı araç setlerine sahip değillerdir.

Sonuç olarak, çoğu dilde çevik metodolojilerle yeterince çalışacağınızı düşünüyorum; Uygulama henüz teoriyi yakalayamadığı için şu anda açık bir kazanan olduğunu söyleyemem.

Otomatik yeniden düzenleme, dinamik olarak yazılmış bir dil olan Smalltalk'ta icat edildi. Yani hayır, dinamik olarak yazılmış bir dilde otomatik yeniden düzenleme yapmak imkansız değil. Ne kadar zor olduğu, yazma disiplininin yanı sıra diğer faktörlere de bağlıdır. C ++ ve Java'nın her ikisi de statik olarak yazılmıştır, ancak yeniden düzenleme araçları yalnızca Java için gerçekten mevcuttur. Smalltalk, içgözlemi ve basit sözdizimi ile araçları yeniden düzenleme için gerçekten iyi bir adaydı.

Bazı açılardan, dinamik yazma aslında yeniden düzenlemeyi kolaylaştırır. İyi bir test paketiniz varsa, yeniden düzenleme işlemlerinizin hiçbir şey yapmadığından emin olabilirsiniz. Dinamik olarak yazılan kod tabanı genellikle daha küçüktür. Ayrıca, yeniden düzenleme işlemleri daha az kodu etkileme eğilimindedir. Dinamik kod tabanını manuel olarak yeniden düzenleme çabaları, statik kod tabanından daha azdır.

Yeniden düzenleme dinamik dillerde icat edildi. Otomatik Yeniden Düzenleme Araçları dinamik dillerde icat edildi. IDE'ler dinamik dillerde icat edildi. Dinamik dillerde birkaç Çevik Metodoloji icat edildi.

Gerçekten herhangi bir sorun görmüyorum.

Unutmayalım ki, Extreme Programming (XP) olarak bilinen "Agile" çalışma şekli bir Smalltalk projesinde oluşturuldu (ve Smalltalk kesinlikle "dinamik" bir dil olarak sayılır).

Dinamik olarak yazılan bir dille sağlanan bir yeniden düzenleme aracının endüstriyel kullanımına ilişkin bir örnek olay incelemesi:

Cargill'de tahıl asansörlerinin çalışmasını ve buna bağlı emtia ticareti faaliyetlerini desteklemek için çok büyük bir Smalltalk uygulaması geliştirildi. Smalltalk istemci uygulamasında 385 pencere ve 5.000'in üzerinde sınıf bulunmaktadır. Bu uygulamadaki yaklaşık 2.000 sınıf erken (1993 dolaylarında) veri erişim çerçevesiyle etkileşime girdi. Çerçeve, dinamik olarak nesne özniteliklerinin veri tablosu sütunlarına eşlenmesini gerçekleştirmiştir.

Analizler, dinamik aramanın istemci yürütme süresinin% 40'ını tüketmesine rağmen, gereksiz olduğunu gösterdi.

Business class'ın açıkça kodlanmış bir yöntemle sütun eşlemesine nesne niteliğini sağlamasını gerektiren yeni bir veri katmanı arayüzü geliştirildi. Testler, bu arayüzün daha hızlı büyüklük sırası olduğunu gösterdi. Sorun, veri katmanının 2.100 business class kullanıcısını nasıl değiştireceğiydi.

Geliştirilmekte olan büyük bir uygulama, bir arabirimin dönüşümü oluşturulurken ve test edilirken kodu dondurmaz. Dönüşümleri, kod deposunun paralel bir dalında ana geliştirme akışından oluşturmak ve test etmek zorunda kaldık. Dönüşüm tamamen test edildiğinde, tek bir işlemle ana kod akışına uygulandı.

17.100 değişiklikte 35'den az hata bulundu. Tüm hatalar üç haftalık bir sürede hızla çözüldü.

Değişiklikler manuel olarak yapıldıysa, dönüşüm kurallarının geliştirilmesi için 235 saat ile karşılaştırıldığında 8.500 saat süreceğini tahmin ediyoruz.

Görev, Yeniden Yazma Kuralları kullanılarak beklenen sürenin% 3'ünde tamamlandı. Bu 36 faktörlü bir gelişmedir.

"Uygulama veri katmanının dönüşümü" nden Will Loew-Blosser OOPSLA 2002

Ayrıca - "İmkansız değişiklikler yapmak için araçlar - büyük Smalltalk programlarını dönüştürmek için bir araçla deneyimler"

İlkelerin bana doğru geldi .

C # gibi güçlü yazılan diller, sürekli olarak yeniden faktoring gerektiren bir kod tabanı için iyi adaylardır. Temel olarak piyasadaki çoğu yeniden faktoring aracı (Resharper, JustCode vb.) Statik olarak yazılan programlama dillerinde çok etkilidir.

Gerçek dünya projeleri, çevik metodoloji için dinamik olarak yazılan dillerin kullanımı hakkında ne anlatıyor?

Çevik / Scrum metodolojisini uygulayan geliştirme ekibi için, zırh altında iyi bir yeniden faktoring aracı setine sahip olmak çok yararlı (hatta kritik). Aksi takdirde, gelecek süratteki tüm ani değişiklikler, değiştirilmesi veya yeniden tasarlanması için bir kabus olabilir.

Bu nedenle, çevik metodoloji statik olarak yazılan dillere veya dinamiklere bir kez avantaj sağlamaz. Sağladığı, sağlam bir uygulama oluşturmak için yinelemeli bir yaklaşımdır.