Yapılandırılmış Programlamaya Kuşkucu Bir Bakış ve Bazı Alternatifler — Bölüm I
Tom Gilb
Iver Holtersvei 2
N-1410 Kolbotn, Norveç
"SP’nin doğru seçimi ve etkin kullanımı için, katkılarının sürekli olarak ölçülmesi esastır. Sadece en iyi programcınız ilk kez kullandığında değil, ortalama programcılarınız da iki yıl sonra bundan sıkıldığında bile."
Bilgisayar Dünyasının En Yeni Dini
Yapılandırılmış programlama, bilgisayar dünyasının en yeni dini olarak hızla yerleşmektedir. Bunu yapan programcılar bundan hoşlanıyor. O hâlde iyi bir şey olmalı. Belki öyledir, ancak bundan emin değilim ve sanırım siz de değilsiniz; her ne kadar öyle olduğuna ikna olmuş olsanız da.
Yapılandırılmış programlamanın (SP) değerini anlamamı zorlaştıran iki şey vardır:
- Hiçbir zaman gerçekten alternatif tekniklerle karşılaştırılmaması ve elimizdeki deneyim verilerinin yeterince iyi olmaması.
- Programlamadaki gerçek devrimden (artan otomasyon ve program kalitesi ölçümü) tamamen habersiz görünen kişiler tarafından değerlendirilmesi.
Yakın zamanda akademik bilgisayar bilimi topluluğuna hitaben yazdığım bir mektupta, SP’nin diğer yöntemlerden daha iyi olduğunu gösteren makul bilimsel kanıtlar sunmalarını istedim. Bu meydan okumanın yayımlanmasının nedeni, varsayımımca, böyle kanıtların eksik olduğunun kabul edilmesiydi.
Akademisyenlerden birkaç yanıt aldım; hiçbirinde en ufak bir kanıt parçası bile yoktu. Bu, SP’nin bir teknik olarak son derece iyi bazı özelliklere sahip olduğunun gösterilemeyeceği anlamına gelmez. Ancak bu durum kuşkularımı artırıyor; umarım sizinkileri de.
SP konusundaki tanınmış "otoritelerin" çoğuyla temaslarımda, iyi niyetle birlikte, insanların SP kullanırken umdukları sonuçların aynısını elde etmeye yönelik alternatif teknikler hakkında açık bir bilgi eksikliği gözlemledim.
Neyse ki, bu kişilerin çoğu bilgisayar bilimi profesörü olduğundan, SP ile ilişkili diğer tüm program yazma teknikleri hakkında mutlak bir bilgisizlik söz konusu değildir. Sorun, yazılarında diğer tekniklerin tartışılmasını reddetmeleridir.
Bu basitleştirme, her seferinde tek bir teknik ele alma yaklaşımı, akademisyenler için yararlı olabilir; ancak pratik insanları, tek bir tanrısı ve tek bir buyruğu olan ("GO TO kullanmayacaksın") bir programlama dinine sürüklüyor gibi görünmektedir.
Copyright © 1975 Tom Gilb.
Yapılandırılmış Programlama Ölçülebilir mi?
Yeni tekniklerin değerli olup olmadığını anlamanın sistematik bir yolu vardır. Etkilerini ölçün. Bir tekniğin etkisini hiç ölçemiyorsanız, neden onu kullanmakla uğraşasınız? Eğer tekniğin "iyiliğini" ölçebiliyor ya da ölçümler elde edebiliyorsanız, neden bunu yapmıyorsunuz?
IBM’den Myers’ın program modülerliği üzerine yazdığı mükemmel makalesinde /3/ gösterdiği gibi, bir tekniğin kullanım derecesine ilişkin ölçütler ile, tam olarak o derece uygulandığında program kalitesinde ortaya çıkan çoklu özelliklerin ölçütlerini oluşturmak mümkündür. Myers, program modülerleştirme sorununa ilişkin ve SP sorununa da eşit derecede uygulanabilir olan birkaç noktayı kabul etmektedir:
- bir tekniğin uygulanma dereceleri ölçülmelidir;
- bunu yapmak için birden fazla ölçüt oluşturmak gerekebilir;
- bir tekniğin aynı anda birçok olası etkisi vardır;
- bunlar da ölçülebilirdir;
- ancak yöntemini kullanırken etkilerini henüz bilmediği "yan etkiler" ya da nitelikler için açıkça bir liste vermektedir.
Yapılandırılmış Programlama İçin Bir Ölçüt
Yapılandırılmış programlamanın baskın etkilerinden en az biri için pratik bir ölçü (bir "metrik") oluşturmaya çalışalım.
Doğru anlıyorsam, SP’nin tüm mekaniklerinin birincil amacı, program kaynak kodunu okuyanlar için daha kolay anlaşılır kılmaktır. Mühendislerden bazı teknolojileri /4, 5/ ödünç alarak, SP’yi değiştirilmiş bir "bakım yapılabilirlik" metriği kullanarak ölçmeye çalışabilirim:
"(tanımlanmış) bir program kaynak kodunu okuyan kişinin, belirli bir süre içinde mantığı doğru biçimde anlayabilme olasılığı."
Artık bir metriğimiz olduğuna göre, geriye makul maliyet ve doğruluk sağlayan pratik bir ölçüm aracı kalıyor. Neyse ki IBM’den Gould /6/, benim "bebugging" /7, 8, 9/ adını verdiğim basit bir yöntemin örneğini sunmuştur; bu yöntem basitçe, kontrollü bireysel programcı gruplarından farklı kaynak program durumlarında (örneğin "yapılandırılmış" ve "yapılandırılmamış") yerleştirilmiş hataları bulmalarını ister. Hataları bulabilme yeteneği, yanlış tahminlerin miktarı ve gereken süre, SP’nin ya da herhangi bir derecesinin iyiliğine dair açık bir ölçü sağlar.
Yapılandırılmış Programlamaya Alternatifleri Belirlemek İçin Metriğin Kullanımı
SP’nin iyiliğini ölçme kavramını kullanarak, alternatifleri ve birleşimleri araştırmaya başlayabiliriz. Başlangıçta şunu vurgulamak isterim ki, bebugging ölçümünün en azından basit bir biçimi, oldukça küçük bilgisayar kurulumlarında bile uygulanabilir. Bu tür ölçümlerin maliyeti, toplam bütçeye kıyasla ve yanlış yöntemlerin kullanılmasından ya da doğru olanların yanlış uygulanmasından kaynaklanabilecek israfa kıyasla düşüktür.
Yukarıda belirtilen bakım yapılabilirlik metriği, yalnızca program çalışır duruma geldikten sonra değişiklik yapmanın olası kolaylığını ölçmekle kalmaz; aynı zamanda ilk geliştirme sırasında program koduyla çalışmanın kolaylığını da yansıtır. Bu önemlidir; çünkü yüksek güvenilirlikli yazılımlar için kodlama çabası %5 kadar düşük olabilirken, geleneksel program üretim yöntemleri kullanıldığında tipik olarak toplam çabanın yaklaşık %25’i düzeyindedir. Daha iyi kodlama uygulamaları, test ve yeniden çalışma aşamalarındaki çabayı (şu anda proje maliyetinin diyelim ki %50’si) azaltabiliyorsa, bu açıkça ilgi çekicidir.
Artık aşağıdaki ilkeyi ifade edebiliriz:
belirli bir zaman dilimi içinde programları doğru biçimde değiştirebilme yeteneğimiz üzerinde olumlu etkisi olan herhangi bir teknik, yapılandırılmış programlamaya potansiyel bir alternatif ya da tamamlayıcı tekniktir.
Alternatiflerin veya Tamamlayıcıların Basit Bir Listesi
Okuyucu izin verirse, yalnızca en kısa gerekçelerle, olası alternatif tekniklerin ya da tamamlayıcı tekniklerin bir listesini sunmak isterim. Birçok okuyucunun, daha fazla ayrıntı verilmedikçe tam olarak ikna olmayacağını kabul ediyorum; bu ayrıntıları kaynaklarda bulabilirler.
Yorumlar
Programlardaki yorumlar, kaynak kodunu okuyan kişinin program mantığını anlama yeteneğini geliştirmek için uzun süredir yerleşik bir yöntemdir. Açıkça söylemek gerekirse, iyi konumlandırılmış ve iyi yazılmış yorumlar, program mantığı ve bunun veriyle ve diğer program mantığıyla ilişkisi hakkında, SP’nin (mantık akışının basitleştirilmesi gibi sınırlı anlamda) asla katkı sağlayamayacağı bilgileri verebilir.
Yorumlar ile SP arasında bir seçim yapmak zorunda kalsaydım, potansiyel olarak daha güçlü bir araç olarak yorumları tercih edeceğimden hiç kuşkum yok. Neyse ki her ikisine de sahip olabilirim. Ancak yorumların kullanımı, bilgisayar bilimi akademisyenlerimizin üzerine kuram üretmesi için pek heyecan verici bir konu değildir; bu yüzden ya hiç bahsetmezler ya da iyi uygulama örnekleri vermezler /2/. Kendini belgeleyen program miti henüz tamamen ortadan kalkmış değildir.
Neyse ki TRW-Systems gibi /10, 11/ daha pratik kurumlar vardır; bunlar gerçek dünyada ayakta kalmak için programların gerçekten çalışmasını sağlamak zorundadır. TRW, yorumların kullanımını vurgular ve hatta bir adım daha ileri giderek, yorumları analiz eden ve yorumlardan yararlanarak program dokümantasyonunu ve dokümantasyon güncellemelerini otomatik olarak oluşturan yazılım paketleri geliştirir.
"... yapılandırılmış programlama ile ... kaynak programın kendisi, ... uygun yorumlarla iyi biçimde açıklanmışsa, gereken tüm görünürlüğü sağlayabilir," /10 (s. 4-67, A. S. Liddle, TRW)/.
Modülerleştirme
Modülerleştirme, programların bakım yapılabilirliğini artırmak için uzun süredir denenmiş bir başka tekniktir. Bazı uzmanlar, modülerleştirmeyi ya da yukarıdan aşağıya modülerleştirmeyi SP kavramlarının içine dahil eder ve böylece karmaşaya katkıda bulunur. Sorunlardan biri, COBOL programcılarının bir alt yordamın ne olduğunu keşfetmelerinin yıllar almış olmasıdır; bu nedenle SP ortaya çıktığında, programlara biraz yapı kazandırma fırsatına atladılar. Umarım burada kullanmaya çalıştığım terminoloji okuyucuyu karıştırmıyordur. "Yapılandırılmış programlama" (en sınırlı biçimi ve en yaygın tanımıyla), bir modül içindeki mantık akışının yapısını ifade eder.
"Modülerleştirme" ise, bu SP mantık akışını içeren program mantığı ve veri tanımlarının işlevsel birimini ifade eder. Bir modül, oldukça basit bir biçimde, sistemin geri kalanına karşı tanımlı bir sınırı olan ve sistemin geri kalanıyla iletişim için iyi tanımlanmış bir arayüze sahip olan "bir şey"dir. Modülerleştirme, geleneksel SP’den (DO WHILE, IF ... THEN, GOTO yok vb.) daha yüksek bir soyutlama düzeyidir ve ayrı ama bütünleşik bir değerlendirmeyi hak eder.
Dick Canning /12/, özellikle yazılım araçlarıyla desteklenen bir disiplin olarak daha yaygın olduğu Büyük Britanya’da, program modülerleştirmesi üzerine yaptığı özel bir analizde, modüler programlamanın kullanıcılara SP’nin de verdiğini iddia ettiği şeyleri sağladığına dair ikna edici kanıtlar sunmaktadır. Örneğin kullanıcıların %89’u "daha kolay bakım ve değişiklik", %64’ü "daha yüksek programcı verimliliği" iddiasında bulunmuştur.
IBM, kavramları "top-down structured programming" ifadesini tutarlı biçimde kullanarak birleştirmiştir. Ancak bu, konuyu bulanıklaştırmaktadır. Top-down, tasarım ve uygulama sırasında modüllerin ele alınışına ilişkin belirli bir yaklaşımdır. Modül sayısı da, boyutları da eskisi kadar fazladır; ancak modüllerin tasarım ve kodlama/test sıralamaları "top-down tasarım ve uygulama ortamında" yeniden düzenlenmiştir. Bu bizi şaşırtmamalıdır. Üç bağımsız kavram vardır: SP (mantık akışının basitleştirilmesi), modülerleştirme ve top-down. Hepsi bazı iyi katkılar sağlayabilir ve birlikte de kullanılabilir. Ancak bunlar özünde bağımsız tekniklerdir; eğer bunları karıştırır ve etkilerini ayrı ayrı incelemezsek, araçlarımızın efendisi olamayız.
Bir program, bugün birçok COBOL programında olduğu gibi, yekpare bir dev olarak yazılmışsa (paragraflar bir modül için çok zayıf sınırlar sağlar), SP programa bir tür düzen getirir. Ancak sıradan modülerleştirme ilkeleri uygulanırsa; yani iyi tanımlanmış işlevsel modüller, küçük boyutlu, iyi yorumlanmış, tek bir giriş ve çıkış noktasına sahip (SP bu fikri geliştirmedi; bazıları öyle sansa da), hiyerarşik olarak düzenlenmiş modüller oluşturulursa; o zaman SP’den, maliyetiyle ilişkili olarak, hangi ek (ölçülebilir!) faydayı bekleyebiliriz? Bir maliyeti vardır; eğitim, yazılım, ek derleme süresi ve yazma çabası gibi. Soru "olumlu bir etkisi var mı?" değil, "diğer tekniklere kıyasla daha iyi bir fayda/maliyet oranı sağlıyor mu?"dur.
Myers, "Composite Design" başlıklı makalesinde /3/, benim görüşüme göre bu açık ayrımı yapan ve farklı modülerleştirme derecelerinin nasıl denetleneceğini anlama yönündeki çok boyutlu probleme eğilmeye çalışan az sayıdaki yazardan biridir.
Programlama teknikleri hakkında basitleştirici düşünmenin, bir projenin ya da programın ölçeği büyük olduğunda veya sistemin uzun vadeli kullanılabilirliği kritik olduğunda tehlikeli olabileceğini aklımızda tutmalıyız. Bu noktada, tekniklerimiz hakkındaki "mitodoloji" kullanımını bırakmalı ve neyse ki IBM, TRW ve diğerlerinden çıkan yeni teknolojilerin çoğunun özelliği olan yöntemli ve nicel düşünceyi kullanarak bu tekniklerin karmaşıklıklarına hâkim olmaya başlamalıyız.
Ölçütler
Programlarınızın ya da veritabanlarınızın bakım yapılabilirliğini en son ne zaman resmi olarak tanımladınız? Teslim edilen sistemin, hepimizin muhtemelen iyi bir şey olduğu konusunda hemfikir olduğu bakım kolaylığı, taşınabilirlik vb. niteliklere sahip olmasını güvence altına almak için pratik bir ölçüm yöntemi dahil ettiniz mi? Bu tür program kalite hedeflerinin nasıl belirtileceğini biliyor musunuz? Başkaları biliyor /5, 10, 4/. Bu kalite hedeflerine ulaşımın ölçülmesine yönelik pratik yollar biliyor musunuz? Başkaları biliyor /10, 11, 8, 9, 4, 6/.
İyi bir teknik, ölçülmezse, muhtemelen bozulur.
SP’nin doğru seçimi ve etkili kullanımı için, katkılarının sürekli olarak ölçülmesi esastır. Sadece en iyi programcınızın onu ilk kullandığı zaman değil, ortalama programcılarınızın da ondan sıkılmasından iki yıl sonra bile.
Program kalitesi için açık hedefler belirlendiğinde, insanlar bu hedeflere ulaşmak için motive edildiğinde ve hedeflere ulaşım doğru ve nesnel olarak ölçüldüğünde, oraya varmak için makul bir şansınız olur. Aksi halde, kontrol dışındasınızdır.
Program bakım yapılabilirliği gibi konular için ölçütlerin ve ölçüm araçlarının etkili kullanımı ile SP arasında bir seçim yapma şansım olsaydı, ölçütleri ve ölçüm araçlarını seçerdim. SP yalnızca bir tekniktir. İyi sistemlere giden pek çok olası yoldan biridir. Kesinlikle tek yol ya da zorunlu bir yol değildir. Haritamı ve pusulamı kaybedersem, oraya asla varamayabilirim. Program kullanıcım SP’mi asla görmeyecek, ama programım çalışmazsa ya da yeni gereksinimlerine uyarlamak çok fazla zaman alırsa bunu mutlaka fark edecektir.
Ölçütler SP’nin doğrudan bir ikamesi ya da alternatifi değildir; ancak dolaylı alternatifler ya da tamamlayıcı tekniklerdir, çünkü doğru kullanımları program bakım yapılabilirliğine en az SP kadar etkili bir biçimde katkıda bulunma olasılığı çok yüksektir.
Bunu basit bir ölçüt uygulamasıyla açıklayayım:
"Program B’nin bakım yapılabilirliği, rastgele program-hatasının 2 saniye içinde düzeltilmesi için %98 olasılık olacaktır."
İlk bakışta imkânsız gibi geliyor, değil mi? Eğer "2 saat içinde" ya da "2 gün içinde" deseydik, belki SP ve diğer teknikleri kullanarak bu hedefe ulaşma şansımız olabilirdi.
Şimdi açıktır ki, ne kadar zarif düşünülmüş olursa olsun, hiçbir SP miktarı bizi bu hedefe ulaşmaya yaklaştıramaz. Bu arada, bu bir hava trafik kontrol sistemi içindir ve hata ortaya çıktığında çarpışma rotasında olan uçağın içinde siz oturuyor olabilirsiniz. Dolayısıyla bunu önemsemelisiniz.
Neden bu bakım yapılabilirlik problemini SP ile çözemiyoruz?
Anladınız, değil mi? Programcınız iki saniye içinde kahve fincanını bile bırakamaz. Aslında, bu tasarım hedeflerini karşılayacak herhangi bir teknik varsa, bu insan tepkisini içermez. Hataların tamamen otomatik olarak düzeltilmesi gerekir. SP yardımcı olmaz, çünkü SP insanların programları onarmasına yardımcı olan bir tekniktir. Makineler SP’yi bizim takdir ettiğimiz şekilde gerçekten takdir etmez.
Eğer program kalitenizi insanların verebileceği niteliklerle sınırlamak istiyorsanız, bu makaleyi okumayı bırakın ve DO WHILE yapılarınızla oynamaya geri dönün. Bilgisayarları önemli uygulamalar için kullanma yeteneğinizi sınırlayan o deli gömleğinden çıkmak istiyorsanız, okumaya devam edin! Programları birkaç milisaniye içinde nasıl onaracağınızı öğrenebilirsiniz.
Ölçütler konusundan ayrılmadan önce, TRW-Systems Group’un Characteristics of Software Quality /10/ adlı kitabına dikkat çekmek isterim; bu kitap, program tasarımı ve gerçekleştirilmesinin, tamamen otomatik (yani diğer programlar veya yazılım geliştirme araçları tarafından) ölçüm yapabilen, iyi tanımlanmış, çok boyutlu ölçütler aracılığıyla denetlenmesinin önemini bütünüyle kabul etmektedir.
Aşağıda gelen listedeki diğer tekniklerin birkaçı (ikili kod, bebugging ve test yolu analizi ile veritabanı tanılaması), ölçütlerin kullanımıyla ilişkilidir; çünkü bunlar, diğer şeylerin yanı sıra, program bakım yapılabilirliği ve üretimiyle bağlantılı sorun alanları için ölçüm araçlarıdır.
Bebugging
Bu makalenin başlarında bebugging kullanımından söz etmiştik. SP ile bağlantılı olarak iyi bilinen Harlan Mills, bunu "hata bulma sürecinin kendisini kalibre etmek amacıyla bir programa kasıtlı, ancak rastgele, hatalar eklenmesi" olarak tanımlar. /13, s. 236/
Bu konu üzerine ince ama ilginç bir literatür vardır /6, 7, 8, 9/ ve kesinlikle tam olarak keşfedilmiş değildir. IBM’den Gould ve Drongowski, bilgisayar programı hata ayıklama üzerine yaptıkları çalışmada bunu kullandılar /6/ ve onların çalışmalarından, bunun programların insanlar tarafından bakım yapılabilirlik derecesini ölçmek için pratik bir araç olduğu açıkça görülmektedir. Hem durağan program niteliklerini hem de insan yeteneklerini ölçebiliriz.
Aynı temel yöntemin, bir programda kalan hatalara ilişkin tahminler ve program kalitesini daha yüksek bir güvenilirlik düzeyine çıkarmak için gelecekte gerekecek çabaya ilişkin tahminler vermek için de kullanılabileceği eşit derecede açıktır. Bu bağlamda "güvenilirlik", belirli bir zaman aralığında rastgele hatalarla karşılaşma olasılığıdır. Örneğin %50’den %96’ya güvenilirlik eğrisi üzerinde ilerlemenin tarihsel oranlarına dayanan, çeşitli durumlar (SP bunun bir varyasyonudur) için deneyim eğrileri, bu tür tahminler için rehberimiz olacaktır. Doğal olarak ölçüm aracının doğruluğu, eklenen hataların sayısı ve temsil gücü; hataların verimliliği (otomatik bebugging ve güvenilirlik hesaplaması?) ve bunların giderilmesinin ölçülmesi; programcının motivasyonel yönleri tarafından belirlenir.
(lütfen 23. sayfaya bakınız)
Gilb
22. sayfadan devam
Bu ölçülmüş ortamda hata bulma, geleneksel, ölçülmemiş durumdan oldukça farklıdır. SP’den önce hata ayıklamayı seçerdim; ama her ikisine de sahip olabiliriz.
(Bir sonraki sayıda devam edecek)