Fuck Test Driven Development

Habitat ya da Ekosistem

Yazılarımda tarih, sosyoloji ya da psikoloji gibi konulardan oldukça yardım almaya çalışırım. Yazılım yani teknoloji dünyasında olsak da AI henüz herşeyi ele geçirmediği için hala insanlarla çalışıyoruz. Kod yazan, teknoloji ile uğraşan insanlar da tarih, sosyoloji ya da psikoloji gibi çevresel faktörlerden etkilenir ve onlara göre biçimlenir. Bu nedenle herşeyi teknoloji veya yazılım metodolojileri ile açıklayamayız. Bu bağlamda oldukça sapıkça bulduğum bazı durumlardan bahsederek TDD dinini ya da tarikatını hedef alacağım. Ek olarak, sosyolojik değerlendirmelerimin neredeyse her konu için geçerli olduğu inancındayım.

Sorumsuzluk

İnsanlar üzerinde gözlem yapmayı oldukça severim. Biraz eğlenceli, çokca öğretici bulurum. Bana göre insanlığın en büyük zehiri ya da uyuşturucusu eroin değil; yönetilmeye, itaat ve iman etmeye olan düşkünlüğüdür. Evet, insanoğlu birilerine ya da birşeylere itaat, iman etmeye bir uyuşturucudan daha fazla bağımlıdır. Koşulsuz, sorgusuz olarak birine itaat ve iman ‘ın altında aslında çok basit bir neden yatmaktadır. “Sorumsuzluk”

Sorumsuzluk her seviye ve her disiplindeki insanlar için en büyük uyuşturucu ya da kaçış yoludur. İnsanoğlu gururundan kabul edemez ancak bir şeylere koşulsuz itaat ve iman etmenin getirdiği sorumsuzluk ve vicdan rahatlaması kadar özgürleştirici bir ilaç henüz icat edilmemiştir.

Biraz geriye yaslanıp düşünelim. Bir şirkette çalışırken yaptığınız işlerden tam sorumlu olarak sürekli hesap verebilir olmak mı, yoksa müdür X bana bir görev verdi, senior Y de bu görevi böyle kodlayacaksın dedi, bende amirlerimin tüm talimatlarına uyarak görevi tamamladım demek mi daha kolay?

Başarılı sonuçlarda çalışanların 99%’u amirlerim bana böyle dediler ben de öyle yaptım başarı onların, benim değil demez. Ancak başarısız veya problemli sonuçlarda çalışanların 101%’i kesinlikle amirlerim böyle istedi bende yaptım, sorumluluk onların derler. Evet, bu yazıyı okuyan güzel kardeşim sen de böylesin.

Ben bilmem beyim bilir… “Amirlerim istedi, tarif etti ben de yaptım” daki sorumsuzluğu, rahatlığı hissettiniz mi? O gergin zamanlarda ortamdaki alev topunu başkasınun kucağına atabilmenin verdiği hazzı bence hepimiz hissettik.  Dinlerdeki mesih, mehdi, aziz, evliya gibi kurtarıcı figürleri birilerinin sorumluluk almaya, görevlerini yerine getirmeye cesareti ve sabrı olmadığı için var.

Sorumsuzluk bir din olsaydı, dünyada en çok inananı olan din olurdu.

Alper Akalın

Bir şeyler yapıyorsun, bir şeyler kodluyorsun, başarısız olduğunda sen değil başkası sorumlu oluyor, o başkası cezalandırılıyor. Harika bir döngü değil mi? En basitinden hani kod yazmayıp mail yazıyoruz ya da mail atmaktan kod yazamıyoruz diyoruz ya; o maillerin bir çoğu kimse bu işi ben yaparım demeye cesaret edemediğinden, yani sorumluluk alamadığından/almadığından top sektirmek için atılıyor.

Zehir

