Tuesday, July 24, 2007

Developer sadece kod mu yazar?

Bundan 7-8 sene önce Kıbrıs'ta bir grup arkadaş program yazdığımız sırada, ya da ondan bir kaç sene sonra yine bir grup arkadaş, İsrail'e bir proje geliştirdiğimiz sırada, yaptığımız tekşey kodlama idi. Yani, kodumuzun nasıl çalıştığı, nerede çalıştığı ile ilgilenmez, sadece ne yaptığı ile ilgilenirdik. Sonra okul bitti ve şimdiki işyerimde çalışmaya başladım. Burada bir iş akış sistemi geliştiriyorduk. Burada da kod yazıyorduk, ama zaman zaman IIS'i restart etmemiz gerekiyordu. Sonra, kodumuzda bir açık olduğunu ve sistem performansında darboğaz oluştuğunu farkettik, bu sefer yavaş yavaş yazılan SQL cümlelerini analiz etmeye başladık. Sonra MS SQL Server üzerinde Performance Tuning olayları ile ilgilenmeye başladım. Bu bahsettiğim olay ise tam 3 sene önce idi.

Yukarıda kendi programcılık deneyimim ile ilgili yazdığım paragraf bile, bir developer'ın on senelik sürede nasıl değiştiğini, nasıl değişmesi gerektiğini sanırım ifade etmiştir. Yani bundan 10 sene öncesinde bir developer sadece kod yazıyordu, ama aradan geçen zaman ve proje yönetimi kavramındaki pozitif değişiklikler beraberinde Agile Development ve Extreme Programming kavramlarını getirdi. Ve bu kavramlar da developer'ın yapması gereken işleri ve sorumluluğunun çerçevesini genişletti.

Şimdi birazda şu anda geliştirilen uygulamalara bakalım. Örneğimiz de benim üzerinde çalıştığım proje olsun. Kapsamlı ya o bakımdan.. Geliştirdiğimiz projede developer'lardan ilk beklentimiz darboğaza yol açmayacak kodları sürüm sistemine dahil etmeleridir. Bunu yapmak için developer'lar (isterlerse 3rd party tool'lar kullanarak) kodlarını analiz edip, olası bug'ları ve leak'leri temizlemek zorundadırlar. Bu da onlara kod yazmanın yanında kodlarını analiz etme yükümlülüğünü de getirmiştir. Sürüme katılan her bileşen veritabanı ile ilgili yaptığı operasyonlardan sorumludur, mesela bir tablo yaratılacaksa, uygun index'ler ile yaratılmalı ve gerekli key'ler verilmelidir. Bu da veritabanı bilgisi ve performans iyileştirme kavramlarını getirmektedir. Kodlama içerisinde bir SQL cümleciği sorun yaratıyorsa, bunu TOAD veya SQL Navigator'da açıp SQL'in nerede takıldığını bulmak zorunda olabilir, bu da yine performans iyileştirme kavramını beraberinde getirmektedir. Büyük ölçekli sistemlerde çıkabilecek hataları önceden tahmin etmek için kodlarını lokalde çalıştırıp Memory ve CPU değerlerini gözlemlemelidir, bunun içinde etrafta bir sürü araç mevcut. Sakın gözünüz korkmasın, bu bahsettiğim işler yapılan işler. Yani çalıştığım projede zaman zaman bu tür voltranlar oluyor. Arada sırada ışın kılıcını falan çıkarıyorlar.

Evet Voltran, bundan sonra developer değil Voltran diyeceğim. Çünkü yazdıklarımdan sonra Developer kavramı Voltran'a benzedi değil mi? Ama doğal eleksiyon sadece doğada yok, iş piyasasında da var. Yani bunları yapabilen developer'ın yaşama şansı daha yüksek.. Çünkü bu tür yeteneklere sahip developerlar geliştirilen projeye daha çok katkıda bulunurlar. Yani bir programlama dilinde mükemmel kod yazıyor olabilirsiniz, ama artık sadece mükemmel kodlama yapmanın yanında yazdığınız kodun sistem ile entegrasyonunu anlamak, iş mantığını çözmek ve sistemi bir bütün olarak düşünebilmek yavaş yavaş ağır basmaya başladı.

Developers' Changing Roles linkinde bulduğum bir röportaj bayaa ilgimi çekti. Can alıcı ve hakikaten gözümüzün önünde olduğu halde, bize sıradan gelen bir değişimin hikayesi..

3 comments:

İbrahim DEMİR said...

Selamlar Oğuz Bey;

Ben de yakın zamanda blogumda "sistemden anlamayan developer olur mu? " başlıklı bir yazı yazmaya hazırlanırken sizin yazınız güzel bir tesadüf oldu.

Sanırım şu anda developerlarda kullandığımız high level dillerin verdiği bir rahatlık var. Development olayı artık SALDIM ÇAYIRA VIRTUAL MACHINE KAYIRA şeklinde yürüyor.

Hem siz hem de Mustafa abi uygulama sunucularında darboğazların tespit edilmesi ile ilgili yazılar yazıyorsunuz. Ama asıl yapılması gereken hatayı bulmak değil hatayı meydana getirmemek bu da taaaaa development aşamasında sorumluluk ve bilinç ile oluyor.

Ben de bahsettiğiniz yeni projenin bir parçası olduğum için (@Cybersoft :) ) aksaklıkları görüyorum. Ama bu çoğu ortamda malesef böyle. Development .'ı keyfimize göre yaparız sistemciler öleçklesinler yaklaşımı hep var. Hele de sistem kaynakları bollaşınca yada ucuzlayınca bu rahatlık 2'ye katlandı.

