Ekşi Duyuru

biz yazılım derslerinde kodları ve algoritmları A4'e yazardık. sınavda da hoca A4'lere puan verirdi. bir hata yaptın kod çalışmıyor diyelim. sıfır geçmiş olsun.

şimdi elimizde 1000 yazılımcı var ise gerçek dünyada bunların belki 50 tanesi sıfır hata ile kod yazabilecek sabır bilgi ve donanıma sahiptir.

gerçek hayatta programı run edelim hataları düzeltelim çoğu insan tarafından daha anlaşılır bir metot olarak kalıyor.

yani 1000 yazılımcıyı bu şekilde yönetebiliyorsun. bir hata çıktı istifanı ver desen adam bulamazsın.

diğer mühendislik branşlarında da 3-5 böyle özel sektör.

hatasız bir yazılım mümkün değil elbette ama minimuma indirmek için gerçek ortama geçmeden önce test etmen, ettirmen gerekiyor.

ondan da öte kod yazarken tdd'yi deneyebilirsin..

(bkz: devsecops) denilen nane bu sebepten dolayı ortaya çıktı tam olarak. %100 hatasız ve güvenli kod mümkün değil ama buna yaklaşman mümkün. Şu videoda 12:20'den itibaren anlatıyor kısaca: www.youtube.com

Bu arada ben sadece güvenlik olarak baz almışım, üründeki genel bug'lar için farklı yöntemler tabii ki vardır. Güvenli - güvensiz kod olayı çok daha büyük bir problem bug'lardansa. Çünkü bug hemen ortaya çıkıyor, ama güvensiz bir kod 3-4 sene sonra bile operasyonu alt üst edebilir. Asıl endişen bu olması lazım.

büyük ürünlerde hata çıkmaması mümkün değil. Ancak hataları production'a çıkmadan önce çözmek gerekir. dolayısıyla iş başlamadan önce kapsamlı bir analizi yazılmalı, tüm süreç bu analize uygun şekilde kodlanmadı. sonrasında test case'ler hazırlanmalı ve bir tester( yazan kişi test etmemeli) tüm bu case'leri test etmeli. Sonrasında ürün productiona hazır oluyor temelde.

oncelikle unit test yazmak onemli. cunku yazilimda cikan hatalarin cok buyuk kismi unit testler tarafindan tespit edilebilecek hatalar.

daha sonra integration testler onemli. cunku diger buyuk hata kumesi de integration testlerle tespit edilbilir.

tabi bu testlerin cok sık calismasi lazim o nedenle de ci/cd prosesleri cok onemli. testler lokalde calistigi gibi ayni zamanda integrasyon sirasinda farkli platformlarda da test edilmeli. ornegin git push yapar yapmaz bir docker container icinde test edilebilir. bunun icin bircok arac var ornegin travis, jenkins vs.

ci/cd prosesleri otomotize edilmeli ki. bunun icin cesitli codepipeline yontemleri var. ornegin aws code pipeline ya da github actions pipeline icin kullanilabilir.

ayrica code coverage tool kullanilmali ki testler tarafindan denetlenmemis hicbir kod satiri kalmasin.

code review ve test case review farkli deneyimlerdeki ve uzmanliktaki gelistiriciler tarafindan cok disiplinli yapilmali.

kodlar mumkun oldugunca stateless yazilmali. icinde state barindiran her kod hata olasiligini katlanarak arttirir. bircok alette state sifirlamak icin bir kapat/ac yapmamizin temel nedeni budur. o nedenle mumkun oldugunca stateless functional kod yazmak bizi rahatlatir.

tespit edilmesi en zor hatalar asenkron calisan kod bloklarinda olur. cunku bu kod bloklari arasinda bir bagimlilik var ise asenkron calisan kod bloklarindan birinde gerceklesen islem zamani gecikmesi digerlerini etkileyebilir. bu hatalar cok problemli hatalardir cunku "hersey" ayni olsa bile "bazen" bu hatalar gerceklesir. network hizinda dalgalanma veya islemci sicakligindaki degisim bile bu tarz hatalara neden olabilir.

