TDD (Test Driven Development) ile ilgili güzel bir makale

Cihat Altuntas sitesini begenerek takip ettigim yazilimcilardan biri.
Özellikle refactoring ve TDD ile ilgili örneklerle pekistirdigi güzel makaleleri var. Bunlardan bir tanesini sizin ile paylasmak istedim. TDD nin örnek bir uygulama ile güzel bir sekilde anlatildigi bir makale. Asagidaki linkden makaleye ulasabilirsiniz.

Test Driven Development

Oracle - PL-SQL ile Dosya Boyutunu bulma

CREATE OR REPLACE FUNCTION flength (
location_in IN VARCHAR2,
file_in IN VARCHAR2
)
RETURN PLS_INTEGER

IS
TYPE fgetattr_t IS RECORD (
fexists BOOLEAN,
file_length PLS_INTEGER,
block_size PLS_INTEGER
);

fgetattr_rec fgetattr_t;
BEGIN
UTL_FILE.fgetattr (
location => location_in,
filename => file_in,
fexists => fgetattr_rec.fexists,

file_length => fgetattr_rec.file_length,
block_size => fgetattr_rec.block_size
);
RETURN fgetattr_rec.file_length;
END flength;
/

SQL Server - T-Sql ile Dosya boyutunu bulma

CREATE FUNCTION udf_GetFileSize (@filename varchar(1000))
returns bigint
as
BEGIN
DECLARE @FS int
DECLARE @OLEResult int
DECLARE @FileID int
DECLARE @Size bigint
DECLARE @Flag bigint

Set @size =0
Set @Flag =0

EXECUTE @OLEResult = sp_OACreate 'Scripting.FileSystemObject', @FS OUT
EXECUTE @OLEResult = sp_OAMethod @FS, 'GetFile', @FileID OUT,@filename

IF @OLEResult <> 0
begin
set @Flag =-1
end
else
begin
EXECUTE @OLEResult = sp_OAGetProperty @FileId,'Size', @Size OUT
IF @OLEResult <> 0
begin
set @Flag =-2
end
end

EXECUTE @OLEResult = sp_OADestroy @FileID
EXECUTE @OLEResult = sp_OADestroy @FS

if @flag <> -1 and @flag <> -2
begin
set @flag = @size
end
return @flag
END

'Kullanimi
select dbo.udf_GetFileSize ('c:\temp\test.txt')

