Agile - Kanban Tahtası Örneği

Scrum Turkey 'de Türkçeleştirilmiş olarak yayınlanmış Kanban tahtası örneği aşağıda bulunmaktadır:

Dokümana buradan erişebilirsiniz: Kanban Tahtası Örneği

Eğer dokümanın orjinal versiyonu ile ilgileniyorsanız, buradan ulaşabilirsiniz.

Kaynak:

• http://www.scrumturkey.com/2014/06/kanban-tahtas-ornegi.html

Yazılım Tasarım Teknikleri – Clean Code

Temiz kod yazmak, bilgisayarlar tarafından kodun düzgün çalıştırılmasını veya anlaşılmasını değil, kodumuzu okuyan diğer geliştiriciler tarafından kodun doğru şekilde anlaşılmasını amaçlamaktadır. Temiz kod, projelerin zamanla yönetilebilir olmaktan çıkmasını engellemektedir. Dolaylı olarak maliyetleri de düşürdüğü görülmektedir.Temiz kod kaliteli koddur.

Yukarıdaki çizimden de anlaşılacaği gibi kaliteli kodun dört sıfatı ya da özelliği vardır:

Basit; Kaliteli kod her şeyden önce basittir, olabileceklerin en basitidir. Dolayısıyla daima “en basiti bu mudur?” diye sorularak kod yazılmalıdır.

Odaklı; Her yazılan kod parçasının sadece ve sadece tek bir amacı olmalıdır.

Tam; Ne eksik ne fazla, sadece ihtiyaç için kod yazılmalı, başka hiç bir şey yazmamalıdır. İhtiyaçla ilgili ne varsa yazılmalı, ilgisiz olan hiç bir şeyi yazılmamalıdır.

Güvenilir. Sadece normal durumlar değil, anormal durumlar da düşünülmelidir. Hatalı halleri görmezden gelinmemelidir.

Biraz daha detaylandırarak açıklayacak olursak;

Basit kod en temelde anlaşılır koddur. Basit kod, hem şekil hem de içerik açısından rahat anlaşılır, gözü ve zihni yormaz. Bu anlamda basit olmanın şekil şartı isimlendirme ve şekil standartlarına uymaktır. Öte taraftan basit kod elde etmek için içerik olarak da basit kod yazmak gereklidir. Bu da hem odaklı hem de kısa kod yazmakla gerçekleşir.

Odaklı kod, hem basit kodun bileşenidir hem de kendi başına özelliklere sahip olduğundan apayrı bir şekilde ele alınması gereken bir ilkedir. Odaklı olmanın iki yüzü vardır: Bir yerde sadece bir şeyi halletmek, bir şeyi sadece bir yerde halletmek.

Tam kod, ne eksik ne fazla, sadece istenilenin yapıldığı, istenilen, beklenen, ihtiyaç duyulan dışında hiç bir fazla ya da eksik bir şeyin yapılmadığı koddur.

Güvenilir kod ise sadece olması gerekeni yapmaz. Güvenilir kod olması gereken yanında olmaması gerekenin olmayacağından emin olur, olabilecek olanları da göz önüne alır. Bu anlamda güvenilir kod, bir ihtiyacı her yönüyle halleder.

Kaynaklar:

• http://www.javaturk.org/?p=3231
• http://books.google.com.tr/books/about/Clean_Code.html?id=_i6bDeoCQzsC&redir_esc=y

Yazılım Tasarım Teknikleri – SOLID

SOLID(Single responsibility, Open-closed, Liskov substitution, Interface segregation ve Dependency inversion) yazılım tasarım prensipleri için kullanılan bir kısaltmadır. Yazılım yaparken SOLID uygulandığı taktirde bakımı ve geliştirilmesi kolay yazılım sistemleri oluşturmak mümkündür. En verimli hali test güdümlü yazılım ile uygulanır.

S - SRP, Single Responsibility Principle(Tek sorumluluk): Her yazılım biriminin (sınıf, nesne, metot) tek bir sorumluluğu olmalıdır.

O - OCP, Open/Closed Principle: Yazılım birimleri geliştirilmeye(extends) açık, değişikliğe(modify) kapalı olmalıdır.

