12 Ocak 2013 Cumartesi

Yazılımda ne kadar kaliteye ihtiyacımız var?

Yazılım geliştirenler bilirler, yazılım geliştirmek nispeten basit, kaliteli yazılım geliştirmek ise sabır, disiplin, tecrübe ve bilgi isteyen bir iştir. Takım çalışmasını ve takımca aynı amaca odaklanmayı gerektirir. Kaliteli yazılım geliştirmek, kodu yazmaktan başka içinde bir çok süreci ve pratiği barındırdığından, geliştirme süreci bir çok kişiye normalden uzun gelir. Bu nedenle ucuz değildir. Kısa vadede maliyetlidir, ancak orta ve uzun vadede maliyetleri fazlasıyla azalmasını sağlar.


Peki ne kadar kaliteye ihtiyacımız var? Tahmin ederim ki "projelerin yapısına, beklenen gereksinimlerin tipine ve sayısına, elimizdeki bütçeye ve tabiki markete çıkış zamanına göre değişir" diyeceksiniz. "Her uygulamanın çok kaliteli olmasına gerek yok, bazı uygulamalar gelir ve geçer. Sadece bir süre işe yaraması yeterli. Üzerinde o kadar da çalışmaya gerek yok" diyeceksiniz.

Kalitesiz yazılımlar, yazılımın amacı, tipi, büyüklüğü ve hedef kitlesi ne olursa olsun, müşterisini ve kullanıcısını asla memnun etmez. Memnun olmayan müşteri ve kullanıcı, harcanan onca emek ve paranın uçup gitmesine neden olur. Yazılımda kalite, pazardan aldığınız meyvenin çürük olup olmamasına benzer. Çürükleri yeni gelen müşterilere kakalayabilirsiniz ama bir kez meyvalarınızın kalitesini farkeden müşteriler, bir kez daha size gelmezler. Kısa vadede çok kaybınız olmaz. Ama orta ve uzun vadede itibarınız zadelenir, müşteri kaybedersiniz, emeğiniz heba olur ve para kaybedersiniz. Sanılanın aksine, yazılımda kalite bir yazılımda olmazsa olmazlardandır. Eğer geliştireceğiniz yazılım kalitesiz olacaksa, hiç geliştirmeyin daha iyi, daha az hasarla atlatırsınız.

Bazen pazarı yakalayabilmek için uygulamanızı canlıya hatalar (bug) ve eksik özelliklerle (dikkat! hatalı çalışan özelliklerle değil, eksik özelliklerle) çıkmak zorunda kalabilirsiniz. Hatalar bir yere kadar tahammül edilebilir. Eksik özellikler ise kalitesiz yazılım ürettiğiniz anlamına gelmez. Bu, tekrarlamalı (iterative) proje geliştirdiğiniz anlamına gelir.

Agile Manifesto, belirttiği değerler içinde yazılımın kalitesinden pek bahsetmez. "Çalışan yazılım"ın önemine parmak basar. "Çalışan yazılım, kapsamlı belgeleme ve dökümantasyondan daha değerlidir" der. Aslında kaliteye ucundan da olsa Agile Manifestonun 12 prensibinde değinilir. Prensiplerinden birinde, "teknik mükemmeliyet ve iyi tasarım konusundaki sürekli özen çevikliği artırır" diye belirtilir. Yazılımın teknik altyapı ve tasarımın iyi olmasının faydasından bahseder.

Agile Manifesto'nun yazılım kalitesine doğrudan değinmediğini farkeden ve çalışan yazılımdan ziyade kaliteli yazılıma değer verenler, "Yazılım Ustalığı Manifestosu"nu yayınlamışlar. Bu bildiride "sadece çalışan yazılıma değil, ustaca üretilmiş yazılıma da değer veriyoruz" diye belirtmişler ve "ustaca üretilmiş yazılımı vazgeçilmez bir değer" olarak görmüşler. Yazılım Ustalığı kavramı ve extreme programming'in bizlere önerdiği pratikler ve kavramlar, bizlere ne yapmamız gerektiği konusunda ipuçları verir. Agile kültürün oturabilmesi için bu önerileri iyi değerlendirmek gerekir.

Kaliteli yazılım geliştirmek için gerekli olan birkaç süreci, disiplini ve pratiği şöyle sıralayabiliriz. Önce süreç ve ortamlardan başlayalım.
  • Takım çalışması. Güvene dayalı işbirliği ve yardımlaşma kültürünün inşa edilmiş olması
  • Usta-Çırak İlişkisi. Deneyimsiz yazılımcıların model olarak belirleyebileceği deneyimli yazılımcılar ile beraber çalışması
  • Hizmet eden lider. Çalışanları sorun olarak gören değil, onların sorunlarını çözmeye odaklanmış yöneticiler
  • Bölünmeden çalışma. Yazılımcıların bölünmeden çalışabilecekleri ortam ve zaman dilimi
  • Basit araçlar. Yazılımın geliştirilirken gözlemlenebilmesi ve denetlenebilmesi için türlü türlü "tracking" aracı ve yazılımı kullanmak yerine takımın olabildiğince şeffaf olabilecekleri oldukça basit araç ve süreçler
  • Bitti Kavramı. "Bitti" kavramının (Definition of Done) içinin takımca doldurulmuş olması ve buna herkesin disiplinli bir şekilde uyması
  • Sürekli İyileştirme. Takımda sürekli iyileştirme kültürünün oluşmuş olması, yapılan hatalardan ders çıkarma ve sorunları düzeltme içgüdüsünün yerleşmesi
  • Aynı mekanda çalışma. Takım elemanlarının birbirine yakın, mümkünse aynı oda yada mekanda çalışıyor olması
  • Günlük Ayakta Senkronize Toplantıları. Takım elemanlarının birbirleri ile hergün düzenli olarak yapılan iş üzerinde senkronize olması
  • İç eğitimler. Takım ve şirket içerisinde bilginin paylaşılması için çalışanların iç eğitimler ve toplantılar düzenlemesi
