Made With Notepad Campaign
Uzunca bir süredir, C# yazıyorum. Asp.net ile kullanmak için "Class Library" türünde projeler oluşturuyor, bunları projeye dahil ediyorum. Sayfalarım da zaten Page türünden bir nesne.
Daha önceki yaptığım işlere nazaran (daha önceki projelerim genellikle katalog türü siteler ve sipariş verilebilen küçük firma siteleri idi) hayli büyük bir projeye ikinci girişimimi gerçekleştireli epey oluyor. Şu günlerde, özellikle son birkaç haftada eskisi kadar faaliyet gösteremiyorum internet üzerinde. Geçtiğim günler içinde, eğer özeleştirisini yapacak olursam oldukça aptalca kararlar vermiş olduğumun farkına vardım. Meslekte benden daha tecrübeli olan ve bir ağabeyimin tavsiyesiyle bilgisayarıma Visual Studio 2005 yükledim. Aynı zamanda diğer küçük projelerim için de Visual Web Developer 2008 ile Sharpdevelop 2.2 yi koordineli kullanmaya başlamıştım.
Aynı kodu hem bir metin editöründe, hem de bir IDE ile çıkartabiliyorsam metin editörü kullanmanın bana avantajı nedir? Kocaman bir hiç değil mi? Büyük dosyaları düzenlemek ve içinde değişiklikler yapmanın kolay olması durumu dışında metin editörü kullanmanın bir mantığı yok ki. Bunu benim anlamam neden bu kadar uzun sürdü, sanırım daha önceden girdiğim projelerin büyük olmayışından. Böylece Made With Notepad Campaign den ayrılmış oluyorum. Sonuca giden yolda beni en hızlı götüren vasıtaları kullanmaktan çekinmeyeceğim. Metin editörleri de tabii buna dahil :-)
Derleme zamanı hataları (compile time errors)
Hangi dilde yazdığımızdan bağımsız olarak, hataların ortaya çıktığı zamana bağlı olarak sınıflandırılması gibi bir alışkanlık vardır. Eğer biz hatayı projeyi (veya kaynak kodunu) derleyiciye gönderirken alıyorsak bu bir derleme zamanı hatasıdır. Güçlü tipli bir dil ile (C#, Java gibi) uygulama geliştiriyor iseniz derleme zamanı hataları gidermeden projeyi derleyememeniz gerekir. Typed dataset, güçlü tipler vs. bir çok özellik hatayı hemen almanızı sağlar.
Burada altın kuralımız şu : Hatanın farkına ne kadar erken varıyorsak, o kadar iyi. Bu anlamda derleme zamanı hataları en iyisidir.
Çalışma zamanı hataları (runtime errors)
Bu hatalarla genellikle geliştirme yaptığımız dil, belli yeteneklerden yoksun ise ve bunu dış kaynaklardan karşılıyorsa o noktalarda karşılaşıyoruz. Çok bilinen bir örnek olarak SQL sorgularını gönderdiğimiz zaman. SQL sorgusu veya Stored Procedure adı alelade bir string değil midir? Bunun çalışma zamanında hata vermesi ancak kodun işleyişinin o noktaya gelmesiyle anlaşılacağından çalışma zamanı hataları kötüdür.
Çalışma zamanı hatalarını sevmiyorum. Eğer ben bir tablodan veri çekiyorsam ve tablonun ismi değişti ise beni uyarabilmeli geliştirme yaptığım dil. Veya ben, araya bir ek katman yerleştirme pahasına, çalışma zamanı hatalarını derleme zamanı seviyesine çekebilmeliyim. Bu hataların daha çabuk farkında olmamı sağlayıp program yazma hızımı arttıracaktır.
MS in her şeyi IDE ye bağlama fikrinden nefret etmem belki de boşunaydı. Her şey tek merkezden yönetilince hataları yakalamak daha kolay olacaktır.
Güçlü tipin önemi
Dinamik dillere zaman zaman sempati duyuyorum ancak, güçlü tiplerin gerçekten hata yakalamayı kolaylaştırması (derleme zamanına çekebilmesi) büyük bir avantaj. Bu dinamik dillerde TDD (Test Driven Development) ile aşılabilir. Madem kod o noktaya erişmeden hata olup olmadığını anlayamıyoruz o halde kodun o ihtimali de denemesini sağlarız diyebilirsiniz. Nitekim Dive Into Python içinde roma rakamı çeviren betik geliştirilirken ufaktan çevik yaklaşıma giriş yapılmış.
Ama güçlü tipli dillerde aynı zamanda çevik yaklaşım kullanma şansı da var. O cephede tek eksiğim sanırım tanımlanabilecek en düşük sayıda nesneyi tanımlamak. En iyi pratikleri (Design patterns) inceleyip anlamak, anlatmak.
Son haftalarda bunların üzerine düşünüyorum.
Subscribe