Yazılıma Bakalım Mı?

Yazılım Mühendisliği

Daha önceki yazılarda sıklıkla, yazılımın değişmek için geliştirildiğini ve değişmenin yazılım için kaçınılmaz olduğunu yazdım. Bu anlamda bu yazı, bu yazının devamı niteliğinde ama başlığını değiştirdim.

Yazılımın bakımı ya da kısaca İngilizcesiyle “maintenance” dediğimiz sürece biraz daha yakından bakalım bu yazıda.

IEEE’nin 1219 nolu standardına göre yazılım bakımı yani software maintenance şöyle tanımlanıyor:

“the modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a modified environment.”

Yani

“müşteriye teslimden sonra, hataları gidermek, performans ve diğer özellikleri iyileştirmek, ya da farklı bir ortama uyarlamak için yazılım ürününün değiştirilmesidir. ”

Bakım dediğimizde kabaca şu dört çalışmadan birisini anlarız:

Düzeltme ya da iyileştirme (corrective): Bu tür bakımda yazılım sisteminin hataları giderilir, yani “bug fix” dediğimiz çalışmaları içerir. Yazılım sistemindeki hatalar bazen ihtiyaçların yanlış-eksik alınmasından, bazen tasarım hatalarından bazen de her şeye rağmen yanlış kodlamadan kaynaklanır. Belli ki bu hatalar testlerde de yakalanmamış ve müşterinin önüne kadar gelmiştir.

Uyarlama (adaptive): Bu tür bakım yazılım sistemini yeni ortamlara hazırlamak içın yapılır. Yeni donanım, yeni yazılım vb., yazılımın ortamındaki yeniliklere uyum sağlamak için yapılan değişikliklerdir. Sistemi yeni donanım ya da işletim sistemi ortamına taşımak, derleyicinin (compiler) ya da örneğin JVM’in sürümünü değiştirmek bu türden uyarlama çalışmalarıdır.

Yeni geliştirme (ya da zenginleştirme)/mükkemelleştirme (enhancement/perfective): Bu tür bakımda yazılıma yeni davranışlar katılır. Yeni süreçler, yeni iş kuralları, yeni kısıtlar vb. fonksiyonel yapılar yazılıma kazandırılır. Örneğin yeni tür kullanıcılar sisteme yeni ihtiyaçlarla katılırlar.

Önleyici (preventive): Yazılımın zamanla kalitesinin düşmesi karşısında yapılan ve yazılımın kalitesini arttırmaya yönelik bakım çalışmalarıdır. Bu türden çalışmalar “reengineering” olarak da adlandırılır. Mimari iyileştirmeler, sistemin modülerliğini arttırıcı, alt yapıların birbirlerine olan bağımlılıklarını azaltıcı yöndeki çalışmalar hep bu türdendir.

Tabi olarak yazılıma yapılan bir türden değişiklik başka türden bir değişikliği tetikleyebilir. Örneğin bir hatanın giderilmesi bazı mimari iyileştirmeleri gerekli kılabilir. Ya da bazı mimari iyileştirmeler için derleyicinin sürümünü yükseltmek ya da sistemi farklı bir platforma taşımak gerekebilir. P. Grubb ve A. A. Takang’ın “Software Maintenance” isimli kitabında bu ilişkiler şöyle resmedilmektedir:

Yazılımın bakımını etkileyen pek çok faktör vardır. Yazılımın tipi, kullanıcı çeşitliliği ve eğitim seviyesi, yazılımın yerine getirdiği iş süreçlerinin ve kurallarının tabiatı, hep bakımla ilgili belirleyici etkenlerdendir.

Bakımın mahiyetini daha iyi anlamak için Robert L. Glass’ın 2002 yılında basılmış olan “Fact and Fallacies of Software Engineering” isimli kitabındaki gerçeklerden bakım ile ilgili olan beş tanesini aktarmak istiyorum.

Adı geçen kitabın 41 numaralı gerçeği de şudur:

“Maintenance typically consumes 40 to 80 percent (average, 60 percent) of software costs. Therefore, it is probably the most important life cycle phase of software.”

Yani

