Teori Kurma Olarak Programlama (1985)

• Peter Naur’un "Programming as Theory Building" metni, programlamayı program metni üretme etkinliği olarak değil, programcının problem ve çözüm hakkında bir teori kurma etkinliği olarak görür.
• Buradaki “teori”, yalnızca soyut önermeler ya da belgelenmiş tasarım açıklamaları değildir.
  • Gerçek dünyadaki problemin ne anlam taşıdığını anlamak,
  • program yapısının bu gerçeklikle nasıl örtüştüğünü açıklayabilmek,
  • neden böyle tasarlandığını gerekçelendirebilmek,
  • yeni gereksinimler geldiğinde bunların mevcut yapı içinde nasıl entegre edileceğine karar verebilmek demektir.
• Dolayısıyla bir programın çekirdek bilgisi, kodun ya da belgelerin içinde bütünüyle yer almaz; o programı anlayan programcının zihnindedir.

Programlama ve bilgi

• Naur, programlamayı gerçek dünyadaki etkinlikleri bilgisayarın yürütebileceği biçimsel sembol işlemlerine eşleme faaliyeti olarak görür.
• Bu bakış açısında programı değiştirmek de programlamanın bir parçasıdır.
  • Çünkü gerçek dünyadaki faaliyet değişirse program da değişmek zorundadır.
• Programlamanın özü, ortaya çıkan belge ya da kod değil, programcıların biriktirdiği belirli türden bilgidir.
• Belgeler önemlidir ama ikincil konumdadır.
  • Belgeler teorinin yerini tamamen tutamaz.
  • Daha çok teori kurmayı destekleyen araçlardır.

Örnek 1: Derleyici devri ve başarısızlık

• Grup A, L dili için bir derleyici yaptı.
• Grup B, genişletilmiş L + M dili için bir derleyici yapmak üzere A grubunun derleyici kodunu, belgelerini ve tavsiyelerini aldı.
• Kod ve belgeler yeterince verilmişti, ancak B grubu bazı tasarımlarda mevcut yapının gücünden yararlanamadı ve yama tarzı çözümler önerdi.
• A grubu sorunu hemen fark etti ve mevcut yapı içinde daha basit, daha doğal çözümler sundu.
• Bu örneğin özü şudur:
  • Yalnızca program metni ve belgeler, tasarımın derin teorisini aktarmaya yetmez.
  • Mevcut tasarımın “neden”i ve “nasıl genişletilmesi gerektiği” yalnızca belgelerle yeterince aktarılamaz.
• Daha sonra A grubunun yönlendirmesini almayan başka programcılar derleyiciyi değiştirirken, başlangıçtaki güçlü yapı giderek biçimsiz eklemelerle zayıfladı.
• Bu da program metni ve belgelerin, çekirdek tasarım teorisini korumakta sınırlı kaldığını gösterir.

Örnek 2: Büyük ölçekli gerçek zamanlı sistem

• Yaklaşık 200 bin satırlık endüstriyel bir gerçek zamanlı sistem örneği verilir.
• Kurulum ve hata teşhisinden sorumlu programcılar, sistem tasarımının ilk aşamalarından itibaren uzun süre sistemle yakından bağlantılıydı.
• Bu kişiler hataları teşhis ederken çoğunlukla kendi anlık sistem kavrayışlarına ve açıklamalı koda güvendiler.
• Buna karşılık belge ve eğitim almış dış operatör programcılar sürekli zorluk yaşadı.
• Üreticinin deneyimli programcıları ise bu sorunları kolayca çözdü.
• Sonuç:
  • Büyük programların bakımı ve değiştirilmesi, esas olarak programla uzun süre bağlantıda kalmış kişilerin sahip olduğu bilgiye dayanır.
  • Belgelenmiş açıklamalar tek başına bu bilginin yerini tamamen alamaz.

Ryle’ın “teori” kavramı

• Naur, Gilbert Ryle’ın teori kavramını ödünç alır.
• Bir teoriye sahip olmak, sadece bazı önermeleri bilmek demek değildir.
  • Bir şeyi yapabilmek,
  • o şeyi açıklayabilmek,
  • soruları yanıtlayabilmek,
  • kendi yargılarını gerekçelendirebilmek anlamına gelir.
• Zeki faaliyetler zorunlu olarak yalnızca kuralları izlemeye indirgenemez.
  • Çünkü kuralları izleme işi de zeki biçimde yapılmalıdır.
  • Kuralların nasıl izleneceği için bir başka kurala ihtiyaç duyulursa sonsuz gerileme ortaya çıkar.
• Bu nedenle zihinsel faaliyet, yalnızca kural uygulamak değil, durumlar arasındaki benzerlikleri kavrayıp uygun biçimde karşılık verebilme yetisini de içerir.

Teori kurallarla bütünüyle ifade edilemez

• Bir teoriye sahip kişi, gerçek hayattaki farklı durumlar arasında anlamlı benzerlikleri fark eder.
• Ancak bu tür benzerlikleri açık ölçütler ya da kurallarla bütünüyle ifade etmek zordur.
• Örnekler:
  • Yüz benzerliği,
  • melodi benzerliği,
  • şarap tadı benzerliği.