Şimdi gereken yazılım pratikleri ve disiplinlerini sıralayalım.
  • TDD/BDD. Daha kaliteli tasarlamak, daha esnek ve geliştirmeye açık kod yazabilmek için Test güdümlü programlama (Test Driven Development) ve davranış güdümlü programlama (Behavior Driven Development) ile yazılım geliştirmek
  • Test edilebilir kod. Mutlaka ama mutlaka test yazmak, test edilebilir kod geliştirmek
  • Çok katmanlı test. Birçok katmanda test etmek (unit, integration, functional, acceptance, regression, smoke, uat gibi) 
  • Kod gözden geçirme (code review). Gün içerisinde yarattığımız belge ve kodun mutlaka başkaları tarafından gözden geçirilmesi
  • Refaktör etmek (refactoring). Kodun mutlaka ama mutlaka yazan tarafından refaktör edilmiş olması
  • Temiz kod (clean code). Yazılan kodun okunaklı ve temiz olması
  • Sürekli entegrasyon (continuous integration). Kodun anında test edilerek hataların bulunması
  • Sürekli dağıtım (continuous delivery). Projenin yayınlanma süreçlerinde, otomatik çalışan testler (automatized tests), sürekli entegrasyon (continuous integration) ve sürekli yayınlama (continuous deployment) ile ciddi bir basitleştirmeye gitmek ve yeni gereksinimlerin müşteri ile buluşmasını çabuklaştırmak
  • Kısa aralıklarla sürüm çıkmak (frequent releases). Her geliştirme başka geliştirmeler ile etkileşim halindedir. Bir seferde ne kadar az sayıda geliştirmeyi canlıya çıkarsanız, o kadar hata riskini azaltmış olursunuz.  Bunu başarabilmek için de sık aralıklarla sürüm çıkmak ve mümkün olduğu kadar sürekli dağıtım süreçlerini oturtmak
  • Versiyonlama (versioning) ve dallar (branching). Kod versiyonlama sistemi kullanmak ve mümkün olduğu kadar çok özellik için versiyon dalları (feature branch) yaratmak 
  • Kod analizi (code analysis). Kodunuzu, kod kalitesini analiz eden Sonar tarzı uygulamalar ile, ya da PMD, FindBugs ve CheckStyle gibi araçlarla analiz etmek, çıkan hata ve uyarıları mümkün olduğu kadar çözmek
  • Yeteri kadar belgeleme (agile documentation). Detaylı belgeleme yapmaktan ziyade yeteri kadar belgeleme (agile documentation) yapmak
  • Çoklu sunucu ortamları (enterprise environments). Canlı ortamından başka, entegrasyon, performans ve kullanıcı kabul testlerinin yapılabileceği (test, qa ve staging gibi) başka ortamlar sağlamak 
  • Eşli programlama (pair programming). Eşli programlama (pair programming) ile yazılım geliştirmek ve geliştirilen yazılımı mümkün olduğu kadar sık takım elemanları ile paylaşmak
  • Düzenli demo (review with customer). Geliştirilen yazılımı düzenli aralıklarla müşteriye göstermek, ondan olabildiği kadar hızlı geribildirim almak
  • Yinelemeli geliştirme (iterative development). Yazılım bitmeden gereksinimler değişebilir. İşin doğasında bu var. Değişken gereksinimlerden projemizin gidişatının sekteye uğramaması için kısa döngüler (iteration) ile yazılım geliştirmek  
  • Kısa ön-tasarımlar (short up-front designs). Projenin başında büyük çaplı tasarım çalışması yapmak yerine, gerekli zamanlarda kısa süreli tasarımlar yapmak (up-front design)
  • Sürdürülebilir tempo (sustainable pace). Yazılım zihin işidir. Zihni yorgun yazılımcıdan verim beklemek anlamsız olur. Fazla mesai zaman zaman gerekse de, fazla mesainin bir istisna olarak algılanması ve iş dışı zamanlarda iş ile uğraşılmaması
  • Hatarı test ederek çözümlemek (reproduce bugs in tests before fix). Bir hata bulunduğunda, yazılmış testlerle hata yeniden yaratılmalı ve yapılan düzeltmenin (fix) yine yazılan testlerle onaylanması 
  • Kod kataları (code katas). Nasıl ki iyi bir kareteci olabilmek için tekrar tekrar aynı hareketlerin denenmesi gerekiyorsa (kata), iyi yazılımcı olabilmek için de düzenli olarak pratik yapmak gerekli. Düzenli aralıklarla yazılım pratikleri (coding kata) yapmak 
Yazılımda kaliteye ulaşmak uzun ve zorlu bir yol. Yeteri kadar sabırlı, disiplinli ve tecrübeli takım ve şirketler başarıya ulaşacaktır.

Bu yazı, yayınlandığından bu yana 3 kez güncellenmiştir.
#1 Yazı bitiş paragrafı yenilendi
#2 Pratikler ve disiplinler listesindeki her bir maddeye bir başlık eklendi
#3 Pratiklere sürekli dağıtım ve kısa aralıklarla sürüm çıkmak eklendi 

2 yorum:

  1. Cok guzel ozetlemissin Lemi, eline saglik.

    YanıtlaSil
  2. Böyle güzel Türkçe kaynak bulmak gerçekten zor. Elinize sağlık.

    YanıtlaSil

Template developed by Confluent Forms LLC; more resources at BlogXpertise