L - LSP,    Liskov’s Substitution Principle: Alt sınıflardan oluşturulan nesneler üst sınıfların nesneleriyle yer değiştirdiklerinde aynı davranışı göstermek zorundadırlar.(Örneğin, bir dikdörtgen sınıfından türeyen kare alt sınıfının alan hesaplaması dikdörtgen sınıfının alan hesaplaması ile aynı davranışı göstermelidir.)

I - ISP, Interface Segregation Principle: Herşeyi ihtiva eden interface sınıflar yerine belli bir işlemi yapan interface sınıflar oluşturulmalıdır. Oluşturulan interfaceler ortak özelliklerine göre bölümlenmelidir.

D - DIP, Dependency Inversion Principle: Üst seviye sınıflar alt seviye sınıflara tersten bağımlı olmamalıdır. Bir nesne direkt olarak kullanılmamalı, ortak özellikleri soyutlanarak kullanılmalıdır ki nesnenin tüm özellikleri, sonradan o nesneyi kullanan nesnelerin özellikleri çakışabilir. (Örneğin; Kumanda->Televizyon kumandası<Ses ve görüntü açma>,Radyo kumandası<Ses açma> gibi)

Yararlanılan Kaynaklar:

• http://www.kurumsaljava.com/2011/12/30/solid/
• http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)

SOAP(Simple Object Access Protocol)

SOAP protokolü, web servisleri ile istemciler arasında gerçekleştirilen veri alışverişinde, karşılıklı olarak akacak mesajların nasıl ve ne şekilde paketleneceğini yada başka bir deyişle bilgilerin nasıl kapsülleneceğini belirtir. SOAP, özünde XML tabanlı mesajların oluşturulmasını belirtir. Bu nedenle SOAP protokolünü uygulayan mesajlar (ki bunlar SOAP Mesajı olarak adlandırılır), herhangibir ağ ortamında hiç bir sorunla karşılaşmadan uzak makineler arasında iletilebilirler. SOAP protokolü, 4 temel üzerine inşa edilmiştir. 

SOAP protokolünün dayandığı bu temel kurallar içerisinde en önemlisi Envelope kısmıdır. Bir SOAP mesajı mutlaka bir zarf olarak teşkil edilmeli ve Zarf kurallarına göre tasarlanmalıdır. Diğer temellerin uygulanması zorunlu değildir. Veri kodlama kuralları, özellikle serileştirilen nesneler için bir model sunar. Başka  bir deyişle, tanımlanmış veri tiplerinin uygulama için kullanılma kurallarına karar verir. Bu katmandaki kuralların uygulanması opsiyoneldir. Mesaj değişim modeli, web servisi ile istemciler arasında değiş tokuş edilen mesajlar için bir istek/cevap deseni tanımlar. SOAP, Remote Procedure Call tip mekanizmasını esas alan bir veri değiş tokuş desenini kullansa da bu bir zorunluluk değildir. Mesaj değişim modelide opsiyoneldir. Veri bağlama kuralları ile, SOAP’ın iletişim protokollerinin birbirlerine nasıl bağlanacağına dair tanımlamalar içerir. Veri bağlama kuralları da opsiyoneldir.

J2ME projesinde örnek SOAP gösterimi

Yazılım Tasarım Teknikleri – GRASP

GRASP(General Responsibility Assignment Software Patterns <or Principles>) Yazılımda sorumluluk atama ile ilgili genel geçer şablonlar(prensipler) demektir. 2004-2005 yıllarında Craig Larman öne sürmüştür. Bu teknik yaklaşımlarda; yazılım geliştirirken 9 tekniğin kullanılmasının geliştirilen yazılım ürününde;  daha az satır kod yazmayı, daha okunabilir,anlaşılır temiz kod yazmayı, daha kullanışlı, daha performanslı çalışan kod yazmayı sağladığı öne sürülmüş ve genel kabul görmüştür. Bu teknik yaklaşımlar:

1) Controller,

2) Creator,

3) Indirection,

4) Information Expert,

5) High Cohesion,

6) Low Coupling, 

7) Polymorphism,

8) Protected Variations,

9) Pure Fabrication.

