bug fixes

• mobil uygulamalarda yaygın bir what's new çeşidi. yani bir yığın yeniliğe ek olarak bu satırdan bahsetmiyorum. tüm açıklama alanı "bug fixes" cümlesinden ibaret olan bir güncellemeden bahsediyorum. zamanında ekşi sözlük'ün dandik uygulamalarını outsource ettiğimiz firma da yapmış aynısını.
  
  firma bununla kullanıcıya "tatava yapma güncelle geç" mesajı veriyor. bunu yaparak aslında kullanıcılarıyla büyük bir iletişim fırsatını çöpe atıyor. muhtemelen "kullanıcı anlamaz" deniyor ancak o zaman kullanıcıyı hiçbir şekilde etkilemeyen bir şey düzeltilmiş demek oluyor ki: **yanlış**
  
  kullanıcıyı hiçbir şekilde etkilemiyorsa niye düzeltiyorsun? mesela memory leak var diyelim. "kullanıcı heap yapılarından, unmanaged resource'lardan anlamaz" diyebilirsin. ancak senaryoyu kullanıcıya etkisi üzerinden kurabilirsin: "uygulamanın uzun süre açık kalınca cihazda yol açtığı yavaşlık, çökmeler" cümlesine çevirebiliyorsun. o zaman hem kullanıcı anlıyor, hem senin uygulamandan bu yüzden şikayetçiyse ekstra mutlu oluyor, takdir ediyor.
  
  acaba bu tarz iletişim de başarısız olduğundan, hatta tam tersine olumsuz pr'a yol açtığından mı bundan vazgeçildi? mesela "uygulamanın uzun süre açık kalınca cihazda yol açtığı yavaşlık düzeltildi" deyince insanların kafasında hata düzeltilmiş olsa bile uygulamanın gerçekten böyle bir yavaşlığa yol açtığı mı kalıyor? "bak işte bundanmış" mı diyor? uzun vadede aynı sorunu başka uygulama yüzünden yaşarsa "aha düzelttik demişlerdi düzeltmemişler" deyip faturayı firmaya mı çıkarıyor? mimleniyor mu? yoksa bir getirisi olmadığına dair yoğun kanaatten dolayı mı böyle? ya da yerelleştirme maliyeti mi yüksek?
  
  üşengeçlik dışında tüm bunlar makul gerekçeler. keşke gerçek sebebini bilebilseydik.
• genellikle geleceğe yönelik ön hazırlık için dosya atımı yaptığımda kullandığım tabirdir kendileri.
  
  diyelim ki bir oyuna 3 adet daha karakter ekleyeceğiz ve tek güncelleme ile her şeyi yüklemek sıkıntı yaratacak o zaman 3 parça güncelleme çıkarıyoruz ve her güncellemede sahnede ufak tefek kullanıcı aa bunu da yapmışlar diyeceği egg'ler ekliyoruz ve güncellemenin en altına bug fixes yazıyoruz. oysa ki amacımız ileride gelecek olan güncellemenin ana hatlarını oluşturmak. bunu açık açık yazarsanız korkunç bir mail yağmuruna tabi kalabiliyorsunuz. fikrini belirtenler, öneri sunanlar küfredenler. yani kullanıcıya iletişim kanalında bilmesi gerekenden fazlasını verirseniz kullanıcı sizin ortağınız gibi davranıyor.
• bug fixes and performance improvements'ın bir tık altındaki açıklamadır. her zaman kullanılmaz ama bazı durumlarda da gayet mantıklıdır.
  
  bazı cihaz bazlı sorunları çözmek için bir sürüm çıkardığında, uygulamanın kullandığı api'ler ya da backend server'ında yapılan değişiklik yüzünden bir düzeltme yaptığında, test ekibinin çılgınlar gibi uğraşıp bulduğu ama son kullanıcının onu gerçeklemesinin mümkün olmadığı bir bug'ı düzelttiğinde, resim işleme ya da hesaplama algoritmalarında yapılan ufak iyileştirmelerde gönül rahatlığıyla bunu yazabilirsin. bütün büyük firmalar da bunu bu şekilde yapar.
  
  hangi durumlarda yazmaması gerektiğine gelecek olursak. uygulamaya yeni bir özellik eklendiğinde, uygulamanın arayüzünde yapılan radikal değişikliklerde, işletim sistemi versiyon geçişlerindeki hatalar temizlendiğinde vs...hepsini yazamayacağımı farkettim ama genel bir fikir vermiştir diye düşünüyorum.
  
  hepsine bug fixes yazıp geçiyorsa da üşengeçlik ya da ux bilgisi eksikliğinden başka makul bir açıklaması yoktur.
• uygulamayı indirip kuruyorsun 70 mb. üç gün sonra bug fixes adı altında güncelleme geliyor. kendi kendine diyorsun ki "uygulama 70 mb ise güncellemesi de 3- 5 mb olur herhalde". ama o da ne güncelleme dediği şey uygulamayı yeniden indirmek; 70 mb güncelleme.
  bu da böyle bir anımdır. evet, sadece 8gb alanım var.
• test ekibinin çılgınlar gibi uğraşıp bulduğu ama son kullanıcının onu gerçeklemesinin mümkün olmadığı bir bug'ın düzeltilmesi yanlış. test ekibi bulmuş olsa bile bu bug kullanıcıya hiç yansımıyorsa bug bar'ı geçmemesi gerekir. haliyle kaynak israfıdır.
  
  (bkz: bug bar)
• bilmediğimi ve sebebini merak ettiğimi açık açık belirttiğim bir entry'den "he sen biliyon" diye tepki veren insanlar var. ilginç. not al arçibıld.
• esasen kullaniciyi etkilemiyormus gibi gorunse de duyurulmasi dogru olan bir seydir. zira kullaniciyi etkileyecegi bir kombinasyon henuz gerceklesmemis olabilir.
• mobil projeler ile web projelerini ayırıp bug bar kavramını ona göre değerlendirmek gereklidir. 1/1000 oluşma olasılığı olan bir bug'ı ele alacak olursak. bir web sitesi bu tip bir hata için "ihi sitemiz patladı ama bir refresh yapın belki düzelir" gibi sempatik bir mesajla durumu toparlayabilir. öte yandan 50000 kullanıcısı olan bir mobil uygulamada, bu hata ile karşılaşan 15 kişi sizin uygulamanıza 1 yıldız verirse, ne kadar şirinlik yapsanız da durumu toparlayabilirsiniz. bunun yanında kaynak planlamasına gelecek olursak. orta ölçekli bir mobil projede ortalama bir bug fix'in maliyeti 1/4 adam/gündür. ben kaynağımı harcamayı tercih ederim.
  
  bunun yanı sıra demode proje yönetim kavramları mobil projeler için artık geçersiz durumdadır. agile bir şekilde proje planlaması yapılır. 3 ay sürecek bir mobil proje için kimse oturup bug bar seviyesi belirlemek için 2 gününü ayırmaz, hatta ayırmamalıdır. test ekibi proje planından sonra en ekstrem durumlar dahil test senaryolarını belirler. her sprint sonunda bu testler koşulur ve her bug düzeltilir.
  
  tanım: hayırlı bir şey.
• sözlük sahibinin altında formata kafa attığını gördüğümüz başlık.
• (bkz: hata ayıklama)