Wednesday, November 1, 2000

Yazılım Şirket Çeşitleri

Bu yazımızda, yazılım üreten şirketlerin hangi kategorileri oluşturduğunu, bu kategorilerin tarihini birkaç örnek ile göstermeye çalışacağız. Kategorilerden birisi olan "ürün şirketi", rahatça bilinen ve tasvir edilen bir şirket olsa da, öteki şirket türü, danışman şirketi, yaygın olarak bilinmeyen yazılım şirketleridir. Yazının bilgilendirici olacağını umuyorum.

Ürün şirketi ile başlayalım.

Ürün şirketleri

Microsoft, Oracle gibi büyük şirketler, paket program olarak ürün piyasaya sürerler. Direk ev kullanıcısı, ya da programcılara hitaben altyapı olarak kullanabilek bu ürünler, parakende fiyat ile piyasada satılır. Ya da, Oracle'ın kullandığı oldukça çetrefilli bir lisans (fiyatlandırma) kuralı eşliğinde ürün müşteriye satılır.

Ürün yazılım şirketleri, bir paketi piyasaya sürmeden önce, uzun süreli bir ar-ge dönemi süresince büyük paralar harcarlar. Mesela Oracle veri tabanı, ya da Microsoft Windows işletim sistemi, milyonlarca dolarlık programcı ve testçinin zaman harcayarak ortaya çıkardığı bir sonuçtur (sürekli bozulsa da (!)).

İlginç olan, ilk geliştirme seviyesi aşıldıktan sonra, paket programlar kopyalanma, ya da normal sanayii'nin anladığı şekilde, üretim/çoğaltma safhasında neredeyse yok denecek bir miktar harcanmasıdır.

Yazılım tabanlı ekonomik modele 'yeni ekonomi' denmesinin de sebeplerinden biri budur. Kıyaslayacak olursak, bir maden ocağı ortada olan belli miktardaki bir kaynağı çıkartıp, piyasaya sürerek getiri kazanmaya uğraşır. Eğer maden ocağı daha fazla üretim yapsın der isek, daha fazla elemen işe koyulması gerekir. Fakat bunun anlamı aynı zamanda maliyat fiyatlarının 'artması' demek olacaktır. Belli bir arttırımdan sonra eldeki kâr kaybolmaya başlayacağı için de, maliyet, üretim miktarı gibi ayarların dikkatli gözlenmesi gerekir, nitekim ekonomide bu kuramın 'düşmekte olan getirilerin kuramı (theory of diminishing returns) olarak anılmasının sebebi budur.

Fakat yazılımda, ürün şirketleri için yazılımın kopyalanması safhası çok ucuzdur, hatta şimdi İnternet sayesinde sıfıra yakındır. Bu yüzden herhangi bir firma piyasaya derhal (en önce) çıktığı anda, sıfır üretim maliyeti sayesinde süratle kopya çıkartarak, piyasayı anında tekelleştirmesi mümkün olmaktadır. Nitekim, Microsoft'un mahkemelik olmasının sebebi de biraz da açıdan alınmalıdır. Yazılım sektöründe, dişe-diş, pastayı eşit paylaşmış olan rakiplerin kavgası yerine, bir tekelin ötekini yıkarak geldiği bir savaş vardır, buna değişik zamanlı tekellerin savaşı denebilir.

Programcılar Açısından Ürün Şirketleri

Ürün şirketleri, bir kod bazı ile uzun süre beraber kaldıkları için, tekrar-tekrar kullanır (reusable) kodlama yapmaya daha özen gösterebilirler. Danışman şirketlerinde tanıştığımız, tekrar kullanılan kodlama tekniklerini en çok ilgi gösteren kimseler, ürün geçmişi olan programcılar oluyordu. Tabii daha farklı olan danışmanlık ortamı, bu arkadaşlara genelde biraz garip gelibiliyor. Yazılıp/atılan kodlama, uzun süreli bakılan/genişletilen kodlar ortamından tabii ki değişik olmaktadır. Danışman şirketleri yazının geri kalan kısmında işleyeceğiz.

Bu fark dışında ürün şirketleri de sürekli tümleştirme tekniklerini kullanırlar, mesela Microsoft projelerinde günlük bütün kod bazını derleyen ayrı bir makina vardır diye duyumlar almıştık. Tabii Extreme Programcılık yöntemi, bu sayıyı çok daha sıklaştırmıştır.

Ürün şirketlerinde bir kötü taraf, zamanla programcının aynı konu üzerinde sürekli çalışması ile ortaya çıkan 'aşırı uzmanlaşma' durumudur, bu durumda bir nevi at gözlüğü takılmış gibi sadece bir konuya odanlanma olayı ortaya çıkabilir; Fakat eğer ürünün gelişmesi uzun sürecek ve gelişerek yeni teknolojiler eklenecek ise, bu durum o kadar kötu olmayabilir. Her halukârda, XP'nin eşleme tekniği ve sandalye değiştirme taktikleri ile bu aşırı uzmanlaşmanın önüne geçilebilir.

Danışman Şirketler

Bu tür yazılım şirketi çoğu kimse için (hatta çoğu programcı için bile) tam bir muammâdır, bu yüzden özellikle işlemek istedik.

Önce tarih.

Danışman şirketlerin tarihi, en azından Amerika'da, 'vergi danışmanlık' tarihi ile yanyana gider.

Bunu da anlamak için Amerika'nın vergilendirme sistemini bilmek gerekiyor. ABD'de birçok vergi kanununun oluşturduğu, yılların da verdiği değişim, lobilerin kendi sektörleri için Kongre'den geçirttikleri ekler (rahatlıklar) yüzünden ortaya çıkan tam bir keşmekeş durumu vardır.

Bu keşmekeşin içinden çıkmak bir süre sonra bir uzmanlık haline gelmiş, ve bu tür danışmanlık yapan şirketler holdinglerin kapısını çalmaya başlamıştır. Danışmanlar, müşterileri olan şirketlere vergilerini nasıl vereceklerini, aynı zamanda da, nasıl daha az vereceklerini öğretmek için vergi sistem açıklarını, müşterilerinin bulundukları sektörü gözeterek önemli bir servis sağlamaya başlamışlardır. Bu danışman şirketlerin sunduğu vergi tavsiyesi, bir bakıma holdinglerin kârlılığı üzerinde direk bir etki teşkil ediyordu.

Bu şekilde vazgeçilmez hale gelen danışmanlar, bir süre sonra vergi danışmanı olarak girdikleri şirketlere yan ürünler de pazarlamaya başladılar.

Bu yan ürünlerden birisi (ya da servis demek daha uygun olur) "stratejik tavsiye" türünden bir danışmanlık idi. Holdinglerin işletmesini ilerletmesi için getirilmesi mümkün olan iyileştirmeler, bir şirketin nasıl düzenleneceği, karar mekanizmasının nasıl isleyebileceği, vs. gibi tavsiyeler hep bu şemsiye altında sunulmaya başlanmıştır. Vergi tavsiyesi için zaten müşterinin kapısından girmiş olan danışman, bir yandan da açık gördüğü yerlerde bu tür yeni danışmanlığı pazarlamakta zorluk çekmemiştir.