Yaklaşık 23 yıllık profesyonel tecrübem var. Yani 23 yıldır şu veya bu şekilde Yazılım veya IT işleri üzeriden para kazanıyorum. En kötü patron firmalarında, en heyecanlı startuplarda, en şatafatlı kurumsal firmalarda çalıştım. Yani sektörde hemen hemen her seviyede biraz zehirlenmişliğim, her seviyede biraz acı tecrübem var.  Yazılım dünyasında onca acının arasında iki tane ölümcül zehir gördüm.

1. Root sorunu ve sorumluyu çözmek yerine günü kurtarmak.
2. Koda, kod kalitesine değil metodolojiye inanmak.

Test Driven Development İnancı

Eğer TDD bir din olsaydı, Kent Beck peygamberi, Extreme Programming kutsal kitabı, en büyük havarisi ise Martin Fowler olurdu.

Alper Akalın

Bu abiler benim de saygı duyduğum büyüklerimdir ancak ben bunların bir inananı, koşulsuz takipçisi değilim. Peki TDD’yi neden bir tarikat bir din olarak tanımladım. Din ve tarikatların en temel ortak özelliği sorgulanamaz ve haklarında kötü konuşulamaz olmalarıdır. Dogmatikdirler, kesindirler, herşeyin üstündedirler. Gelin TDD’yi google ve ChatGPT üzerinden sorgulayalım. Google ve  ChatGPT’ye aynı soruları soralım.

Not: Ben bu soruları Opera browser, private tab ve VPN üzerinden sordum. Yani mümkün olduğunca temiz bir browser background’u ile sorgulama yapmaya çalıştım ki sonuçlar benim browser geçmişimden etkilemesin.

• What is the cost of Test Driven Development?
• What are the disadvantages of Test Driven Development?
• Test Driven Development costs?
• Test Driven Development disadvantages?

Sonuçlardan göreceğiniz üzere Google ve ChatGPT TDD için olumsuz yanıt dönmekten imtina ediyor. Olumsuz bir şey söyleyecekse bile TDD’nin iyi yönlerinin yanında şöyle bir kötü yanı var diyerek. Kötü yanları gizlenmeye ya da küçük gösterilmeye çalışılmaktadır….

Test Driven Development, Gerçek Maaliyetler

Şahsen bu konuda yapılmış gerçekci bir araştırma görmedim.  Birkaç makalede development süresine 13-30% arasında ek yük getirdiğini söylenmektedir. Böyle aralıklı değerlenedirmelerde genelde en kötü senaryoyu tercih ederim, yani 30%. Ancak TDD için bu ek maaliyetin çok üzerinde hatta 50%’nin üzerinde olduğu inancındayım. Bu duruma bir göz atalım. TDD’nin ne olduğuna hiç girmeyeceğim ancak döngüsü üzerinden biraz konuşalım.

Bir proje içerisindeki test edilecek sınıflar/fonksiyonlar belirlenir ve bunlar için atomik birim testleri yazılır.

• Fonksiyon birim testi geçerse fonksiyon başarılı sayılır.
• Fonksiyon birim testi geçemezse, problem – bug – hata çözülür ve tekrar test edilir.
• TDD döngüsünde problem – bug – hata çözümüne “Refactoring deyip kutsallaştırıyorlar. Aldanmayın!
  • TDD’li ya da TDD’siz bulunan hataların çözümü ile refactoring kesinlikle aynı şeyler değildir. Bug çözmek Refactoring ise ben bunca yıldır olayları çok yanlış anlamışım demektir.

Yazılım dünyasında bazı kutsallar var ise Refactoring kesinlikle en önemli kutsal’ların başında gelir.

Alper Akalın

Sorular

1. TDD uygulanmış bir projede bug çıkmaz mı? Çıkarsa ne olur?
2. TDD uygulanmış bir projede bug çıkması saçma değil mi?
3. TDD uygulanmış bir projede nasıl bug çıkar?
4. TDD uygulanmış bir projede UAT testlerinde çıkan bug’ları nasıl yakalar, nasıl çözeriz?
5. TDD uygulanmış bir projede son kullanıcının bug’lar ile karşılaşması normal mi?
6. TDD uygulanmış bir projede son kullanıcının karşılaştığı bug’ları nasıl yakalar, nasıl çözeriz?

