Recep Karabıçak

Author: irecep

  • Birim testleri ne işe yarar?

    Birim testleri ne işe yarar?

    Kötü yazılmış bir kodun bizi nasıl yavaşlattığını anlatmama gerek yok sanırım. Ama şu sebepten ama bu sebepten hepimiz sonradan düzeltirim yalanına sığınarak özensiz kodlar yazdık. Dönüp düzeltme zamanı geldiğinde ise olanı bozmak korkusuyla öylece bıraktık. Ama bıldır yediğimiz hurmalar bizi durma noktasına getirdi.

    Bu kötü gidişatı durdurmanın, tersine çevirmenin yolu etrafı temizlemekten geçiyor. Peki bir şeyleri bozma korkusunu nasıl yeneceğiz? Üzerinde çalıştığımız sistemi uçtan uca test edebilseydik, bir şekilde yaptığımız her değişiklikten sonra sistemi bozmadığımızın geri bildirimini hızlıca alabilseydik? Onlarca else altına bir else de biz eklemez; gerekli düzeltmeleri yapar, mutfağı temiz bırakırdık. İyi bir test setinin varlığı bize kodu temiz ve kaliteli tutmak için gerekli olan güven ortamını veriyor. Ve nihayetinde kaliteyi arttırarak değişiklik yapmanın maliyetini kontrol altında tutmamızı sağlıyor.

    Geleneksel usülde testler, yazılım geliştirme bittikten sonra işi test olan insanlar tarafından yapılır. Bu yöntem kaliteyi denetleyen, ölçen bir yaklaşım. Biz ise kaliteyi ürüne yedirmek, onun bir parçası haline getirmek istiyoruz. Geliştirme sonrası, başkaları tarafından yapılan testlerin verdiği geri bildirim bizim amacımız için çok geç gelen bir geri bildirim. Bu aşamada çoktan bir şeyleri bozma korkusuna yenik düşmüş; bulunan her hatayı bir yama ile düzeltme eğiliminde olacağız.

    Bize lazım olan yazılım geliştirme döngüsünde çok daha erken koşabileceğimiz bir test türü – birim testleri. Birim testlerinin tanımına gelin Unit Testing Principles, Practices, and Patterns kitabından bakalım:

    Bir geliştiricinin, yaptığı geliştirmenin beklediği gibi çalıştığından emin olmak amacıyla yazdığı aşağıdaki özelliklere sahip test türüdür:

    • Otomatik çalıştırılabilir
    • Kodun küçük bir parçasını (birim olarak da bilinir) doğrular
    • Hızlı çalışır
    • İzole çalışır

    Bu tanımı irdelemeyi ileriye bırakıp, bu yazıyı testlerin önemi hakkında sevdiğim bir tespit ile bitireyim:

    Testleri kullanarak canlı koda ulaşmak kolaydır, ancak bunun tersi zor olacaktır. Bu durum testler hakkında bize şaşırtıcı bir şey söyler: Testler, bir sistemdeki en önemli bileşendir. Canlı koddan daha önemlidirler.

    — Robert C. Martin

  • Yazılım geliştirmenin zorlukları

    Yazılım geliştirmenin zorlukları

    Yazılım geliştirmek zor zanaat. Peki bu zorluğun kaynağı ne olabilir hiç düşündünüz mü? Bu soruya klasik kabul edilen “The Mythical Man-Month” kitabından cevap arayalım:

    Karmaşıklık

    Üzerinden çalıştığınız yazılımın bütün durum uzayını bir düşünün; düşünemediniz değil mi? İşte bu büyüklük onu kavramayı, açıklamayı ve test etmeyi zor hale getiriyor. Zaten karmaşık olan bu yapıyı büyütmek istediğimizde de mevcudun kopyalarını oluşturamıyor; sistemlerimize yepyeni elemanlar ekliyoruz yani durum uzayını büyütüyoruz. Sistem büyüdükçe anlaması anlatması daha da zor hale geliyor.

    Uyum

    Yazılımlarımızın çoğu zaman yapmak zorunda olduğu bir şey var kendinden önce gelenlere uyum sağlamak. Bunlar mevzuatlar olabilir, başka sistemlerin API’leri olabilir, iş yapış şekilleri olabilir. Yapacağımız hiçbir tasarım bizi uyum sağlamak zorluğundan kurtaramıyor. Bütün bunları anlamamız ve ilmek ilmek programlamamız gerekiyor.

    Değişkenlik

    Yazılımın en güçlü yanı – yazılı olması – aynı zamanda onun laneti sanırım. İnsanlar kolayca değişebilmesini bekliyor. Aynı durumu arabalar, makineler, telefonlar gibi üretilen şeylerde görmüyoruz. Yeni modellerinin çıkmasına ve eskinin atılıp yeni ile değiştirilmesine alışmışız.

    Bir yazılım için değişim kaçınılmaz:

    • İnsanlar bir yazılımı kullandıkça yeni şeyler düşünüp keşfediyorlar ve mevcudu geliştirmek istiyorlar
    • Başarılı olmuş yazılımların altyapı (işletim sistemi, donanım, mevzuatlar gibi) değişikliklerine ayak uydurmasını bekliyorlar

    Görünmezlik

    Bana yazılımın resmini çizebilir misin Abidin? Yazılım dediğimiz şeyin gerçek uzayda bir karşılığı yok ve onu kolayca resmetmek mümkün değil. Evet bin bir türlü diyagram seçeneğimiz var ama daha önce denediyseniz bunun ne kadar zor olduğunu bilirsiniz. Komponentleri, kontrol akışı, data akışı, bağımlılıkları, zaman davranışı, network topolojisi … Bu zorluk bütün bir sistemi bir kişinin kafasında tutmasını ve başkaları ile iletişiminin kurulmasını da zorlaştırıyor

  • Karmaşıklığın iki yüzü – Asli ve Arızi

    Karmaşıklığın iki yüzü – Asli ve Arızi

    Eminim çok kez başınıza gelmiştir; geliştirme yaparken, çözmeye çalıştığınız ana problem yerine bir anda kendinizi teknik sorunlarla boğuşur halde bulmak. IDE sorunları, network sorunları, yanlış konfigürasyonlar… Siz de benim gibi iseniz içinizden geçmiştir; ben elimdeki probleme odaklanmak yerine neden bunlarla uğraşıyorum.

    Fred Brooks 1975 tarihli “The Mythical Man-Month” kitabında yazılım geliştirmenin zorluklarını asli(essential) ve arızi(accidental) olarak ikiye ayırıyor. Asli zorluklar problemin özü ile ilgili ve çoğu zaman soyut şeyler: veri yapıları ve aralarındaki ilişkiler, algoritmalar. Problemi nasıl çözersek çözelim oradalar. Arızi zorluklar ise probleme ürettiğimiz çözümden – yani yazılımdan ve üretim süreçlerinden kaynaklı zorluklar. Aynı problemi farklı teknoloji çatıları ile çözebiliriz esas aynı kalacak; karşılaştığımız sorunlar farklılaşacaktır.

    Peki bu bilgi gerçek hayatta ne işimize yarayacak?

    • Brooks, yazısında arızi tarafta büyük gelişmelerin zaten yaşandığını ve artık buradaki iyileştirmelerin etkisinin kısıtlı olacağını söylüyor. Değer önerimizin hangi tarafa düştüğünü değerlendirerek kariyerimize yön verebiliriz. Bir .NET geliştiricisi olmak mı finans sitemlerinde uzman olmak mı daha değerli?
    • Modüler ve bağımsız bir sistem hepimizin isteği peki modül sınırlarını nasıl belirleyeceğiz? Alın size bir başlangıç kriteri: asli olanı arızi olandan ayırabilirsiniz. Örneğin bir kelime işlemci uygulamasında kelimeleri dosyadan okuduğunuz ve yazdığınız bir modül(arızi), kelimeler üzerinde işlem yaptığınız başka bir modül(asli), kelimeleri ekranda görselleştiren başka bir modül(arızi) olabilir.
    • Asli zorlukları aşmanın bir kısa yolu yok gibi görünüyor size sunulan sihirli değneklere mesafeli yaklaşın. Paydaşlarla o uzun konuşmalar yapılacak, isterler belirlenecek, sistemler tasarlanacak, demolar revizeler olacak …