Mingitau
23/02/2005, 20:43
Program yazarken en zor husus, nerede duracağını bilmektir bence. Bugün aklıma geldi, not düşeyim dedim.
Bir uygulama yazarken karşımızdaki sorunlardan en büyüğü, sorunun kendisini tanımlayabilmektir. Tipik "Nasıl çay yaparsınız?" sorununa bakarsanız, lojistik, aşçılık, damak zevki, bütçe vs. bir sürü şey biraraya geliverir. Sonuçta tipik bir uygulama sözle bir kaç satır olan sorunu bir kaç bin satır kodla ancak aşar hale gelir.
Bu sorunu çözmek üzere en faydalı yaklaşımlardan biri nesneye yönelik yaklaşımdır. Bu yaklaşımda problemi ifade eden "Problem Domain" tarif edilir. Buradaki aktörler ve aralarındaki ilişkiler belirlenir. Hayat döngüleri çıkarılır ve voilaa. Arkası çorap söküğü gibi gelir. Ne kadar atomik nesnelerle problemi tarif ederseniz, o kadar sağlıklı bir analiz yapmış olursunuz. OOP'un inheritance kavramını da işe katıp bu atomlardan üst düzey nesneler oluşturdukça, sorun çözümü sorun olmaktan çıkar.
Programlamadaki en kritik husus olan doğru tasarımın en önemli ayağı, sorunu doğru kavrayabilmek ve işte bu problem domain'ine giren atomik nesneleri doğru tespit edebilmektir. Ama bu bir zaman maliyetine sahiptir. Zaman, sonsuz değildir. Daha kötüsü zaman tasarımcıya bıkkınlık veren bir kavramdır. O bir an önce klavye ve kod başına oturmayı ister. Bu yüzden genellikle her zaman orada olan sorunlar görmezlikten gelinir. Hatta bazen görülmez. Fakat uygulama iş yapmaya başlayınca, bu sorunlar birer birer kafamıza düşmeye başlar.
İşte bu noktada, sorununun analiz zamanı ve analiz kalitesi arasında bir denge kurmak kritik bir husustur. Eğer, makul bir uygulama yapmak istiyorsanız, sorunların mutlaka farkında olun. Sorunların hepsini uygulamanız içinde çözemiyor/çözmüyor olabilirsiniz. Şu zaman illeti gene burada tepenizdedir. Genellikle sorunların farkında olmadan yapılan kodlama ve ileri dizayn safhaları daha çok zaman kaybına neden olur.
Kısacası, sorun yumağını doğru tanımlamak en önemli husustur. Bu sorunların tümünü çözemeyebilirsiniz. Bir sonraki versiyonda çözersiniz en kötü ihtimalle. Ama bu sorunlardan kaçamazsınız. Mutlaka ama mutlaka, önceliği sorunları doğru tespit etmeye vermek gerçekten zaman yönünden daha kazançlı çıkmanızı sağlayacaktır.
Peki sorun yumağını çözebilmek için ne yapabiliriz? Bunun bir yolu yordamı, reçetesi var mıdır? Belki her durumda %100 garantili bir prospektüs yok, varsa da ben bilmiyorum. Ama çoğu durumda sorunları tespit edebileceğiniz, requirement/review oluşturma yöntemleri var. Nasip olursa, buraya bunlarla alakalı şeyler de ekleriz sanıyorum...
Serdar Köylü yine mükemmel bir adım adım anlatısı yapmış. Tanımlamasında Malzeme derslerinde gördüğüm önemli anlatılara benzer noktalar gördüm, mesela bir parça çeliğin daha sağlıklı olması için en ufakparçalarını etkileyen şeyleri inceliyorsunuz. En minimal boyutta(iki atom;iki molekül) sorunları çözünce ardışık olarakdiğerçiftlerle sorunları aynı yöntemlerle çözüyorsunuz ve ssonuca gidiyorsunuz.
Bir uygulama yazarken karşımızdaki sorunlardan en büyüğü, sorunun kendisini tanımlayabilmektir. Tipik "Nasıl çay yaparsınız?" sorununa bakarsanız, lojistik, aşçılık, damak zevki, bütçe vs. bir sürü şey biraraya geliverir. Sonuçta tipik bir uygulama sözle bir kaç satır olan sorunu bir kaç bin satır kodla ancak aşar hale gelir.
Bu sorunu çözmek üzere en faydalı yaklaşımlardan biri nesneye yönelik yaklaşımdır. Bu yaklaşımda problemi ifade eden "Problem Domain" tarif edilir. Buradaki aktörler ve aralarındaki ilişkiler belirlenir. Hayat döngüleri çıkarılır ve voilaa. Arkası çorap söküğü gibi gelir. Ne kadar atomik nesnelerle problemi tarif ederseniz, o kadar sağlıklı bir analiz yapmış olursunuz. OOP'un inheritance kavramını da işe katıp bu atomlardan üst düzey nesneler oluşturdukça, sorun çözümü sorun olmaktan çıkar.
Programlamadaki en kritik husus olan doğru tasarımın en önemli ayağı, sorunu doğru kavrayabilmek ve işte bu problem domain'ine giren atomik nesneleri doğru tespit edebilmektir. Ama bu bir zaman maliyetine sahiptir. Zaman, sonsuz değildir. Daha kötüsü zaman tasarımcıya bıkkınlık veren bir kavramdır. O bir an önce klavye ve kod başına oturmayı ister. Bu yüzden genellikle her zaman orada olan sorunlar görmezlikten gelinir. Hatta bazen görülmez. Fakat uygulama iş yapmaya başlayınca, bu sorunlar birer birer kafamıza düşmeye başlar.
İşte bu noktada, sorununun analiz zamanı ve analiz kalitesi arasında bir denge kurmak kritik bir husustur. Eğer, makul bir uygulama yapmak istiyorsanız, sorunların mutlaka farkında olun. Sorunların hepsini uygulamanız içinde çözemiyor/çözmüyor olabilirsiniz. Şu zaman illeti gene burada tepenizdedir. Genellikle sorunların farkında olmadan yapılan kodlama ve ileri dizayn safhaları daha çok zaman kaybına neden olur.
Kısacası, sorun yumağını doğru tanımlamak en önemli husustur. Bu sorunların tümünü çözemeyebilirsiniz. Bir sonraki versiyonda çözersiniz en kötü ihtimalle. Ama bu sorunlardan kaçamazsınız. Mutlaka ama mutlaka, önceliği sorunları doğru tespit etmeye vermek gerçekten zaman yönünden daha kazançlı çıkmanızı sağlayacaktır.
Peki sorun yumağını çözebilmek için ne yapabiliriz? Bunun bir yolu yordamı, reçetesi var mıdır? Belki her durumda %100 garantili bir prospektüs yok, varsa da ben bilmiyorum. Ama çoğu durumda sorunları tespit edebileceğiniz, requirement/review oluşturma yöntemleri var. Nasip olursa, buraya bunlarla alakalı şeyler de ekleriz sanıyorum...
Serdar Köylü yine mükemmel bir adım adım anlatısı yapmış. Tanımlamasında Malzeme derslerinde gördüğüm önemli anlatılara benzer noktalar gördüm, mesela bir parça çeliğin daha sağlıklı olması için en ufakparçalarını etkileyen şeyleri inceliyorsunuz. En minimal boyutta(iki atom;iki molekül) sorunları çözünce ardışık olarakdiğerçiftlerle sorunları aynı yöntemlerle çözüyorsunuz ve ssonuca gidiyorsunuz.