Her yazilim gelistirme metodu temelinde kullanilabilir, hatasiz ve müsteri gereksinimlerini tam olarak karsilayan bir ürün üretebilmek için ortaya çikmistir. Bir bakima dinler gibi hepsi temelinde iyiye ve dogruya yöneltmeye çalisir insanlari ve bu yolda uygulanmasi gereken bir dizi kuraldan bahseder.
Yazilim gelistirme metodlarinda sonradan eklenen çesitli yöntemler ile metod artik takip edilmesi ve ögrenmesi zorlasmis bir hal alir ki bu da projelerin uzamasina ve onaylama mekanizmalarinin çok zaman almasina neden olur.
Neyseki din degistirmek kadar kati olmadigi için kullanilan metodu degistirebilir veya farkli metodlarin çesitli kisimlarini bir araya toplayarak yeni bir olgu yaratabiliriz.
Yapisi oturmus bir firmada metod degistirmek zor olacaktir. Ve heleki yasi ilerlemis ve firmada masa, sandalye gibi demirbas listesine girmis elemanlar varsa isiniz daha da zor. Kendi istedikleri olsun da patrona “en çok ben biliyorum” gibi gözükeyim konusundan baska dertleri yoktur bunlarin. Birde tabii adamin dinini degistirmek istiyorsunuz bir bakima. Yillardir takip ettigi ve yazilim gelistirdigi metodu degistiriyormus gibi gelecektir ona. Aslinda farkina varsa sadece ufak eklentiler oldugunun, her sey daha kolay olacak.
Birden bire yazilim gelistirme metodunu degistirmek istediginizde direnislerle karsilasabilirsiniz. Bunun için ufak paketler halinde degisiklikleri sunmali ve ise yaradiginin ispatini diger çalisanlara kanitlamalisiniz.
Eski metodun bir kismini “tamami ile degistirmek” yerine (yada en azindan bu cümleyi kullanmak yerine) “degisiklikler ile güncellemek” daha iyi bir yöntem olacaktir. Yapilan isin ismini ayni birakin fakat isleyisini degistirin. Getirmeye çalistiginiz metodun ismini ise kesinlikle kullanmayin. “Ben burada Extreme Programming metodunu uygulayacagim artik” derseniz bastan kaybedersiniz. Bunun yerine sebep sonuç yasasini kullanin. Eger sebepler metodu degistirmeniz için bir sinyal veriyorsa, isleyisi degistirip sonuçlarinda yapilan kara bakin ve daha iyi bir metod oldugunu herkese kabul ettirin.
Extreme Programming ismi kulaga uzaydan düsme bir isim gibi gelsede içerik olarak uygulanan metodlarin günümüzde kullandigimiz metodlardan pek farki yok. Bir miktar da insanin kendi özverisi ile zaten uyguladigi seyler. Bu tip mevhumlari ögretemezsiniz zaten, insanin kisiliginden gelen seylerdir. Ama görsel olarak uygulayabileceginiz pek çok XP yöntemi mevcuttur.
Narsistlik yapip sadece kendini düsünen kisiler olacaktir. Onlara hak da veriyorum çünkü kendilerini satabilecekleri tek hünerlerini digerlerine ögretmesini istiyorsunuz. Kisinin aklina “acaba ilerde beni sutlayacaklar mi” sorusunu sokar ki bu kisi hiç çalismasa daha iyi olur. Verdigimiz seylerden daha çok aldigimiz seyler ile ilgilenip daha fazla nasil gelistirebilirim diye düsünmemiz lazim. Ilerleme ancak bu sekilde olur. Ama zor bir yoldur.
Neyse biz konumuza dönelim. Anlatacagim bir kaç XP metodunu ben deneyip gördüm ki gerçektende yazilim gelistirme asamasinda ise yariyor ve hizli bir biçimde sonuca ulastiriyor. Aslinda eski metod da hakkiyla uygulandiginda sonuca ulasilabilir fakat insanoglu yasayan bir organizma ve bir süre sonra rutin islerden sikilmaya basliyor, üstelik bir de yapilan is pek çok kontrol gerektiriyorsa ve “bunu yapmasak ta olur” gibilerinden suistimale açiksa hiç bir zaman hakkiyla uygulanmiyor. Bizim amacimiz yapilan isi basitlestirmek veya parçalara bölerek yapmak.
BENIM HIKAYEM
Bu bölümde benim basimdan geçen bir durumu aktaracagim. Uzun gelirse buradan sonrasini okumaniza gerek yok.
Ürün destek bölümüne ilk geçtigim zaman bir basibosluk sezinledim. Proje bitmis ve ben tek basima üründen sorumlu olarak tayin edilmistim. Bana yardimci olacak bir eleman verdiler fakat bu kisinin konu ile yakindan uzaktan alakasi yoktu. Birakin olayin isleyisini programciliktan anlamayan bir kisi idi.
Büyük problemin farkindaydim fakat proje müdürüm farkinda degildi ve bana verilen kisinin kisa zamanda benimle ayni seviyeye çikmasi bekleniyordu. Burada öncelikle kabul edilmesi gereken planlarin uzayacagidir. Proje müdürünü ve bana verilen arkadasi karsima alip bir toplanti yaptim. Ben her seyi aktarsam bile ürün destekte problemlere çözüm bulmak zaman alacaktir bu arkadas için, çünkü yeterli alt yapisi yok. Bunu kabul etmeleri 2 saat aldi fakat kabul ettiler. Insanoglu bazi tümsekleri görmezden gelir ya buda öyle birsey.
Benim esas problemim hem is akisini hemde programcilik konusunu bana verilen arkadasa nasil anlatmam gerektigi. Problemi parçalayip çözmek için programcilik konusunu egitimin disinda tutmaya karar verdim. Düsünecek olursaniz sizinle ayni seviyede çalisan birinin en az sizinki kadar bilgiye sahip olmasi gerekir. Bu yüzden arkadasa bazi kurslar tavsiye ettim, proje müdürü de onaylarsa kurslari ücretsiz alabilecek. Ben, sonuç olarak programcilik ögretmek için burada çalismiyorum.
MODEL DUVARI
Öncelikle tüm sistemin isleyis semasini büyük kagitlara çizerek duvara astim. Tüm kutulari isimlendirip anlattim. Tabii ilk anlatimda ancak %25 oraninda bir bilgi hafizada kalir. Daha fazlasi için tekrar gerekir. Semalari duvara asmam iyi oldu problem oldugunda hemen ilgili kutuyu gösterip anlatabiliyorum. Genel semalar disinda sinif yapisini ve veritabani yapisinida duvara astim. Böylece semalar arasinda baglanti kurarak anlatabiliyorum. Bir resmini çekip burada göstermek isterdim fakat yasa geregi göstermeyorum.
Burada kullandigim 3 çesit model tipi var. Birincisi sistemin isleyisi ile ilgili olan Is Nesneleri Modeli. Bu modelde hem bizim sistemin iç yapisi hemde diger sistemlerle olan baglantilari yer aliyor. Genel yapiyi kus bakisi görmek için ideal. Ikinci model Sinif Yapisi. Kendi sistemimiz içinde kullanilan tüm siniflar sahalari ve metodlari ile burada gösteriliyor. Üçüncü model ise Veritabani Modeli. Bunda da veritabaninin yapisi ve tablolar arasi iliskiler ile hangi “stored procedure” hangi tabloya erisiyor gibi bilgiler var.
SIK SÜRÜMLER VEREBILMEK
Ikinci olarak tüm projeyi derledim. Daha önceki sürümlerde sadece degisen kismi paketleyip kullanicilara göndermisler. Fakat tüm projenin derlenebiliyor olmasi gerekir. Visual Source Safe erisimlerini kapatip tüm projeleri indirdim ve derleme yaptim. Derleme sirasinda hatali modüller ve eksik modüller ortaya çikti bunlari temizlemek iki gün aldi. Daha önce NT4 üzerinde derlenmis ve MTS nesneleri eski idi, tüm bunlari yeni COM+ karsiliklari ile degistirmem gerekti. Tüm projeleri derledikten sonra test ekibinden test etmelerini istedim, bu arada bulduklari hatalarida düzelttim. Sonuç olarak eskisinden daha hizli çalisan ve tamami derlenebilen bir ürüne sahip olduk. Artik küçük sürümler halinde projeyi derleyebiliyorum ve her ay yeni bir sürüm kullanicilara gönderebilirim.
VSS ORGANIZASYONU
VSS organizasyonu çok kötü yapilmisti. 45 adet ufak projeden meydana gelen bir istemci uygulamasi, 18 COM+ uygulamasi ve 4 adet sürekli çalisan daemon uygulamasi var. Fakat derleme sirasinda hangi dll’in hangi projede kullanildigini anlatan bir belge bulamadim. 45 projenin her birini tek tek VB ile açarak References kismindan hangi dll veya ocx’lere erisim yapildigini yazdim. Daha sonra her projeyi numaralandirarak bir derleme sirasi olusturdum. Örnegin:
01-ErrorLog
02-DbAccess
03-BRCheck
Bu sirada derleme yapildiginda proje sifirdan derlenebiliyor. VSS’de de proje isimlerini degistirdim. Böylece her bakan bu siranin ne oldugunu tahmin edebilir.
Ilk basta var olan Development, Test, Production gibi VSS dizinlerinide teke indirip hepsini bir dizin altinda topladim. Anlamiyorum neden böyle bir yola basvuruyorlar. VSS zaten eski sürümleri tutuyor birde 3 farkli dizin açip her seyi tekrar ediyorsun. Tamami ile gereksiz bana göre. Etiketleme diye bir sey var. Eski sürümden bir dosya istiyorsan “History” kismindan indirebilirsin.
VSS için yaptigim diger bir olay ise Shadow dizinleri. Shadow dizinlerini kullanarak en son sürümün sabit disk üzerinde bir dizine toplanmasini saglayabilirsiniz. Bunun için srcsafe.ini dosyasina asagidaki satirlari eklemek gerekiyor. Admin aracindan da yapilabilir Tools-Options menüsünden Shadow Folder sekmesine gideceksiniz. Köseli parantez içindeki kisim kopyasini almak istediginiz VSS dizini. Benim 1-Builds olarak adlandirdigim dizin 45 ufak projenin exe’lerinin “Share” edildigi dizin. Bir projenin exe dosyasini sag klik ile tasiyip baska bir dizin üzerine biraktiginizda bir menü göreceksiniz. Burada “Share” seçerseniz, o dosyanin bir kopyasi bu dizinde de var olacaktir ve siz projeyi üzerinde degisiklik yapip VSS’e geri yolladiginizda bu “Share” edilmis dosya her iki dizinde de güncellenecektir. NAnt gibi bir lüksümüz olmadigi için bu yolla projenin exe, dll, ocx gibi çiktilarini bir dizinde bu sekilde toplayip daha sonra “Shadow” yöntemi ile VSS disinda normal bir dizine atabiliriz.
[$/1-Builds]
Shadow = \\Yoda\Builds
Shadow_SetTime = Current
Shadow_SetTime için 3 adet deger var. bunlar Current, Mod ve Update. Ne zaman projeyi VSS’e geri yollarsaniz bu “Shadow” dizinindeki ilgili dosya da güncellenecektir.
Tahmin edeceginiz gibi veritabani da VSS’de mevcut degildi. Tüm veritabanini script olarak alip VSS içine yerlestirdim ve her güncelleme için ayri bir script dizini yarattim. Böylece veritabaninda yapilan degisiklikleri takip etmek kolaylasti. Ayrica programin çalisabilmesi için gereken konfigürasyon verisi için de scriptler hazirlayip bu dizinde tutuyorum.
VSS ile isim bittiginde artik güvenilir bir kod kontrol sistemimiz oldugunu söyleyebilirdim.
ISTEK ve HATALARIN YÖNETIMI
Program için gereken degisiklik ve istekleri takip edecek bir access uygulamasi gelistirerek herkesin kullanmasini sagladim. Bu sayede kullanicilarin ne gibi problemleri oluyor veya istedikleri degisiklikler var mi kontrol edebildik. Gelen istekleri parçalara ayirarak sik sürümler içinde halletmeye çalistik. Kullanici isteklerinin hizli yapildigini görünce daha fazla degisiklikler istedi bunnlarida projelendirip yaptik. Hem kullanici kendini proje ekibinin bir parçasi olarak hissetti hemde bizim firma içindeki yerimiz saglamlasti.
Istek ve Hatalarin isleyisindeki bazi bürokrasileri ortadan kaldirdim. Bir degisiklik için 15 ayri yerden onay almak gerekiyordu. Alinacak onaylari 5’e indirip degisikligin merkezi olarak takip edilmesini saglayinca hem degisiklikler çabuk uygulandi hemde sirtinda imza atma yükü bulunan kisiler rahatladi. Imza atmak büyük sorumluluk istiyor, eger birde attiginiz imzanin ne için oldugunu bilmiyorsaniz daha da zor. Onay almak için geçen zaman uzuyor.
BELGELEME
Ilk projeyi devraldigimizda belgeleme açisindan çok fazla eksik vardi. Bu eksikligi gidermek için bir UML Case Tool ile tüm projeleri modelledim. Girdi/Çikti ve parametrelerine varincaya kadar tüm fonksiyonlari semalar halinde çizdim. Daha sonrada her fonksiyon için bir açiklama yazdim. Genel modüller içinde genis açiklamalar yazdim. Bir kere Case Tool ile bu isi yapinca, gerekli belgeleri kolayca rapor halinde yaratabiliyorsun. Ayrica tüm modelleri html sayfalari halinde yayinlayarak herkesin görmesini sagladim. Is analistleri modelleri inceleyip yorumda bulunabiliyordu.
Kod içine yerlestirdigim yorum satirlari ile daha iyi okunabilir hale gelmesini sagladim. Ayrica her public fonksiyon için “Tools/Procedure Attributes” menüsünden bir açiklama girdim. Bu dll kütüphanelerinin baska projelerde kullanilmasi halinde yardimci oluyor. Object Browser ile bir dll içindeki fonksiyonlari görüntülediginizde fonksiyonlarin açiklamalari da geliyor baska bir dökümana ihtiyaciniz kalmiyor.
XP VE BENIM YAPTIKLARIM
XP presiplerini benim yaptiklarimla karsilastirdigimizda nasil örtüsdügüne bir bakalim.
Iletisim – Proje içi iletisim ve kullanicilarla olan iletisim %70 oraninda artti.
Basitlik – Onaylama mekanizmasini basite indirgeyerek geçen süreyi %300 oraninda kisalttim. Ayrica VSS üzerindeki çalismam derleme islerinin çok kisa zamanda yapilmasina neden oldu
Geri Besleme – Kullanicilarinin kendini ifade edebilecekleri bir ortam hazirlayarak, istek ve hatalarin bize dogrudan gelmesini sagladim.
Cesaret – Tüm kodun yeniden derlenmesi ve VSS’in yapisinin degistirilmesi konusunda büyük risk aldim fakat degdi.
Agir Baslilik – Tüm bunlari yaparken insanlari bilgisizliklerinden dolayi asagilamak yada suçlamak gibi terbiyesiz girisimlerde bulunmadim.
Eger sifirdan baslamis bir proje olsa idi yapilacak çok sey vardi fakat bu proje zaten sonlanmis bir proje, yapilacaklarda kisitli oluyor. XP’nin sadece bir kismini uygulamak bile pek çok isin hizli ve tam anlamiyla yapilmasina yetti.