1)Controller(Kontrol edenin belirlenmesi): Nesnelerin yaptıkları iş itibari ile nesneler arasında olası bir iş kırılımı olması olasılığı var ise; o iş kırılımlarını kontrol edecek bir controller yazılması gerektiğini söyler.

2)Creator(Oluşturucu): Object Oriented kod yazılırken,  nesnelerin oluşturulması (create) işleminin ortak ve tek bir yapı ile yapılması gerekliliğini söyler.(Örnek: Factory pattern gibi.)

3)Indirection(Dolaylı,endirekt bağımlılık): Nesne gruplarının kendine has yaptığı işlerde diğer nesnelere bağımlılığının(object coupling) azaltıması gerektiğini söyler.(Low Coupling in genelleştirilmiş bakış açısı denilebilir.Örn. Delegation pattern, Model View Controller pattern gibi)

4)Information Expert(Bilginin uzmanı): Nesnelere sorumluluk atarken; bir işi , o işin uzmanı olan nesneye atamak gerekir. Yani bir sorumluluğu yerine getirmek için gerekli bilgiye sahip olan nesneye o sorumluluğun atanması gerektiğini söyler.

5)High Cohesion(Yüksek alaka): Nesnelerin sorumluluklarının; birbiriyle çok alakalı olan işler ile ilgi olması gerektiğini söyler.

6)Low Coupling(Az bağımlılık): Bir nesnenin yaptığı iş itibari ile diğer nesnelere en az bağımlı olması gerektiğini söyler.(Örnek: Web Services)

7)Polymorphism(Çok çeşitlilik): Bir nesnenin ortak özelliklerinin, çok çeşitli olarak kullanılabilecek şekilde tasarlanması gerektiğini söyler.(Örnek: Tekerlek<Araba tekerleği, bisiklet tekerleği ,... gibi>)

8)Protected Variations(Güvenli,birliktelik oluşturan Çeşitlemeler): Nesneleri ,birliktelik oluşturacak şekilde(‘yabancılarla konuşmayan’ gibi), olabildiğince kullanıma açık, değiştirilebilmeye kapalı olarak tasarlamanın gerektiğini söyler.(Örnek : Open-Closed prensibi)

9)Pure Fabrication(Saf fabrikasyon): Nesnelerin uzmanlık alanlarının belirlenmesinde, nesne bağımlılığı(object coupling) ve method alakası(method cohesion) ile ilgili problem olduğu düşünülüyor ise; uzmanlık konusu ile alakası olmayan yeni bir suni sınıf/katman oluşturulması gerektiğini söyler. (Örnek : Service<Systems Architecture> )

Yararlanılan Kaynak:

·      http://en.wikipedia.org/wiki/GRASP_(object-oriented_design)

·       

Yazılımda Motivasyon

Giriş

Yazılım geliştirme yaratıcı bir iş çıkartmayı hedefleyen bir süreç olup, mutlak dikkat ve konsantrasyon gerektirir. Chicago Üniversitesi Psikoloji Bölüm Başkanı Mihaly Csikszentmihalyi tarafından yapılan bir çalışmada yazılımcıların beyinlerinin sanatçıların çalışma tarzına sahip olduğu görülmüştür. Programlama sırasında beyin bir“akış” (flow) moduna geçmekte, etrafla ilişkisini kesmekte ve bir probleme günlerce konsantre olabilmektedir. Ciddi bir çevresel izolasyon gerektiren akış moduna girildiğinde, üretkenlik maksimum düzeydedir ve tüm kritik kodlamalar bu seviyede yapılır.

 Akış moduna giriş, zaman alan ve karmaşık bir süreç olup, çözülmesi gereken problemle veya yapılması gereken işle ilgili gerekli bilgiler toplanır. Örneğin:

§ Olası çözümler

§ İlgili metotlar

§ Değişkenler

§ Parametreler

§ Kullanıcı ara yüzleri

§ Nesneler ve veri yapıları

§ İş akışları