Bu tip soruları olduça çoğaltabilir, uzatabiliriz. Ancak TDD’nin bunlara cevap verdiğini göremeyiz. Çünkü TDD ideal yani labaratuar şartlari için koşullandırılmış bir metodolojidir. Bir fonksiyonun alabileceği parametreler, yapacağı hesaplamalar bellidir, dönüş değerleri önceden tahmin edilmiştir. Bu durumda yazılacak testler sadece ideal koşulları karşılamaz mı? Ancak user ya da tester’ın beklenmeyen bir hareketi ile karşılaşınca TDD uygulanmış birçok fonksiyon bekleneni vermez ya da hata verir.

Hepimizin lise kimya dersinden bildiği üzere normal koşullar ile ideal koşullar aynı şeyler değildir. Örneğin bir araba üreticisi T modelimiz 100 km de 5lt yakar demesi kesin bir bilgi değildir.  O üretici kendine göre ideal şartlar oluşturmuş ve 90 km/s ile bu testi yapmıştır. Siz 90 km/s ile gitseniz bile farklı koşullarda olacağınızdan üreticiden farklı sonuçlar alırsınız. Hatta sizin tekrarlı testlerde aldığınız sonuçlar bile farklılık gösterecektir. Yani ideal koşullar ile normal koşullar – gerçek hayat aynı şeyler değildir. Bu durumda ideal olmayan şartlarda TDD sanki işlev kaybına uğradı gibi gibi.

Çok karmaşık ya da çok uzun örnekler verilebilir ancak herhangi bir ürünü sorguladığımız basit bir UI –> API Backend –> Database akışını ele alalım. Herhangi bir sebeple ürünlere squential id atadığımızı ve sorgulamayı bu id üzerinden yaptığımızı düşünelim. Kullanılan teknoloji dağılımı da aşağıdaki gibi olsun.

1. UI –> JavaScript
2. API Backend 1 –> JavaScript
3. API Backend 2 –> Java
4. DataBase –> MongoDB

Sorgulama Akışı –> –> UI  –> API Backend 1  –>  API Backend 2  –>  Database şeklinde olsun.

• JavaScript ise typesafe bir dil değildir. Verinin tipine bakmadan işlem yapmaya çalışır.
• Java typesafe bir dildir. Veri tipine göre işlem yapar.
• MongoDB NoSQL bir db’dir. Sequential bir ID’yi number yani numeric olarak tanımlasak bile birçok durumda tip kontrolü yapmayabilir. Yani yazılımcı type’lar konusunda bazı aksiyonlar almalıdır.

Test Türleri

1. Birim Testler
2. Entegrasyon Testleri – INT
3. Kullanıcı Kabul Testleri – UAT
4. Gerçek Kullanıcı Deneyimi – Ultimate or Real Tests

Unit Test’in 50 Tonu – Fifty Shades of Unit Tests

Ürün sorgulama akışını sıralayalım.

1. UI’da bir form yaratılır ve kullanıcı buraya ürün id’sini girerek sorgulama yapar.
   1. Bu sorgulama için bir ya da birkaç fonksiyon yaratılır.
2. Backend 1, UI’dan gelen isteği işler, düzenler Backend 2’ ye gider.
   1. Bu isteği işleyen bir ya da birkaç fonksiyon yaratılır.
3. Backend 2, Backend 1’den gelen isteği işler, düzenlerDB’ ye gider.
   1. Bu isteği işleyen bir ya da birkaç fonksiyon yaratılır.
4. DB kendisine gelen sorguya cevap verir.

Sorgulama akış testini sıralayalım.

Not: Aşağıdaki testler birim test olduğundan birbirinden tam bağımsız yazılmalı ve işletilebilmelidir.

1. UI, formdaki alanları validate eden bir unit test yazılır.
   1. Bu test ile alanların null ya da tip kontrolü yapılabilir.
2. Backend, ui’daki requesti karşılayan fonksiyon için bir ya da birkaç unit test yazılır.
   1. Bu testlerde tip, null kontrolü yapılabilir.
