Programlamanın Tao´su 3. ve 4. Kitap

0
FZ
3. Kitap - Tasarım

Ve şöyle dedi usta programcı:

"Program test edilmeye başlandığında tasarım değişiklikleri yapmak için artık çok geçtir."
3.1

Bir zamanlar bir bilgisayar fuarına giden bir adam vardı. Her gün girişteki güvenlik görevlisine şöyle diyordu: "Ben büyük bir hırsızım, arakladığım şeyler yüzünden meşhurum. Seni uyarıyorum bu fuar da benden nasibini alacak."

Bu konuşma güvenlik görevlisini çok rahatsız etmişti çünkü içeride milyonlarca dolar değerinde bilgisayar ekipmanı vardı ve o da bu yüzden hırsız olduğunu söyleyen adamı yakın takibe almaya karar verdi. Ancak adam bir standdan diğerine gidiyor ve kendine kendine mırıldanıyordu, tüm yaptığı buydu.

Adam fuarı terk eder etmez, güvenlik görevlisi onu bir kenara çekiyor baştan sonra arama tarama yapıyordu. Adamın hırsızlığına işaret eden hiçbir şey çıkmıyordu üzerinden.

Ertesi günü fuara gelen adam güvenlik görevlisine yanaşıp dedi ki: "Dün iyi iş çıkardım ama bugün daha da iyi olacak." Tüm huzuru kaçan bu sefer takip işini daha sıkı tutmaya karar vermişti ancak sonuç gene hüsrandı.

Fuarın son gününde dayanamayan güvenlik görevlisi adama gidip şöyle dedi:"Sayın Hırsız, o kadar şaşırmış durumdayım ki huzurum kaçtı, çok kötü durumayım, lütfen beni aydınlatın, çaldığınız şey nedir?"

Adam gülümsedi ve tek bir cümle sarf etti:"Fikir çalıyorum."

3.2

Bir zamanlar yapısal olmayan programlar yazan bir usta programcı vardı. Çömez programcı onu taklit etmeye yeltendi ve o da yapısal olmayan programlar yazmaya başladı. Sonra ustaya gidip programlarını değerlendirmesini isteyince usta ona yapısal olmaya programlar yazmadığı için kızdı ve dedi ki: "Usta için uygun olan çömez için uygun değildir. Yapıyı aşmadan önce Tao'yu kavramalısın."

3.3

Bir zamanlar savaş lordu Wu'nun topraklarında yaşayan bir programcı vardı. Wu onu huzuruna getirtti ve sordu: "Hangisini tasarlamak daha kolaydır, bir muhasebe paketi mi yoksa bir işletim sistemi mi?"

Programcı cevapladı: "Bir işletim sistemi."

Kulaklarına inanamayan savaş lordu içini çekti ve dedi ki: "Bir işletim sistemi ile kıyaslandığında muhasebe yazılımının çok basit olduğu su götürmez!"

"Tam olarak öyle denemez efendim", dedi programcı, "bir muhabesebe paketi tasarlarken programcı değişik fikirleri olan insanlarla muhatap olmak zorunda kalır: program nasıl çalışmalıdır, raporlar nasıl görünmelidir, vergi kanunlarına ne şekilde uymaldıdır, vs. Oysa bir işletim sistemi dış görünüş ile sınırlandırılamaz. Bir işletim sistemi tasarlarken programcı makina ve fikirler arasındaki en basit uyumu arar bu yüzden de işletim sistemi tasarlamak daha kolaydır."

Savaş lordu Wu başını onaylar biçinde salladı ve gülümsedi: "Güzel ve akıllıca! Peki hangisinin hatalarını ayıklamak daha kolaydır?"

Programcı cevap vermedi.

3.4

Bir müdür usta programcıya gitti ve yeni bir uygulama ile ilgili özellik listesini gösterdi. Sonra da sordu: "Eğer 5 programcıyı görevlendirirsem sistemin tasarlanması ne kadar sürer?"

"1 yıl," diye cevapladı usta hiç tereddüt etmeden.

"Fakat bu iş çok acil! 10 programcı çalıştırsak?"

Ustanın kaşları çatıldı. "Bu durumda iki yıl sürer" dedi.

"Peki ya 100 programcı çalıştırsak?"

Usta omuz silkti ve "O zaman tasarım asla tamamlanmaz" dedi

4. Kitap - Kodlama