tum bunlar sayesinde elbette sifir hata saglanmaz, cunku bir projede bircok farkli kutuphane, framework kullaniliyor ve bunlardaki hatalar da sizi etkileyebilir. ya da bunlarla olan entegrasyon sizi etkileyebilir ama cok buyuk oranda hatalari dusurmus olursunuz.

Hatasız kod olmaz +1.

Öte yandan ben testlerin kod kalitesini artırabileceğini düşünmüyorum. Kodunuzun ne kadar kaliteli olduğunu ölçebilir ya da hangi hataların varolduğunu gösterebilir, ama yeni hata çıkmasını engellemez. Test yapmak kodunuzun daha az bug üretmesini sağlamaz yani, sadece varolanları tespit etmenizi sağlar.

Kilo vermek istiyorsanız spor yapmanız ve az yemeniz lazım, tartılmak sadece sonucu gösterir, tartılarak kilo verilmez vs. Bunun gibi.

Neyse, bence hatayı minimuma indirmenin yolu kod karmaşıklığını minimuma indirmektir. Ne kadar güzel/sade bir mimariniz olur, ne kadar loosely coupled kod yazarsanız bug çıkma olasılığı o kadar düşer, çünkü bug'lar genelde developer'ın karmaşıklığın içinde kaybolmasından kaynaklanıyor benim gördüğüm.

Ha yine kodun kritik/karmaşık yerleri vardır, oraya unit test yazarsınız, her zaman çalıştığından emin olmak için e2e kurarsınız düzenli çalışır falan. Onlar ayrı. Ama "yeni bug" çıkma rate'ini düşürmek için mimarinizi ve mindset'inizi değiştirmeniz lazım.

Arada dikkatsizlikten de olabilir ama agile yapıyorsanız, günde 2-3 deploy çıkabiliyorsanız o hatalar zaten minik olur, çok bir şeyi bozmadan görüp düzeltebilirsiniz. Ayrıca external tester yerine developer'ın kodun düzgün çalışmasından sorumlu olduğu bir setting'in developer'ı daha iyi kod yazmaya teşvik ettiğini düşünüyorum.

Ben de bu test süreçleri ve aşırı analiz planlama ile hantallaşma yerine en hızlı şekilde yayına alıp kullanıcıların da bu sürekli gelişim döngüsünde rol almasının mümkün olmasını hayal ediyorum. Bazı yazılımlar hatalı bir işlem yapınca bunu çok smooth bi şekilde bug reporta dönüştüren akışlar yapıyorlar. Hayalim kullanıcının da hem feature isteği hem bug rapor olarak nefret ederek değil de karşılıklı feedback olarak çalışabileceği bir yapı. Hatta belki bu tip tester-kullanıcılara fiyat avantajı vs tanınması. Çünkü 'tester' rolündeki insanların bulduğu hatalar sadece ekibi yıldırıp moral bozmaya sebep oluyor bazen. :D

hatasız kod olmaz, "ilk çıkardığınız üründen utanmıyorsanız yanlış yapıyorsunuz" demiş steve jobs

hatasız kod için sürekli aynı işi aynı platformda öğrenme süreci olmayacak şekilde yapıyor olmalısınız.

ekibinizin hataları nerede yaptığını analiz edip buna göre bazı optimizasyonlar yapılabilir. mesela en sık yapılan == yerine = koymak gibi typolar. uygulanabiliyorsa MISRA C gibi kurallar tanımlayıp ekibi bu kurallara uymaya ve alışkanlık haline getirmeye zorlayabilirsiniz.

@plutongezegendegilmi yazdiklarinin bircoguna katiliyorum ama sadece "test hata engellemez" dusuncesine katilimiyorum.

cunku yazilan automatik test kodlari ayni zamanda kodu yazarken gelistiriciye yol gosterici olur. ornegin yazdiginiz ve potansiyel olarak bug olsturacak kod ilk planda kodu yazdiginiz anda test edilebilir ve size bir geri bildirim yapacaktir. yani tum testlerden gecmeyen bir kodu zaten "git push" yapmayacaksiniz.

