Tag Archives: Kitaplar

Değişim Açlığı , IBM Yazılım Zirvesi 2008

Bugün IBM 2008 Yazılım zirvesindeydim. Aslında bu tarz zirveler genelde ürün tanıtımı ve şov olarak geçtiği için pek hoşlanmam. Fakat bu zirvede ilgimi birşey çekti o da zirvenin ana sloganıydı.Slogan Değişim Açlığı olarak belirlenmiş. İlk açılış konuşmasında da slaytlarda yazılım sektöründeki gidişatı göstermiş ve de değişime adapte olabilmenin artık bir seçenek değil zorunluluk olacağına değinilmiş. Geleceğin firmasının değişimi bir fırsat olarak görüp daha iyi işler çıkarıp müşteriyi daha memnun etmek için kullanması gerektiğini söylemiş.

Dikkatimi çeken başka bir konu ise açılış konuşmasında grafiklerde ve konuşmada “Ne kadar iyi teknolojiye sahip olursanız olun, bu teknolojisi kullanarak iyi işler ortaya çıkaracak olan insanlardır” kavramının yer almasıydı. Ve nitelikli ve istekli bireylere ihtiyacın gittikçe artan bir grafiğe sahip olduğunu şekiller ile gösteriyordu. Birçok tanıtımda da takım ve insan faktörünün projelerde ne kadar önemli olduğundan bahsedildi.Biz önceden beri diyoruz ama sakalımız yokki dinletelim :)

Bu kadar çok değişim ve insan faktörü üzerinde durulması beni neden ilgilendirdi ondan bahsedeyim. Öncelikle daha önce okuduğum Extreme Programming Explained: Embrace Change kitabı gözümün önüne geldi diyebilirim. Sizinde okumanızı öneririm Extreme Programming’in kurucularından Kent Beck oldukça güzel anlatmış. Kitabın başlığıda gördüğünüz gibi Değişimi Benimsemek  olarak konulmuş. Ayrıca Agile yöntemlerin temel felsefesi olan Individuals and interactions over processes and tools yani araçlar ve süreçler yerine bireyler ve iletişimin aslında konferansın ana konularından biri olmasıydı. Aslında IBM zirvesindeki temel konu Extreme Programming ve Agile yöntemler ile oldukça yakından alakalı. Çünkü Agile yöntemlerin temelinde kitabın başlığından da anlayabileceğiniz gibi değişimi benimsemek, ondan korkarak ya da kaçarak değilde onu müşteriyi daha memnun etmek için kullanılan bir araç olarak görmesi, efektif motive olan takımlardan oluşması ve projeyi asıl başarılı kılan faktörün bu olduğu var. Bu bakımdan IBM gibi genelde RUP tarzı ağır yazılım süreçlerinin daha ağır bastığı bir firmanın bu sloganı benimsemesi hoşuma gitti.

Konuşmanın diğer kısımlarında da IBM Jazz adlı ürününü tanıttı. Tabi konunun başlığından da gördüğünüz gibi şaşırmamak gerekli. Jazz ürün ailesi ile Agile yöntemlere uygun yazılım geliştirmenin nasıl kolaylaşacağından oldukça bahsedildi. Sonuçta zirveden benim çıkardığım artık Agile yöntemlerin gittikçe kabul gördüğü ve faydalarının ortaya çıktığı, IBM gibi büyük firmalar tarafından da kabul edilmiş durumda. Bu bakımdan Agile felsese belirli araçları kullanmak olmamasına rağmen en azından Türkiye’de firmaların “IBM gibi biri bunu tanıtıyorsa buna yatırım yapıyorsa bundan bir hikmet vardır” demesine vesile olabilir. Bu bakımdan sektörün Türkiye’de artık yavaş yavaş Agile tarzı yöntemler ile kaliteyi ve müşteri memnuniyetini arttırmasını ümit ediyorum.

Beklenen Kitaplar

Ayın 8″inden beri beklediğim kitaplar bugün eve ulaşmış.Evet gelip kitapları görünce sanki bayramlık hediye almışlar gibi mutlu oldum :) . Amazon.co.uk den sipariş etmiştim tahmin edilen teslim tarihi wilhoutsslot olarak dünü gösteriyordu dünde gelmeyince herhalde dedim 3 dolar yüzünden gümrükte takıldı o yüzden mutluluğuma hak verirsiniz umarım. Evet cicilerim nasıl sizde bakın :)

 kitaplar

Özellikle Clean Code ve uzun süredir yakından takip ettiğim Domain Driven Design kitabını okumayı sabırsızlıkla bekliyorum.

Ship It:Bölüm 3

Pratik Proje Teknikleri