Ve şöyle dedi usta programcı: "İyi yazılmış bir program kendi içinde bir cennettir, kötü bir program ise cehennemin ta kendisi."

4.1

Bir program hafif ve çevik olmalıdır. Alt rutinleri inci dizileri gibi bağlanmalıdır. Programın ruhu ve amacı sürekli göz önünde bulundurulmalıdır. Fazla ya da az olmamalı, gereksiz döngüler ve değişkenler kullanılmamalıdır. Ancak yapıdan yoksunluk ya da değiştirilemez bir katılık da bulunmamalıdır.

Bir program "En Küçük Şaşkınlık" yasasını takip etmelidir. Nedir bu yasa? Program kullanıcıya daima onu en az şaşırtacak şekilde cevap vermelidir.

Bir program, ne kadar karmaşık olursa olsun, tek bir birim gibi çalışmalıdır. Program dış görünüşü tarafından değil içsel mantığı tarafından yönlendiriliyor olmalıdır.

Eğer program bu ihtiyaçları karşılamazsa düzensizlik ve karmaşa hakim olur. Bunu düzeltmenin tek yolu programı yeniden yazmaktır.

4.2

Bir çırak ustaya sordu: "Bazen çalışan, bazen de çöken bir programım var. Programlama kurallarına uydum ama gene de apışıp kaldım. Bunun sebebi ne olabilir?"

Usta şöyle cevapladı: "Kafan karışmış çünkü Tao'yu anlamıyorsun. Sadece bir insan etrafındaki insanlarda rasyonel davranışlar bekler. Sen neden aynı şeyi insanların yaptığı bir makinadan bekliyorsun? Bilgisayarlar determinizmi simüle ederler, mükemmel olan ise sadece Tao'dur.

Programlama kuralları geçicidir. Sadece Tao kalıcıdır. Bu yüzden aydınlanabilmek için önce Tao'yu kavramalısın."

"Peki ama aydınlandığımı nasıl anlayacağım?" diye sordu çırak.

Usta cevap verdi: "Programın düzgün çalışacak."

4.3

Bir usta çıraklardan birine Tao'nun doğasını anlatıyordu: "Tao tüm yazılımların içinde vardır, ne kadar küçük olurlarsa olsun bu yazılımlar."

"Bir hesap makinasında Tao var mıdır?" diye sordu bir çırak.

"Vardır."

"Peki bir video oyununda da var mıdır Tao?" diye devam etti çırak.

"Bir video oyununda bile vardır," dedi usta.

"Peki, kişisel bilgisayardaki Windows sisteminde de Tao var mıdır?" diye sordu çırak.

Usta öksürdü, boğazın temizledi, biraz kımıldandı ve "Bugünkü dersimiz bu kadar," dedi.

4.4

Prens Wang'ın programcısı yazılım kodluyordu. Parmakları klavye üzerinde dans ediyor, programları tek bir hata mesajı olmadan derleniyor ve rüzgar gibi çalışıyordu.

"Mükemmel!" diye bağırdı Prens. "Tekniğin kusursuz!"

"Teknik mi?" dedi programcı ve terminalinden yukarı doğru baktı. "Benim takip ettiğim şey Tao'dur - tüm tekniklerin ötesinde. Programlamaya ilk kez başladığımda tüm problemi tek bir kütle gibi görüyordum. Aradan yıllar geçtikten sonra o kütleyi görmüyorum. Bunun yerine alt rutinler kullanıyordum. Ancak şimdi artık hiçbir şey görmüyorum. Tüm varlığım şekilsiz bir boşluk gibi. Ruhum plansız programsız, içgüdülerini takip ederek özgürce çalışabiliyor. Kısaca programım kendi kendini yazıyor. Evet, doğru, bazen güç problemlerle karşılaştığım oluyor. Onların geldiğini görüyorum ve yavaşlayıp sessizce izliyorum. Sonra tek bir satırı değiştiriyorum ve problemler duman gibi uçup gidiyor. Programı derliyorum ve yapılan işin güzelliği varlığıma işliyor. Gözlerimi kapatıyorum ve sonra sistemden çıkıyorum."

Bunun üzerine Prens Wang dedi ki "Keşke tüm programcılarım senin kadar bilge olsaydı."

İlgili Yazılar

Ruby Nesnelerine Kalıcılığı Öğretmek

anonim

