Daha Sonra Asla Düzeltemeyeceksiniz - Ekibinizi Bataklıktan Nasıl Çıkarırsınız

Hiçbir başlangıç bir test cihazıyla başlamaz.

Sonra 2 yıl sonra, bu girişim, her şeyi büyük bir patlamayla yeniden yazmadıkça, şimdiye kadarki en büyük müşterileri için yeni bir özellik yayınlayamaz. Bunu tekrar tekrar izlemek acı verici.

Yazılımımızın hijyenik kalitesini korumak için yapmanız gereken basit şeyler var, böylece bu duruma düşmezsiniz.

Öncelikle korkularınızı kucaklayın. Mühendisler cesur insanlardır ve endişelerimizin olduğunu hemen kabul etmeyiz. Ancak bu kaygıları ne kadar erken kabul edip paylaşırsak onlarla yüzleşmeye o kadar çabuk hazırlanacağız.

Bugün Yazılımı Nasıl Geliştiriyoruz?

O kadar acelemiz var ki hep geç kalıyoruz. Test için zaman yok. Birim testi için zaman yok. Yeniden düzenleme için zaman yok.

Biz mühendislik ekipleri olarak kendimizi sabote etmeye devam ettiğimiz sürece bunu doğru yapmak için asla yeterli zamanımız olmayacak.

Bize bunun ne kadar zaman alacağı soruluyor ve birim testini, manuel testi ve hatta API testini ve yeniden düzenlemeyi tahminlerimizin dışında tutuyoruz.

Böylece şöyle bir yazılım geliştiriyoruz:

• Hızlı ve kirli

• Hızlı değil, hâlâ kirli

• Hızlı ve mutlu çapraz yol test edildi

• Geriye kalan her şey son durum olarak kabul edilir. (Son durum diye bir şey yoktur.)

  
  

Çok azımız hızlı ya da kirli yazılıma hayır diyecek ve hızlı ve istikrarlı bir yazılım geliştirecek kadar cesuruz.

Tahminlerinizden çıkarmanız gereken şey nitelik değil kapsamdır.

Üzerinde çalıştığınız bileşenin kalitesi hakkında ne biliyorsunuz?

• Kırılgan olduğunu biliyorsun ama çok kırılgan olduğu için ona dokunmak istemiyorsun.

• Bunu uzun zaman önce yaptın, neredeyse hiç dokunmadın, işe yarayacaktır.

• Kırılgan olduğunu bilmiyorsun.

• Gerçekte ne kadar kırılgan olduğunu test edecek ve ortaya çıkaracak hiçbir test ve kimse yok.

  
  

Her gün bu kirli yazılımla uğraşmaktan mutlu musunuz?

İyi olmaktan uzak olduğunu bildiğiniz halde, her gün işinizin kalitesinden ödün vermekten mutlu musunuz? "Temizlemek için zamanımız yok" ile başa çıkmak ve hala kirli olduğu için geç kalmak ve temizlemeden muhtemelen devam edemezsiniz.

Bir sonraki iş görüşmenizde olduğunuzu hayal edin . Şu anki işinizde neyle övüneceksiniz? Baskı altında performans gösterebildiğinizi ve gece geç saatte düzeltmeler yapabildiğinizi mi? Seni bunun için sevecekler ama aynı zamanda neden bu konuda bir şeyler yapmadığını da soracaklar. Belki bu senin işin değildi.

Bu kararları verecek ekip liderleri ve mühendislik yöneticileri vardı. Eğer sana kalsaydı, bir şeyler yapardın. Onlara kodun yeniden düzenlenmesi gerektiğini ve her retroda teknoloji departmanı için zaman planlamanız gerektiğini söylediniz ama kimse dinlemedi.

Bil bakalım ne oldu, izne ihtiyacın yok. Yaptığınız işin kalitesi yalnızca size bağlıdır. Kimse sizi berbat kod yazmaya zorlayamaz. Zaman baskısı kısa vadeli bir bahanedir. Hızlı ve kirli çözümler tüm projeyi geciktirir ve ilk seferde doğru yapmanıza göre daha maliyetli olur.

Daha Sonra Asla Düzeltmeyeceksin

Bu farkı yaratmaya istekli misiniz?