3. DB, db deki alanların kontrolleri için ayrıca unit testler yazılabilir.
   1. Bu testlerde alanların gönderilen verilere nasıl tepki verdiği test edilebilir.

Bu testlerin tamamı birbirinden bağımsız testlerdir. UI –> Backend 1  –> Backend 2–> DB arasındaki entegrasyon testleri yazılmalıdır. Bu cümleme ileride geleceğim “yorum yazmam, log koymam, debug yapmam” diyen delikanlılara, TDD sevdalılarına gelsin. İdeal bir TDD için test/kod yazma oranı 1’e 3, 1’e 4 gibi uçuk rakamalara çıkabilmektedir. 1 satır kod yazıp 3 satır kod ile 0 bug ile çalışabileceğime emin olsam yeminle TDD’nin en büyük sevdalısı ben olurdum.

Gelelim Unit Test’in 50 Tonuna; bu id alanı için yazılan testlerde olabilecekler…

• Null kontrol
• Numerik kontrol
• Alfa Numeric kontrol
• Length kontrol

UI

JavaScript ile yazıldığından bu kontrollerin tamamını manuel olarak hazırlamamız ve test etmemiz gerekir. Bir kısmını unuttuk vs diyemeyiz.  1 alan –> 4 validasyon, 4 unit test gibi düşünebiliriz.

Backends

UI, backend’e bir REST isteği ile ulaşacağından her API için 1 alan –> 1 json parser, 4 validasyon, 5 unit test gibi düşünebiliriz.

DB

1 alan –>  4 unit test

Bu kontrollerin tamamı bir unit test içerisinde de olabilir, birden fazla test de yazılabilir TDD’yi uygulayan SRP – Single Responsibility Principle uygulamazsa ayıp olur diyerek, TDD sevdalılarının birden fazla test yazacağına yürekten inanmak istiyorum. 😊

The Fuck Up

İdeal şartlar altında TDD yi bir harikalar diyarı olarak adlandırabilirsiniz. Ancak ideal şartlarda yaşamıyoruz. Aşağıdaki gibi bir dizi sorunla karşılaştığımızda TDD’nin davranışları çok önemlidir. Yukarıdaki kontrollerden bir tanesi unutulduğunda uçtan uca birçok şey değişecektir. Gelin biz hiç beklenmeyeni tartışalım.

Tüm kontroller yapılmıştır ve tüm testler başarılıdır. Ancak JavaScript ve Web Browserlar “data integrity” konusunda daima güvenilmez olmuşlardır.

• Browser’daki bir hata anında kullanıcı ürün sorgulama alanına numeric olmayan bir karakter girerek bir sorgulama başlatabilir.
• Kötü niyetli bir arkadaş API’ye bir hook atıp ürün sorgusuna beklenmeyen bir karakter ekleyebilir.
• UI ve API’ler farklı developerlar tarafından geliştirildiğinden yukarıdaki kontollerden bazıları tüm projede olmayabilir.

API-1 de numeric – alfanumeric kontroller unutulmuş ve test edilmemiş UI’dan da bir şekilde hatalı id gelseydi siz ya da TDD ne yapardınız?

• API-1 JavaScript olduğundan typesafe değildir ve gelen isteği kendince işleyip API-2 ye iletecektir.
• API-2 de error hanling’te bilerek ya da kodlamada garip bir şekilde tip kontrolünde hata yaptıysak, istek DB’ye yönlendirilecektir.
• DB’ye gelen istek bir select olduğunda DB böyle bir ürün bulunamadı diye dönecektir.

Böyle bir akışta hiçbir yerde error, hata vs olmadığından kullanıcıya ürün yok bilgisi dönülecektir. Göksel varlıkların da yardımıyla bu istek bir şekilde tekrar ederse ya da farklı şekillerde akış hatalı işlerse kullanıcı ürünü sürekli bulamayacaktır. Buradaki en ölümcül problem user’ın başka bir API olmasıdır. O API geçerli bir sonuç buluncaya kadar bizim API’mize istek göndermeye devam ederse sonsuz bir döngüye girmez miydik? Bu durumda TDD ne yapardı?