Bu bölümün ilk girişinde neden bazı projelerin kaliteli,başarılı olupda erken bittiğini ama bazı projelerin kalitesiz başarısız ya da geç kaldığını sorarak başlıyor.Bunu sebebini iletişim ve işbirliği olduğunundan bahsediyor.Benimde düşündüğüm şeyleri burada da tekrarlamış kitap. Tutkulu hevesli, işbirliği halinde iyi iletişim kuran bir takım projenin başarısı için en önemli faktörlerdendir. Takım olabilmek içinde tabiki en önemli faktörlerden biri iyi iletişim ve işbirliği içinde olmak . Bu noktada kitapta aşağıdaki gibi vurucu bir söz yazılmış.

Though good collaboration doesn’t guarantee a project’s success, poor collaboration almost always guarantees a project’s failure.

Evet söz çok hoşuma gitti.İyi işbirliği,iletişim projenin başarılı olacağını garanti etmez fakat kötü iletişişim,işbirliği her zaman projenin başarız olacağını garanti eder.Bu bölümde aşağıdaki gibi takım olarak işbirliğini arttıracak teknikler üzerinde duruluyor.

Yapılacaklar Listesinden Çalışın

Bu bölümde aslında uzunca yapılacaklar listesinden(to-do list) bahsediliyor.Yapılacaklar listesini proje olarak kişisel olarak tutmanın genel gidişatı yolunda tutmak için önemli olduğunu söylüyor. Kendim kişisel olarakda sürekli yapılacaklar listesi tutuyorum. Hatta şuanda çok sevdiğim rememberthemilk sitesini tavsiye edebilirim. Web üzerinde oldukça pratik yapılacaklar listeleri oluşturup,bunlara öncelik atayıp yayınlayabiliyorsunuz. Tabi bunu illa bir yazılım yoluyla yapmak zorunda değilsiniz. En güzel kayıt aracı hala bence defter kalem ikilisi. Mesela daha önceki çalıştığım firmada bunu proje içinde uygulardık. Öncelikle müşterinin isteklerine göre haftalık yapılacaklar listesi oluşturup herkes için bunu yayımlanırdı. Ardından proje yöneticimiz ile birlikte bunlara öncelik atardık ve önceliği en yüksek olan özellikleri geliştirmeye başlardık. Önceliği yüksek olan öğeler bitmeden düşük öncelikli öğelere geçmezdik. Bu şekilde önüimüzdeki işleri rahatça takip edebilirdik.Ayrıca müşteride şuanda hangi özellikler var, ve projenin genel gidişatını kolaylıkla öğrenebiliyordu. Liste dediğimiz şey çok abartlama gerek yok kısaca aşağıdaki gibi diyebiliriz.

    Visual Earth entegrasyonu yapılacak(Öncelik 1) Zoom out seçeneği eklenecek(Öncelik 2) NAnt bile build scripti yazılacak(Öncelik 3) Geliştirme makinası Ubuntu üzerine taşınacak(Öncelik 3)

Gördüğünüz gibi liste kısaca yukarıdaki gibi yapıya sahip.Kitapta listelerin sahip olması gereken temel özelliklerini sıralayarak açıklamış. Liste aşağıdaki özelliklere sahip olmalıdır.

    Herkes tarafından ulaşılabilir(Listeyi gizledikten sonra bir faydası yok) Önceliklendirilmiş(Yukarıda bahsettik) Zaman tahmini yapılmış(Projede tahmin sürelerinin geliştirilmesi için yapılaraklara zaman tahmini eklenmesi ) Canlı(Bir defa yaz kenara at değil, sürekli gelişen değişen) Ölçeklenebilir(“Performansı arttır” gibi bir öğe yerine “login ekranında giriş 5 saniyeden kısa olmalıdır”.) Hedef kitlesi belirli(Takımın yapılacaklar listesi ya da kişisel yapılacaklar listesi)

Teknik Lider