Bu süreçte bu bilgiler beynin kısa süreli hafızasında (short term memory space) biriktirilir, harmanlanır ve çalışmaya hazır hale gelinir. Yapılan farklı çalışmalara göre yazılımcının beyninin “akış” moduna geçmesi yaklaşık 15 dakikazaman almaktadır. Tam akış moduna girmiş ve programlamaya devam ederken yazılımcının herhangi bir nedenden dolayı bölünmesi (interruption) beyninin kısa süreli hafızasındaki topladığı bilgilerin silinmesine neden olur. Dolayısı ile yazılımcının tekrar işe dönüp çalışması yine 10-15 dakika daha zaman alacaktır.

Bölünme (Interruption) Nedir?

 Akış modunda olsun veya olmasın, yazılımcının dikkatinin dağılmasına ve konsantrasyonunun bozulmasına neden olan her şey bölünmedir? Bölünmeler değişik türlerde ve zamanlarda gerçekleşebilirler. Tipik bölünmeler:

§ Odaya bir kişinin girmesi

§ Odada gürültü olması

§ Tam bir işin ortasındayken başka acil bir işin gelmesi (Daha sonra ondan da acil işin gelmesi)

§ Telefon gelmesi

§ Acil konulu e-posta gelmesi

§ Anlık mesajlaşmalar

§ Arkadaş soruları

§ Bu fonksiyon tam olarak nasıl kullanılıyor anlamadım?

§ Bir hata aldım debug etsem de çözemiyorum. Evet dediğin yerlere baktım ama yine de işin içinden çıkamıyorum. Sonrasında daha üzerimde bekleyen çok acil hatalar var. Yardım edebilir misin? (Klasik ama etkili :) )

§ Kalemini alabilir miyim?

§ Çay alacağım sen de ister misin?

§ Şurada indirim var duydun mu?

§ Tatildeki fotoğraflarıma bakalım mı?

§ Dünkü maçı izledin mi?

Gerçek hayattan bir örnek: Akış sürecine girmiş bir yazılımcının yanına gidip soru ile onu bölmeye çalıştığınızda; öncelikle size bir süre (5-10 saniye) garip garip bakabilir. Tam da bu noktada yazılımcının beyni akıştan çıkmamak için direnç göstermeye başlamıştır. Öncelikle olabildiğince sizi uzaklaştırabilecek basit cevaplar verir (Evet, Hayır, 2 dakika sonra vb.). Bu cevapları üretip tekrar kaldığı yerden devam etmesi bile 2-3 dakika zaman almaktadır. Baktı ki karşısındaki kişi tatmin olmuyor ve sormaya devam ediyorsa, yazılımcı pes edip akış modunu keser ve ciddi bir zaman kaybı yaşanır.

Bazı Çalışmalar

   Parnin tarafından yapılan çalışmada Eclipse ve Visual Studio kullanan 86 programcının yaptığı 10,000 programlama oturumu ve 414 programcının anket analizi sonrasında aşağıdaki sonuçlar ortaya çıkmıştır.

§ Bir yazılımcının herhangi bir bölünme sonrasında tekrar kodlamaya başlaması yaklaşık (ortalama) 10-15 dakika sürmektedir.

§ Yazılımcılar günde sadece 2 saatlik kesilmeden çalışabilmektedirler.

   Yazılımcılar bu bölünmelerle baş etmek ve tekrar hızlıca kodlamaya dönebilmek için aşağıdaki yöntemleri denemektedirler.

§ Kağıtlara notlar alırlar

§ Derleme hatasına neden olacak hatırlatıcılar veya breakpoint’ler koyarlar

§ Son kaldıkları kod satırından devam etmeye çalışırlar (Genelde başarısız olurlar, bu satıra nasıl geldiklerini hatırlamak veya işlerini garantiye almak için başa dönerler)

§ Kaynak kod tarihçesine dönerler ve kaynak kod farklarına bakarlar (30 dakika önce yaptıklarını hatırlamak için)

Kaynaklar

§ http://blog.ninlabs.com/

§ http://denizkilinc.com/

Yazılım Geliştirme Yaşam Döngüsü (SDLC)