Böylesine beklenmeyen durumlarda API dolayısı ileTDD felç olurdu. Eğer TDD bir insan olsaydı ölü balık numarası yapardı. Çünkü yapacağı hiçbirşey yok. Proje bileşenlerinin tüm geliştiricileri kendi taraflarında tüm birim testleri yazdıklarını ve böyle birşeyle karşılaşmadıklarını söyleyecektir. Yani klasik benim makinamda çalışıyor sendromuna gireceklerdir. TDD sonuçları tartışmalı hale gelecektir. Bu akışta error vs olmadığından hataya dair bir iz bir gölge olmayacağından bu probleme yönelik yeni bir test senaryosu da geliştirilemeyecektir. Ee TDD’nin o ilahi, o göksel gücüne ne oldu şimdi?

The Real Heroes – Debug and Logs

Bu durumda yapılacak tek şey proje tester’larının ya da projedeki tüm developerların bir araya gelerek aynı senaryoyu tekrar etmeleri ve tekrar ederken projeyi uçtan uca debug etmek  ve göze çarpan yerlere geçici log yazmak olacaktır. Debug sevmeyenlere, öldü diyenlere söylüyorum; sizin cenazenizi debug kaldırır.

Eğer gerçek bir fuck up tan bahsedeceksek, kesinlikle bu hatalı senaryonun tekrar edilmesidir. Tecrübeliler ya da büyük projelerde uzun zaman harcayanlar bilir. Kullanıcının karşılaştığı hataları tekrarlamak yani aynı hatayı yakalamak çoğu zaman hata çözümünden çok çok daha zordur.

Bu öngörülemeyen hataları yakalamanın en iyi yöntemi çılgınca test yazmak ya da tekrar tekrar test etmek değildir. Düzgün error handling ve loglama yapmaktır. Bu sayede hatayı olduğu anda olduğu yerde yakalamış, belgelemiş olursunuz.

Çalıştığım birçok developer’a loglamayı tavsiye ettiğimde bana şeytan görmüşcesine bakıyorlar. Onlara göre loglama gereksiz bir amelasyon kodlamadır. Programalama dili ya da uygulama sunucusu yeterince loglama yaptığından developer’ın yapmasına gerek yoktur. “At yalanı, seveyim inananı”. Bu tip yobaz developerlar TDD, Agile Development gibi dinler çıktıktan çıktıktan sonra oldukça yaygınlaştı.

Aşağıda bir anımı anlatacağım. Bu anı ile birlikte ne kendimi övme ne de firmayı kötüleme gibi bir amacım yok. Projenin büyüklüğünü anlatarak böylesine büyük ekiplerde dahi küçük hataların nasıl büyük ve çözülemez sorunlar yarattığına işaret etmeye çalışacağım.

7-8 yıl önce Avrupa merkezli Avrupanın en en en büyük ödeme alt sistemi üreticilerinin bir tanesinin TR deki arge ofisinde çalışıyordum. Oldukça kısa bir çalışma oldu. Birbirimizi aşırı sevemedik, ben hemen kaçtım. Firmada ana ödeme alt yapısı yaklaşık 200K kod içeriyor. Ancak düzgün bir mimari ile yönetilemediğinden bankalara göre özelleştirme yapılarak her banka için code base duplicate edilmiş. Ben oradayken kod satırı 800K idi. Yani sadece firma büyük değil, kod repoları da oldukça büyük. İlk başladığımda bana ısınma turu olarak yaklaşık 200K kodu olan başka bir projenin direktörlüğünü verdiler.

