yazılım geyiklemeleri

Standart CV sitelerinden bir ilan;

ÜRÜN GELİŞTİRME UZMANI

İşin Tanımı :

İşe kabul edilecek kişi; Ürün geliştirme proje ekibi içerisinde analiz, tasarım, kodlama çalışmalarını gerçekleştirmek, müşteri ortamında kurulum, entegrasyon ve destek hizmet vermekten sorumlu olacaktır.

Aslında bu ilan Türkiye'de ürün geliştirme ve arge projelerine bakış açısının bir özetidir. Yapılan her tür işe "ürün" sıfatıyla bakılması yüzünden bu noktaya geldik.

Belki Ürün ve Proje ayrımlarını bu saatte yapmak belki geç olacak ama olsun;

Üzerinde belki milyonlarca kitap/yazı yazılmış bir konu olan yazılım ürünleri ile diğer "ürün" adı verebileceğimiz bir emek sarfedilen işler/nesneler arasındaki ayrım; ortaya çıkan "şey"in tüm geliştirilme ve hayat döngüsünü etkileyecek kadar önemlidir.

Niyetim bu blog'u okuyan kişilere ürün geliştirme nedir diye öğretmek değil, sadece kendi bildiğim kadar kısmını aktarmaktır.

Ürün'e ait özellikler;

Belirli bir müşterisi yoktur

Kısa boylu insanlar için pantalon üretebilirsiniz ve bu bir ürün olabilir ancak ismi "Ali" olan birisi için dikilen pantalon ancak bir "Proje" olabilir. Çünkü kısa boylu insanlar'ın farklı talepleri (genişlik, desen, renk) olacaktır ve tüm bu talepleri dikkate alarak üretim yaparsınız. İsmi "Ali" olan birisine ait pantalon üretirken talepler sabittir.

Belirli olmayan talepler için üretim yaparken tüm olası parametreleri düşünerek hareket etmeniz gerekir. Bu ürünün geliştirme süresini arttırır ancak yaygınlığı daha fazladır.