12 Agile Principles

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Proje başlangıcından hemen bir kaç hafta sonra sadece bir kısmı çalışan proje yayınlanır ve her bir modül bittikçe proje yayına geçriilir.Bir kaç haftalık periyodlarla bu düzenleme gerçekleştir,ta ki müşteri kendi en temel ihtiyaçlarını karşılayana kadar.Bundan itibaren,müşteri projeyi kullanmaya başlar.Burada önemli olan nokta bizim belirlediğimiz periyodlarla(bu 2 veya 3 hafta olabilir) projenin çalışan kısmını müşteriye sunmak, yayına sokmaktır.Böylelikle müşteriden sürekli geri dönüşüm alınacağından dolayı,projede hata olasılığı azaltılacak,müşteriyle yazılımcı arasında kuvvetli bir bağ kurulacaktır. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Bir yazılım ekibi yazılım gereksinimlerinin değişmesine açık olmalıdır.Öyle bir sistem kurmalıdır ki, gerçekleştirilen bir gereksinim değiştiğinde projedeki düzeltilen yerler çok az olmalıdır.Yani proje genişleyebilir ve değiştirilebilir olmalıdır. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale. Çalışan proje belli aralıklarla müşteriye teslim edilmelidir.Bu süre bir kaç hafta veya ay olabilir.Müşteriye çok büyük bir proje verilmemelidir.Bunun yerine ufak ufak ama zamanla kapsamı genişlemiş parçalar teslim edilmelidir. Businesspeople and developers must work together daily throughout the project. Projeyi talep eden,Projeye maddi yatırım yapan firma,sponsorlar,proje yöneticisi,takım lideri ve yazılımcılar birbirleriyle çok sıkı ilişki içerisinde olmalı ve belli ve kısa aralıklarla görüşmeler yapmalıdırlar.Bir yazılım projesi için şu yanlış bir yöntemdir;Müşteri projeyi yazılımcılara devreder ve yazılımcılar proje bitiminde müşteriye yapılanları gösterir.Bu kesinlikle yanlış bir yöntemdir,onun yerine Agile takımlar,müşteri ve diğer kişilerle proje süresince sıkı sıkıya ilişki içerisinde olmalıdırlar. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Bir projede en önemli faktör insandır yani yazılım mühendisidir.Metodlar,tasarımlar,mekan vs. gibi etkenler çok önemli olsa da yazılım mühendisi bunların içinde en fazla öneme sahip olandır.O yüzden yazılımcıların motivasyonları kaybedilmemelidir. Ücretleri düzenli verilmeli,kafalarını meşgul eden durumlar ortadan kaldırılmalı ve yazılımcıya kesinlikle güvenilmelidir.Yazılımcıya rahat bir şekilde çalışacağı ortam sağlanmalıdır.Kısacası yazılım mühendisinin,yazılımı düşünmesini etkileyecek etkenler ortadan kaldırılmalıdır. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Bir projede emeği geçen bütün kişiler(Yazılım mühendisleri,proje yönetcileri,müşteriler vs.) sık sık yüzyüze görüşmelidirler.Böylelikle insanlar birbirlerini daha iyi anlamış ve ortaya az hatalı ürünler koyulmuş olur.Dökümantasyon ve yazılı iletişim sadece sadece ihtiyaç duyulduğunda yapılmalıdır.Aksi durumda herşey yüzyüze görüşülmelidir. Working software is the primary measure of progress. En önemli unsur yazılımın çalışan kısmıdır.Bir projede yazılım alt yapısı çok iyi kurulmuş olabilir,dökümantasyon çok iyi yapılmış,en önemli kodlar türlü zorluklarla yapılmış olabilir.Her ne kadar bunlar önemli olsada birinci öncelik müşterinin ihtiyaçlarını karşılan,çalışan proje kısmıdır.Bir projede ihtiyaçların %30'u karşılandı ise projenin %30'u bitmiş demektir. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Bir yazılım ekibi kısa mesafe koşucusu gibi bir süre hızlı bir şekilde koşup daha sonra tükenmez.Onun yerine uzun mesafe koşucuları gibi,sürekli sabit hızla gidebilecek kadar hızlı giderler.Hızlı gidip de yorgun düşecekler ise,bu durumda hızlı gitmezler.Hızlı gerçekleştirilen projelerin sonu hiç de iyi olmamaktadır,ilk anda her ne kadar çalışan parçalar elde ediliyor olsada,zaman içerisinde yapılan şeyin aslında ne kadar yanlış olduğu anlaşılmaktadır.Bir yazılım mühendisinin bir sonraki gün ki enerjisi bugünden kesnlikle ama kesinlikle çalınmamalı,yazılım mühendisine bir anda çok yük bindirip,100 metre koşucusu gibi koşması beklenmemelidir. Continuous attention to technical excellence and good design enhances agility. Bir yazılım takımı yaptığı yazılımlarda maksimum kaliteyi hedefler.Bunu gerçekleştirmek için teknik anlamda en iyi ve en güzel mimariyi kullanır.Yalnız bunu yaparkende yazılımın karmakarışık olmasına izin vermez.Yapılan yazılımda önemli olan onun açık(kolay anlaşılır) ve sağlam olmasıdır. Simplicitythe art of maximizing the amount of work not doneis essential. Yazılım takımı yazılımı gerçekleştiriken bugünün gereksinimlerine odaklanır ve bugünün problemlerini en basit ve en tutarlı,en kaliteli ve en değiştirilebilir bir biçimde gerçekleştirir.Bugünün işini yaparken yarını düşünerek yapmaz.Yaptığı yazılımlarda kaliteyi en üst düzeyde tuttuğu için yarın karşılacak bir gereksinim sisteme sorunsuz bir biçimde dahil edilebilinecektir(entegre edilebilecektir). The best architectures, requirements, and designs emerge from self-organizing teams. Yazılım ekibi bütün sorumluluklarda ortaktırlar.Yani bir kişi test işinde görevlendirilip,biri veri tabanı işinde görevlendirilip,biri de arayüz tasarlamada görevdirilmez.Bu yanlış bir tutumdur.Takım içiçe olmalı ve herkes her adımda bulunmalıdır.Bazı takım üyelerinin özellikleri bir iş konusunda daha yeterli ise bu durumda belki o kişiye ilgili konuda daha fazla görev verilebilir ama muhakkak diğer takım elemanları da o işe dahil edilirler.Böylelikle bütün problemler yazılım takımının bir elemanı tarafından değil,tamamı tarafından çözülmüş olur. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Yazılım ekibi belli aralıklarla toplantılar yaparak, kaliteyi geliştirmek adına yöntemlerinde,durumlarında bazı değişiklikler yapabilirler.Zira yazılım ekibinin ortamı(yazılım ortamı,fiziksel ortamı,yazılımda gerçekleştirilecek bölümler) değişeceğinden,yazılım ekibide bu değişime ayak uydurmalıdır.O yüzden takımın davranışları,rolleri, poziyonları, görevleri belli aralıklarla yapılan görüşmelerde yeniden gözden geçirilmelidir. Kaynak: Nurettin Şimşek msegitim.net