“Bakım yazılımın maliyetinin tipik olarak %40 ila %80’ini (ortalama olarak %60) oluşturur. Bu yüzden muhtemelen yazılımın hayat döngüsündeki en önemli kısımdır.”

Bundan daha önce de bahsetmiştik: “Değiştirmek için geliştirmek.”

Aynı kitabın 42. gerçeği ise şudur:

“Enhancement is responsible for roughly 60 percent of software maintenance costs. Error correction is roughly 17 percent. Therefore, software maintenance is largely about adding new capability to old software, not fixing it.”

Yani

“Yeni geliştirmeler yazılım bakım maliyetinin kabaca %60’ını oluşturmaktadır. Hata giderme kabaca %17sini oluşturmaktadır. Dolayısıyla, yazılım bakımı, hataları gidermekten ziyade çoğunlukla yazılıma yeni yetkinlikler kazandırmaktır.”

Glass, kitabında bu son iki gerçeği 60/60 kuralı olarak birleştirir. Yani yazılımın bakımı, tüm maliyetinin %60’ını, yeni geliştirmeler ise bakımın maliyetinin %60’ını oluşturmaktadır. Buna göre eski yazılıma yeni özellikler kazandırmak pahalı bir iştir.

Kitabın 43. gerçeği ise şudur:

“Maintenance is a solution, not a problem.”

Yani

“Bakım bir çözümdür, problem değildir.”

Bu madde gerçekten çok bir fikir gibi görünmekle birlikte ciddi bir yanlışımıza parmak basıyor. Yazılım bakımını bir dert olarak görmek sağlıklı bir bakış açısı değildir. Çoğu zaman yazılımın bakımını dert oalrak görme eğiliminde oluruz. Halbuki bakım, yazılımı yaşatan şeydir. Bakımı yapılmayan yazılım muhtemelen kısa süre içinde kullanımdan da kalkacaktır.

Kitabın 44. gerçeği ise şöyle:

“In examining the tasks of software development versus software maintenance, most of the tasks are the same—except for the additional maintenance task of “understanding the existing product.” This task consumes roughly 30 percent of the total maintenance time and is the dominant maintenance activity. Thus it is possible to claim that maintenance is a more difficult task than development.”

Yani

“Yazılım geliştirme ve yazılım bakımı işleri incelendiğinde, ‘var olan sistemin anlaşılması’  şeklindeki fazladan bir bakım işi dışında”, pek çok iş aynıdır. Bu fazladan iş ise toplam bakım zamanının yaklaşık olarak %30’unu almaktadır ve en baskın bakım çalışmasıdır. Bu yüzden bakımın, geliştirmeden daha zor bir iş olduğu iddia edilebilir.”

Kitabın 45. ve bakım ile ilgili son gerçeği ise şöyle:

“Better software engineering development leads to more maintenance, not less.”

Yani

“Daha iyi yazılım mühendisliği gelişimi daha az değil daha fazla bakıma yol açar.

Bu insana ters gelen bir durum değil mi? İlk etapta “nasıl yani” dedirtiyor insana ama şu gerçeği gözden kaçırmayalım. Daha kaliteli yazılım, daha çok değişme demektir. Çünkü kaliteli yazılımlar değişir, kalitesiz yazılımlar, değişimi zor olduğundan kenara atılırlar, yerlerine daha yeni ve kaliteli olan yazılımlar gelir. Dolayısıyla, modern zamanlarda yazılımın bakım maliyeti, önceki zamanlara göre artmaktadır:

Maintenance Cost by Years