O halde yapmanız gereken şu: Disiplinli olun. Üzgünüm ama bunun başka yolu yok. Ve bu her düzeyde olmalıdır.

Daha kaliteli kod oluşturmaya yönelik ilk adımlarınız neler olmalıdır?

Günlük Kaydı ve Uyarıyı Uygulama

Günlüğe kaydetme ve uyarı verme için tonlarca araç vardır. Yapılacak ilk şey bu. Yazılımınız çöküyor ve siz bunun farkında değilsiniz.

İstisna uyarılarından kolayca destek bildirimleri oluşturmanıza ve bunları "bilinen" olarak işaretlemenize veya raporlandıktan sonra gruplandırmanıza olanak tanıyan bir çözüm bulun.

Uyarıları İzlemek ve Raporlamak için Bir Ekip Rutini Oluşturun

Bunun sıkıcı olduğunu düşünüyorsanız size şunu sorayım: Tüm iş gününüz boyunca bu bölgenin derinliklerinde misiniz? Tüm toplantılardan ve yoğun program çalışmalarından sonra konsantrasyonunuzu biraz rahatlatmanız gerekiyor. Uyarılar kanalında gezinmek, başka herhangi bir kanalda gezinmekten çok daha iyidir.

"Bildirim bildir" düğmesini veya "Biliniyor olarak işaretle" düğmesini tıklamanız yeterlidir. Ve eğer ilginizi çekerse, muhtemelen bir veya iki tanesini düzeltirsiniz.

İşte en büyük argüman geliyor: Birkaç tanesini düzeltebiliriz, ancak birisinin onaylaması gereken testler yazıyoruz, dağıtmamız gerekiyor ve bu da ekip için daha fazla plansız iş yaratıyor.

Başbakan bize yüksek öncelikli konular üzerinde değil, altın kaplama küçük uyarılar üzerinde çalıştığımızı bağıracak.

Tüm "M" rollerinin yer aldığı Ekip bu konuda hemfikirdir.

Genel bir kural yayınlayın: "Küçük ve düşük riskli görünüyorsa ve kesinlikle devam eden başka bir çalışma yoksa, hemen devam edin ve düzeltin. Sprint başına "kapsam dışı" olarak düzeltilen bir veya iki küçük uyarıyı halledebiliriz Planlananlarla birlikte."

İşte bu, çok basit.

Günlükleri ve Uyarıları Tek Tek Temizlemeye Başlayın

Ara sıra yapılan düzeltmelere ek olarak temizliği uygun şekilde planlayın. Planlama derken, ciddiyetlerine veya önceliklerine bakılmaksızın bunları düzeltmek için günlük/haftalık zaman ayırmayı kastettiğimi unutmayın. İlk 5'i düzeltmek yerine önceliklerini değerlendirmek için daha fazla zaman harcayacaksınız. O halde düzeltmeye başlayın.

Her geliştirici için bir uyarı olduğundan emin olun veya çoğu zaman mobbing yapıyorsanız uyarılar için günlük bir zaman dilimi belirleyin. Ve bunu sabah ilk iş olarak yapardım çünkü aksi takdirde asla yapamazsınız.

Tekrar ediyorum, bu yeni bir özellik değil ve kritik önceliklerinizin zamanını tüketiyormuş gibi görünebilir, ancak kritik öncelikleriniz bu gizli sorunlar nedeniyle zaten gecikti. Zaten geç kaldın!

Tüm Boş Try-Catch İfadelerini Kaldırın ve Çökmesine İzin Verin!

Uyarılar ve günlük kaydı pek çok şeyi açığa çıkarsa da, gizlediğiniz şeyleri günlüğe kaydedemezler. O yüzden sorunlarınızı halının altına süpürmeyi bırakın.

2 yıl önce düşen şeyin bugün neden tamamen farklı olduğunu bilmiyordunuz. Bırakın çöksün ve düzeltin. Muhtemelen aynı şekilde çökmeyecek veya çökmeyecek bile, dolayısıyla öyle ya da böyle kodunuz bunlar olmadan daha iyi bir durumda olacaktır.

Birim Testlerini Hemen Yazmaya Başlayın

İçtenlikle söyledim. Şu anda bazı kodlar üzerinde çalışıyorsunuz. O zaman hiçbir şey sizi birim testi yazmaktan alıkoyamaz.