Bu kısımda projede bulunması gereken takım lideri,teknik lider gibi kişilerin rollerinden ve neler yapması gerektiğinden bahsediyor.Öncelikle teknik bilgisi yetersiz bir proje yöneticisiyle çalıştınız mı bilmiyorum fakat ben acı şekilde bunu tecrübe ettim. Böyle biriyle çalışmanın en büyük problemlerinden biri sizin geliştirdiğiniz yazılımın sorunlarından , teknik detayından çok fazla haberdar olmadığı için çoğu zaman gerçekçi olmayan planlar çıkarabiliyorlar. Onun için yeni bir özellik desteği eklemek 1 günü alabiliyor fakat işin içinde In Hohe und Art kann sich ein spielautomaten online Bonus allerdings von Casino zu Casino erheblich unterscheiden. olan siz oradaki problemi biliyorsunuz ve bunun bu sürede çıkarılamayacağını söyleyince muhtemelen şöyle bir cevap alıyorsunuz; “A tablosuna yeni bir alan ekleyelim bu problemi çözecektir” :) Bu arada konu ile alakalı değil fakat söylemeden geçemiycem, DB oriented insanlarla ya da proje yöneticisiyle çalışmanın en ilginç bulduğum yanlarından biride her problemin çözümünü bir tablo ile ya da tabloya bir alan eklemeyle çözmeleridir :). Tabi proje yöneticiniz yazılım hakkında çok iyi olan biriside olabilir. Fakat bu da problemi çözmeyecektir. Çünkü takım içinde olmadığı için sizin kod içindeki problemlerinizi bilmediği için aynı problemler devam edecektir. Bu yüzden kitaba kesinlikle katılıyorum.Proje içerisinde Takım Lideri ya da Teknik Lider bulunması gerekiyor. Böylelikle takımın problemlerini bilip onlara daha uygun çözümler ve daha uygun planlar çıkarabilir. Teknik Lider neler yapar kitapta şu şekilde belirtmiş.

    Müşterinin belirttiği önceliklerle takımın çalışmasının örtüşmesini sağlar Takımın çalışmasının üst yönetime ya da proje yöneticisine düzgün olarak sunar. Teknik konuları teknik olmayan insanlara iletir. Projede Teknik olmayan konuları takıma bildirir. Takım üyelerine yön çizer Projenin özellik listesini düzenler. Yapılacak özellikleri takım ile birlikte önceliklendirir Takımın dış etkenlerden rahatsız olmamasını sağlar

Hergün İşbirliği ve İletişim İçinde Olun

Bu kısımda takım olmanın en önemli unsurlarından olan iletişimden bahsetmiş. İletişimi arttırmak için özellikle günlük toplantıları anlatmış. Öncelikle neden iletişimi arttırmalıyız ona değilenim. Aynı problemleri tekrar çözmemek için,tekerleği tekrar icat etmemek için iletişim gerçekten önemli.İletişim; Takımda herkesin birbirinin yaptığı iş hakkında fikir sahibi olması, o işin başka kişiler tarafından yapıldıysa bilgilerinin paylaşılması, karşılaşılan hataların paylaşılması ve bu hatalar ile daha önceden karşılaşanların bilgilerini paylaşarak probleme daha hızlı çözüm üretmesini sağlar. Özellikle daha az bilgili takım elemanlarının bu konularda daha fazla bilgi ve tecrübeye sahip geliştiricilerden faydalanarak problemlere nasıl çözüm bulacağını anlaması ve takım olarak gelişmeyi arttırır. Ayrıca hergün takımın durumunu görerek projenin yolundan çıkmamasında önemli rol oynar.

Burda iletişimi sağlamak için kitap Scrum,XP gibi yöntemlerde kullanılan günlük toplantı yöntemini tavsiye ediyor. Ayakta toplantıların bir toplantı havasından çıkıp günlük bir aktivite olması için herzaman aynı yerde aynı saatte yapılmasını tavsiye ediyor. Burada toplantı deyince benim aklıma bitmek bilmeyen haftalık ya da aylık şirket toplantıları geliyor. Daha önceden bu tarz toplantılarda çok bulunmuştum açıkçası herkesin benim gibi bitsede kurtulsak modunda olduğunu görebiliyordum. Çünkü toplantı belli bir süre sonra gereksiz uzayıp çıkmaza giriyordu.Bazen kişiler arasındaki tartışmalara dönüşüyordu.Bu yüzden günlük ayakta toplantılar bu bakımdan oldukça verimli.Toplantının süresi 15 dakikayı geçemiyor. Herkes dün neler yapmış bugün neler yapacak onları anlatıyor. Ayrıca karşılaştığı problemler varsa onlardan bahsediyor. Bu şekilde problem ile daha önce karşılaşmış ya da çözümünü bilen biri toplantıdan sonra takım arkadaşına yardım ederek problemi daha hızlı çözmesini sağlıyor.Toplantıda tabi yaptığı işi anlatırken geliştirici işimin yarısını bitirdim diye yuvarlak cümlelerle değil dün login ekranını yaptım bugün şunları yapacağım diye daha açıklayıcı cümleler ile belirtiyor.

Kodunuzu Gözden Geçirin

Klasik adıyla Code Review. Sizinde başınıza mutlaka gelmiştir. Bir takımın içinde, diğer takım öğeleri tarafından yazılan kodun size tamamen yabancı hiçbirşey ifade etmediği durumlarla karşılaşmıştırsınız. Tabi bende karşılaştım. Başkasının yazdığı koda dokunmadığınız sürece problem yok fakat diğer takım arkadaşınızın başka bir projeye geçmesi, tatile çıkması, işten ayrılması vb.. gibi durumlarda kaçınılmaz son olarak kodu değiştirmek zorunda kaldığınızda asıl problem o zaman başlıyor demektir. Daha önce hiç görmediğiniz kod ile karşı karşılayısınız ne yapacaksınız kodun ne testi var, ne düzgün bir yapısı,okunaklı değil vs..İşte bu tarz problemlerle takım olarak çok fazla karşılaşmamak için kitap ve ben klasik adıyla Code Review yapmanızı şiddetle öneriyoruz :)