hadi yaptiniz, bu durumda da CI aksiyonu devreye girecek ve tum testleri calistiracak. bu sefer de sizin bu degisim yaptiginiz versiyon ana versiyon ile birlestirilemeyecek.

hadi bundan da gecti, bu sefer de CI/CD araci devreye girecek ve testlerden gecmeyen versiyonun production a alinmasina izin vermeyecektir.

yani potansiyel bug her seferinde potansiyel olarak kalmaya devam edecek. testler duzgun yazidiysa her adimda test duvarina carpacaktir. testler yazilmasa her satir kod degisikliginde urunun tamaminin test edilmesi imkansizdir, ama testler yazildiginda her degisiklik sonunda bir yer bozuldu mu diye bir geri donus alinabilir.

ayrica bir karmasayi da aciklayayim test ile kastedilen test kodlari. yoksa bir insan tarafindan yapilan manual test yapmak gecmiste kalan bir yontem.

ekleme: asagida @plutongezegendegilmi aciklamasina katiliyorum. kaliteli kod ve temiz kod yaklasimlari her zaman yazilan testten once gelir. yazilan kod kalite prensiplerine uymadiginda hersey sarpa saracaktir, test yazilsa da nafile. bu nedenle burada boyle bir duzeltme yapmak istedim.

care tdd :) turkiye'de e-ticarette ilk 5'te olan bir firmanin altyapisini yeniden yazdik, en onemli kisim olan sepette, canlida 1 tane bug cikmadi, 1 tane bile. inanmasi guc. tabii ki eksiklikler vardi, sonraki versiyonlarda tamamlandi. tdd sayesinde sisteme yeni ozellikler katmakta cok kolaylasti cunku testler sayesinde her kodun dokumantasyonu var ve herkes her yere kolayca girebiliyor.

@emrahday, hocam biliyorum bahsettiğiniz konuları ama kastettiğim farklı bir şey.

Şimdi diyelim yeni bir X feature'ı geliştiriyorum, bunu geliştirirken de varolan bir A fonksiyonunu değiştirmem gerekti. Bu A fonksiyonu, Y,Z,T gibi bir sürü diğer feature'u da etkiliyor olsun.

A fonksiyonunu değiştirdiğim için testler patlayacak, testleri de değiştirmem lazım. Üstüne sadece yeni geliştirdiğim X'i değil, Y,Z,T feature'larının da nasıl çalıştığını ve yeni testlerin sadece X'i değil, Y,Z ve T'yi de kontrol ettiğinden emin olmam lazım.

Bu şekilde kod yazmak hem development'ı yavaşlatıyor, hem de bir developer'ın bilmesi gereken business miktarını çok artırıyor. Yeterince büyük bir projede geliştirme yapmak zamanla imkansız hale geliyor bu yüzden.

Peki alternatif nedir? A yazıldıktan sonra onu çok zorunda kalmadıkça değiştirmemek. Onun yerine bir B fonksiyonu yazıp, A'yı extend etmek. Bunu yaparsam sadece B'ye test yazıp geçebilirim. Bunu yapmıyorsam, önceden A'ya yazılan testler anlamsız hale geliyor, çünkü kod değişti. Her değişiklikle birlikte bir sürü başka testi değiştirmem gerekiyorsa bu da maliyeti inanılmaz artırıyor ve mimaride bir sorun var demek oluyor. SOLID'in O'su bundan bahsediyor aslında.

Yani demek istediğim test yazmayın değil. Ama mimari düzgün değilse, iyi kod yazılmıyorsa test anlamsız bir hale geliyor. Sadece test olması kodun iyi olduğunu garanti etmiyor. Test yazarak yeni çıkan 100 bug'ın 80'ini yakalayabiliyorsun, güzel, ama elde 20 bug var. Mimari düzgün olsa 10 bug çıkacaktı, overall'da daha iyi durumda olacaktık. Demek istediğim şey bu.