Yeni bir iş’e başladığımda ilk 3-4 ay ortamı izler ve dinlerim. Her şeye atlamam, karışmam.  Ben başlamadan önce benim sorumlu olacağım uygulamada bir hata alınmış ve ekipteki arkadaşlarım bu konuyu çözmeye çalışıyorlarmış. Başladığım günde ekip arkadaşlarım beyaz tahta önünde bir şekil üzerinde ilgili hatayı tartışıyorlardı. 45-50 gün sonra ekip belli bir iletişimi yakaladığımızı düşünerek abi “böyle böyle bir sorun var defalarca test ve debug ettik, ancak müşterinin hata aldığı senaryoyu tekrarlayamadığımız için hatayı bulamıyoruz ve çözemiyoruz.” dediler. Arkadaşlara hata alınan fonksiyonun yaptığı işlemler ve olası senaryolar ile ilgili bazı sorular sordum ve aldığım cevaplara ben de ikna oldum, 😊 fonksiyonda bir hata görünmüyordu.

Sonunda, o beni şeytanlaştıran soruyu sordum. Bu hata ile ilgili elimizde bir log var mı? Aşağılayıcı bir bakıştan sonra tabiki yok dendi. Oldukça alt perdeden nazik rica ile fonksiyonun çağrıldığı yere, girişine ve dönüşüne basit bir log koyup akışı takip edersek güzel olur, console log bile olur dedim. Yanlış hatırlamıyorsam, ekip çaresiz kaldığı için sabah 11:30 gibi logları koydu. Öğle arası kod proda alındı. Öğlen yemeğinden sonra 13:30-14:00 arası hatanın bizim API ve fonksiyondan kaynaklanmadığı loglar sayesinde loglar ile birlikte görüldü, ispatlandı.

Siz bu API’yi kullanan dış uygulamalardan bir tanesi olsanız ve ben size yaklaşık 60 gün sonra hata biz de değil sizdeymiş desem ne dersiniz. Ben olsam nasıl küfür edeceğimi şaşırırım. Hatanın bizde olduğunu bulmanız 60 gün sürdü birde hata sizde olsaydı sanırım 360 gün sürecekti diye başlarım ve iltifatlarımın sonu baya karanlık olurdu.

Tersten bakalım, siz o şirketin sahibi ya da yöneticisisiniz. Projelerinizden birinde 60 gündür çözülemeyen bir problem var ve ekibiniz daha problemin ne olduğunu bile saptayamamış durumda. Müşterileriniz ya da üst yöneticileriniz ensenizde boza pişiriyor. Ekibe yeni biri geliyor. 3-4 satır console log basın bir bakalım diyor. Ekibiniz gönülsüzce log basıyor, 3-4 saat içerisinde hatanın sizin API’nizden değil de ortak iş yürüttüğünüz diğer firmanın API’lerinden kaynaklı olduğu ortaya çıkıyor. Bu durumda aşağıdakilerin hangisine üzülür/sinirlenirsiniz.

• 1440 saatte bulunamamış hatanın 4 saate bulunmasına mı? (24*60=1440)
• 1440 saatir müşteri ve diğer proje paydaşlarının ensenizde boza pişirmesine mi?
• 1440 saat sonra hatanın sizde olmadığını anlayıp bir sürü ağız kokusu çekmek zorunda kalmış olmanıza mı?

Çok çalışmak değil verimli çalışmak elzemdir. 4 satır kod 1440 saatin emeğini 4 saatte yiyebiliyormuş, yenebiliyormuş.

TDD Yeniden

Fonksiyonun çalıştığı API istanbulda çok aktif bir trafik tahsilat sistemini yöneten 5 farklı platformdan sadece bir tanesi idi. Yani ilgili trafik tahsilatını yapmak için 5 kurum entegre ve senkronize uygulamalar ile ödeme işlemleri gerçekleştiriyordu.  Kısa bir beyin fırtınası yapalım.

1. Beş farklı platformun entegre çalıştığı bir senaryonda birim testlerin ne kadar önemi olabilir?
2. Entegrasyon ve UAT testleri titizlik ile yapılmamış ise kullanılan yazılım metodolojisi Agile olmuş Waterfall olmuş farkeder mi?
3. Entegrasyon ve UAT testleri titizlik ile yapılmamış ise kullanılan dilin, design pattern’lerin bir önemi olabilir mi?
4. * Prod’ta karşılaşılan hataların bulunması bile haftalarca sürecekse yukarıdaki 3 maddeyi eksiksiz yapmanın ne yararı var.