Yukarıda bu durum resmedilmiştir. (Bu diyagramı http://www.omnext.net/downloads/Whitepaper_Omnext.pdf  adresindeki “How to save on software maintenance costs” başlıklı Mart 2010 tarihli bir Omnex araştırmasından aldım.) Konu ile ilgili buradaki Schach’in kitabından alınan diyagramlara da bakabilirsiniz.

Konuyla ilgili bazı online kaynaklar şunlardır:

 

Toplam görüntülenme sayısı: 1870

Yazılım ve Değişim – II

Yazılım Mühendisliği

Bu blogda sıklıkla söyleyip, vurguluyorum:  Yazılımın bakımı, geliştirilmesinden daha pahalıdır. Hatta şu cümleyi slogan gibi tekrarlarım. “Yazılımı geliştirmeye odaklananlar yanlış yapıyorlar. Yazılımı geliştirirken odaklanılması gereken şey, onun ileride nasıl değişeceği olmalı. Yazılımın en temel kalite sıfatı ne kadar rahat değişebildiğidir çünkü. Bu konuyu burada da ele almıştım, özellikle diğer mühendislik dallarındaki değişimin tabiatıyla, yazılımdaki değişimin tabiatının çok farklı olduğunu vurgulamıştım. Şimdi biraz daha bu konunun üzerine gidelim.

Problem şu ki ülkede yazılımı yönetenler de dahil olmak üzere hemen herkes öyle ya da böyle yazılımı “geliştirmeye” odaklanmış durumda. Nedense yazılım için değişimin mahiyetini ve önemini algılamış durumda değiliz. Uzun vadeli düşünemeyeşimiz, hayatımızı uzun vadeli stratejiler yerine günlük taktikler üzerine kurguluyor olmamız, yazılıma yaklaşımımızı da etkiliyor tabi olarak.

“Yazılımı hızlıca bitirelim, piyasaya sürelim, …yı kaçırmayalım”, “müşterinin tarihlerine uyalım, faturamızı keselim”, “iş birimi ne olursa olsun … tarihine yetişmesini istiyor” vb. sözler, bizim yazılımla ilgili en temel gerçeği görmemizi engelliyor. Bu gibi baskılar, bazen müşteri beklentilerinden, bazen ekonomik zorunluluklardan bazen de aynı kurumdaki iş birimlerinin kaprislerinden, neyden kaynaklanırsa kaynaklansın, bizim yazılımla ilgili en temel gerçeği görmemizi, dolayısıyla yazılımın ekonomisini anlamamızı engelliyor. Yazılım ile ilgili en temel gerçeğin ilk kısmı, yazılımı geliştirmenin çok da önemli olmadığı, şu ya da bu şekilde herhangi birisinin bir yazılım geliştirebileceğidir. Bu gerçeğin tamamlayıcı diğer yarısı ise, bir yazılımın fikir olarak akla gelişinden, gelişitirilip, devreye alınıp, sonrasında bakımının yapılıp, nihayetinde kullanımdan kaldırılmasına kadar geçen sürede yapılan masrafın büyük bir kısmının aslında o yazılımı geliştirmeye değil, geliştirdikten sonra değiştirmeye harcanıyor olmasıdır. Yani yazılımın bakımı, geliştirilmesinden çok daha pahalıdır. Maliyet en önemli unsursa, yazılımın bakımı, geliştirilmesinden çok daha önemlidir demektir.

Aşağıda, yukarıda bahsedilen durum, Stephen Schach’ın “Object Oriented And Classical Software Engineering” isimli kitabının 8. baskısında aşağıdaki iki diyagramda resmedilmiştir:

Maintenance Costs

Bu diyagramlardan ilki 1976-81, ikincisi ise 92-98 yılları arası için verilmiştir.

Bu iki diyagram bize iki şeyi söylüyor: İlki yukarıda özetlediğim gerçek, yazılımın bakımı, geliştirilmesinden daha pahalıdır. Diğeri ise yıllar geçtikçe yazılımın bakım maliyetinin tüm maliyeti içindeki payının artması. Bu durum bize ters gelebilir ama malesef, yazılımla ilgili bilgi ve tecrübemiz arttıkça, yazılımların bakım maliyetleri azalmıyor, aksine artıyor. Bunun en temel sebebi de yazılımların büyümesi, hayatımızda daha fazla yerde olması ve sonucunda değişiminin de daha büyük çaplarda olmasıdır. Yazılım ile ilgili teknolojilerin ve yaklaşımların gittikçe daha ileri, faydalı ve uygulanabilir olması, yazılımı geliştirmeyi ve bakımını yapmayı daha kolay hale getirmiyor.

Ben buradaki rakamalrın ülkemiz için biraz daha farklı olduğunu düşünüyorum. Memleketimizde bakımın maliyetinin, tüm yazılım maliyet içinde %90’dan az olmadığını düşünüyorum. O kadar ki pek çok proje bakımda tamamlanıyor. Pek çok yazılım evi bakımla ayakta duruyor. Proje sözleşmesinde üzerinde hem fikir olunan pek çok özellik, düzgün bir planlama olmamasından ve farklı niyetlerden dolayı ancak bakımda tamamlanabiliyor.

Yazılımı geliştirmenin zor olduğu şeklindeki algımızın büyük kısmı aslında değiştirmenin zor olmasından kaynaklanıyor. Yukarıda da bahsettiğim gibi yazılımı herhangi bir sekilde geliştirmek kesinlikle zor değildir. Bu durum, belli becerilere sahip bir kimsenin bir araba yapmasından farklı değildir. Ama problem şurdadır ki herhangi bir kimsenin yaptığı arabaya çok ucuz bile olsa para verip almak istemeyiz. Çünkü kalitesi hakkında ciddi endişelere sahip oluruz. Bu durumu ünlü Gerald Weinberg çok veciz bir şekilde şöyle belirtiyor:

“If builders built houses the way programmers built programs, the first woodpecker to come along would destroy civilization.”

Yani

“Eğer inşaatçılar binalarını, programcıların programlarını yazdıkları gibi dikselerdi, ilk gelen ağaçkakan medeniyeti yerler bir ederdi.“

Komik ama bir o kadar da gerçek değil mi?

Yazılımda aslolan, değiştirmek için geliştirmekdir. GoF bunu “design for change” yani “değişim için tasarla” diye ifade ediyor. İnsanlar, inşaat mühendisleri ve mimarların tasarlayıp ürettikleri binalarda, sadece barınma aramakla kalmıyor, nasıl rahatlık, konfor, dayanıklılık vb. sıfatlar da arıyorlarsa biz yazılımcılar da yazılımlarımızın sadece fonksiyonel olarak müşteriyi tatmin eder noktada kalmasını değil, fonksiyonelliğin kalitesine de önem vermeliyiz. Foksiyonellikle ilgili en temel kalite maddesi ise, değişebilirliktir. Bu yüzden geliştirdiğimiz yazılım sistemlerinin, aynı zamanda müşterinin yeni isteklerini de hızlıca karşılayabilecek kalitede olmasını sağlamak zorundayız.

Yazılımcılara da bu konuda çok iş düşüyor. Daha rahat değişen mimariler ve nesne yapıları nasıl kurgulanır, katmanlar, modüller ve nesneler arasındaki bağımlılıklar (coupling) nasıl yönetilir, iş süreçleri ve iş kuralları nasıl esnek ve değişebilir yapılır, tüm bunlar yazılımcılar olarak bilmemiz gereken şeylerden. İşin açıkçası bu konularda iyi olduğumuz söylenemez. Bırakın bunları, daha doğru düzgün isimlendirme yapamadığımız kodlarımızla, esnek, hızlı değişen mimariler kurgulamak bize çok uzak malesef.

Değişimin kendisinin fark yaratan en büyük etken olduğu, değişimin hızının gittikçe yükseldiği bir devirde, yazılımların bu değişime ayak uydurmasını beklemek, iş birimleri için son derece normal. Ama onların da, bu beklentiyi sağlamanın, eskiden bu yana uyguladığımız yazılım geliştirme yöntem ve teknikleriyle olamayacağını anlamaları gerekli. Yani hem proje süresi, çalışan kalitesi ve iş gücü aynı kalsın ama daha büyük, daha donanımlı ve daha kolay değişen yazılımlar geliştirilsin. Hiç bir makul zihin bunu kabul etmez. Kalite, hız ve fiyatı düşündüğümüzde, her üçünde de en iyi durumda olamayız. En fazla ikisini seçip üçüncüden taviz vermek zorundayız. Bu durum “project triangle” oalrka da adlandırılır:

Proje üçgeni

Proje üçgeni şunu söyler bize: İkisini seç. Çünkü üçü bir arada olamaz.

Benzer şekilde yazılım müşterileri hızlı değişen yazılımlar istiyorlarsa, bedelini öngörmek ve buna göre yazılım geliştirilmesine rıza göstermek zorundalar. Fakat bu durumu onlara anlatacak kişiler ise bizleriz. 

 

Toplam görüntülenme sayısı: 1077

Java Kodunuzun Nesne-Merkezli Olmadığının 10 İşareti – IX: Demeter prensibini ihlal eden metotlar.

Java, Yazılım Mühendisliği

Geliştirdiğimiz Java kodunun nesne-merkezli olmadığının 10 işaretinin neler olduğunu bu yazıda listelemiş ve ilk yedi maddeyi daha önce ele almıştık. Şimdi de sekizinci maddeyi inceleyelim:

Demeter prensibini ihlal eden metotlara. (Methods that break the Demeter law.)

Demeter prensibi, bir nesnenin metotlarının, hangi nesnelerin metotlarını çağırabileceğini belirler. Buna göre bir nesnenin metotlarında, kendisi üzerinde metot çağrısı yapabileceği nesneler ancak şunlar olabilir:

  • kendisi,
  • nesne değişkenleri,
  • metoda geçilen parametre nesneler,
  • metotta oluşturulan nesneler.

Yani bir nesne ancak arkadaşlarıyla konuşur, yabancılarla konuşmaz.

Bu durumu bir örnekle açıklayalım: 

public class A{
   private B b;
	
   public void f(C c){
      h();                      // 0- Yapılabilir    
      b.g();		    	// 1- Yapılabilir
      c.u();		    	// 2- Yapılabilir
      D d = new D()
      d.v();		    	// 3- Yapılabilir
      E e = c.w();      
      e.z();	  //4- Yapma bunu! E’den iş isteme, C’den,                       //E'den iş istemesini talep et.
   }

   public void h(){
      ...
   }
}

 

Bir nesnenin metotdunda, o nesnenin diğer metotlarını çağırmak son derece tabidir. “0”de ifade edilen durum budur.

Demeter kuralına göre, bir nesnenin bir metodunda, o nesnenin değişkenlerinden olan nesneler üzerinde metot çağrısı yapabilirsiniz. “1”de ifade edilen durum budur. Bu normaldir çünkü, nesne değişkenleri, nesnenin parçalarıdır, beraber yaşadığı nesnelerdir.

“2”de ifade edilen satırda çağrılan “u()” metodu “f()” metoduna geçilen bir parametre olan “c” nesnesi üzerindeki bir metottur. Bu durum da normaldir çünkü, “c” nesnesi “f()” metoduna zaten işlenmek üzere argüman olarak geçilmektedir.

“3”de ifade edilen satırda çağrılan “v()” metodu da “f” metodunda oluşturulan D tipindeki bir “d” nesnesi üzerindeki bir metottur. Bu durum da normaldir çünkü, “d” nesnesi “f” metodunda zaten ihtiyaç olarak oluşturulmaktadır.

“4”deki durum ise yukarıdaki üç halden farklıdır çünkü bu satırda üzerinde metot çağrısı yapılan “E” tipindeki “e” nesnesi, “A” sınıfının nesnelerinin doğrudan bildiği bir nesne değildir.

Demeter kuralı, bize bir nesnesin sahip olabileceği bağımlılıklarla ilgili bilgi verir, olabildiğince az bağımlılık yaratarak programlama yapmamızı sağlar. Nesne, tabi olarak bildiği nesneler dışında kimseyle konuşmamalıdır, sdece ve sadece yakınında olan nesneleri bilmelidir. Bu yüzden bu prensibe “principle of least information” da denir, yani “en az bilgi prensibi”. Nesneler olabildğince az bilgi bilmelidirler. Nesneler sadece en yakınındaki nesneleri bilmelidirler. Bu durumu şöyle bir örnekle de açıklayabiliriz:

Bir şirkette müdür, müdürün sekreteri ve fotokopici olsun. Müdür bazı belgelerin fotokopisine ihtiyaç duyduğunda yapacağı şey, sekreterinden fotokopiciye gidip o belgelerin fotokopisini çektirmesini istemektir. Bu durumdaki haberleşme şekli makul olandır ve aşağıda gösterilmiştir:

Demeter1

Bir de şu durumu düşünün: Müdür sekreterden bunu istemek yerine, sekretere, “bana fotokopiciyi cağırır mısın” diye istekte bulunsa, müdür aslında konuşmaması gereken bir nesneye ulaşmış olacak ve konuşµa hiyerarşisi bozulacaktır. Bu durumu şöyle resmedebiliriz:

Demeter2

Demeter kuralına uymak, paketler, modüller, bileşenler ve katmanlar arasındaki haberleşmeyi düzenler. Demeter kuralına uymadığımızda bağımlılığı (coupling) yüksek yapılara sebep oluruz. Bu durumda da yazılımlarımızın bakımını yapmak çok zor olur, özellikle değişiklik yapmak çok maliyetli hale gelir.

PMD‘nin Coupling ölçütünün ölçümlerinden birisi de LawOfDemeter’dir ve burada bahsettigimiz prensibe uymayan erişimleri raporlar.

Kodda bu kuralı ihlal eden en temel kalıp, zincirleme erişimdir. Yani

...
Object o = a.getB().getC().getD().calculate();
...

şeklindeki kullanımlar aslında birbirlerinden hiç haberdar olmayan a nesnesi ve D‘nin nesnesini birbirine bağımlı kılar. Bir başka deyişle a nesnesi, hiç gerekmediği halde D‘nin nesnesini bilir, onun API’sinden haberdar olur, dondürdüğü değeri alır.

Bu tür zincirleme erişimlerin makul olabileceği yerleri düşündüğümüzde ilk akla gelen web katmanındaki view yapılarıdır. Örneğin, Java’nin web bileşenlerinden JSF kullandığınızda, view sayfalarında, arkadaki managed beanlere ulaşırken bu şekilde zincirleme özellik ulaşımı yaparsınız. Pek çok Java EE yapısı da açıkçası bu şekilde zincirleme erişimle çalışır. Fakat iş mantığı içınde ya da örneğin katmanlar arasında bu şekilde kısa yollar kurmak son derece sıkıntılıdır.

Demeter kuralı önemlidir, uyarak kod yazmak kodumuzu çok daha kaliteli kılacaktır.

 

Toplam görüntülenme sayısı: 1205

Modülerlik: Nesne-Merkezli ve Prosedürel Yaklaşım

Java, Yazılım Mühendisliği , , ,

Nesne-merkezli yaklaşımların, daha modüler dolayısıyla da daha basit ve anlaşılır yapılar üretmeye yatkın olduğu devamlı olarak söylenir. Fakat işin teorisi başka, pratiği ise başkadır. Şahsen ben bu durumun teoride böyle olduğunu bilmeme ve yazdığım kodlarda daima bu durumu uygulamama rağmen, herkes bu konuda aynı şekilde düşünmeyebilir ya da düşünse bile farklı sebeplerden dolayı bu şekilde davranmayabilir. Java ile kod yazıp da her türlü günahı kodlarında işleyen Javacılarla devalı karşılasıyorum, özellikle de sabahları aynaya bakınca 🙂

Aynı konuda meraklı iki araştırmacı, Lisa K. Ferrett ve Jeff Offutt 2002 yılında “An Empirical Comparison of Modularity of Procedural and Object-oriented Software” başlıklı bir makale yayınladılar. Offutt bir akademisyendir ve 90’lı yıllarda ben de Yazılım Mühendisliği yükek lisansında kendisinden ders almıştım. Bu makalede anlamak istedikleri şey, hakikatten nesne-merkezli dillerle yazılan yazılımların daha modüler olup olmadıklarını anlamak. Bu amaçla Internet üzerinden erişilebilen yazılımlardan 38 tanesinin açık olan kaynak kodunu malzeme olarka kullanmışlar. Makalede anlatıklarına göre 10 Fortran, 10 C, 10 C++ ve 8 Java uygulamasının kaynak kodunu incelemişler. Bu dillerden ilk ikisi prosedürel, diğer ikisi ise nesne-merkezlidir.  Bu deneysel çalışmada iki şeyi test etmek istiyorlar:

  1. Hakikatten nesne-merkezli programlar daha ufak modüllere sahipler mi?
  2. Nesne-merkezli programların modüllerine geçilen parametre sayısı ortalama olarak prosedürel programlardan daha mı az?

Bu amaçla yazarlar toplam 38 programın kaynak kodlarını, fonksyonarın satır sayısı ve fonksiyonlara geçilen parametre sayısı cinsinden analize tabi tutmuşlar. Bakın makalede yer alan sonuç tablolarını aşağıda sizinle paylaşıyorum:

Module Size

Yukarıdaki tablo, 4 dil içın ayrı ayrı olarak hazırlanmış ve bu dillerle yazılmış açık kaynak kodlu yazılımların, fonksiyon satır sayısı cinsinden analizlerini içeriyor. Yukarıdan da görebildiğiniz gibi ortalama sonuçlar söyle: Fortran: 44.6, C: 32.6, C++: 33.4, Java: 7.9.

Bu ilk sonuç iki şeyi gösteriyor. İlki nesne-merkezli programların ortalama olarak prosedürel olanlara göre daha ufak metotlara sahiptir. Bu durum hem ortalamalardan hem de standart sapmalardan açıkça görülüyor. Lakin bir diğer, belki de daha çarpıcı olan sonuç, C++ ile yazılan programların modül uzunluğunun C ile yazılanlar civarında olması. Bu durum yazarların da dikaktini çekiyor. Yazarların ve benim de kanaatim odur ki malesef C++ programcıları sağlıklı bir nesne-merkezli programlama kültürüne sahip değilller, bu yüzden C++ programları sanki C ile yazılıyor. Java programlarının metot uzunluğunun diğer üç dilinkilerden çok daha kısa olması, Java ile yazılan yazılımların hakikatten daha sağlıklı olduklarını, en azından burada örneklenen programlar temelinde gösteriyor. Doğru olan da bu zaten. Metot uzunluğu uzerine burada yayınlanan bu yazıya bakabilirsiniz.

İkinci sonuç ise fonksiyonlara geçilen parametre sayısı üzerine. Dört dildeki sonuçlar şöyle:

Module Parameters

Modüllere geçilen parametre sayısın açısından da dört dilin ortalamaları şöyle çıkmış: Fortran: 3.6, C: 2.3, C++: 2.2, Java: 0.9.

Bu sonuçlar da aslında ilk maddede çıkan sonuçları destekliyor. Nesne-merkezli dillerle yazılan programlardaki fonksiyonlar, prosedürel programlama ile yazılanlara göre daha az parametre alıyor. Az parametre daha basit ve kullanışlı API anlamına geldiğinden az parametreli metotlar tercih edilir. C++’ın yukarıda bahsedilen problemi burada da var. Bu yüzden nesne-merkezli programları Java ile yazılanlar olarak kabul edersek, iki maddede de ciddi bir prosedürel-nesne-merkezli karşıtlığı göze çarpıyor.

Her iki analizde de prosedürel dillerin ölçumlerindeki start sapmanın, nesne-merkezli dillerdekinden, özellikle de Java’nınkinden yüksek olduğuna da dikkat çekmek isterim. Bu durum Javacıların daha standart kod yazdıklarının bir göstergesidir.

Bu çalışma deneysel bir çalışma. Bu yüzden de doğruluğu sadece bu çalışmada ele alınan programlarla sınırlı. Java ile kötü yazılmış kodlar bulabileceğimiz gibi Fortran ile yazılmış, daha modüler yapılarla da karşılaşabiliriz. Ya da dört dilde ele alınan programların aynı programlar olmadıklarını, pek çoğunun farklı tipte uygulamalar olduklarını ve tamamen farklı kişiler tarafından yazıldığı gerçeği de bu arada düşünülmesi gereken noktalardan.

Her şeye rağmen bu çalışma bize Java ile ortalama 6-7 satırlık ve ortalama 1’in altında parametre alan metotlara sahip programların yazılmasının mümkün olduğunu gösteriyor. Darısı bu ülkedeki Javacıların başına 🙂 

Toplam görüntülenme sayısı: 1872

«< 36 37 38 39 40 >»