Dünyada en çok sevilen programlama dili olduğu söylenen Ruby ile sunucu taraflı uygulama geliştirmek için elimizde RoR gibi kullanması çok kolay ve işlevsel bir arayüz var.

Peki ya masaüstü uygulamalarımız için Hibernate benzeri kalıcık araçları karşısında Ruby'de alternatif yok mu?

Tabii ki var. Og (Object Graph) ile Ruby nesnelerine nasıl kalıcı olacaklarını öğretmek çok kolay olsa da, bu makale ile daha kolay olacak.

YazBoz API'nin İlk Sürümü Çıktı

FZ

Daha önce bahsettiğimiz yazboz.com ile ilgili yeni bir gelişmeyi paylaşmak istiyoruz: sistemi kendi uygulamalarında kullanmak isteyen araştırmacılar için bir API hazırlandı.

yazboz.com geliştiricileri Can Altıneller ve Özgür Oktay'ın hazırladığı API belgesinin ilk sürümünü FM takipçisi bilgisayarcılarla paylaşmak istiyoruz:

YazBoz.com'da biriktirdiğiz verileri bilim insanları ve uygulama geliştirmek isteyen herkesle paylaşabilmek için bir API geliştirdik. Bugüne kadar Yazboz'u inceleyen yapay zekâ araştırmacıları, dilbilimciler ve bilişsel bilimciler yazboz verilerinin kendi çalışmalarına önemli katkılarda bulunabileceğini düşündüler. YAZBOZ API’nin bu ilk sürümü ile bilim insanları ve geliştiriciler yeni uygulamalar yapabilecekler. Uygulamalar çoğaldıkça ve geliştikçe biz de YAZBOZ API yi geliştireceğiz.

Design Patterns: Tasarım Şablonları ve Programlama Dillerinin Kötü Yönleri

FZ

Geçen sene Eylül ayında, Volkan Yazıcı programlama dünyasının sıcak konularından biri olan tasarım şablonlarına yani 'design patterns' konusuna değinmişti:

Merhaba, comp.lang.lisp listesinde "This may be a nonsensical question, but I was wondering if it is idiomatic to apply common design patterns to lisp applications." kaşıntısı ile başlayan bir tartışmalar dizisi oldukça ilgimi çekti -- şüphesiz ki bunda bu dönem almaya başladığım Aspect-Oriented Software Development dersinin de etkisi olmuştur -- ve sizin ile oradan çok ufak bir mesajı paylaşmak istedim.


Tasarım Şablonları, nam-ı diğer Design Patterns mevzusu epey bir süredir sıcak konular arasında. Bu gibi durumlarda sık sık karşılaştığımız gibi konu basit bir teknik konu olmaktan çıkıp pek çok yanlış anlamayı, çok çeşitli felsefi bakış açılarını, alakasız yerlere dallanıp budaklanmayı, düpedüz mantıksal hataları, politik ve ekonomik savaşları bünyesinde barındırmaya başlıyor. Acaba neden?

Özgür Dünya ve Müzik Eğitimi: GNU Solfege

FZ

Son kiii üç dört!

GNU Solfege, GNU/Linux ve MS Windows sistemler üzerinde çalışan bir solfej ve kulak eğitimi yazılımı.

Melodik ve armonik aralıklarını tanımak, aralık boylarını kıyaslamak, bilgisayarın gösterdiği aralıkları söylemek, akorları tanımak, akorları söylemek gibi konularda kullanıcıyı eğitmeyi amaçlayan program sonsuz sabırlı bir müzik eğitmeni olarak görevini yerine getirmeye çalışıyor.

Yazılımın dokümantasyonunu okuyup daha çok bilgi sahibi olabilir, ekran görüntülerine bakabilir ya da UNIX Review dergisinden Marcel Gagné'nin GNU Solfege eleştirisine göz atabilirsiniz.

Curl Programlama Dili Yarışması Sonuçlandı

FZ

Friedger Mueffke ve Nikhil Damle Curl programlama dili yarışmasında en iyi dereceleri aldılar. Söz konusu yarışma Curl Corp. tarafından destekleniyordu.

Mueffke etkileşimli bir web form elementi, Damle ise bir alışveriş arabası tasarladı. Programlar basit olmakla birlikte her iki yazılımcı da dilin çok kullanışlı ve öğrenilmesinin de çok kolay olduğunu belirttiler.