• Benzer şekilde programlamada da yeni bir gereksinimin mevcut yapıya nasıl benzediğini ve nereye entegre edilmesi gerektiğini basit kurallara indirgemek zordur.
• Örtük bilginin özü de burada yatar.

Programcının sahip olması gereken teori

• Bir programın teorisine sahip olan programcı şunları yapabilmelidir:

1. Gerçek dünya ile program arasındaki karşılığı açıklayabilmek

• Programın her bölümünün gerçek dünyadaki hangi faaliyet ya da kavrama karşılık geldiğini açıklayabilmelidir.
• Tersine, gerçek dünyadaki bir faaliyetin program içinde nasıl ifade edildiğini de açıklayabilmelidir.
• Neyin ilgili, neyin ilgisiz olduğuna karar verebilmek için gerçek dünyanın bütünü hakkında anlayış gerekir.

2. Programın neden öyle olduğunu gerekçelendirebilmek

• Programın yapısının ve uygulama ayrıntılarının neden öyle tasarlandığını açıklayabilmelidir.
• Bu gerekçelendirme kurallar, çıkarımlar, tasarım ilkeleri, nicel tahminler vb. kullanabilir.
• Ancak nihayetinde hangi ilkenin uygulanacağına karar vermek, programcının doğrudan kavrayışına bağlıdır.

3. Yeni değişiklik taleplerine yapıcı biçimde karşılık verebilmek

• Yeni bir gereksinimin, mevcut programın hangi işlevine ya da yapısına benzediğini fark edebilmelidir.
• Bu benzerlikten hareketle, değişikliği mevcut teoriye doğal biçimde entegre olacak şekilde tasarlayabilmelidir.
• Bu yeteneğin yerini yalnızca belgelenmiş prosedürlerle doldurmak zordur.

Program değişikliği ve maliyet

• Yazılım kaçınılmaz olarak değiştirilir.
  • Çünkü kullanım sırasında yeni gereksinimler ortaya çıkar,
  • gerçek dünyanın koşulları da değişir.
• Sıklıkla mevcut programı değiştirmenin yeniden yazmaktan daha ucuz olduğu düşünülür.
• Ancak Naur’un bakış açısından bu beklenti her zaman geçerli değildir.
• Program değiştirmenin maliyeti, metni düzenleme maliyeti değildir.
  • Asıl maliyet mevcut programın teorisini anlamakta
  • ve yeni gereksinimi bu teori içine entegre etmekte yatar.
• Bu yüzden kodun kolayca düzenlenebilir bir metin olması tek başına değişikliğin kolay olduğunu göstermez.

Esnekliğin sınırları

• Programa gelecekteki değişikliklere hazırlık olsun diye önceden esneklik koyma iddiası ancak kısmen doğrudur.
• Esneklik bedelsiz değildir.
  • Hangi gelecekteki durumlara hazırlanılacağına karar vermek gerekir,
  • parametreler ve yapılar tasarlanmalıdır,
  • uygulama, test ve açıklama maliyetleri vardır.
• Bunun yararlılığı belirsiz gelecekteki olaylara bağlıdır.
• Dolayısıyla esneklik, değişime uyum için genel bir çözüm olamaz.
• Asıl önemli olan, her türlü değişikliğe önceden yapı kurmak değil, değişiklik geldiğinde programın teorisine dayanarak uygun karar verebilme yetisidir.

İyi değişiklik ve kötü değişiklik

• Aynı dış davranışı sağlayan değişiklikler bile farklı şekillerde uygulanabilir.
• Yüzeyde hepsi doğru görünebilir.
• Ancak programın teorisi açısından aralarında büyük fark vardır.
  • Bazı değişiklikler mevcut teoriyi doğal biçimde genişletir.
  • Bazıları ise mevcut yapının üstüne eklenmiş bir yama gibi çalışır.
• İkinci tür değişiklikler tekrarlandıkça program giderek yamalı bohçaya döner.
• Programın uzun vadeli yaşayabilirliği, her değişikliğin mevcut teoriye ne kadar iyi kök saldığına bağlıdır.

Programın yaşamı, ölümü ve dirilişi

Programın yaşamı

• Programın teorisine sahip programcılar hâlâ o programı etkin biçimde denetliyorsa, program yaşıyordur.
• Bu kişiler değişiklik taleplerine zihinsel olarak karşılık verebilir.

Programın ölümü

• Programın teorisine sahip ekip dağılırsa program ölür.
• Ölmüş bir program hâlâ çalışabilir ve yararlı sonuçlar üretebilir.
• Ama değişiklik taleplerine gerektiği gibi yanıt veremediğinde bu ölüm görünür hâle gelir.

Programın dirilişi