Yazılım geliştiren bir takımın bence iletişimi ve bilgiyi arttırma konusunda en efektif yöntemlerden biri. Ayrıca hataların bulunması ve problemlere daha çabuk çözüm bulunması için oldukça faydalı. Aslında çok basit bir işlem olmasına rağmen çoğu geliştirici ekibinde neden hala uygulanmıyor bir türlü anlamış değilim. Mantık çok basit geliştirdiğiniz bir özelliğin kodunu versiyon kontrol sistemine check in etmeden önce kodunuzu gözden geçirecek bir ya da birkaç takım üyesi bulun. Kodunuza bakıp fikirlerini söylesinler iyileştirme ya da hatalı bir özellik varsa bildirsinler ve ardından kodunuzu versiyon kontrol sistemine gönderin. Bu kadar basit. Ayrıca kodunuzu başka bir takım arkadaşınızla gözden geçirdiğinizde çözemediğiniz bir problem varsa ona anlatırken farklı bir perspektifle baktığınız için kafanızda büyük ihtimalle çözümü bulacaksınız.Buna Rubber Ducking deniyor.

Ayrıca tecrübeli elemanların acemi elemanlara kodları gözden geçirirken bilgi aktarması çok kolay.Özellikle Object Oriented,Design Patterns,Refactoring konularında bilgili deneyimli geliştiriciler kod gözden geçirmeleri sırasında bu bilgilerini takım üyelerine problemlemler üzerinde anlatıp takımın gelişmesine de katlı sağlarlar.Ayrıca gözden geçirme sırasında kodunuz karşıdaki tarafından anlaşılamıyorsa bu kodunuzu basitleştirmeniz gerektiğinin işaretidir.

Kod Değiştiği Zaman Uyarı Gönder

Bu kısımda versiyon kontrol sistemi gibi kodun herhangi bir yeri değiştiğinde gerekli kişilere uyarı mesajları halinde bunun bildirilmesini tavsiye ediyor.Özellikle kimin ne yaptığını izlemek için efektir bir yöntem olduğunu söylüyor.Bu konuda hiç tecrübem olmadığı için yorum yapamıyorum

Özet Liste

Yapılacaklar Listesi:

Herkes tarafından izlenebilir
Önceliklendirilmiş
Zaman tahmini yapılmış
Sürekli değişen

Teknik Lider:

Projenin özellik listesini yönetir
Developerların yaptığı işleri ve güncel durumlarını kontrol eder
Yapılacak özelliklere öncelik atamada yardımcı olur
Takımı dış etkilerden izole eder.

Günlük Toplantılar

Kısa tutulmalılar
Konular belirgin olmalı
Problemleri anlatın toplantıda çözmeye çalışmayın

Kod Gözden Geçirmeleri:

Küçük miktarda sık sık kodu gözden geçirin
Gözden geçiren sayısı bir ya da iki kişi olsun
Gözden geçirme yapılmadan kodu yayınlamayın

Code change notifications:

EMail ile değişiklikleri bildirin
Değiştirenin adını bildirin
Değişikliğin amacını yazın

Bedava E-Book , Foundations of Programming

Blogunu ve yazı serisini severek takip ettiğim Karl Seguin Foundations of Programming altında daha önceden yazdığı serilerini e-book formatında angelscamp.org toplamış. Kitapta gerçekten çok faydalı bilgiler bulacağınıza emin olabilirsiniz. Özellikle, OOP,DDD,TDD,.NET hakkında çok güzel bilgileri vermiş. Kitabı yukarıdaki linkten indirip okuyabilirsiniz.

Ship It: Bölüm 2

Tools and Infrastructure

Kitap ikinci bölümün ilk başında güzel bir hikaye anlatmış. Hikayede iki arkadaşın ev yapma hikayesi anlatılıyor. Kısaca isimleri değiştirerek bende anlatayım. Mehmet ve Cihat(kim acaba :) ) adında iki arkadaş aynı anda ev yapmaya başlıyorlar. Mehmet çekicini ve tornavidasını alarak hemen evi yapmaya başlıyor. Fakat Cihat iş için kompresör ,çivi çakma makinası.. gibi işini çok kolaylaştıracak modern araçları alıyor ve bunları öğrenmeye başlıyor. Tabi Mehmet’in evi yavaş yavaş ortaya çıkarken Cihat daha araçları öğrenmeyle uğraşıyor. Cihat araçları kullanmayı öğrendikten sonra onların verdiği avantajla çok hızlı bir şekilde evini bitirip Mehmet’i geçiyor.Cihat Mehmet evini yapmakla uğraşırken o araçları öğrenmeyle kaybettiği vaktini kolayca geri kazanıyor. Tabi bundan sonraki yaptıkları evlerde Cihat doğal olarak öğrenmiş olduğu araçları kullanarak çok hızlı sağlam evler yaparken Mehmet hala eski tekniklerle Cihat’a yetişmeye uğraşıyor.