Taleplerin belirli olmadığı bir ortam için öncelikle fzibilite yapılmalıdır. (Türkiye'de bunun yerine önce proje geliştirilir ve sonra kullanabilecek başka kim var diye bakılır. Birileri belki bulunur ancak genellikle talepler farklıdır. Belkide temel hatalardan birisi bu). Fzibilite çalışması yapmadan geliştirme yapmanın belki de tek kuralı "Domain Expert" olmanızdır (-ki gönlüm el vermeden yazıyorum bunu). "Domain Expert" olmadan ürün geliştirmeye çalışmak, taleplerin belirli (belki 1 adet?) müşteri grubundan gelmesi demektir, ki genellikle sonucu facia ile biter.

Taşınabilir olmalıdır

Ürün kullanılırken konfigurasyon denilen değişiklikler dışında başka bir müşteride de kullanılabilir olmalıdır. Taşınabilir olması yaygınlığını arttırmanın en temel kuralıdır. Geliştirdiğiniz yazılım taşınabilir değilse onu geliştirildiği yerde bırakıp eskiye dair bilgilerinizle yeniden geliştirmek her zaman için en kısa yoldur.

Özelleştirilebilir olmalıdır

Farklı taleplerin olduğu yerlerde ihtiyacı karşılamak için ürün üzerinde yine "Taşınabilir" özelleştirmeler yapılabilmelidir. Taşınamayan özelleştirmeler ürün ile proje'nin birbirine girdiği noktadır.

Örneğin yazılım içerisinde "ProjeKodu = 12345" benzeri bir satır var ise bu yazılımın tem taşınamaz, hem de özelleştirilemez olduğunun kanıtıdır. (En çok temel yazılımcılar tarafından yapılır bu hata)

Versiyonları vardır

Ürün'lerin önceden biçilmiş bir hayatları yoktur, talep olduğu sürece hayatlarını (gelişerek) devam ettirirler.

Proje'lerde versiyonlar iş tamamlanana kadar (ki bu zaten işin sonudur) devam eder ve geliştirilmesi durur.

Sistematiği vardır

Ürün geliştirilirken izlenen her yolun bir sistematiği ve disiplini vardır. Bu sistematiğin dışına çıkılan her yolda karanlıklar içinde kaybolup kendiliğinizden başladığınız noktaya geri dönersiniz.

Projeler için talepleri karşılamak ilk hedeftir. Bu yüzden her yol mübahdır, en kısa ve en doğru yol ışığa çıkar.

Ürün ve Proje ekipleri farklıdır

Anlayış farkı nedeniyle, geliştirme ekipleri farklıdır. Bu ekipleri birbiriyle karıştırmak projelerin uzamasına, ürün'ün ürün olmaktan çıkmasına neden olur.

Proje'de çalışan ekipler müşterinin talepleri ile güdülme eğilimindedir ve görüş açıları (detayları nedeniyle) ancak proje kapsamındadır.

Ürün geliştirmede çalışan ekipler kendi geçmiş tecrübe ve yaratıcı fikirleri ile güdülür.

Yukarıdaki ilandaki gibi "destek" kısmını ayırmadığınızda hem proje hem ürün ekibiniz dağılır. Sonuçta (ve kısa zamanda) "never ending story" tipi bir sürü yazılım elinizde kalır.

Özet

Kısaca terzi'lerin çalıştığı bir pantalon fabrikası kuramazsınız. İkiside kutsal işlerdir ancak amaçları farklıdır.

Yaptığınız işte daha iyi olmak için neler yapabilirsiniz?

Notepad kullanın

Normalde nerde kod yazıyor olursanız olun, kod dosyalarını çift tıkladığınızda notepad ile açılır hale getirin.

Bu hem dosyalara bakmak istediğinizde size hız sağlar hemde IDE olmadığı durumlarda eliniz ayağınıza dolaşmaz.

Notepad2 kullanın

Windows ile standart gelen notepad temel işlerinizi görecektir ama kod üzerinde hafif düzeltmeler yapmanız gereken durumlarda syntax hilighting gibi cici şeylere ihtiyaç duyabilirsiniz.

Ben notepad'e benzediği için notepad2 kullanıyorum, ultraedit gibi daha gelişmiş olanları var ama editor konusunda minimum ihtiyaçları karşılaması yeterli. Böylece kendi makinanız dışında başka yerde çalışırken tekrar eliniz ayağınız dolaşmaz.

Araç Seti Oluşturun

Sık kullandınız araçları bir dizinde toplayın, böylece bir sorun yaşadığınızda elinizde ne olduğunu unutmazsınız.

Kullandığınız araçlara sadece bir tıklama ile uzak olacak şekilde kısayollar oluşturun. Benim yolum desktop'da bir toolbar açarak tüm kısayolları buraya yerleştirmek. Böylece ekranda daima karşımda olan bir araç seti olur. Unutmadan desktop'unuzdaki kaldırabildiğiniz herşeyi kaldırırsanız tüm pencereleri minimize ettiğinizde rahat bir nefes alabilirsiniz.

Araç olarak kullandıklarım;

• regmon
• Registry'e erişimleri loglayan bir araçtır. Programların registry üzerinde ne işe yaptıklarını izlemek için kullanılır
• filemon
• RegMon gibi ancak dosya sistemi üzerinde yapılan işlemleri izlemeyi sağlar
• CSS Reference
• Herhangi bir CSS Reference sayfasına link. Internet olmadığı durumlarda kullanabilmek için ben kendi diskimde tutuyorum.
• DbgView
• DbgView (DebugView) uygulamaların hataları bulmak için yazdığı logları görmek için kullanabileceğiniz bir uygulama. Çoğu uygulama buraya kayıt atmaz ancak kendi uygulamanız içinde System.Diagnostics.Debug yada Trace classlarını kullanarak buraya çıktı gönderebilirsiniz.
• ProcessXp
• Windows ile standart gelen Task Manager'a alternatif olarak kullanabilirsiniz. Bunun yanında .Net processleri ile ilgili bazı bilgilerde veriyor.
• Internet Information Services
• Normalde Control Panel\Administrative Tools altında bulunan bu kısayol web altında geliştirme yaptığınız durumlarda en çok kullanacağınız araçlardan biridir.
• HexEdit
• HexEdit text dışındaki formatlardaki dosyaların içeriğini görmek için kullanabilirsiniz. Gayet minik ve göstermek için dosyanın tamamını okumadığı için gayet kullanılabilir bir araçtır.
• Reflector
• Reflector hem .net kütüphanelerini gezmek hemde içeride ne yapıldığını görmek için kullanabileceğiniz bir decompiler. Çoğu hatanın asıl nedenini bulmak için yardımcı olacaktır.
• Managed Spy
• .Net uygulamarının içeriğini kurcalayabileceğiniz bir uygulamadır. Uygulamanın penceresi içerisindeki nesnelerin özelliklerini çalışırken değiştirmenize izin verir.
• TcpView
• Network bağlantısı yapmış yada yapan uygulamaları izlemek için kullanabilirsiniz.

Bu araçların dışında kendi yazdığım diğer bir sürü uygulamalarda (XmlFormat, Base64Decoder..) ve yıllardır kullandığım bir Dopus uygulaması varki, windows'un içinde preinstalled gelsin istiyorum.

Firefox Kullanın

Web uyumluğuğu, performans, açık kaynak konularını bir kenara bırakın sadece FireBug için bile bu browser'ı kullanabilirsiniz. Internet Explorer nedense gittikçe daha yavaş daha tuhaf daha bişeyler oldukça bu böyle kalacak.

Firefox ile aşağıdaki addonları mutlaka kullanmanızı tavsiye ederim.

• Firebug
• IE Tab
• Linkification
• PDF Download

Beyond Compare Kullanın

Beyond Compare kod dosyalarını karşılaştırmak için para veripde karşılığını alabileceğiniz az adetteki araçlardan biridir. TortoiseSVN ile birlikte kullanma imkanınızda var.

Source Monitor ile istatistiklerinizi izleyin

Source Monitor kodlar üzerinde statik analiz yapmanızı sağlayan bir araçtır. Bu araçla satır adedi, karmaşıklık gibi detaylı raporları görebilirsiniz.

Fiddler

Web üzerinde uygulama geliştiriyorsanız arkada neler olduğunu görmek için kullanabileceğiniz en iyi ve tek uygulama. Kendisini browser'a proxy olarak tanıtıyor ve http işlemlerini izlemenizi sağlıyor.

Biraz uzun bir yazı oldu ancak halen yeterli olduğunu düşünmüyorum ancak konuyu bilmeyenler için hızlı bir giriş ve önemli konuları anlatabilirim umarım.

Serialization tanımladığınız class'ları memory, disk, network gibi katmanlardan geçirmek için kullandığınız teknolojidir. .Net içinde Remoting, WebServices gibi geniş alanlarda siz farkında olmadan sessiz sedasız çalışırlar.

Tanımladığınız class serialize edilirken kullanacağınız formata göre farklı şekillerde formatterlar kullanılır. Format olarak .Net içerisinde Xml ve Binary olarak temel 2 format için formatter tanımlanmıştır.

Serialization'da temel olarak yöntem bir obje üzerinden diğer tüm obje ilişkileri çözülerek bir hedef kaynağa tüm özellikler yazılır. Karşı tarafta da aynı işlemin tersi yapılarak obje yeniden hayata geri döndürülür.

Serialization sırasında objeniz üzerindeki Method, Property gibi özellikler kaydedilmez, sadece ve sadece private olarak tanımlanmış class üzerindeki tüm yer kaplayan bilgiler (string, datetime, başka bir class) kaydedilir. Bu işlem system.reflection ile class üzerinde tüm değişkenler taranarak yapılır. Bu yüzden class'ı yeniden hayata geçirek olan tarafda o class'ın biliniyor olması gereklidir, yani client ve server tarafında aynı class'ın tanımlanmış olması (dll yada farklı yöntemlerle) gerekli.

Bu arada System.Reflection kullanıldığı ve genel bir sistem için tasarlandığından standart class yaratıp kullanmaya göre biraz daha yavaş çalışır ama korkulacak seviyede bir yavaşlıktan bahsetmiyorum.

Binary Formatter

Binary formatter çoğunlukla hız gereken yerlerde (Remoting) gibi kullanılılır. Mesela Client/Server bir uygulama yazmak istediğinizde classlarınızın çok hızlı şekilde client ve server arasında dolaşmasını istiyorsanız bu format sizin için uygun olacaktır.

Aynı şekilde bir class'ı diske kaydetmek istediğinizde .Net size itiraz etmez ancak pratikte bunun bazı yan etkileri olacaktır. Bu detaylara ilerleyen kısımda geliriz.

Xml Formatter

Bu formatda class xml formatına dönüştürülerek yapılır. Üretilen Xml formatı açık olduğu için herhangi bir başka uygulama yada platform tarafından okunabilir. Böylece web servislerinin tüm kapıları açılır.

Örnek olması için başka bir blog'dan aldığım örnek;

Code:

class'larını serialize etmek isteğinizde;

XML:

bir xml dosyası oluşacaktır. Bunu yapmak için;

Code:

metodunu kullanabilirsiniz.

Dikkat

Serialization dikkatli kullandığınız sürece her zaman için işinize yarayacak bir araçtır. Ancak yanlış kullanımlarda başınıza ciddi sorunlar açabilir.

Diske kayıt işlemleri için ASLA binary formatter kullanmayın. Aksi halde class'larınız üzerinde değişiklik yaptığınızda yada versiyon'u numarasını değiştirdiğinizde eski verileri okuyamazsınız. (Bunu atlatmanın yolları var ancak pratikte pek işinize yaramaz)

Client/Server konuşmaları için ASLA xml formatter kullanmayın. Aksi halde ciddi performans sorunları yaşayabilirsiniz. Web servisleri içinde xml formatter kullanılsa da bu servisler zaten yavaş çalışacağı bilinerek tasarlandığından sorun olmaz ancak client server tipi uygulamalarda kabul edilen sınırı aşan bir yavaşlık yaşarsınız.

Yeterli zamanınız varsa xml için kendi mekanizmanızı oluşturun. Bu xml verisini okumak ve class'ları başlatmak için çok daha hızlıdır.

Code:

şeklinde bir interface tanımlayarak kendi serialize metodlarınızı tanımlayabilirsiniz. Bu sayede reflection olmadan hızlı yollarla ve versiyon değişikliklerinden etkilenmeden yola devam edebilirsiniz.

Bir köşesinde benim de tuzum olan Tasdix Türk Blog Yazarları Buluşması’nda sunumu olacak. Katılmak için adresinden form'u doldurabilirsiniz.

Tasdix, 9 Şubat 2008 Cumartesi günü altıncısı düzenlenecek olan Türk Blog Yazarları Buluşması’na katılıyor. Blog yazarlarının her ay biraraya gelerek internetin farklı boyutlarını tartıştığı Türk Blog Yazarları Buluşması’nda, uzman konukların tecrübelerini aktardığı sunumlara da yer veriliyor. Taxim Hill Hotel’de gerçekleşecek olan etkinlik kapsamında “Web Üzerinde Fikri Haklar ve İçerik Koruma” konusu Tasdix’in katkılarıyla ele alınacak ve internet ortamında özgün tasarım ve içeriğin korunması için alınabilecek önlemler tartışılacak.

Türk Blog Yazarları Buluşması’na katılım ücretsiz ve blog yazarı olmayanlara da açık. Etkinlik ayrıca canlı yayınlanacak.

9 Şubat 2008 Cumartesi 16.00
Taxim Hill Hotel, Taksim - İstanbul

www.tasdix.com

Konuya yabancı olanlar için xml namespace'leri "allahın belası prefixler ve web adresleri" olarak gözükmesi normaldir. (kendimden biliyorum)

Konuya başlangıç olması için örneğin;

XML:

şeklinde bir xml düşünelim. Bu bir web servisinin kullandığı bir tanım yada bir uygulamaya entegrasyon için kullanılıyor olabilir.

sorun person içerisine kendinize özgü bir alan (mesela yaşı belirtecek olan bir age şeklinde bişey eklediğinizde ortaya çıkar. yani;

XML:

age element'ini eklediğinizde kullandığınız webservisi yada uygulamanın "age diye bir şey bilmiyorum ben!" diye bağırmaması için dua etmeye başlayabilirsiniz.

xml namespace'leri tam bu aşamada devreye girerek aynı xml içerisinde farklı amaçlar/alanlar tanımlamanıza imkan verir. yani;

XML:

şeklinde person ve içindeki namespace verilmemiş tüm elementlerin "http://mynicewebservice.org" adresine ait olduğunu ama age element'inin farklı bir alana ait olduğunu belirtebilirsiniz.

verilen adresler gerçek bir web adresi olmak zorunda değildir ancak teoride o namespace için kullanılan schema'ları içeren bir xsd göndermesi beklenir. bunu yaparsanız Visual Studio gibi renkli ortamlarda intellisense gibi olayların otomatik çalışmasını sağlayabilirsiniz.

neden prefix?

aynı namespace'i birden fazla kullanılması durumunda xml içerisinde yüzlerce xmlns="http://mynicewebservice.org" yazmak yerine bunu kısa yoldan yazacak bir metod kullanmak gerekir. yani;

XML:

böylece xx prefix'i verilmiş tüm node'lar söylediğiniz alana ait olur.

bunun daha derli toplu olmasını istiyorsanız root element içerisinde tüm namespace'leri tanımlayarak daha temiz bir xml elde edebilirsiniz.

yani;

XML:

yazdığınız prefix'lerin hiç bir önemi yoktur, önemli olan namespace url'sinin unique olmasıdır. bu xml'i okuyacak olan sistem sizin verdiğiniz prefix'lerle ilgilenmez bile, onun için önemli olan namespace için verdiğiniz (web adresi) uri'dir. kendine ait olan veriyi bu namespace içerisinde okuyacağı için sizin gönderdiğiniz age element'ini görmezden gelecektir. yani;

XML:

örneği bir önceki xml ile tamamen aynıdır. prefix sadece namespace'i tanımlamak için kullanılır.

ne sorun yaşarım?

gelelim "allahın belası" kısmına,

öncelikle bu xml'i okuyacak sistemin namespace tanımlarına dikkat ediyor olması gerekli, eğer bu tür şeyleri umursamayan bir sistemse "ne demek istiyorsun?" şeklinde hata mesajları verecektir.

xml içerisindeki verileri sorgulamak için kullanılan xpath'ler üzerinde namespace tanımını yapmış olmanız gereklidir.

örneğin;

Code:

şeklinde bir kod "xx" prefix'ine ait bir namespace tanımlamadığınıza dair bir hata verecektir. bunun yerine;

Code:

şeklinde xml element'lerine erişebilirsiniz. xml içerisindeki prefix'i canınızın istediği şekilde verebilirsiniz, yeterki namespace'ler aynı olsun.

ne gerek var?

örnekteki gibi ufak xml dosyaları çalıştığınız sürece namespace tanımlarına zorunlu olmadıkça ihtiyaç duymazsınız. ancak xml tanımlarınız genişlemeye başladığında aynı element isimlerinin birbirleri ile çakışması, hangi element'in nereye ait olduğunu tanımlamada zorlanmaya başlarsınız.

buna göre 2 seçim şansınız vardır, ya şimdiden namespace'lere dikkat ederek kod yazabilirsiniz yada benim boyum ufak kalacak diyerek bunların hiç birine aldırış etmeyebilirsiniz. iki yolda mübahtır, hangisini isterseniz.