Yine çalıştığımız projeye gelicen sanırım burada tıkanıklığa neden olan (performans konusunda) bu projeden sonra ortaya çıkan ürünün başka ortamlara da satılacağı. Yani Oracle gibi lisansı yüz binlerce doları bulan bir RDMS 'de ansi-sql ile işleri yürütüyoruz. Tüm taklaları, kontrolleri uygulama tarafında yapınca haliyle uygulama sunucuları da altta eziliyor.

Özetle sistem tarafından anlamak çok büyük bir avantaj özellikle de bir sistem geliştiriyorsanız tüm parçaları aklınızda canlandırabiliyor olmak çok büyük bir keyif oluyor. Bilmeyince de böyle bloglarda eleştirilere maruz kalabiliyrsunuz :)))

Bir gün bu OID 'ler çakışacak diye öpüm kopuyor :)

Kolay gelsin.

oguzdag said...

Selam İbrahim,

Yorumun için teşekkür ediyorum.

İnsanlar, bir tehdit gördüklerinde buna karşı kendilerini hazırlarlar, hazırlamayanlar kaybederler, bu doğanın kuralı. Ve bu kural o kadar genel bir kural ki, her yerde var.

Developer'da kod yazmanın artık sadece kod yazmak olmadığını, güzel kod yazmanın, optimize kod yazmanın, ölçeklenebilir kod yazmanın aslında kod yazmak olduğunu anlamak zorunda. Çünkü piyasa artık bu tür kodlama yapan insanları istiyor.

Sonuçta bahsettiğim çok zor birşey değil. Sadece işi layığıyla yapabilmek...

İbrahim Demir said...

Doğanın genel kuralı konusunda haklısnız ama arada gözden kaçan en önemli nokta insanalar o tehditi göremiyorlar.

Yani siz işin sistem tarafında olduğunuz için bunları görüp o insanlara da göstermeye çalıştığınızı biliyorum. Ama gelin görünkü tekrar iş başına dönüldüğünde aynı hatalar tekrarlanıyor. Burada kötü alışkanlıkların yanı sıra iş yükünün de etkisi var diye düşünüyorum.

Herkes ortaya çalışır bir ekran çıkarma derdinde. Çalışsın da hele sağ sağlim bir exception fırlatmasın da sonra optimize ederiz??? O sonra da hiçbir zaman gelmiyor haliyle.

Bir diğer yanıltıcı noktada yük altındayken sistemi göremiyor olmak. En güzeli Mustafa Abi gibi GCViewer ile yaşanan yükü gösterip "bakın marifetinize" demek. Çünkü dev. ortamında en sağlam testi en fazla 20 veri ile yapıyoruz ve daima single user olarak işi götürüyoruz:) (Bu da test etmekse artık) Burada bir load simulasyonu yada bir stress test uygulanmadığından herşey çok güzel geliyor bize (çoğu kişi bu hataya düşüyor malesef)

Umarım birgün herkes işini layıkıyla yapar ve layıkıyla yapabileceği kadar iş alır.

Selamlar.