Yazılım ürününün hem üretim hem de müşterideki kullanım süreci boyunca geçirdiği tüm aşamalar yazılım geliştirme yaşam döngüsü (“software development life cycle”, “SDLC”) olarak adlandırılır. Yazılım geliştirme süreci, zamanlamaya dayalı ve içerik olarak bölünmüş aşamalardan oluşmaktadır. Bu sayede yazılım planlı bir şekilde geliştirilmektedir. Yazılım işlevleri ile ilgili gereksinimler sürekli olarak değiştiği ve genişlediği için, söz konusu aşamalar sürekli bir döngü biçiminde ele alınır. Döngü içerisinde her hangi bir aşamada geriye dönmek ve tekrar ilerlemek söz konusudur. Temel yazılım geliştirme aşamaları aşağıdaki gibidir:

§ Planlama: Yazılım yaşam döngüsünün ilk aşamasıdır. Temel ihtiyaçlar belirlenir, proje için fizibilite çalışmaları yapılır (maliyetlerin ve sistemin yararlarının tanımlanması) ve proje planlaması gerçekleştirilir.

§ Analiz: Bu aşamanın amacı sistemin işlevlerini ve kesin gereksinimleri açıklığa kavuşturmak ve sonucunda bunları belirli bir formatta dokümante etmektir. Bu çalışma müşteri, yazılım mühendisi, sistem analisti, iş analisti, ürün yöneticisi vb. rollerin bir araya geldiği gruplar tarafından yapılabilir. İhtiyaçların net olmadığı durumlarda yazılım mühendisi ve müşteri arasında iletişim ve birlikte çalışmanın çok daha fazla olması gerekir. Çeşitli yazılım geliştirme metodolojilerinde bu aşamada kullanım dokümanları ve test plan dokümanları da oluşturulabilir.

§ Tasarım: Gereksinimlerin tamamlanmasıyla beraber sistem tasarım aşamasına başlanır. Yazılım ürün tasarımı, müşterinin gereksinim ve isteklerini karşılamak üzere yazılım ürününün özellikleri, yetenekleri, ve arayüzlerinin belirlenmesi etkinliğidir. İki tür tasarımdan bahsetmek mümkündür (Yüksek düzeyde tasarım – Mimari tasarım ve Detaylı tasarım). Mimari tasarım, yazılım modüllerinin genel yapıları ve organizasyon içerisindeki etkileşimleri ile ilgilenir. Sonucunda mimari tasarım dokümanları oluşturulur. Detaylı tasarım aşamasında Mimari tasarım dokümanları genelde revize edilirler. Tasarım ve analiz aşamalarının ayrımı “Problem Ne?/Problem NasılÇözülür?” sorularının kullanımı ile ilgilidir. Gereksinimlerin belirlendiği analiz aşaması problemin ne olduğu ile ilgilidir. Unutmamak gerekir ki sistemdeki tüm problemler yazılım ürününün tamamlanması ile çözülmeyecektir. Maalesef çoğu zaman Ne söylemi tasarım kararı olurken Nasıl söylemi de müşterinin gereksinimi olabilmektedir. Bu duruma dikkat etmek gerekir.

o Yazılım tasarımında kullanılan en önemli tekniklerden birisi Soyutlama (Abstraction) dır. Soyutlama, problemlerin çözümlerini kolaylaştırmak için nesnelerin, olayların ve durumların bazı özelliklerin görmezden gelinmesidir. Problemi basitleştirerek en önemli kısımlarına odaklanmamızı sağlar. Modelleme is temel tasarım aracı olup statik ve dinamik modellerden bahsetmekten mümkündür. Statik model, programın çalışması sırasında değişmeyen yönlerini ifade etmek için kullanılırken (sınıf ve nesne modelleri), dinamik model programın çalışması sırasındaki işleyişi ifade etmek için kullanılır ( durum ve sıra diyagramları).

§ Gerçekleştirim (Kodlama ve Test)

o Tasarım aşamasının belirli bir olgunluğa ulaşmasıyla birlikte Kodlama aşaması başlar. Müşteriye teslim edilecek ürünü programlama aşamasıdır. Kaliteli kodlama üzerine önümüzdeki yazılarda bayağı kafa yoracağız. Şimdilik kısaca değinelim. İyi kod, okunabilirliği ve bakımı kolay olan basit koddur. KISS (Keep it simple) prensibine göre yeni mezun olmuş birisine kodunuzu verdiğinde 1-2 gün içerisinde anlayabiliyor ve değiştirebiliyorsa kodunuz iyi bir koddur. İster bir şirkette çalışın ister bireysel projeler geliştirin mutlaka belirli bir kodlama kalite standardınız olsun (İsimlendirme standartları, yorum satırı kullanımları, tekrar eden kodlar, dev –if koşul blokları, aşırı benzer işlevler, uzun metotlar vb.)