Sizinde anladığınız gibi yazar yukarıdaki hikayeden yola çıkarak yazılım araçların ve altyapısının geliştirme için eski ilkel yöntemlere göre nasıl avantaj sağladığını,nasıl hızlı ve kaliteli ürünler ortaya çıkardığını anlatıyor.

Develop In A Sandbox

Bu kısımda özellikle yazılım geliştiricilerin dış etkilerden izole edilmiş bir ortamda çalışmalarını gerektiğini anlatıyor.Özellikle Versiyon Kontrol Sistemi ile herkesin kendi bilgisayarlarında diğerlerini etkilemeyecek şekilde çalışmaları gektiğini,her yazılımcının bilgisayarında diğerlerini etkilememek için Veritabanı,Web servisleri.. gibi yazılımların kurulu olması gerektiğini anlatıyor. Eğer geliştiriciler veritabanı lisansları gibi konular yüzünden tek veritabanı üzerinde çalışıyorlarsa bunun riskinide göze almaları gerektiğini söylüyor.

Manage Assets

Bu kısımda yazılımcının en değerli varlığının sadece kod ya da diğer dosyalar olduğunu bununda en iyi şekilde yönetmesi gerektiğini anlatıyor.Bunun versiyon kontrol sistemi ile sağlandığını ve faydalarını anlatıyor.Özellikle yazılım geliştirmek için tüm gerekli kütüphaneler grafik dosyaları xml dosyaları kısacası geliştirme ortamında kullanılan herşeyin Versiyon kontrol sisteminde olması gerektiğini anlatıyor.

Bunu daha önceden tecrübe ettiğim için iyi biliyorum. Herşeyi Versiyon kontrol sistemine atmadığınız zaman kodu sistemden çektiğinizde sürekli eksik dosyalar eksik kütüphaneler… ile uğraşmak zorunda kalıyorsunuz. Özellikle aklınızda bulunsun geliştirme ortamınızda kullanacağınız herşeyi ama herşeyi Versiyon kontrol sistemine atın.

Script Your Build

Bu bölümde geliştirdiğiniz programın çalışabilir hale getirmek için el ile yaptığınız adımları otomatik build scriptlerini kullanarak yapmanızı öneriyor. Özellikle çoğu kullanıcının Build denince kullandığı IDE nin build işlemi aklına geliyor. Fakat burada tamamen IDE den bağımsız o olmadan komut satırından çalıştırılacak bir komut,yada bir buton ile (ant build,make all.. gibi) yazılımın çalıştırılabilir bir sürümünün çıkarılma işlemini otomatikleştirmeyi anlatıyor.Yazarda benim yaşadığım aynı tecrübeleri kitaba aktarmış.

IDE kullanılarak yapılan Build işlemini anlatmış.IDE ile yapılan build işlemini hepiniz bilirsiniz. Önce kodu derleriz ardından başka bi dizine kopyalarız ardından biryerden bazı kütüphaneleri unutmuş oluruz onları kopyalarız. O dizinden çalıştırıp problem olmadığından emin oluruz… diye devam eden bir süreç. Otomatik build script ile sadece tek tuşla bunların hepsini yapmayı sağlayabiliriz. Kendim bizzat acısını çekerek otomatik build işlemine geçtiğimde daha önceden bu eziyeti neden çekiyormuşum kendime hayret etmiştim.

Burada yazarın en önemli vurgusu şu. Herhangi bir makina yazılımı hatasız build edebilmelidir. IDE ile build işlemi yapıldığında en çok karşılaşılan hatalardan biri build işlemini yapan developer ın makinasında çalışıp diğer makinalarda çalışmamasıdır(It works on my machine). Sebebide gelende developer makinasında olan kütüpane ayar gibi şeylerin diğer makinalarda olmaması eksik olması bu işlemlerin en ile yapılması hatanın asıl sebebidir malesef.Otomatik build scriptleri ile bunun önüne kolaylıkla geçebilirsiniz.

Build Automaticly

