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.

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.

yazılım dünyasında 95'lerde RAD geliştirme ortamlarının yaygınlaşmasıyla dünyamıza girdi grid.

görünüm olarak gayet temiz, satır ve sütunlardan oluşan listeleri sadece 2-3 satır kod yazarak ekranda gösterilebilir ve düzenlenebilir hale getirebiliyorduk.

QBasic ve Pascal'dan gelen programcılar için biraz tuhaf olan yeni windows işletim sistemi için bir sivilceli suratlarımıza atılmış bir sarışın gülümsemesiydi bu kontrol. Ardından gelen birkaç sene sonra tüm arayüzleri gridden ibaret uygulamalar türemeye başladı.

Muhasebe paketleri, hastane uygulamaları, insan kaynakları, stok paketi adı altında görünüşü organize edilmiş excel dosyaları gibi her bütona tıkladığınızda (anlamsız) başka bir grid açılan uygulamalar görmeye başladık. Bu tür uygulamalarda artık arayüz (UI) olarak anlaşılan şey gridler ve bütonlardan ibaretti.

Genetik olarak bozuk arayüzler

Devamında sadece satır ve sütunlar yerine hiyerarşik satırlar, edit ettiğiniz hücreye göre farklı arayüzleri olan tuhaf grid bileşenleri ortaya çıkmaya başladı. Bu tuhaf grid'lerle mail client'larından ERP sistemlerine ve hatta mp3 player'lara kadar garip uygulamalar yazıldı.

Bu uygulamaların tasarımınında herşey kullanıcının veri girebileceği herhangi bir alan olması üzerine kuruludur ve kullanılabilirlik yada kullanıcı dostu olmak gibi terimler grid'in yetenekleri ve programcının zevki ile alakalıdır.

Inductive arayüzler

Windows XP ile başlayan inductive arayüz tasarımları sayesinde artık bu anlamsız;

arayüzler yerine

şeklinde yeni tipdeki arayüzleri kullanmaya başladık. Özellikle yeni Vista işletim sisteminde inductive arayüzler tüm işletim sisteminde görülebiliyor.

Neden?

Grid yapısındaki uygulamalar oldukça gelişmiş diyebileceğimiz uzmanlıktaki yazılımcıların son kullanıcılara bir eziyetidir.

Yazılımcı daha iyi bir arayüz vermediği için kullanıcılar elde olanı kullanmak zorunda kalır. Kullanıcılardan "bu böyle olsa daha iyi olur" şeklinde analitik bir geridönüş beklentisine girmek kendi işinizi başkasından beklemekle eşdeğerdir. Ama bu beklenti nadiren gerçekleşir çünkü onların sizin verdiğiniz arayüzü kullanarak yapacağı bir ton kendi işleri vardır.

Uygulamayı tanımayan bir son kullanıcı için karşılaştığı arayüzler "Napıyoruz? Nerdendi? Şimdi?" gibi soruların kaynağıdır.

Kullanıcıya ne yapması gerektiğini söylemeyen tüm arayüzlerde kullanıcı sizden okumayacağı bir kullanım kitabı isteyecektir. Siz o kitabı yazsanız bile asla okumayacağı için her bir arayüzde ne yapması gerektiğini yan masadaki arkadaşından öğrenmesi gerekir ve bunu sürekli unutur. Her yeni kullanıcı için bir kaç hafta sonra tekrar sorular soracağı aynı eğitimleri tekrarlarsınız. Sadece liste içerisinde göstereceğiniz minik bir ikon bile kullanıcıya biraz önce yan masadaki arkadaşıyla şakalaşması sırasında o anda ne yaptığını hatırlatmaya yardımcı olacaktır.

Uygulamanın kullanım ve bilinirliğini düşürür, bu yüzden son kullanıcı uygulamanızın sadece belli bir oranını kullanır ve bu oran kendiliğinden zaman yükselmez.

Arayüzler yapılacak işleme göre (task based) tasarlanmadığı kullanıcıya olası tüm fonksiyonları içeren ama kurcalanmaya korkulan bir uygulama yaratırsınız. Kullanıcılar kullanıcı kitabının yanında ekrandaki yazılarıda asla okumadıkları için 1sn önce hangi bütona tıkladıklarını ve yazılımın hangi uyarıyı verdiğini hatırlamazlar. (Ne? Emin misiniz diye soruyordu o büton? Peki neden evet'e tıkladın?!) Kurcalanmaya korkulan herşey bilinmezliklerle doludur.

Performansı katleder.

Listeden seçilecek tek bir tane müşteri için binlerce adet kaydın listelenmesinin anlamı yoktur. Siz sayfalama v.s gibi teknikler kullansanız bile hiç bir kullanıcının 55 sayfa içerisinde gezerek istediği kayıdı arayacak zamanı yoktur. Bunun yerine asla tüm kayıtları listelememeli ve arama tabanlı, maksimum adetli bir liste kullanmanız her zaman mantıklıdır. Liste içerisinde sadece kullanıcının o anda yaptığı iş ile alakalı verileri listelemek ve seçenekler sunmak yardımcı olacaktır.

Belki bir mühendislik harikası değil ama kesinlikle bir sanat eseri. Ekran kartım iyi diyorsanız link'deki demoyu seyretmenizi tavsiye ederim.

Nedense bize pek hoş anlatmasalar da yunanlı kardeşlerimiz ASD grubundan.

http://www.pouet.net/prod.php?which=31571