o Kodlama süresince ve kodlama sonrasında yapılan diğer önemli aşama test’tir. Erken test et yaklaşımı ile (early testing) hareket edip, analiz aşamasından itibaren test bakış açısına sahip olmamız hata yapma oranımızı ve maliyetleri (zaman, para, prestij vb.) düşürecektir. Birim testleri, duman testleri, yanlış değer testleri, kabul testleri, kullanım senaryo testleri, yük testleri, kullanıcı kabul testi, yoldan geçen adam testi, test otomasyonu gibi sürece ve duruma göre uygulanabilecek çok farklı kategoride ve derinlikte test türü bulunmaktadır.

§ Teslim ve Bakım

o Tüm test aşamaları tamamlandıktan sonra yazılım ürünün sahaya teslim edilebilir bir versiyonu çıkartılır ve teslim aşaması gerçekleştirilir. Teslim çıktısı olarak ürün tek başına yeterli değildir. Mutlaka son kullanıcılar için kullanım kılavuzu ve versiyon fark dokümanı oluşturulmalıdır. Teslim ile birlikte bakım aşaması da başlar. Hata giderici, önleyici, altyapıyı iyileştirici, ürüne yeni özellikler ekletici gibi farklı bakım faaliyetleri  mevcuttur.

 Yaşam döngüsünün temel adımları çekirdek süreçler (core processes) olarak da adlandırılır. Bu süreçlerin gerçekleştirilmesi amacıyla Yazılım Belirtim Yöntemleri ve Yazılım Süreç Modelleri kullanılmaktadır.

§ Yazılım Belirtim Yöntemleri (Specifications)

o   Bir çekirdek sürece ilişkin fonksiyonları yerine getirmek amacıyla kullanılan yöntemlerdir.

o   Süreç Akışı İçin Kullanılan Belirtim Yöntemleri: Süreçler arası ilişkilerin ve iletişimin gösterildiği yöntemlerdir (Veri Akış Şemaları, Yapısal Şemalar, Nesne/Sınıf Şemaları).

o   Süreç Tanımlama Yöntemleri: Süreçlerin iç işleyişini göstermek için kullanılan yöntemlerdir (Düz Metin, Algoritma, Karar Tabloları, Karar Ağaçları, Anlatım Dili).

o   Veri Tanımlama Yöntemleri: Süreçler tarafından kullanılan verilerin tanımlanması için kullanılan yöntemlerdir (Nesne İlişki Modeli, Veri Tabanı Tabloları, Veri Sözlüğü).

§ Yazılım Süreç Modelleri (Processes)

  Yazılım yaşam döngüsünde belirtilen süreçlerin geliştirme aşamasında, hangi düzen ya da sırada, nasıl uygulanacağını tanımlayan modellerdir. Karmaşıklığı azaltıp krizleri önler. Ürünlerin beklenilen kalitede olması süreçlerin kontrol edilmesine bağlıdır. Belli başlı yazılım süreç modelleri aşağıdaki gibidir;

• Kodla ve Düzelt (Code and Fix)
• Şelale Modeli (Waterfall Model)
• V Modeli (V-shaped Model)
• Evrimsel Geliştirme (Evolutionary Development)
• Prototipleme (Prototyping)
• Spiral Model
• Formal Sistem Geliştirme (Formal System Development)
• Matematiksel sistem modeli formal (kurallara uygun) olarak gerçekleştirilir.
• Yeniden kullanıma yönelik geliştirme (Re-use based development)
• Sistem var olan bileşenlerden toparlanır
• Artımlı Geliştirme (Incremental Development)
• Birleşik Süreç (Unified Process)
• Çevik Modeller (Agile models: XP, Scrum)

Kaynak :

• http://denizkilinc.com/2013/07/08/yazilim-yasam-dongusu-temel-asamalari-software-development-life-cycle-core-processes/#more-168