• Bu, yeni bir ekibin mevcut programın teorisini yeniden kurmaya çalışma girişimidir.
• Naur’a göre bu, sıkı anlamda mümkün değildir.
• Çünkü yalnızca belgeler ve kodla, ilk ekibin sahip olduğu teoriyi eksiksiz biçimde geri kurmak mümkün olmaz.
• Diriliş mümkün olsa bile pahalı ve zordur; ayrıca özgün teoriden farklı bir teori üretme olasılığı yüksektir.
• Bazı durumlarda mevcut kodu kurtarmaya çalışmaktansa, yeni ekibin problemi baştan çözmesi daha iyi ve daha ucuz olabilir.

Metodoloji eleştirisi

• Naur, programlama metodolojisini “programcının hangi sırayla hangi işleri yapacağını belirleyen kurallar kümesi” olarak görür.
• Teori kurma bakış açısından bu anlamdaki metodoloji, programlamanın özünü yakalayamaz.
• Nedenleri:
  • Teori kurmada sabit bir sıra yoktur.
  • Teori, özünde parçaların doğrusal birleşimi değildir.
  • Gösterimler ya da belge biçimleri teori kurmaya yardımcı olabilir ama teorinin kendisi değildir.
• Bu yüzden programlamanın birincil faaliyeti için evrensel olarak doğru bir yöntem olmadığı sonucuna varılır.

Bu, metodolojinin bütünüyle değersiz olduğu anlamına gelmez

• Naur’un reddettiği şey, mekanik biçimde iyi tasarımı garanti eden prosedür olarak metodolojidir.
• Metodolojiler, tasarım teknikleri, gösterimler ve doğrulama teknikleri eğitsel değer taşıyabilir.
• İyi örneklere, yapılandırma ilkelerine ve doğrulama tekniklerine aşina olan programcıların daha iyi teoriler kurma olasılığı yüksektir.
• Ancak hangi tekniğin ne zaman ve hangi sırayla uygulanacağı, gerçek problemi anlayan programcının yargısına bırakılmalıdır.

Programcının konumu

• Programlama endüstriyel üretim gibi görülürse programcı, değiştirilebilir bir parça gibi ele alınır.
• Bu, prosedürler ve kurallar izlenirse herkesin aynı sonucu üretebileceği bakış açısıdır.
• Naur bu bakışı reddeder.
• Eğer programın asıl çıktısı programcının sahip olduğu teori ise, programcı kolayca değiştirilebilen bir emekçi değildir.
• Programcı, bilgisayar içeren tüm faaliyeti sorumlu biçimde geliştiren ve yöneten bir profesyonele daha yakındır.
• Bu nedenle programcıya süreklilik taşıyan bir statü ve sorumluluk verilmelidir.
• Eğitim de yalnızca söz dizimi, gösterimler ve veri işleme tekniklerinin ötesine geçip teori kurma becerisini geliştirmeye yönelmelidir.

XP’de metafor ve teori kurma

• XP’deki “metafor”, Naur’un teori kurma bakışıyla iyi açıklanabilir.
• İyi bir metafor, ekibin program yapısı hakkında benzer varsayımlar kurmasına yardımcı olur.
• Örnekler:
  • Programı bir “montaj hattı” olarak anlamak.
  • Programı bir “restoran” olarak anlamak.
• İyi bir metafor yalnızca bir benzetme değildir.
  • Tasarımcıların hangi yapıları beklemesi gerektiğini,
  • yeni kodun nereye eklenmesi gerektiğini,
  • başkalarının yazdığı kodla nasıl uyum kuracağını değerlendirmelerine yardımcı olur.
• Ekip büyüdükçe ve paralel çalışma arttıkça paylaşılan metaforun değeri de artar.
• Ortak bir teori yoksa her programcı kendi teorisini kurar ve sistem giderek daha uyumsuz ve karmaşık hâle gelir.

Belgelemenin rolü

• Belgeler programın güncel durumunu bütünüyle yakalamakta zorlanır.
• Yine de bu, belgenin gereksiz olduğu anlamına gelmez.
• Belgenin amacı her şeyi kaydetmek değil, bir sonraki programcının uygun bir teori kurmasına yardımcı olmaktır.
• İyi belge, okurun belleğini ve deneyimini harekete geçirir; doğru düşünme yollarını açar.
• Bu tür belgeler, yalnızca mevcut sınıf, fonksiyon ve modül listelerini sıralayan belgelerden daha uzun ömürlüdür.

İyi bir tasarım belgesinin yapısı

• Deneyimli tasarımcılar genellikle belgeye şu öğelerle başlar:
  • Temel metafor,
  • ana bileşenlerin amacının açıklanması,
  • ana bileşenler arasındaki temel etkileşimleri gösteren diyagram.
• Bu üç unsur, sonraki ekibin tasarım teorisi kurmasına büyük ölçüde yardımcı olur.
• Kaynak kodun kendisi de teori aktarma aracıdır.
  • Tutarlı adlandırma,
  • basit yapı,
  • öngörülebilir kalıplar,
  • gereksiz istisnaların en aza indirilmesi.
• “Temiz kod”un önemli bir bölümü, okurun sistem hakkında tutarlı bir teori ne kadar kolay kurabildiğiyle ilgilidir.