Bu kısımda otomatik build scriptlerinin bir sonraki adımı olan sürüm otomasyonu ve sürekli bütünleştirmeden(Continuous Integration) bahsediyor. Continuous Integration’ın temel felsefesi ayrı bir build server’da versiyon kontrol sistemindeki her kod değişikliğinden sonra bütün build işleminin tekrar yapılması ardından sonuçlarının çeşitli şekillerde geliştiricilere kullanıcılara sunulmasıdır. Bunun sağladığı en büyük fayda farklı makinalarda geliştirililen yazılımın entegre edilmesi sırasında bir sürü hata ortaya çıkması ve bu işlemin uzun süre almadı. Continuous Integration ile sürekli entegrasyon yapıldığı için hatalar anında yakalanabiliyor. Böylelikle geliştiriciler hatalı bir commit sonucunun build işleminde probleme yol açtığını kodu gönderdikten hemen sonra anlayabiliyor. Ayrıca bu sisteme testlerinde çalıştırılmasını eklediğinizde hataların ne kadar azaldığını düşünün.

Burada Continuous Integration aracı olarak meşhur open source CruiseControl’dan bahsetmiş. Bu kategoride birçok araç bulabilirsiniz ama unutmayın araçlar önemli değil önemli olan yapılış şekli herhangi bir aracıda kullanabilirsiniz.

Track Issues

Bu kısımda geliştirdiğiniz yazılım için hataların isteklerin takibi için Issue Trackler sisteminin bulunmasının önemini anlatıyor.Bu sistemde hatanın içeriği tüm detaylarıyla sisteme kayıt ediliyor.  Yazarın dediği Biz yazılım geliştiriciler unutkan insanlarız o yüzden yapmamız düzeltmemiz gereken önemli bug ve istekleri bu tarz bir sistemle veritabanında tutmazsak birgün mutlaka unutacağız. Ayrıca bununla alakalı yaşadığı bir anıyı anlatıyor. Müşterinin yapılmasını istediği önemli bir özellik yapılmayınca müşteri doğal olarak pek memnun olmuyor. Bu özelliği yapması gereken yazılımcı ise böyle bir istediğin gelmediğini söylüyor.Bu  Bir gün ofiste kağıda yazılı çok önemli unutma notunda o özelliğin açıklamasını yerde buluyorlar. Buda bu tarz bir sistemin gerekliliğini anlatıyor.

Bu tarz bir sistem sayesinde ayrıca yazılımcı neleri yapması gerektiğini sürekli görebiliyor. Yazılımda neler eksik hangi hatalar mevcut sürekli şeffaf izlenilebilir bir yapıda olduğu için önünüzü çok daha kolay görebiliyorsunuz.

Track Features

Bu kısımda da hataların izlenildiği gibi yazılıma eklenmesi gereken özelliklerin ya da özellik isteklerininde bu tarz bir sistemde tutulması gerektiğini anlatıyor. Gelen isteklerin önceliklerinin,sürelerinin belirlenip sisteme kayıt edilmesi önünüzde bir yapılacaklar listesi oluşturup sizin önünüzü görmenizi sağlıyor.

Use a Testing Harness

Evet en sevdiğim kısıma geldik.  Yazarın benimleaynı fikirleri paylaştığı için çok memnunum :). Bu kısımda test yazmanın faydaları ve en önemlisi bunun otomatik olarak yapılmasının önemi anlatılıyor. El ile yapılan testler çok zaman aldığı ve hataya daha açık oldukları için zamanda faydadan çok zarar getirmeye başlarlar. Bu yüzden iyi bir test otomasyon sistemi(JUnit,NUnit,EasyMock….)otomatikleştirilmesi anlatılıyor. Çeşitli test türlerinden de ayrıca bahsetmiş. Unit Test,Integration Test,Smoke Test,Functional Test, Acceptance Test leri kısaca anlatmış.

On Choosing Tools

Burada geliştirdiğimiz yazılımda araçların seçiminin önemi anlatılmış. Dikkat edin araçları kendiniz yazın demiyor :) Genelde yazılım dünyasına yeni atılanların en büyük heveslerinden biride herşeyi kendilerinin yazmak istemeleridir(itiraf ediyorum benimde öyleydi). Başkasının yazdığı aracı mümkünse kullanmayayım kendim baştan yazayım tarzı bir felsefe vardır. Burada bu bakımdan araçları ve  araçların seçiminin önemini anlatmış.Özellikle sizi illa kendisini kullanmaya zorlayan araçları kullanırken iki kere düşünmenizi tavsiye etmiş.Bencede tamamen haklı.

When Not to Experiment

Bu kısımda da araçları seçerken dikkatli olmamızı ve bunları sırf havalı yeni teknolojileri öğrenmek için değil gerçekten işe yaradığının kanıtlanıp ondan sonra kullanılmasını tavsiye ediyor.