Ah anlıyorum! Birim testi için hazır bir altyapı yok, değil mi? Hadi! Zaten o özenti özelliğini erteleyeceksin.

Birim testi çerçevesini ve testleri çalıştırmak için CI'nızı ayarlamak için bir günden fazla zamana ihtiyacınız yoktur. Sadece yap.

Hata Düzeltmeleri için TDD'yi başlatın

"Sorunun ne olduğunu ve bunu nasıl düzelteceğimizi bilmiyoruz. Henüz var olmayan bir kod için testler yazamayız."

Sevgili geliştiricim, testin amacı bir hipotezi kontrol etmektir. Bu sadece yazılım testi için değil, genel olarak test için de geçerlidir. Yani test yazmanız gereken şey kod değil. Beklenen davranışa ve sonuca ihtiyacınız var.

Şimdi, kullanıcı hikayeleri belirsiz ve net değilse ve kullanıcı hikayelerine karşı testler yazmaya başlamaya hazır değilseniz, bunun için de bir çözümüm var, ancak ondan önce hatalar için ilk test kodunu yazmaya başlayın.

Hata açıklamasının "Beklenen sonuç" adı verilen bir bileşeni vardır ve yeniden oluşturulacak adımlar sizin test durumunuzdur. Yani önünüzde zaten test senaryosu var. Şimdi, düzeltmeyi kodlamaya başlamadan önce onu kodlayın.

Test Odaklı Geliştirme, doğru yaptığınızı değil, doğru işi yaptığınızı doğrulayan bir test yazmaktır. Birim testleri doğru yapıp yapmadığınızı doğrular.

Kapsama Yol Haritası Çizin

Test otomasyonu ve teknoloji borcunun benzer trajik kaderleri var; asla başlamıyorlar çünkü "Asla her şeyi kapsayamayız, asla her şeyi temizleyemeyiz, bu çok fazla yük oluşturuyor. Bunun için zamanımız yok."

Beni dinleyin: her şeyi otomatikleştirmek zorunda değilsiniz!

Ancak yüksek öncelikli kullanım durumları, kritik altyapı ve temel işlevler gibi görev açısından kritik öğelerinizi kesinlikle otomatikleştirmelisiniz. Nasıl isterseniz öyle adlandırın, ancak işletme kodunuzun ve altyapınızın %20'sine güveniyor ve müşterileriniz özelliklerinizin %20'sini kullanıyor.

Bununla nereye varacağımı görüyorsun.

Şu anda bu özellikler için otomatik testler yazmaya başlamanıza bile gerek yok. İlk yapmanız gereken onlara öncelik vermektir.

Yüksek ve düşük düzeyli mimari diyagramlarınızın önünde ekip olarak bir araya gelin. Hiç yok, değil mi? Yoksa mevcut olanlar 2,5 yıl önce çekilmiş bir beyaz tahtanın fotoğrafı mı? Biliyorum.

Evet yarım gününüzü ayırıp bunları güncellemeniz gerekiyor. İyi haber şu ki, size yardımcı olacak eğlenceli araçlar var, dolayısıyla bakımı manuel olarak yapmanıza gerek yok. Biraz araştırma yap.

Sonuçta siz bir Ar-Ge ekibisiniz, değil mi?

Tam Kapsamı Hedeflemeyin - Bunun yerine Düşük Risk ve Yüksek Güveni Hedefleyin

Güncel mimarinizin ve altyapınızın şemasını çizerken, notlar veya daireler ekleyin veya aşağıdaki tüm yerleri kalın veya kırmızıya boyayın:

• İşletmeniz ve yazılımınız için kritik görev

• Çaresizce yeniden düzenlemeye ihtiyaç duyuyorsunuz, yoksa diğer görev açısından kritik özelliği her zaman ertelemeye devam edeceksiniz.

• Sürekli kırıp tamir etmek için zaman harcamak boşuna çünkü birkaç gün sonra tekrar kırılacaklar.

Çizimler hazır olduğunda ekibinizle birlikte oturun ve daire içine alınmış tüm bu bileşenler için neyin test edilmesi gerektiği konusunda beyin fırtınası yapın.