Tabii, stratejik danışmanlık, 80'li yıllardan sonra beraberinde teknolojik danışmanlığı da otomatikman getirmiştir.

ABD televizyonlarında çıkan bir IBM reklamının da söylendiği gibi, artık şirket başkanlarının (CEO'ların) aldıkları her karar, mutlaka teknolojik bir değişiklik yani yeni bir yazılım projesi içermektedir. Gitgide yazılıma bağımlı olan şirketler, eğer yeni bir düzenleme yapmak istiyor iseler, yeni bir yazılım değişikliği de yapmaya mecbur kalmaktadırlar.

Bu açığı kapatmak için danışman şirketler, ek bir servis olarak yazılım danışmanlığını da dağarcıklarına ekleyerek yelpazelerini genişletmişlerdir.

Zamanla, bu üç danışmanlık çeşidi bazen tek başlarına görülmeye başlanmıştır. Günümüzde, kimi şirket sırf yazılım danışmanlığı, kimisi sırf stratejik, kimisi de sadece vergi danışmanlığı yapabilmektedir. Tabii eskiler, ya da beş büyük diye anılan şirketler hala tüm servisleri birarada taşımaktalar. (Taşımakta idiler demek daha da doğru olabilir, çünkü son zamanda meydana gelen şirket bölünmeleri bu durumu biraz değiştirmiştir).

Danışman Şirketlerin Düzeni

Sırf yazılım danışmanı olan bir şirketi ele alalım. Bu şirketlerin atmosferi genelde şöyledir.

Bütün hayat proje etrafında döner. Gelişen teknolojilerinde etkisi ile proje bitme süreleri iyice düşmüştür, ve bu yüzden kim nerede, kim hangi projede gibi konuşmalar duyarsınız. Sürekli bir hareket vardır.

Kültür olarak, danışman şirketlerde çalışan kişiler, programcı seviyesinde bile, teknolojiyi allandırıp pullandırmakta en büyük ustadırlar. Çünkü, söyle ya da böyle müşteri karşısına çıkacaktırlar, ve bu yüzden teknolojiyi satmak zorundadırlar. Teknoloji satmakten kastımız, kendilerinin XYZ teknolojisini kullanarak getireceği çözümü satmaktır. Genelde danışman şirketlerin kendi ürettiği bir ürün yoktur.

Artı olarak danışman şirketlerin en iyi tarafı, dinamik ve sürekli devirdaim olan teknoloji bilgisidir. Her proje 6-7 ayda bittiği için, bu her seferinde yeni bir yazılım projesine silbaştan başlanacak demektir, ve bu yeniden başlama sırasında bir önceki projeden gelen, halâ taze olan bilgilerden muhakkak yararlanılır. Mesela kaynak kod idare sistemi kuruluşu, sürekli tümleştirme makinasının kuruluşu, programcıların ihtiyacı olan Unix kullanıcı hesaplarının sıfırdan kurulması birkaç projeden sonra artık süratle yapılır hale gelirler.

Ek olarak, bir de her projenin getirdiği yenilikler vardır. Danışman programcı, her yeni projede, sürekli değişmekte olan teknolojiden yeni bir tanesini denemeye fırsat bulabilir. Sıfırdan başlandığı için ekleme yapmak zor olmaz. Tabii, yeni teknolojiyi öğrenme için harcanacak (kaybedilecek) zaman göz önünde tutulmalıdır. Eğer danışman her projede yeni bir teknoloji ile uğraşılıyorsa, bir süre sonra öğrenmeyi öğrenir, ve yeni teknolojileri daha süratli bir şekilde yutabilmeye başlar.

Tabii herkesin öğrenmesinin bir sınırı vardır; bu yüzden en çok değişik teknoloji ile haşır neşir olmuş danışmanın bile bir 'favori' teknoloji demeti mevcuttur. Bu demet, ne kadar sektörde kanıtlanmış ve geleceği olan teknolojilerden ise, o kadar iyidir, çünkü bu daha kalıcı olacak ve öğrenildiği zaman danışmanı daha değerli halde en uzun süre tutacak bilgiler toplamıdır. Bu yüzden danışman programcıların kafasından, kişisel bazda, sürekli olarak hangi teknolojiler yeşeriyor, hangisinin geleceği var sorusu mevcuttur. Mesela daha kariyerinin en başında, en büyük yol ayırımı yapılır; Microsoft'mu, Unix'mi sorusuna cevap verilir. Amerika'da çoğu danışman bu soruya Unix cevabını vermişlerdir. Her iki yol da, ötekinden çok ayrı uzmanlık gerektirdiğinden, bu seçim çok önemlidir ve genelde bir programcı (bazen danışman şirketleri de) bu iki yoldan sadece birinde uzmanlaşır.

Satış

Burada, sabit zaman/fiyatlı proje usulü çalışan danışman şirketlerinden bahsetmemiz gerekecek. Extreme programcılık hakkındaki yazılarımızda bu şirketlerden biraz bahsetmiştik. Şimdi, sabit modelin satış sürecine getirdiği gerginlikten bahsetmemiz gerekecek.

Netice itibarı ile, danışman şirketin elindeki tek kaynak insandır. Ortada ürün, arazi, gibi demirbaşlar mevcut değildir. Patent yoktur. Bu yüzden satış sürecinde de, satış görevlisinin elinde bir insana dolaylı öteki dolaysız bağlı olan iki sübap vardır. Fiyat ve Zaman.

Bu iki faktör haricinde, mesela Kod kalitesi satış süreci sırasında pek göz önüne alınmaz. Demek ki, satışı kapabilmek için, müşteriye "daha hızlı" ve/veya "daha ucuz" proje satabilmek önemlidir. Eğer danışman şirket 'aç', projeye (yani paraya) muhtaç ise, satış görevlisi bu indirimi yapmak için büyük bir istek duyacaktır.

Potensiyel bir problem işte burada ortaya çıkmaktadır, çünkü satış görevlisi genellikle teknik adam değildir. Bu sebeple yaptıği bu seçimin perde arkasındaki programcılar üzerine getireceği yükten habersiz olabilir. 90'lı yıllarda bu birçok kez olmuş bir vakâdır, faturayı ne yazık ki haftada 70 saat çalışmak zorunda kalan programcılar ödemiştir. CTP, Sapient gibi şirketlerin çalışma durumu 90'lı yıllarda bundan ibaretti. Bu şirketlerdeki programcıların yaş ortalamasınında 30'dan aşağı olması tabii ki raslantı değildir, belli bir yaştan sonra bu tür bir tempoyu kaldırmak zor olmaktadır.

Özetle, öğrenek için iyi bir ortam oluşturan danışman şirketler, tempo olarak hızlı, ve sabit bazda çalıştıkları zaman gerginlik yaratan ortam oluştururlar.

Tabii başka yazıda bahsettiğimiz gibi, eğer danışman şirket belli bir ürün demeti üzerinde uzmanlayı (odaklanmayı) başarır ise, o zaman daha az zamanlı ve fiyatlı proje satmayı başarabilir, ve programcıyı daha az öğütür.

HTML ve Yazitipleri

Dokümandaki yazitipini degistirmek için <FONT> tagi kullanilir, genel kullanimi söyledir:

<FONT SIZE="x" FACE="[isim] COLOR="#XXXXXX">

SIZE degiskeni metnin büyüklügünü ayarlar, bu degiskene -1, +2 gibi degerler verilerek metnin puntosunun bir eksiltilmesini veya iki arttirilmasini saglayabilir, direkt olarak bir rakam vererek puntoyu tayin edebilirsiniz. HTML sayfalarinda SIZE degiskenine verebileceginiz en büyük deger 5'tir. 5'ten sonra vereceginiz her deger siz 5 degeri vermissiniz gibi muamele görecektir. Yazitipi çok büyük olmamalidir, büyük yazitipleri hem kullanicilarin sayfayi okumasini zorlastirir hem de sayfanin güzelligini bozar.

FACE takisini tüm web tarayicilari desteklemese de bu taki kullanilarak sayfada resim kullanmadan oldukça güzel görüntüler elde edilebilir. Örnegin FACE="Arial Tur" takisi kullanildiginda yazi tipi Türkçe Arial olacaktir. FACE degerine Türkçe destegi olmayan "Comic Sans Ms" gibi yazitipleri verilmemelidir, verilirse bazi Türkçe karakterler bozuk olarak görülecektir.

Son olarak COLOR takisi yazitipinin rengini ayarlamakta kullanilmaktadir. Web tarayicilarinin destekledigi temel renklerden olusan tablo geçen ay bu bölümde verilmistir. Tablodan dilediginiz bir rengi seçerek bu degiskenin karsisina yazdiginizda yazitipi rengi degisecektir.

<FONT> ifadesi her zaman bir </FONT> ile sonlanmalidir. Bu tag unutulursa web tarayiciniz sayfalari yanlis görüntüleyebilir. (Bazen de hiç görüntülemez)

Yazarin izni ile http://draskin.150m.com sitesinden alinmistir

Yararlı Solaris Araçları

Solaris işletim sistemi, süreçlerinizin (process) performansını takip edebilmeniz için bazı ek araçlar sağlamaktadır. Bu yazıda gösterilen bütün komutlar izledikleri süreçlere başlangıçta çok az ek bir ek yük getirirler, o yüzden canlı bir sistem üzerinde, özellikle tekrar eden bir şekilde kullanılmaları uygun olmayabilir. UNIX man proc sayfasından bu ve öteki komutlar hakkında daha fazla bilgi edinebilirsiniz.

Problem araştırme ve inceleme için aşağıdaki programlar yararlı olacaktır.

ps -eo pid,pcpu,args | sort +1n

CPU kullanım yüzdesine (utilization) göre ps çıktısı almak (en cok kullanıma sahip olan en altta olmak üzere) için kullanilan ps komutudur. Bu komut bizi ayrı ayrı ps ve top kullanmaktan kurtaracaktır.

/usr/proc/bin/pstack

Bu komut size Java sürecinizin içindeki lwp yığıtını gösterir. Her Java Thread'i koşmaya başlamadan önce bir lwp'ye (hafif süreç/lightweight process) bağlanmak zorundadır, ve bu komutu ile hangi Thread'in hangi sistem çağrısı üzerinde beklediğini raporda görebilirsiniz. Bütün Thread'leri bir soketten okumada, ya da bir yerel çağırım üzerinden JDBC sürücünüzü beklediğini görebilirsiniz. Bâzen bu gibi bir bilgi yeterli olmayabilir, çünkü hangi Thread'in hangi soket no'sunu beklediğini bu araç göstermez.

/usr/proc/bin/pldd

Bu komut hangi yerel kodun (native code) JVM'inize yüklenmiş olduğunu göstermesi açısından yararlıdır. Komut, hangi .so dosyasının JVM sürecine dinamik link edilmiş olduğunu göstererek çalışır.

/usr/proc/bin/pflags

Bu komut, her süreç içindeki her lwp'nin işaretlerini (flags) ve bekleme durumunu (wait state) rapor eder. Bu komutu kaç tane thread context değtirimi (switch) olduğunu anlamak için kullanabilirsiniz. Eğer her JVM için birden fazla CPU var ise, context değiştirimi büyük bir ihtimalle yüksek sayıda olacaktır.

/usr/proc/bin/pfiles

Pfiles, herhangi bir sürecin açık tuttuğu dosyaları gösterir, böylece dosyaların kapanmaması ile alakalı olan problemleri takip etmenize yarar.

lsof

Bir Unix sürecinin açık tuttuğu dosyaları görmek için lsof'u kullanabilirsiniz. lsof, pfiles'a benzer, fakat daha yararlı bir çıktı verir. Daha fazla bilgi için lsof'u şurada ziyaret edebilirsiniz.

truss -c -p

Bu komut, bir sürece karşı başlatılması ve kesilmesi (interrupt) arasında süreç tarafından yapılmış olan sistem çâğrılarını rapor eder. Örnek:

[root@balina /]# ps

PID TTY TIME CMD
11218 pts/5 0:00 ps
11211 pts/5 0:00 bash

[root@balina /]# truss -c -p 11211

^C <<---------------- burada kesilme oldu syscall seconds calls errors -------- ------ ---- sys totals: .000 0 0 usr time: .000 elapsed: 3.750

Kaynaklar

* Yazının aslı

XP ve Danışmanlık

Bu yazımızda, Extreme Programcılığın danışmanlık, teknoloji seçimi, takım idaresi gibi açılardan ele alacağız. Gördüğümüz kadarı ile işletimde (execution) çok yerinde tespitler yapan ve kurallar koyan XP'nin, her seviyede doğru anlaşılması için böyle bir anlatımın yapılması iyi olacak.

Satırların yazarının dahil olduğu danışman şirketleri, proje bazında çalışan, sabit zamanlı/sabit bitiş kodlama süreleri koyan ve sabit ücret alan şirketler idi. Bu tür şirketler, hem kendi açılarından tahmin edilebilirlik (ne kadar kazanırız?), personel idaresi (ne kadar kodcu lazım) gibi sorulara kesin cevaplar bulabildikleri için, herşeyi sabit olarak yapmayı seçmişlerdi.

Fakat yazılım projelerinin ne kadar tahmin edilmez olduğu ortaya çıkmaya başlayınca, beton dökerek çizilmiş Microsoft Proje Gantt grafikleri durumu saptırmaya başladı. Bu duruma çözüm olarak şirketler değişik teknikler getirmeye uğraştılar.

Bazıları, programcılara baskı yaparak stres ortamı altında verim almaya çalıştılar. Ya da, birkaç teknoloji üzerinde yoğunlaşarak tahmin edilebilirliği geri kazanmaya çalıştılar.

Bu çözümlerden ikisi de başarasızlığa uğradı. Hatta ilk çözüm kısa vadede bile çökmüştür. Ekonominin iyi olduğu ortamda, programcılar çabuk yer değiştirebilen insanlar oldukları için, stres yerine daha iyi idarecilerin olduğu şirketlere geçiş yapmayı tercih ettiler, ya da, stres altında yaratıcılık yeşermediğinden, kod kalitesinde düşüş yaşandı. Hâtta baskı ile programcıları geç saatlere kadar çalıştırmaya çabalayan danışman şirketler, gene aynı şekilde kod kalitesi açısından kayıp yaşamışlardır.

Geç çalıştırma danışman şirketlerde 80 ve 90 yıllarında öyle yaygındı ki, genelde danışman şirketlerinde akşam 7'da işte çikmak, "erken" çıkmak olarak adlediliyordu. XP, ismine "programcılık" kelimesini özellikle katmıştır, çünkü amaçlarından biri programcının bu şekilde sakız gibi çiğnenip atılmasını engellemektir.

Kural: Programcılar yanlız ve yanlız normal iş saatleri içinde program yazarlar.

İkinci potansiyel çözüm, şu şekilde duvara tosladı. Moore kanuna göre mikroişlemci hızları her 19 ayda ikiye katlandığına göre, mesela artık sürekli derlenmek yerine "yorumlanan" bir dil olarak Java'nın bilişim sahnesine birden çıkıvermesi mümkün olabiliyordu. Bunun gibi ele geçen donanım hızını aç bir şekilde hemen kullanabilen, tabii ki programcıların üretkenliğini arttıran ama arkası kesilmeyen yeni teknolojiler, yararlı olsalarda, yanlarında şu etkiyi getirmişlerdir: Artık programcıların kendini sürekli yenilenmesi, yeni şeyler öğrenmesi gerekiyordu.

Bu yüzden ikinci çözümdeki belirtilen değişmeyen, tek bir teknolojide uzman şirket/takım tipi de tarihe karışacaktı. XP, akıllıca bir yöntem ile tahmin edilmezlik sorununu çözmemiş, sonunu açık bırakarak zamana yaymıştır. XP ile tahmin edilebilirliği önümüzde gelmekte olan tek bir dönem ile sınırlıyoruz.

Yeni Teknolojiler

Sonuç olarak, XP ile yeni teknolojiler ile oynayan, değişimi seven ve bakleyen bir yapıya kavuşacaksınız. Yeni teknoloji ile oynamanın kuralları şunlar.

Teknolojiyi deneyecebileceğiniz bir "smaç zamanı" ayırın. (XP İngilizce belgeleri bu döneme "spike" adını verir). Dönem içinde smaç yapmak için bile bir özellik (kart) yazın, ve tahmin zamanını üstüne yazarak döneme katın. Böylelikle müşteri önem sırasına göre bazı smaçları bazı özellikler için "feda" edebilir. Her dönem içinde ne kadar smaç, ne kadar gerçek özellik kodlanacağı görülecektir.

Stratejik Boyut

Danışman şirketler!

XP'nin yazılımı gerçekleştiren dönemlerde ne kadar yararlı olduğunu biliyoruz. Fakat bu, stratejik türden danışmanlık yapmadan birkaç paket programı sunarak hemen koda atlayalım demek değildir.

Stratejik danışmanlık yapmak için mutlaka zaman ayırın. Mesela birkaç aylık, proje başlamadan önceki bir dönem içinde, yeni bilgi işlem sisteminin stratejik vizyonu ortaya konmalıdır. Ana teknolojiler kararlaştırılmalıdır. Unutmayın, en kötü plan bile, plansızlıktan iyidir.

Bu seviyede istediğiniz kadar belge/çizelge yaratabilirsiniz. Zaten müşteriniz de bu tür şeyleri görmek isteyecektir. Kodlama başladıktan sonra tabii ki durum değişecek, "programı kodlarken aynı zamanda belgeleyin" diyen olursa, XP'nin kod belgelenmesine yasak koyduğunu belirtin. XP, belge değil, kaliteli kod üreten bir sistemdir. Kodu anlamak isteyen, birim ve kabul testlerine bakabilir.

Stratejik danışmanlık zamanına dönecek olursak, bu seviyede üst kademe teknik liderlerinizi toplantılara katmanız uygun olacabilir. Müşteriniz, teknoloji neleri yapabilir, neleri yapamaz açısından beklentilerini dengelemek açısından bu davranış yararlı olacaktır.

Not: "Beklentilerini dengelemek" kelimesi, bir sabit bitiş çizgili refleks ile çıkmış olsa da, yazıda tutmaya karar verildi, çünkü eski/yeni düşünce farkları göstermesi açısından yararlı olabilir. Klasik projelerde, müşteri sabit parayı ödedikten sonra, sürekli bir danışman/müşteri sürtüşmesi yaşanır. Aynı para ile daha fazla şey isteyen müşteri, bir yandan teknoloji hakkında hayaller de kurmaya başlayınca, danışmanlar toplu bir "hayır" korosuna dönüşebilirler. Yukarıdaki "dengeleme" sözcüğü de bu zamandan miras kalmıştır, fakat yazıda tutulacaktır.

Yani, stratejik dönemde ve sonrasında hem dengeleyin, hem de müşterinizin "ufuklarını" açın.

XP Tarihi

Extreme programcılık, 'önce uzun uzun tasarlama, sonra kodlarsın' fikrinin projelerde başarısız olması ile şekillenmeye başladı. Arkasındaki ilgi, özellikle .com yıllarında daha artmıştır. Bunda, .com projelerinin zorluk ve zamanlama açısından yazılım takımlarına daha büyük yük getirmesi muhakkak rol oynadı. .Com devrinde herkes, piyasaya bir an evvel çıkabilmek için, programcılara ve danışman şirketlere büyük baskılar uygularken, bu baskıların sonucunda, bitirilmesi için 10-11 ay gerektiren proje idare yöntemleri tabii ki 'çatlamaya' başladı.

Eski yöntemler yerine yeni bir yöntem bulmak gerekiyordu, ve XP bu boşluğu doldurdu.

XP'nin bir ayrı doğuş noktası, Kent Beck'in müşteri ve programcı gurupları arasında çok katı çizgiler çizmek istemesidir. Kent, bu iki gurubun birbirinin işlerine karışan ve sonuçta projenin seyrine köstek olan davranışlarını kaldırıp, yerine herkesin kendi işini gördüğü, ve kimsenin kimseye stres yaratıp, baskı uygulayamayacağı bir ortam yaratmak istedi. Çünkü projeyi bitirip/bitirmemek bir yana, Kent programcıların mutsuz ve motivasyon eksikliği yaşadığını farketti, ve altta yatan bityeniğini bularak çözümü sağladı.

Müşteri/programcı çizgileri çizilince, müşteri projenin nereye gideceğinin yegane sorumlusu oluyor, fakat aynı zamanda, hiçbir şekilde programcıya 'şu işi daha hızlı yap' deme hakkına erişemiyordu. XP, her dönemde işin ne kadar hızlı yapıldığını ölçerek, sonraki dönemler için ne kadar iş planlanacağını tahmin etmeye uğraştı. Bir kere tahmin yapıldıktan sonra müşteri, özellik listesini ona göre çıkarıyor, ve sonra 'müşteriliğini bilerek' daha fazla projeye karışmıyordu. Çünkü programcılık teknik bir olay idi, ve özelliklerin ne kadar hızlı yazılıp yazılmayacağı teknik dünyaya ait bir karardı.

Ayrıca, XP'nin teknik kodlama süreci/yöntemleri alanında da hayati tavsiyeler getirdiğini görüyoruz. Kent, anlattıgı bir hikayede, rastladığı bir programcının öteki arkadaşlarına sürekli fark attığını gözlediğini söyler. Bu farkın altında, programcının her yazdığı 3 satıra takabül 1 satır da birim testi yazdığını farkedince Kent, bu yönteme daha dikkatle bakmaya başladı. Genelde programcıyı yavaşlatılacağı düşünülen test yazmak eylemi, uzun vadede test eden programcının lehinde büyük farklar doğuruyordu. Çünkü test yazan programcı, kodunu daha cesurca değiştirebiliyor, ve mimari değişiklikleri bile gözünü kırpmadan yapabiliyordu. Öyle ya, eğer mimari değişikliği yaparken bir hata eklenmiş olsa, derlemeden sonra sürekli işletilen birim testleri, bu yanlışı anında yakalayıyordu!

Ve Kent, bu tekniği de XP dağarcığına kattı.

Mekan

Her hikayeye bir mekan gerekir. XP'nin mekanı, C2 projesi denen General Motors şirketinin bordro kontrol projesidir.

Bu proje, mimari olarak duvara tosladıktan sonra, projede olan Kent, uzun süredir planlamakta XP'yi deneme vaktinin geldiğini anladı. General Motor şirketi yönetiminden izin istedi, ve kolları sıvadı.

Kent ilk önce, en büyük sorun olarak gördüğü iletişim sorununu çözdü. Programcılar ayrı odalarda, ya da aynı odada olsalar bile aralarında plastik duvarlarla ayrıli 'hücrelerde' iş yapmaya uğraşıyorlardı, ve tabii ki iletişim kurmak zor oluyordu. Yazılım projelerinde herkesin bildiği bir vaka şudur: Yanınında olmakta olan bir konuşma, sizin için önemli bilgiler içerir, kulak kabartırsınız, ve gerekli ise konuşmaya katılırsınız. Bu gibi bilgi paylaşımı için hücre sistemi ölüm demekti. Ya da, herhangi birine bir soru sormak isteseseniz, ama soru sormak istediğiniz kişi 50 metre ötede olsa, soruyu sormak için ne kadar zahmete katlanacaksınız? Kafanızı kaldırıp azıcık sesli olarak arkadaşınıza bu soruyu sormak daha iyi olmaz mıydı?

Ufak gibi gözüken bu tip şeyler, çok hızlı gerçekleşen yazılım projeleri için önemli faktörlerdi. Yazılımda, bilinen türden hammadde ve sanayii yoktur, herşey düşünce ve iletişim bağlamında gerçekleşir. Bu yüzden tek bir soru soramamak, hatalı bir kod ile hatasız arasındaki farkı belirleyebilir.

Bunu farkeden Kent, hemen herkesi aynı odada topladı, ve hücre duvarlarını kaldırdı.

Bir sonraki değişiklik, sürekli tümleştirme denen teknik akabinde meydana geldi. Kent, genelde XP yöntemini şöyle tarif eder. "İyi olduğu bilinen yazılım tekniklerinin sesini, sonuna kadar açmak".

Gereksiz bir ifade gibi gelebilir, fakat örneklerle daha berraklaştırmaya çalışalım. Herkesin bildiği programcılık teknikleri arasında, bütün proje kodunu derleyerek, tümleştirmek (entegrasyon) ve testlerden geçirmek gelir. Yani, eğer programımızın kullandıği arayüzleri doğru kullanıp kullanmadığımızı anlamak istiyorsak, bütün kodu beraber derleriz, ve testlerden geçiririz.

Bu işlemi yapmak 'iyi' bir teknik olarak bilinir. Eğer iyi ise, niye her zaman yapmıyoruz? Kent, tümleştirme işini bir otomatik programa bağlayarak, bu programın her yarım saatte bir bütün kodu otomatik derleyerek sonuçlarını projeye e-posta ile bildirsini sağladı.

Bunun sonuçları tabii ki devrim oldu. Artık, eğer kaynak kod idare (KKİ) sistemine yanlış, hatalı, yanlış tümleşen bir kod parçası eklenmiş ise, otomatik derleyici bunu en az yarım saat içinde yakalayabiliyordu. Hata e-posta ile alındığında, proje takımı o anda yaptığı işi bırakıp, tamamen o hatayı düzeltmek ile uğrâşacaklardı.

Böylece, tümleşme hataları taa sonuç ortamına aktarıldıktan sonra değil, hata olduktan 30 dakika sonra yakalanıyordu.

Bir başka örnek kod kontrol sırasında oldu. Arada sırada başkasının kodunu kontrolden geçirmemiz, ve stil, teknik olarak bulduğumuz düzeltmeleri arkadaşımıza bildirmemiz de 'iyi' bir teknik olarak bilinir.

Fakat normal projelerde bu teknik, genelde takım liderinin insiyatifi ile başlatılır, ve bir odaya doluşulur, yazıcıdan basılmış koda herkes bakar, ve fikirlerini söyler, sonra herkes odasına döner düzeltmeler yapılır.

Kent şöyle dedi: 'Bu iyi bir teknik ise, niye her zaman yapmıyoruz?'.

Sürekli kod kontrolu yapabilmenin en iyi yolu olarak, tek kişinin kod yazması yerine bir başkasının sonradan kontrolü yerine, iki kişinin aynı anda kodlama yapması, ve sürekli birbirlerini kontrol etmesi fikrine erişti.

Bu yaklaşım da yazılım projelerinde bir devrim oldu.

XP Planlaması

XP kullanmaya karar verdiniz, ve proje lideri, programcı olarak nasıl işleme koyacağızı düşünüyorsunuz. Nereden başlayacağım sorusu aklımıza geliyor. İlk önce, kavram olarak 'iş süresi' ve 'zaman' terimlerini yerlerine koyalım.

XP'ye göre, bir proje dönemlere ayrılır (iteration). Bu dönemin uzunluğu, bir kere kararlaştırıldıktan sonra sabittir, değişmez. Mesela, sizin takımınız için 2 haftalık döneme karar kıldınız, bu şekilde başlayabilirsiniz. Her takım için bu dönem süresi değişik olabilir. Bu tamamen takımınızın ritmine bağlıdır. Unutmayın, daha hızlı takımlar daha ufak dönem seçer diye bir şey yoktur. Sadece, proje hayatınızı ne kadar ufak parçalara bölmek istediğiniz önemlidir. XP takımlarından alınan istatistiklere göre, genelde iki ya da üç haftalık dönemlerin tercih edildiğini görüyoruz.

Eğer dönem süreniz 2 hafta ise, demek ki 3 aylık olarak görülen bir projenin içine 6 dönem sığacak demektir. Tabii proje eğer 3 ayda bitmemiş ise, yeni dönemler ekleriz. Hemen belirtelim: XP'de sabit zamanlı, sabit bitiş çizgili proje yoktur. Eğer bu tür bir ortamda çalışıyorsanız, arkanıza bakmadan kaçabilirsiniz. Bu satırların yazarı dahil birçok kişi sabit bitiş çizgili projelerde yeterince kan ve ter kaybetmiştir. Eğer böyle bir kültür içindeyseniz, kültürü XP ile değiştirmeye uğraşın. Amerika'da bu tür götürülen projelerin yarısı başarısız olmuş, başarılı olanlarında kod kalitesi şüpheli bir seviyede olmuştur. Neyse..XP'ye dönelim;

Dönem süresi karar kılındıkta sonra, müşteriyi temsil edecek birini seçin. Bu müşteri temsilcisi, projeye hangi özelliklerin ekleneceğini, hangi özelliğin ötekinden önce yazılacağına karar veren kimse olacak. Bu tür kararlar, yazılıma talip şirket (yani programcıların müşterisi) için stratejik türden kararlar olduğu için, bu şahsın şirketini ve iş alanını çok iyi bilmesi yararlı olur. Yazının geri kalan kısmında, bu tek kişiyi 'müşteri' betimleyeceğiz.

Planlama dahilinde, müşterinizin istediği özellikleri bir liste olarak dökmesini isteyin. Siz olarak hitap ettiğim, XP takımının teknik lideri olan sizsiniz. Müşteri bu listeyi en önemliden en önemsize doğru sıraya dizmelidir. Bu özellikleri ya bir Excel hesap tablosu, ya da her özelliği tek bir kart üzerine yazılmak suretle kartlar kümesi olarak tutabilirsiniz. Hattâ, şirket içi İntranet üzerinden kullanılabilen XPlanner gibi bir program da yararlı olabilir.

Kartlar hazır olduktan sonra, bir takım toplantısı tertip edin. Bu toplantıyı, her dönem başında yapmanız lazım. Toplantıya müşteriniz ve bütün programcılar katılacak. Toplantı başında kartları masaya dizin, (ya da Xplanner'dan ekrana getirin) ve kartları en önemliden en önemsize doğru tartışmaya başlayın.

Müşterinin yapması gereken, her kartı alıp, takıma okumaktır. Bu özellik hakkında detaylı bilgiler de verilebilir.

Özellik tanımı bittikten sonra, programcılar kartı geliştirme kalemlerine bölmeye başlarlar.

Özellik:

Kullanıcı, banka hesapları arasında para transferi yapmak istiyor.

Programcılar, geliştirme kalemlerine bölerken, müşteriden daha detaylı bilgi isteyebilirler. Bu iletişim çok iyidir. Ayrıca, programcılar kendi aralarında bu bölme işlemi olurken teknik konular hakkında tartışabilirler. Bu da yararlıdır. Sonuçta, mesela şu şekilde kalemler ortaya çıkabilir.

Özellik:

Kullanıcı, banka hesapları arasında para transferi yapmak istiyor.

Geliştirme kalemleri:

- Görsel arayüzü JSP/HTML ile kodla.
- Kullanıcı hesap nosuna kullanıcı kimlik nosu ile veri tabanından
eriş.
- Aynı işlem (transaction) altında bir hesaptan al, öteki hesaba yaz,
işlem bitir.

Bütün kartları bu şekilde işlemden geçirdikten sonra müşterinin katıldığı kısım bitebilir.

Toplantı bittikten sonra, müşterinin katılması gerekmeyen kısma geçebilirsiniz. Bu kısımda, kartları kimin kodlayacağına karar verilir. Her karta iki kişili takımlar talip olur ve kartlar sahiplerine verilir. Bu safhadan sonra, ikili takımlar kartlarının geliştirme kalemlerini ne kadar zamanda kodlayabileceklerine karar verirler. Mesela yukarıdaki örnek:

Özellik:

Kullanıcı, banka hesapları arasında para transferi yapmak istiyor.

Programcılar:

Ahmet, Veli

Geliştirme kalemleri:

- Görsel arayüzü JSP/HTML ile kodla. (Tahmin: 1 gün).
- Kullanıcı hesap nosuna kullanıcı kimlik nosu ile veri tabanından
eriş. (Tahmin: 0.5 gün)
- Aynı işlem (transaction) altında bir hesaptan al, öteki hesaba yaz,
işlem bitir. (Tahmin: 0.5 gün).

Talip olma konusunda bir noktayı vurgulamak gerekir. Takım lideri olarak kimseye bir özelliği 'vermeyin'. İkili takımların/kişilerin bir karta 'talip' olmasını bekleyin. Bu nokta çok önemlidir. Eğer birine bir kartı veriyorsanız, emir/komuta zinciri işletmiş oluyorsunuz. Eğer programcı kendisi talip oluyor ise, kendi insiyatifi ile bu işe kalkışmış oluyor. Bu aradaki fark, ufak bir ruhbilimsel fark olarak gözükse bile, etkisi büyüktür. 'Bu özelliği kim kodlamak istiyor' diye sorduktan sonra bir 'sessizlik' durumu olabilir. Bekleyin. Mutlaka talip olan ikili çıkacaktır.

Toplantıdan sonra, geliştirme kalemlerini birbirine toplayın. Sonuç olarak, bütün özelliklerin bir döneme sığmayacağını bulabilirsiniz. O zaman döneme sığmayacak kartları, bir sonraki döneme bırakmanız gerekir. Hangi kartın sonraki döneme bırakılacağını müşteriye sorun. Özellik sırası, iş dünyasına ait bir karardır, teknik bir karar değildir. XP bu konuda çok hassastır, unutmayalım. Müşteri teknik karar alamaz, programcılar da iş hayatını ilgilendiren kararlar alamazlar.

En son kart listesi elinizde olduktan sonra, takımınıza hangi özelliklerin kodlanacağını artık bildirebilirsiniz.

Bir Dönem Ne Kadar Büyüktür?

Sığmak, sığdırmak terimleri bağlamında bir noktayı vurgulamak gerekiyor. Bir dönemin ne kadar büyük olduğu nasıl bulunur? Yani kabımızın büyüklüğü nedir? İlk birkaç dönem için, takım lideri tahmin bir büyüklük ile başlayabilir.. Bir dönem (iteration) büyüklüğü olarak 2 hafta farzederek başlayalım. Takımımızda 5 programcımız var ise de, bu programcıların haftanın 5 çalışma günü içinde 3 ideal günlük iş yaptığını farzedelim; o zaman kap büyüklüğü 3 ideal gün x 5 programcı x 2 hafta = 30 ideal gün olacaktır. Yani kabımızın büyüklüğü 30 gündür.

Bu yapılan "tahminler", XP'nin gevşek bir yöntem olduğu intibası vermemelidir. Esasında, bir kere kap büyüklüğü hesaplandıktan sonra, hangi özellik sığdırma işlemi çok katı bir şekilde takip edilecektir.

Tahminlerin nasıl yapıldığına gelelim: İlk faraziye, 2 haftalık bir dönem koyulması, ikincisi ise programcının bir hafta içinde kaç ideal gün çalışabildiğidir. 2 haftalık dönemi seçerken, diğer XP projelerinin tecrübelerinden yararlanabilirsiniz. Projenizin ritmini ne kadar kısa aralıklarla böleceğinize karar verin. 1 hafta çok kısa olabilir, 4 hafta da çok uzun. Seçim size kalmış, ama dönem uzunluğunu birinden ötekine sürekli değiştirmeyin.

İkinci tahmin hakkında: Projede ilerledikçe ve her özelliğin 'gerçek zamanı'ölçüldükçe, dönemlerin içine sığacak ideal gün sayısını bulabilirsiniz. Böylece bir sonraki döneme özellik koyarken, önceki dönemin büyüklüğüne göre listeye almaya başlarız, vs.. Ve böylece projemiz ilerledikçe, takımınız tahmin yeteneği de ilerleyecek, bu tahmin/gerçek sayıları birbirine iyice yaklaşacaktır.

XP ve Özellikler

XP yönteminin tamamen özellik kontrollü (function oriented) bir sistem olduğu herhalde açık. Bu açıdan, proje başında 3-4 aylık tasarım yapan ve bir torba belge üreten yöntemlerden XP ayrılıyor. XP projelerinde, 'mimari bitti mi?', 'tasarım belgesi hazır mı?' soruları yerine, 'özellik bitti mi?' sorusunu duyarsınız. Zaten bir projede kullanıcı, o proje için mevkisini riske eden üst düzey yönetici için önemli olan da budur. Özellik.

Bu yüzden, özellik olarak kartların üzerine yazılan şeylerin, hakikaten özellik olması çok önemlidir. Bitme/bitmeme mefru 'özellik' olduğu için, eğer özellik olmayan bir şey kart üzerine yazılmış ise, kargaşa yaratacaktır. Mesela:

Özellik:

E-posta gönderecek bir Java yardımcı nesnesi yaz.

Programcılar:

Ahmet, Veli

Geliştirme kalemleri:

- Nesneyi yaz (Tahmin: 1 gün)


Bu yanlış bir özelliktir. Her şeyden önce, bu özelliğin müşteri tarafından konulduğu şüphelidir, zaten müşteri nesne filan bilmez. Büyük bir ihtimalle programcının 'lazım olur, koyalım' diyerek koyduğu bir 'özelliktir' bu.

Bu sözde özellik tipik bir mimari kodlamanın, özellik kartı olarak araya kaynaması durumudur. Özellikle vurgulamak gerekir ki, XP mimariyi sadece bir özelliğe gerek olduğu kadar yazar. Öyle her özelliğe lazım olacağını tahmin ettiğimiz bir 'mimari nesneyi' baştan, ve o mimariyi kullanacak özellik daha ortada bile olmadan kodlayamayız.

Yukarıdaki örnekte, ortak bir e-posta gönderen yardımcı 'kütüphane' kodu vardır, fakat bu kodu hangi özellik kullanacaktır? Nasıl kullacaktır? Ne kadar iyi tahmin yeteneğiniz olursa olsun, bir özelliğin bu yardımcı nesneyi gerçekten kullaması gerektiğinde, ilk arayüz tasarımınızda boşluklar bulacaksınız. Tabii ki siz çok tecrübeli programcısınız, tabii ki 8 programlama dili biliyorsunuz, fakat konumuz bu değildir.

Konumuz, niye gereksiz bir şey hakkında, efor sarfedeceğimizdir.

Ayrıca, üstteki gibi bir sözde özelliğin bitip bitmeme kriteri tanımsızdır. Zaten en iyi turnusol testi de budur. Müşteriniz bu şekilde bir özelliği test edemiyor ise, biliniz ki mimari bir işlem aradan kaynadı.

Daha iyi bir özellik şöyle olabilirdi.

Özellik:

Kullanıcı, banka transferi yaptıktan sonra ona e-posta gönderilir.

Programcılar:

Ahmet, Veli

Geliştirme kalemleri:

- JSP (görsel) kod içine e-posta tetikleyici kod yerleştir. (Tahmin: 0.5 gün)
- E-posta gönderecek nesneyi yaz (Tahmin: 1 gün)

XP İşletimi

Her ikili takım kendine ait kartlardaki geliştirme kalemlerini teker teker kodlamaya başlar. Her geliştirme kalemi bitince, bu kalemin 'gerçekte' ne kadar zaman aldığını ikili takım not etmelidir. Çünkü bu ölçü, baştaki tahminlerinizin ne kadar doğru olduğunu kontrol için önemli bir sayıdır. Takım lideri olarak siz, bu rakamın tahmine ne kadar uyup uymadığına takımınıza hiçbir sitem, alay, iğneleme yapmamalısınız. XP, programcıya tamamen 'güvenen' bir ortamda olmalıdır. Çıkış amacı ve temeli bunun üzerine kuruludur.

Gerçek zaman not edildikten sonra özellik, şöyle gözükebilir.

Özellik:

Kullanıcı, banka hesapları arasında para transferi yapmak istiyor.

Programcılar:

Ahmet, Veli

Geliştirme kalemleri:

- Görsel arayüzü JSP/HTML ile kodla. (Tahmin: 1 gün, Gerçek: 1 gün)
- Kullanıcı hesap nosuna kullanıcı kimlik nosu ile veri tabanından
eriş. (Tahmin: 0.5 gün, Gerçek: 1 gün)
- Aynı işlem (transaction) altında bir hesaptan al, öteki hesaba yaz,
işlem bitir. (Tahmin: 0.5 gün, Gerçek: 0.5 gün)

Her kartın kodlaması bittikten sonra, ikili takım müşteriye giderek özelliği 'kabul testinden' geçirmesini ister (acceptance test). Kabul testi, şöyle olabilir.

Özellik:

Kullanıcı, banka hesapları arasında para transferi yapmak istiyor.

--Kabul Testleri--

Test 1:

- Sisteme şifre ile gir.
- Transferi başlatacağı hesabı seç. Hesapta 2,000 olduğunu kontrol et.
- Transferin yapılacağı hedef hesap nosunu seç.
- Hesap miktarı 1,000 TL gir.
- Mevcut para miktarı 1,000'e düştü mü?
- Evet ise, test geçti

Test 2:

- Sisteme şifre ile gir.
- Transferi başlatacağı hesabı seç. Hesapta 2,000 olduğunu kontrol et.
- Transferin yapılacağı hedef hesap nosunu seç.
- Hesap miktarı 3,000 TL gir.
- Hata mesajı geldi mi? (çünkü mevcut hesap miktari 2,000 idi)

..
..
..

Bu kabul testi ideal olarak, planlama toplantısından önce hazırlanırsa iyi olur. Çünkü bu şekilde hazır olan bir kabul testi, o özelliği tarif eden 'en iyi' şekildir. Çok katı bir şartlar oluşturduğu için, programcılar için özellik kodlamasının ne zaman bitmiş olduğunu anlamak bakımından, kabul testleri onlara yararlı olacaktır.

Fakat kabul testi yok ise, müşteri özelliği aklında kaldığı kadarı ile testten geçirecektir.

Kabul testleri için güzel bir yöntem, birim testler gibi, otomatik şekilde çalıştırılabilen kabul testleri olabilir. Java Swing için yazılmış olan bir kabul test altyapısını sitemizden paylaşmıştık. Swing tıklayıcı alyapısı, XML ile tanımlanan kabul testlerini, otomatik şekilde tıklayarak sonuçlari e-posta ile bildirebiliyordu.

Bu şekilde bir sistem başta çok zahmetli ise, metin şeklinde yazılı testler yeterli olacaktır.

Müşteri özelliği kabul ettikten sonra, kart biten kartlar kefesine konur, ikili takım dağılır ve başka bir ikili takım altında başka bir kartı kodlamaya başlarlar.

Birim Testleri

Kabul testleri özellik seviyesinde olan şeyler ise, birim testleri nesne (kod) seviyesindeki testlerdir diyebiliriz. Birim testler, banka hesabından 1,000 TL düşülüp düşülmediğini kontrol eden bir kod parçası olabilir. Banka nesnesi üzerinde hesaptanDüş() işlevini test eden, birim testidir.

Fakat yukarıdaki 'kabul testinde aynı şekilde bir test görmüştük. Demek ki bazı durumlarda, kabul testleri ile birim testleri arasındaki çizgi bulanıklaşabiliyor. Yani, eğer elimizde 10-15 diğer işlevi çağıran bir işlem mevcut ise, ve bu işlevi birim test ile çağıriyor isek, bu test birim testinden ziyade bir kabul testine benzemeye başlayabilir. Bu gibi şartlarda hangi testi kullanacağınız size kalmış. Fakat prensip olarak birim testlerini tek bir işlem ve ufak bir ölçüde yapmaya gayret edin.

XP ve İdeal Gün

XP projelerinde, en çok karışıklık yaratan kavramlardan biri budur. "Kartımızı (özelliği) kodladıktan sonra, gerçekte harcadığımız zamanı yazmamız isteniyor. Ben bu karta 2 gün önce başladım, demek ki 2 gündür kodluyorum. Karta, gerçek zaman: 2 gün yazabilir miyim?"

Hayır. XP, tahminler ve gerçek süreler konurken herşeyin 'ideal gün' olarak hesaplanmasını ister. Ideal gün denilen şey, dikkatinizi dağıtacak hiçbir şey olmasa, ve kodlamanızı yarıda kesecek durumlar olmasa, geçireceğiniz hayali bir gün birimidir.

Bir gün içinde sürekli bir takım etkinlikler/oylarlar vuku bulmaktadır. Mesela arkadaşımız ile konuşmakta, veya bir toplantıya katılmak gibi önemli bir şey ile uğraşmaktayız. Fakat XP burada çizgiyi çizerek diyor ki, "bu işlemlerin hiçbiri kodlamanın kendisi olmadığı için, ideal gün altında sayılmazlar. Bütün ölçümler, ideal gün ile yapılmalıdır".

Tahminlerin ve gerçek sayıların ideal gün olarak ölçülmesinin önemi, tahmin sayıları toplandıktan sonra, yönetim merci (müşteri ve teknik lider) kartlarını döneme paylaştırıken ortaya çıkar. Bu sırada şöyle konuşmalar olabilir.

"Geçen dönemde 20 (ideal) günlük kart kodlamışız. Demek ki, 5 programcı x 5 iş günü = 25 normal gün içinde 20 ideal günlük iş yapılabiliyor. Bu yüzden, bir dahaki döneme 25 günlük değil, 20 günlük iş koyuyoruz.

Ya da, şöyle bir sonuca varılabilir: "25 normal günlük dönem içinde, 10 ideal gün kodlama yapmışız. Bu oran biraz az mı? Acaba derleyiciler, bilgisayarlar mı yavaş? Acaba takıma programcı eklemek, hızımızı arttıracağı yerde, azalttı mı?", vs..

Veri Madenciliği

Videoya Donusen Resim

DYNSRC tag'ini daha önce duymus muydunuz? Bu takiyi kullanarak asli görevi resim olmak olan bir görüntüyü üzerine gidildiginde veya yüklendikten hemen sonra görülen bir videoya çevirebilirsiniz.

<IMG... komutuyla kullanilan ve sadece Internet Explorer Web tarayicisinda çalisan bu özellik videolari oynatmanin güzel bir yoludur. Sadece Internet Explorer'in bir özelligi oldugundan <EMBED SRC..> komutu kadar ragbet görmeyen bu komut kullaniciyi videonun yüklenmesini beklerken oyalamakta kullanilabilir. Küçük AVI dosyalari kullanarak resmin üzerine gidildiginde kullaniciyi etkilemek yine bu yolla çok kolaydir.

Komutun kullanimi söyledir: <IMG SRC="DENEME.GIF" DYNSRC="DENEME.AVI" START= FILEOPEN| MOUSEOVER>

FILEOPEN Video yüklenen kadar resmi görüntüler, sonra video'yu oynatir. Varsayilan deger budur. MOUSEOVER Kullanici farenin imlecini resim üzerine götürdügünde video'yu baslatir.

Yazarin izni ile http://draskin.150m.com sitesinden alinmistir

Varsayilan Hedef

Frame'lerden olusan nefis bir sayfa yaptiniz ve sol taraftaki frame'i navigasyon için sag taraftaki frame'i ise içerigi görüntülemek için kullaniyorsunuz. Daha önce <A HREF=.. komutuna target="hedef" gibi bir ek vererek ilgili sayfanin hangi frame'de açilacagini tayin edebileceginizi söylemistik. Eger sol taraftaki frame'inizde çok fazla <A HREF=.. takisi varsa <BASE TARGET.. komutunu kullanmayi düsünebilirsiniz.

<base target="sagtaraf"> <a suraya="sayfa1.htm">Hakkimda</a> <a suraya="sayfa1.htm">Resimlerim</a> <a suraya="sayfa1.htm">Faydali</a>

Yukaridaki gibi kodlar kullandiginizda bu kodlari koydugunuz sayfadaki her bir link sag taraftaki frame sayfasinda açilacaktir.

Yazarin izni ile http://draskin.150m.com sitesinden alinmistir

Üst Simage Ve Altsimge

Web sayfanizda içinde özel bir karakter bulunmayan matematiksel bir fonksiyon kullanmak istiyorsunuz diyelim. Ya da özel bir marka kullaniyor ve TM (c) ifadelerini bu özel markanin sag üst kösesine yerlestirmek istiyorsunuz. HTML dili tüm web tarayicilarinin destekledigi bu islemi gerçeklestirmeniz için size iki adet özel taki sunuyor.

Ingilizce uzatmalari Superscript ve SubScript olan bu iki takiyi kullanarak özel metinlerin, normal metnin yari uzunlugu kadar asagisinda veya yukarisinda olmasini saglayabilirsiniz. Bir metni normal metnin üstüne almak için <SUP> ifadesi ile baslamali metnin bitiminde ise </SUP> ifadesini kullanmalisiniz. Ayni sekilde metnin asagida yaralamasini istiyorsaniz <SUB> takisini kullanin.

YAZININ<SUB>Altinda</SUB> YAZININ<SUP>�stünde</SUP>

Yazarin izni ile http://draskin.150m.com sitesinden alinmistir