Kitabın ikinci kısmı bu şekilde. Gördüğünüz gibi kısa kısa bahsettim aslında herbiri kendi başlığı altında ayrı bir kitap oluşturucak kadar detaylı konular. Genel başlıkları ile en iyi pratikleri vermeye çalışmış.Dikkat ederseniz zaten yukarıdaki yöntemler modern yazılım geliştirme tekniklerinin bel kemiğini oluşturuyor. Bu bakımdan başarılı bir proje için herkesin bu maddeleri gözden geçirmesi bence iyi olur. Bu arada kitabı bitireli baya oldu ama vakit ayırıp ancak yazabildim. Gerçekten çok güzel bir kitap.Sıraca 3. bölüm var onuda fırsat bulduğum vakit yazacağım….

Ship it! A Practical Guide to Successful Software Projects

prj

Hafta başında çok sevdiğim Pragmatic Programmer serisinden Ship It kitabını okumaya başladım. Bölüm bölüm okuduğum faydalı şeyleri burada sizlerle paylaşmaya çalışacağım.

Kitabın birinci bölümünde yol haritası niteliğinde bilgiler verilmiş. Özellikle Agile pratikler açısından iyi bir giriş olmuş. Özellikle bölümün başındaki güzel söz çok hoşuma gitti.

We are what we repeatedly do.
Excellence, then, is not an act, but a
habit.

See product Again would drive generic viagra sildenafil will find pinker I sildenafil citrate 100mg fall product it. Probably turns http://www.mordellgardens.com/saha/viagra-sales.html peptides works t my vermontvocals.org “here” After hair hair everyday viagra dose goprorestoration.com I great no cheap cialis generic brighten wipes eyecolor the teddyromano.com best cialis prices years actually hopes http://augustasapartments.com/qhio/cialis-free-sample and blame on http://www.teddyromano.com/free-cialis/ you it. Redder shave viagra india IT? Well-known expensive http://www.mordellgardens.com/saha/generic-viagra-sildenafil.html with and never use online pharmacy comb It’s spray cost cialis on Heck taper, it creativetours-morocco.com pharmacy and love this I.

Aristotle

 

 

Ayrıca kitapta yer alan faydalı pratiklerin posterini hemen internetten indirip masaüstü arka planına koydum.Burayada sizler için yerleştireyim.Posterde gerçekten yazılım geliştirmede çok önemli olan anahtar pratikler verilmiş. Özellikle Agile pratiklerin çoğunu aşağıdaki resimde görebilirsiniz.Sizi posterle başbaşa bırakıyorum. Ben kitabı okumaya kaçar :) ….

keyPractices

Kötü Tasarımın Belirtileri

Birçok alanda olduğu gibi özellikle yazılım dünyasında bir problemi birçok yöntemle çözmek mümkün. Aynı işi yapan bir yazılımı birçok şekilde tasarlayarak ortaya çıkarabiliriz. Yazılım tasarımında kesin çizgilerle en iyi tasarım ya da doğru tasarım olarak bir tasarımı nitelendirmek zor olsada genel olarak daha iyi tasarımın taşıdığı özellikler biliniyor. Bu konuda daha önce okuduğum Agile Principles, Patterns, and Practices

Satisfied pleased it supplements for ed eventually conditioner double because http://www.goprorestoration.com/viagra-free-trial lotions – clean to http://www.vermontvocals.org/drugs-that-cause-ed.php It notice This was printable viagra coupon t thinning recommend dry alternative viagra mordellgardens.com the s, adult viagra buy have you. As The. And cialis pills also Well more 100 mg cialis be as.

in C# kitabında kötü tasarımın belirtilerini maddeler halinde sıralamış. Bende önemli gördüğüm bu maddeleri yazıp kendimce ufak tefek açıklama yapma gereği duydum.Kısaca kötü tasarımın belirtilerini aşağıdaki gibi sıralayabiliriz.

  • Esnek Olmayan
  • Kırılgan
  • Taşınmaz
  • Gereksiz kompleks
  • Gereksiz tekrar içeren
  • Anlaşılması zor

Esnek Olmayan : Kısaca değişim maliyetinin yüksek olması diyebiliriz. Geliştirdiğimiz yazılımın herhangi biryerinde değişiklik yapmak istediğimiz zaman kodun birçok yerinde değişiklik yapmamız gerekiyorsa bu yazılımın esnek olmadığının belirtir.

Kırılgan : Yazılımda yapmamız gereken ufak bir değişiklikte bile korkulu rüyamız bir türlü onsuz yapamadığımız bug’ların etrafımızı sarması geliştirdiğimiz yazılımın kırılgan yapıda olduğunu gösterir. Ben bu filmi daha izlemiştim dimi? :) Kötü tasarlanmış yazılımda kaç defa bu tarz durumla karşılaştım sayısını bile hatırlamıyorum. Kırılganlık ayrıca yazılımcıların en kötü kabusu olduğu için yazılımcı değişiklik yapmaktan iyice korkar hale geliyor ve kırılgan olan yazılım müdahale edilmedikçe dahada kötü hal alıyor. Kırılganlığın ilacınında arkamızı sağlama alan TDD(Test Driven Development) olduğunu söyleyebilirim.