• "Bu kadarı da fazla! Bunları kapatmak için diğer tüm çalışmaları durdurmalıyız!" tuzağına düşmeyin. Bunların hepsini bir anda ele almanıza gerek yok. Ama bir plana ihtiyacın var. Şimdi başka bir pano açın ve Test Hedeflerinizi yazmaya başlayın. Örnekler:

  
  

  • Başarı ve başarısızlık için tüm veri getirme API'si isteklerini karşılayın; böylece kötü istekler göndermediğinizi ve başarısız olursa satıcı yüzünden başarısız olacağını bilirsiniz.

    
    

  • Görev açısından kritik kullanıcı yolculuğunun ana hatlarını çizin. Birimlere ayırın. Birim testlerini yazın. Test piramidi icat edildiğinde birim, bir yöntem değil, bir bileşen anlamına geliyordu; dolayısıyla yöntemleri ve sınıfları değil, işlevselliği kapsıyordu.

    
    

  • Trafik sıkışıklıklarını belirleyin ve bunları nasıl çözeceğinize karar verin.

    
    

  • Doğru yapmayı planlayın. Hızlı ve kirli kodunuz kirli testlerle kirli kalacaktır.

Test Piramidi yerine kasıtlı olarak bir kapsam Haritası kullandım çünkü... bu aşamada, manuel veya otomatik herhangi bir testiniz olmadığında, Piramit için hazır değilsiniz.

Çoğu takım, önce %96 birim test kapsamına ulaşmaları, ardından entegrasyon testlerine geçmeleri gerektiği gibi yanlış bir izlenime sahiptir. Modern birim testi kapsamındaki sorun, işlevleri değil Yöntemleri ve Sınıfları test etmemizdir.

Daha da fazla ekip kullanıcı arayüzü otomasyonuyla başlıyor ki bu da aynı derecede yanlış.

Bu aslında yapabileceğiniz en kötü şeydir ve başarısızlığa mahkumdur.

Bu yüzden Piramidin tepesinden veya altından başlamayın, bunun yerine bir risk haritası oluşturun.

Bazı özellikler kapsamlı entegrasyon testlerine ihtiyaç duyabilir, diğer özellikler kapsamlı kullanıcı arayüzü testlerine ihtiyaç duyabilir ve bir sonraki bölüm gerçekten de her şeyin bağlı olduğu temel bir özellik olabilir (yine de başka bir tehlike işareti) ve bunu yukarıdan aşağıya tamamen ele almanız gerekir.

Veya bu bir veri toplama hizmetidir ve örneğin API'lerin performansına odaklanmanız gerekir.

Yoğun test gerektiren yazılım etkin noktalarınızın bir haritasını oluşturun.

Daha sonra bu testi nasıl otomatikleştirebileceğinizi düşünün.

Bataklıkta İlerleyemezsiniz ve Kendinizi Oradan Sadece Siz Çekebilirsiniz

Haydi saralım. Eğer hayatınızın yarısını testsiz bir yerde çalışarak geçiriyorsanız, kod bozuktur ve zamanınız yoksa “zamanınız yok” diye taviz vermeye devam edersiniz. Tamamen mutlu değilsiniz ya da en azından oldukça kayıtsızsınız; ödüyorlar, bu onların kararı ve sizin kararınız değil.

Bu çok üzücü. Eminim işinizle gurur duymuyorsunuzdur. Hatta işi ve amacını seveceğiniz bir sonraki tek boynuzlu atın sizi işe almasını bile bekleyebilirsiniz.

Geçen sene işler çok değişti değil mi? Tek boynuzlu atların var olmadığını bir kez daha öğrendik. İşe alınabilmek için olağanüstü bir geliştirici olmanız gerekir. Şirketler, katkıları ne olursa olsun insanları çöpe atabileceklerini anladılar.

Yine de bir şirketin elinde tutmak için her şeyi yapacağı mühendisler var. Onlardan biri olmak için değişimi yönlendirmeniz ve işin sizin gibi insanlara bağlı olduğunu sürekli kanıtlamanız gerekir.
Herkes berbat yazılımlar yazabilir ama gerçekten iyi olanlar sadece keyifle mükemmel yazılımlar yazmakla kalmaz, aynı zamanda başkalarına da ilham verir ve kod kalitesi kültürünü yayarlar.

Bataklıkta ilerleyemezsiniz ve yalnızca kendinizi oradan kurtarabilirsiniz.