Gelelim en ölümcül soruya: Bir projede TDD ile ideal şartları denetledik, test ettik. Projeyi proda aldık ve çalışıyor. Ancak oluşan basit ve karmaşık hataları yakalayacak, yönetecek herhangi bir mekanizma kurmadık. Uygulama ya da API çok farklı kullanıcı ya da platformlardan çok değişik şekillerde çağrılıyor. Oluşan hataları nasıl yöneteceksiniz? Yönetemeyecekseniz ya da sizin için önemli değil ise neden TDD gibi kutsallaştırılmış metodolojilere yatırım yaptınız?

Fuck TDD, Sonuç

Atomik olarak TDD’nin önerdiği paradigmaya çok bir itirazım yok. Ancak makro olarak TDD’nin teolojik bir yapıya bürünerek diğer herşeyin üzerindeymişcesine sunulmasına, kusursuz göksel bir varlık gibi davranılmasına karşıyım. Bir zamanalar Agile Metodolojiler ve Microservisler de aşırı kutsal varlıklardı. Yukarıdaki son örnekte olduğu gibi tekrar edilemeyen bir senaryoda TDD ya da herhangi bir teyyareden metodoloji felç olur. Ve bir yazılımcının büyük bir projede karşılaşacağı hataların en az 15-20% si böyledir.

Bu hataları şirin TDD söylemleri ile yakalayamazsınız. Bunun için ayrı testler hatta ayrı test ekipleri bile ayarlasanız bu hataları bulma ihtimaliniz, o senaryoyu tekrarlama ihtimaliniz çok düşüktür. Hele ki günümüz mikroservis çılgınlığında imkansızdır. Elinizde binlerce servis var hepsi birbirini çağırıyor, biri hepsini çağırıyor, hepsi birini çağırıyor, sütçü, tüpçü, simitçi derken “servis” çocuk en son postacı ‘da patlar sanki…

Örneğin biz bir cloud platform geliştirdik. Core da 30 dan fazla docker içirisinde “microservis”, “miniservis” değil “midiservis” mimarisinde 1000 kadar endpoint yani servisimiz var.  Herhangi bir noktada bir servis hata aldı ise hatanın önemine göre anında alert üretilir ya da sadece loglanır. Herhangi bir hata olduğunda hata nasıl oldu diye sormayız. Direk akışa bakar, hatanın oluş anını, fonksiyonunu ve nedeni anıdan görürüz. Not: Bunu javascript/nodejs içerisinde 0 performans kaybı ile yapıyoruz. Bazıları anladı sanırım.

Simple is the best

İyi tasarlanmış bir API, hata ayıklama ve loglama ile aşırı şişirilmiş metodolojilere ihtiyacımız yok. Hep şöyle denir “küçük projelerde TDD gerekli değil ama büyük projelerde kesinlikle gereklidir”. Gerçekten öyle mi? Ben tam tersi olduğunu düşünüyorum.

• TDD ile gereksiz kod ve test tekrarı maaliyetine katlanmak mı daha akıllıcadır?
• Doğru kurgulanmış error handling ve log mekanizmasına katlanmak mı daha akıllıcadır?

Buradaki en kritik noktalardan bir tanesi TDD’nin maintenance ‘i. Körü körüne bir iman eden değilseniz; TDD bakım, güncellme ve yeni eklemeleri yaparken karşınıza çılgın bir tablo çıkıyor. TDD çıktıları bu maaliyetlere katlanmak için yeterli mi değil mi iyi düşünmek lazım. TDD yerine yazılım geliştirme ve izleme süreçlerini efektif planlamak inanın mucizeler yaratabilir.

O zaman long live LOG DRIVEN DEVELOPMENT diyoruz.

Next episode de gerçek log driven development nedir ne yapar ne yapmaz detaylıca inceleyelim. Birilerinin irite olacak kadar basit gördüğü bir yöntemin ne kadar hayat kurtarıcı olabileceğinden konuşalım.

Sevgiler,

Alper