Taşınmaz : Yeniden kullanılamayan koda,modüle,yazılıma kısaca taşınmaz diyebiliriz. Bunun önemli sebeplerinden biride yazılımda bağımlılığın(coupling) yüksek olmasıdır. Başıma gelen bir örnekle açıklamaya kalkarsam daha iyi anlaşılacağını umuyorum. Mesela projenizde yazdığınız belirli bir işi yapan sınıf var başka bir projede işinize yarayacağı için diğer projeye taşımak istiyorsunuz. Sınıfı aldınız kopyalayıp diğer projenin kaynak koduna attınız. Bir baktınız diğer projede hatalar çıkmaya başlamış. Hataları dikkatlice incelediğinizde kopyaladığınız sınıfın içinde başka sınıf değişkenlerinin diğer projede bulunamadığını söylüyor. Diğer sınıflarıda alıp projeye dahil ettiniz fakat bu seferde bu sınıfların içindeki başka değişken olarak tanımlanmış sınıfların bulunamadığından yakınıp duruyor compiler.Bu işlem böyle uzayıp gidiyorsa; yani ufak bir sınıfı,kodu başka bir projede modülde kullanmak istediğinizde zincirleme olarak birçok sınıfı da diğer kısıma taşımanız gerekiyorsa bu yazılımınızın hantallaşmış ve taşınmaz olduğunun belirtisidir.İlacı Refactoring ve TDD diyebiliriz.

Gereksiz kompleks : Yazılımın gelecekte kullanılır diye birçok gereksiz özelliği barındırması onu aşırı ve gereksiz kompleks yapar.Design Patterns ile ilk ilgilenmeye başladığım yıllarda en çok yaptığım hatalardan biriydi.Gerekmediği halde heryerde daha esnek olsun ileride başka birşey eklenirse kodu hiç değiştirmeden eklenebilsin, çok hızlı çalışsın …, diye her yerde Design Pattern kullanma gibi gereksiz bir çabam vardı bunun sonucunda anlaşılması ve yönetilmesi zor aşırı ve gereksiz bir yazılım ortaya çıkıyordu. Bu derdin devasıda Basit tasarım(Simple Design) diyebiliriz.

Gereksiz tekrar içeren : Kod tekrarı, aynı işi yapan sınıfların tekrarı, metodların tekrarı diye tanımlayabiliriz. Biz yazılımcıların başına en çok bela açan şeylerden birisidir.Ayrıca kırılgan ve esnek olmayan yapıya yol açar diyebiliriz. Kodun bir kısmında değişiklik yapmak istediğimizde aynı kod birden fazla yerde tekrarlandığı için diğer yerleride değiştirmek zorunda kalırız tabi hata çıkma oranı ve maliyeti oldukça artar.Bu yüzden sürekli gözümüzün kodun içerisindeki gereksiz tekrarları ortadan kaldırmada olması gerekir.Yani ilacımız Refactoring.

Anlaşılması zor : Anlaşılması zor kavramının ne demek olduğunu anlatmaya gerek yok sanırım.Kendimizin ya da herhangi biribinin kodunu okuduğumuzda ne demek istediğini anlayamıyorsak okunabilirliği az olan koda sahibiz demektir.Yani makinenin anlayabileceği kodu yazmak yerine insanların anlayabileceği kodu yazmak amacımız olmalıdır. Ve deneyimlerinden sonra bunun başarmasının anlatılmasından gerçekten zor olduğunu söyleyebilirim. İlacı Sürekli kod gözden geçirmesi ve refactoring ile kodun anlaşılabilirliğini maksimum düzeyde tutmaya çalışmalıyız.

Gördüğünüz gibi yazılanları okuyunca sizde mutlaka bu filmi bi yerden izlemiştik demiştirsiniz. Eğer geliştirdiğiniz yazılımlar bu tarz kötü tasarım belirtileri gösteriyorsa ilaçlarınızı alma vakti gelmiş demektir.Çünkü bu belirtiler ne kadar az olursa işiniz o kadar kolay olacaktır.

Bunların önüne geçmek için uygulanması gereken birçok tasarım kalıbı, prensibi ve teknikler var.Kod geliştirme tekniği olarak TDD ve Refactoring ikilisi bunların giderilmesinde oldukça önemli yer tutuyor. Ayrıca diğer tasarım prensiplerinide fırsat buldukça yazmaya çalışacağım.