Grooming toplantısında Hakan sessizce kalktı, tahtaya bir tablo çizdi. Sonra söz aldı. Ben bu konuşulanlardan hiçbir şey anlamadım. Olası senaryoları çıkardım. Bunların her biri için ne yapacağımızı konuşabilir miyiz? dedi.. Bir iş maddesini hazır hale getirmek için atılmış ufacık ama çok etkili bir yöntem. Bu tablonun sonra testlerde kullanılması da cabası.

Başka bir örnek benim kişisel arşivimden gelsin. Sorun bana, abi bazı senaryolarda istediğimiz sonucu alamıyoruz, sistem düzgün gibi sen de bir bakar mısın diye geldi. CLOP NCLOP tekerleme gibi dinlerken iyice çorba oldu. Neyse sonra 2 dakikada şu tabloyu çizdik. Her biri için olması gerekeni söyledi. Yazdık. İş bitti. Artık IF’ini ELSE’ini bile buraya bakarak yazmıştır diye tahmin ediyorum.

( Sinan Yılmaz hocamızın ruhu şad olsun, ne zaman böyle bir tablo çizsem aklıma hep onun dersi gelir.)

Sözün özü: Belirsizlik ve karmaşıklık durumunda, konuya biraz sistematik yaklaşmak bile çözüm yolunda büyük bir adımdır.

Sağlıkla kalın,

Serkan

Bir PBI’ı Kurtaran Basit Tablo was originally published in Bimar Teknoloji Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Redis Pub/Sub İle Cache Invalidation Yönetimi

Redis birçok kişi tarafından hızlı bir cache yönetim aracı olarak bilinmektedir. Bu özelliğinin yanında kuyruk, session yönetimi ve mesajlaşma altyapısı gibi farklı özellikleri de içinde barındırıyor. Bu yazı içeriğinde redis’in pub/sub (publish/subscribe) özelliği ile şirket olarak cache üzerinde tuttuğumuz veriler güncellendiğinde bu durumdan nasıl haberdar olduğumuzu ve sonucunda onları nasıl tazelediğimizden bahsedeceğim.

Cache’te tutulan veriler uygulamalar için büyük bir nimet. Sürekli veritabanından okumanız gereken, çok sık ulaşılan fakat çok sık değişmeyen verileri veritabanından tekrar tekrar çekmek yerine birçok uygulama cache’leme mantığını kullanmaktadır. Cache üzerinden çekilen veriler ile uygulamalar toplamdaki response sürelerini önemli ölçüde azaltıyor.

Fakat veritabanında tutulan verilerde bir değişiklik olduğu durumda gerçeğin bir yansıması olan cache’teki bu kopya verilerin de güncelliğini koruyor olması gerekli. Mesela kullanıcı bilgilerinin tutulduğu verileri düşünelim, uygulamaya ilk defa bir request geldiğinde kullanıcı bilgisine ihtiyaç duyuluyorsa önce cache’e bakılır, cache’de varsa kullanılır yoksa aktif tüm kullanıcılar veritabanından çekilerek cache’e atılır ve sonraki gelen istekler de kullanıcı cache bilgisi dolu olduğundan hep buradaki veri üzerinden cevap verilerek veritabanına tekrar tekrar gidilmez. Eğer kullanıcılardan herhangi birinin verisinde bir değişiklik olup veritabanı güncellemesi gerçekleşirse cache’teki bu bilgilerin de yeni veriler ile “tazelenmesi” gerekir. Aksi durumda uygulama cache üzerindeki verileri kullanmaya devam edeceği için güncel bilgiler ile işlem yapamadığından hatalı bir duruma yol açacaktır.

Temel anlamda cache’in beslendiği kaynak bilgilerinin değişimi ve bu durumda cache’in yeniden güncellenmesi işi terminolojik açıdan cache invalidation şeklinde ifade ediliyor. Bu girişten sonra biraz da bizim uygulamamızın yapısından, karşılaştığımız sorundan ve redis pubsub ile cache temizleme işini nasıl yaptığımızdan bahsetmek istiyorum.

Uygulamamız 3 farklı sunucu üzerinde arkada load balancer yapısı ile yönlendirilen requestleri karşılayacak şekilde windows işletim sistemli serverlar üzerinde host ediliyor ve requestler sticky session mantığında işletiliyor. Kullanıcı ilk requestte hangi sunucuya yönlendirilmişse sonraki tüm istekler o sunucuya gidiyor. Birden fazla sunucu üzerinde aynı uygulamanın host edilmesi ve her sunucu üzerinde çalışan app’in kendi cache’ini kendi sunucu belleğinde tutması redis pub/sub’ı kullanmamızdaki ana motivasyon kaynağımızdı.

Farkındaysanız bu açıdan bakıldığında yaşadığımız problem biraz daha belirginleşmeye başlıyor. 3 farklı sunucu var, sticky session yönlendirme yapılıyor ve cache’lerdeki veriler bu 3 sunucu üzerindeki bellek birimlerinde birbirlerinden habersiz olarak tutulmakta. Sunuculardan biri üzerinde çalışan uygulama cache verisiyle ilgili bir değişiklik yaptığında sadece kendi belleğini temizleyerek yeni veriyi görmeye devam ediyor, fakat geriye kalan diğer 2 sunucudaki cache’ler bu temizlik işleminden haberleri olmadığı için hala eski veriyi kullanmaya devam etme riskiyle karşı karşıya, ta ki uygulamaya ait process stop/start edilene kadar.

Bu eski yapıda kullanıcılar tarafından genellikle şöyle geri bildirimler alınıyorduk; bazı kullanıcılar bir işlemi yapmaya devam edebilirken diğerleri edemiyor veya cache’te tutulan bilgi client tarafta bölgesel bazlı bir kısıtlamaya hizmet ediyorsa yine kullanıcıların bir kısmı (İspanya’daki kullanıcı işlem yaparken Mısır’dakinin yapamaması gibi) ekranlarında bu özelliğin yansımasını görürken geri kalan kısım göremiyordu. Bu durumun tek sebebi cache’in sunuculardan birinde güncellenmiş olması fakat diğer sunuculardaki cache’lerin eski veriyle çalışmayı sürdürmesiydi.

1. Redis Pub/Sub ile Tanışma

Bu noktada kısa bir araştırma ve POC çalışması sonrasında pub/sub’ın hazır olarak sunulan socket haberleşme altyapısını kullanarak cache invalidation işlemini yönetebileceğimizi gördük. Redis pub/sub built-in bir kütüphane olarak Redis sdk’ları ile birlikte kullanılabilir olarak geliyor. Kendi projemizde yapmamız gereken şey bu yapıyı ilgili projemize entegre ederek kullanmaktı.

İnternet araştırmamız sırasında bir github repo’su olarak redis altyapısında kullanacağımız publish, subscribe, redis connection açma gibi işlemleri kendi bünyesinde barındıran bir projeye denk geldik ve bu projedeki wrapper sınıfları kendi projemizde kullanarak redis pub/sub altyapısını hızlı bir şekilde oluşturabildik. Bu repo’ya şu link ile ulaşabilirsiniz 👇

GitHub - antoinebidault/MemoryCacheRedisBackplane.Net

Bu projeden beslenip kendi projemizde değişiklikler yaparken en çok dikkat ettiğimiz kısım uygulama ayağa kalktığında kullanılacak redis nesnesinin -ki bunun üzerinden connection ve pub/sub işlemlerini yürütüyoruz- singleton olarak implement edilmesiydi. Bu kullanım ile birlikte nesnenin sürekli oluşturulma hususundaki belleğe olan olumsuz etkisi ve concurrent işlemler üzerindeki sürprizlere gebe olabilecek endişelerimizden sıyrılmış olduk.

Yukarıdaki şemada pub/sub ile gitmek istediğimiz noktayı özetlemeye çalıştım. Senaryomuzda 1 numaralı sunucuda çalışan uygulamamızda “KullaniciAppCache” anahtarı ile cache’te tutulan bilgiler üzerinde bir değişiklik olduğunu farz edelim. Bu durumda 1 numaralı sunucudaki uygulama önce veritabanına gidip kullanıcı bilgilerini güncelleyecek sonrasında bu işlemi yaptığından “doğal olarak” haberdar olduğu için kendi belleğindeki bu key ile tutulan cache’i silmesi gerekir. 1 numaralı işlem bunu yapmaktadır. Cache üzerindeki bu bilgi silindiği için bu sunucuda kullanıcı bilgisine ilk defa ihtiyaç duyulduğu anda veritabanından çekilecek ve sonra cache’e yazılarak oradan okunmaya devam edilecek. Yani 1 numaralı sunucuda çalışan uygulama kendini kurtardı yani taze bilgiyi cache’ten okuyabiliyor, fakat cache’in kirlendiği bilgisini 2 ve 3 numaralı sunucularla da paylaşması gerekiyor ki onlar da kendi cache’lerini temizlesinler.

2. işlemde aşağıda gördüğünüz gibi Redis sunucusuna bir anahtar ile birlikte sinyal gönderiliyor. Bu sinyali yakalayan redis pub/sub yapısı “daha önceden” kendisine kaydolmuş olan uygulamalara “bakın bu key artık güncel değil” mesajı ileterek uygulamaların kendi cache’ini temizlemesini sağlıyor. Bu işlemler de yukarıda yeşil daire içinde gördüğünüz 3 ve 4 numaralı adımla yapılıyor.

Bu döngü cache üzerinde tutulan her veri için eğer o verinin tutulduğu veritabanında bir değişiklik olmuşsa tetikleniyor, bu noktada tetikleme işlemini yapan noktanın ilk veritabanı güncellemesi yapan kod olduğunu unutmayalım. Böylece herhangi bir sunucu üzerinde çalışan uygulamanın kirlettiği cache’ten pub/sub yapısı ile birlikte diğer sunucularda çalışan uygulamaların da haberi oluyor.

Pub/Sub yapısı bir merkeziyet sağlayarak uydu uygulamaların cache konusunda birbirlerinden haberdar olmasına katkı sağlıyor.

2. Pub/Sub Proje İçi Kodlama Detayları

Yukarıda pub/sub’ın çalışma prensiplerine değindik. Bu bölümde ise uygulama tarafında kodlama sürecini adım adım açıklayacağım.

2.1. Azure üzerinde Redis kaynağının oluşturulması.

Şirket olarak Azure ekosisteminde çalıştığımız için öncelikle burada bir Redis kaynağına ihtiyacımız vardı. Bunu oluşturarak uygulamaların bağlanacağı kaynak ihtiyacını gidermiş olduk. Oluşturduğumuz Azure kaynağındaki hostname ve connection bilgilerini alarak uygulamamızın config bilgilerine ekledik.

2.2. Redis pub/sub backplane yapısının projeye dahil edilmesi.

Bu aşamada, Redis pub/sub mekanizmasını kullanarak mevcut cache temizleme sınıflarını değiştirmemiz gerekiyordu. Bu süreçte, GitHub üzerinde işimizi kolaylaştıran ve pub/sub metodlarını içeren wrapper sınıflarının bulunduğu bir backplane projesine denk geldik. Yukarıda bağlantısını paylaştım; ihtiyacınız olursa siz de kullanabilirsiniz. Bu sınıfları projemizdeki ilgili yardımcı sınıflar üzerinden çağırarak hangi aşamada publish işlemi yapacağımızı ve hangi noktalarda cache temizliği gerçekleştireceğimizi belirledik.

Aşağıda ilgili github reposundaki connect, subscribe ve publish metotlarının nasıl kullanıldığını görebilirsiniz;

(https://github.com/antoinebidault/MemoryCacheRedisBackplane.Net)

 public sealed class RedisService : IDisposable
 {
     private ConnectionMultiplexer _redis;
     private int _retry = 1;
     private DateTime? _lastFailureDate = null;
     private Guid _originId;
     private readonly MemoryCacheRedisBackplaneOptions _options;
     private ISubscriber _sub;

     internal RedisService(MemoryCacheRedisBackplaneOptions options)
     {
         this._originId = Guid.NewGuid();
         this._options = options;
         this.Connect(options.RedisConnectionString);
         _redis.ConnectionFailed += (s, e) =>
         {
             if (_retry < options.NbRetry || _lastFailureDate > DateTime.UtcNow.AddMinutes(5))
             {
                 Connect(options.RedisConnectionString);
                 _retry++;
             }
             _lastFailureDate = DateTime.UtcNow;
         };
     }

     internal void Connect(string cnx)
     {
         _redis = ConnectionMultiplexer.Connect(cnx);
         if (_redis.IsConnected)
         {
             _retry = 0;
         }
         _sub = _redis.GetSubscriber();
     }

     internal void Subscribe(Action<string> subscriptionCallback)
     {
         _sub.Subscribe(_options.EventSubscriptionName, (channel, message) =>
         {
             if (message.HasValue)
             {
                 string value = message.ToString();
                 if (value.StartsWith(_originId.ToString()))
                 {
                     return;
                 }

                 subscriptionCallback(RemoveOriginId(value));
             }
         }, CommandFlags.FireAndForget);
     }
     
     internal void Publish(string key)
     {
         if (_redis.IsConnected)
         {
             _sub.Publish(_options.EventSubscriptionName, AppendOriginId(key), CommandFlags.FireAndForget);
         }
     }

     public void Dispose()
     {
         _sub.Unsubscribe(_options.EventSubscriptionName);
         _redis.Close();
         _redis.Dispose();
     }

     /// <summary>
     /// Append the origin id to the key in order to identify the request origin
     /// </summary>
     private string AppendOriginId(string key)
     {
         return _originId.ToString() + "_" + key;
     }

     /// <summary>
     /// Remove the origin id from string
     /// </summary>
     private string RemoveOriginId(string key)
     {
         return key.Substring(key.IndexOf("_") + 1, key.Length - key.IndexOf("_") - 1);
     }
 }

2.3. Uygulama ayağa kalktığı sırada redis sunucusuna register olunması.

Son aşama ise uygulama ilk nefes almaya başladığı anda hangi sunucu veya process üzerinde çalışıyorsa farketmez ilk yapacağı iş kendini “redis merkezi komutanlığına” bildirmek olmalı. Yani subscribe işlemini yapmalı kendini kayıt ettirmeli ki böylece ben sana gelecek olan değişikliklerden haberdar olmak istiyorum bilgisini önceden vermiş olsun.

Bu kısmı da bizim kullandığımız 2 tür runtime ortamı olduğundan farklı sınıflar içerisinde yaptık. .NET 4.8 framework ile çalışan webform uygulaması için global.asax.cs içinde .NET6 ile çalışan runtime içinse startup.cs sınıfı içinde bu işlemleri gerçekleştirdik.

Global.asax.cs sınıfı (4.8 framework için);

public class Global : System.Web.HttpApplication
{

    protected void Application_Start(object sender, EventArgs e)
    {
        //Redis publish and subscribe mekanizmasi icin ilklendiriliyor..
        if (ConfigHelper.RedisCacheInvalidationDevredeMi)
            MemoryCacheRedisBackplane.Net.MemoryCacheRedisBackplane.Instance(AppMemoryCache.Instance());
    }
    
}

Startup.cs sınıfı (.net core api projesi için);

#region Redis&Memory
AppMemoryCache.Configure(app.Services.GetRequiredService<IMemoryCache>());
if (ConfigHelper.RedisCacheInvalidationDevredeMi)
{
    MemoryCacheRedisBackplane.Net.MemoryCacheRedisBackplane.Instance(AppMemoryCache.Instance()); // Redis pub/sub registration..
}
#endregion

Bu yazıda Redis pub/sub ile gerçek zamanlı cache invalidation yönetimi üzerine deneyimlerimi aktardım. Bu yaklaşımın, benzer sorunlarla karşılaşan geliştiricilere pratik bir çözüm sunacağını umuyorum. Okuduğunuz için teşekkürler.

Bilgisayar bilimlerinin göreceli olarak zor işlerinden biri olduğu düşünülen cache invalidation’a ilginiz varsa muhtemelen diğer bir zor konu olan isimlendirme için yazılmış temiz bir içeriğe hayır demeyeceğinizi tahmin ediyorum. Eğer o konu hakkında da merakınız taze ise şu yazıya göz atmanızı tavsiye ederim 👇
Sahadan Temiz Kod — İsimlendirmeler | by Serkan Apul | Bimar Teknoloji Blog | Medium

Redis Pub/Sub ile Cache Invalidation Yönetimi was originally published in Bimar Teknoloji Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Manifesto for Agile Software Development : http://agilemanifesto.org/

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Pozitif Kaygılarımız

→ Backlog’um değerli mi? (Maddelerim net ve önceliklendirilmiş, iş sahipleri için değer taşıyor)

→ Backlog’umu tüketebiliyor muyum? (maddelerim bitiyor mu?)

→ Ekip mutlu mu?

Scrum Framework Guide PDF : http://www.scrumguides.org/download.html

Product Owner

Ürünün değerinden / karlılığından sorumludur.

Müşteriye karşı sorumludur.

“Delivery Date” den sorumludur.

Developer %10 zamanını PO ya ayırır.

Bu sürede “backlog grooming” yani PBI ların içlerinin zenginleştirilmesi, son haline getirilmesi aktivitesi gerçekleştirilir.

Product Backlog unu yeni sprintler için hazır tutar.

Teknik borç azaltmaya yönelik altyapı — kaliteye yönelik maddeler iş değeri açısından PO ya iyi anlatılmalı ve bir PBI olarak sprint içine alınmalıdır.

SCRUM Master

SM = Agile Coach olarak da ifade edilebilir.

SCRUM konusunda ustadır. Yarım zamanlı bir iştir.

Ekip zamanla scrum’a alıştıkça ve ustalaştıkça SM ye ihtiyaç duymayacak bir konuma gelebilir.

Ekip üyelerinin mevcut işlerinde kesintiye uğramadan çalışmasını sağlamalıdır.

Takımın motivasyonunu devamlı yüksek tutmalıdır.

Takımın sprinti koşmasında, hedefe varmasını engelleyecek her türlü sorunun ortadan kaldırılmasından sorumludur.

Takımın refahını sağlar.

Süreçler üzerinde yeni şeyler deneyelim. En fazla 1 veya 2 sprint kaybederiz.

Waterfall: İnşaat ve Askeriye de geçerli olabilir. Vasıfsız isçiler eliyle yapılan işler içerir.

Scrum: Inovasyon ve sanat içeren yazılım sektörü için uygundur. Ekip; eğitimli, sosyal beklentisi olan, başarılı olmaya odaklı, potansiyelinin engellenmemesi gereken bir topluluktur.

Değişiklikleri ne kadar çabuk kabul eder ve benimsersek o kadar çabuk değer üretiriz.

PLANLAR TAŞA YAZILMAZ.
PLANA TAPILMAZ.

⚠️Hata yapıldığında utanç duyulan bir sistem yaratmamak gerekir.

DEFINITION OF READY

Madde yazıldı. Analizi, iş değeri belirlendi. Talebe başlamak için beklenen bir şey yok. Ekip arkadaşıma ve PO ya sorup devam edebileceğim derinlik yeterlidir.

DEFINITON OF DONE

Bir madde “bitti” dendiğinde bütün ekip aynı şeyi anlamalıdır.
Örnek bir tanım: İş maddesi Build, Test, Reviev, Otomatik Testler, Sonarqube tarama, Güvenlik tarama süreçlerini geçti. Test edildi. Müşteri test sistemine çıktı. ->DONE

BU TANIMLAR MUTLAKA YAPILMALI. TÜM PAYDAŞLAR BU TANIMDA EL SIKIŞMALI VE BU TANIM GÜNCEL TUTULMALIDIR.

SCRUM SERENOMİLERİ

SABAH TOPLANTILARI: (FOCUS ON SPRINT GOAL!)
Toplantıdan önce ekip üyelerinin maddelerinin son durumunu JIRA/TFS/BOARD üzerinde günceller.

Kalan iş BURNDOWN chart’ın güncel olmasını sağlar.

Hedefe koşarken önümüzdeki engeller nelerdir. Nasıl kaldırırız? Bunlar konuşulmalıdır.

Sen bu işle uğraşırsan sprint yetişmez. Buna bakalım.

Önemli olan sprintin yetişmesi önündeki engellerin kaldırılmasıdır. Sprint’e koşan faaliyetler konuşulur.
“Sprint için ne yaptım, ne yapacağım, kime bu yolda destek oldum” konuşulur.
Uzayan konu daha sonra ilgililerin kendi arasında halletmesi için kesilir. Sonra onlar devam edebilir.

Sabah toplantıları 15 dakikayı kesinlikle geçmemelidir.

Bir nedenden dolayı beklemeye geçen kişiler, kendi gündeminden veya düşük öncelikli bir işle değil, MEVCUT SPRINT PLANINA dahil bir iş ile uğraşmalıdır. Aksi halde sprint hedefi tutmaz.

SPRINT PLANLAMA TOPLANTISI
Hafta başına 2 saat planlama faaliyeti olmalıdır. Backlog’dan sıradan başlanarak o sprinte alınacak maddeler seçili

RETROSPECTIVE TOPLANTISI
PO bulunmaz.

SM ye bir KAIZEN çıkarmalıdır. Bu KAIZEN sonucu yapılacak değişiklik bir sonraki sprinte PBI olarak yansıtılabilir. SM bunu en tepeye koyabilir. Daha sonra işe yaradı mı yaramadı mı değerlendirilir.

Devreye alımdan sonra değişikliklerin etkisi ne oldu? Hata üretiyor muyuz? Bir sonraki sprinte neleri daha iyi yapabiliriz.

Bu toplantıları stressiz bir ortamda belki yemek söyleyerek, iyileştirme amaçlı yapmak lazım. Ekip kendi içinde rahatça öz eleştiri yapabilmelidir.

Bu toplantıda artık kimse söz almıyorsa veya toplantı artık hiç yapılmıyor ise umutlar tükenmiş her şey olduğu gibi kabul edilmiş demektir.

SPRINT PERFORMANSI?

Velocity (ekibin planladığı sprintte çıkacak maddelerin iş değeri toplamı) değerinin artırılması performans hedefi olarak verilirse kalite düşebilir. Bununla birlikte ekip tahminleme çalışmasında otomatik olarak maddelere yüksek velocity değerleri verme eğilimine girebilir. Sonuçta çıkan iş aynı olacaktır ama velocity istatistiği bozulmuş olacaktır. Yani bu işe yaramaz. Önemli olan verimliği düşüren tüm engellerin kaldırılmasıdır.

Önceki sprintte tüm çalışmaya rağmen tamamlanamayan bir USER STORY varsa, ekip planladığı kadarını bir nedenden yapamadıysa, yeni sprintte yapabileceğimiz kadar alalım. Başarılı spirintten sonra bir sonrakinde yapabileceğimiz kadar tekrar planlarız. Yapamayacağımızı bile bile fazla madde planlamanın hiçbir anlamı yoktur. Önemli olan ortadan engelleri kaldırarak, daha verimli bir şekilde sprint amacına yönelik çalışmaktır.

Her takımın kendi hızı vardır. Takımlar arası VELOCITY REKABETİ / karşılaştırması yanlıştır. BUG lar veya diğer olumsuz durumlar işler için kişisel sorumlu aramak ve performans sistemine yansıtmaya çalışmak takım ruhuna zarar verecektir. Cadı avına çıkılmamalıdır.

BİR SPRINT NASIL “BAŞARISIZ” OLUR?
Given that each Sprint is an experiment and Scrum is an empirical process: An unsuccessful Sprint is one where at the end we have not learned anything. We did not Inspect and Adapt the results for customizing the Product and Processes.

What is a failed Sprint?

BUG CAP Takımın backlog undaki / havuzundaki açık hata sayısı bir üst sınır koyuyoruz. 30 diyelim. BUG sayısı 30'a ulaştığında ekip kayıt kalemi bırakıp (sprintteki “feature” geliştirimini bırakıp) hata kayıtlarını azaltıyor. Bu isteyemeyen bir durum olduğu için ekip hata sayılarını bu sınırın altımda tutma eğilimine giriyor. Hata adetlerimiz her zaman mümkün olduğunda az olmalıdır.

TASK/CONTEXT SWITCHING
Kaçınmamız gereken bir durumdur. Bitirebileceğimiz kadar iş alalım. Birden fazla isin yarım yarım ilerlemesindense teker teker yapılıp bitirilmesi daha hızlı sürüyor.

→ Bir günden fazla süren TASK olmamalıdır
→ TASK ları hep back log un tepesinden alalım. En değerli iş en önce yapılmalıdır.

GÜÇLÜ PIPELINE, AGILE PROJE
Kod silebilmek yazmaktan daha zordur. Kolayca kod silebilecek güçlü bir pipeline kurmak önemlidir. Bundan kasıt şudur: unit testler, integration ve ui testlerin olmalı ki kod üzerinde değişiklik yapmaktan veya silmekten çekinmeyelim.

Root Cause Analysis From Juran

Framework - Scaled Agile Framework

Acil / Araya Giren Maddeler : Bunların etiketlenmesi, daha sonra ekip ve SM tarafından etki analizinin yapılması gerekir. Süreç neden araya giren talep üretiyor. Mutlaka bir yerdeki sıkıntıya işaret edecektir. Acil işler kesinti yaratır. Bunların da iyi yönetilmesi gerekir. Bu maddeler için nöbetçi atanabilir.

Acil Talepler için BUFFER : Sprint planında bu gibi maddeler için BUFFER zaman koymak yaygın bir yaklaşımdır. BUFFER dan kullanılmaz ise (mevcut sprintte her şey yolunda ise) yerine bir sonraki sprintten madde çekilebilir. Motivasyon yükselten bir şeydir.

Acil istekler veya BUG lar için nöbetçi de tanımlanabilir. Ekibin toplama TASK SWITCHING kaybını azaltmış oluruz.

EMAIL HUNTING : Kim ne demişti kendimize kanıt aramak yerine arayıp konuşalım sorunu halledelim. Analiz ve test uzmanları ekibin bir parçası olabilirler. İletişimin artması beklemeleri azaltacaktır.

BROOKS’S LAW

Geciken projeye adam almak işleri daha da kötüleştirir.

Brooks's law - Wikipedia

CHANGE MANAGEMENT

Organizasyonunuzda bir değişim yapacaksanız ( Scrum’ı devreye almak dahil), bu değişime sistematik olarak yaklaşmanız gerekir.

The Prosci ADKAR® Model | Prosci

Awareness of the business reasons for change. Awareness is the goal/outcome of early communications related to an organizational change

Desire to engage and participate in the change. Desire is the goal/outcome of sponsorship and resistance management

Knowledge about how to change. Knowledge is the goal/outcome of training and coaching

Ability to realize or implement the change at the required performance level. Ability is the goal/outcome of additional coaching, practice and time

Reinforcement to ensure change sticks. Reinforcement is the goal/outcome of adoption measurement, corrective action and recognition of successful change

Value Stream Mapping (VSM)

Süreç iyileştirme yöntemidir. Ürünün kodlanmasından müşteriye çıkmasına kadar olan süreç sondan başa doğru şemaya aktarılır. Bir işin toplamda beklemeler ile kadar sürdüğü, aslında asıl işin ne kadar sürdüğü karşılaştırılır. Manuel yapılan işler ve beklemelerin tespitine yarar.

Kitap Önerileri

• Implementing Lean Software Development: From Concept to Cash (Addison-Wesley Signature Series (Beck))
• The Toyota Way: 14 Management Principles from the World's Greatest Manufacturer

MAKİGAMİ (Roll of Paper)

Bir Başka Süreç İyileştirme Yöntemidir.

Makigami, the Art of Systemic Process Improvement - Makigami Info

Bir metodun ismine karar verebildiğin anda kodun yarısını yazmış oluyorsun.

devopsgames

Scrum eğitimi

Scrum Training Series

Resmi SCRUM Guide

Download | Scrum Guides

Spotify Engineering Culture

• Agile Team Organisation: Squads, Chapters, Tribes and Guilds
• Spotify engineering culture (part 1) - Spotify Engineering
• Spotify engineering culture (part 2) - Spotify Engineering

Kısaca Scrum was originally published in Bimar Teknoloji Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Yazılım geliştirme uzman yardımcısından, teknik liderine, işimizin her daim bir parçası olan hata ayıklama, sorun çözme (Troubleshooting) faaliyetini gerçekleştirirken, aşağı yukarı uyguladığımız taktikler aynıdır. İşte bu taktikleri biraz derleyip toparlamaya çalıştım.

Orijinal Sorunu Anlamak

Sorunu sahibinden dinle, anladığına emin ol. Mümkünse kendi gözlerinle gör. Sorunu bir müşteri bildiriyor ise onu ön yargılardan uzakta ve çok iyi dinlememiz gerekir. Söylediği herhangi bir kelime bizi ipucu verebilir. Onu dinler gibi yaparken, ona nasıl cevap vereceğimizi düşünürsek veya kafamızda kod yazmaya başlarsak, müşterinin kelimeleri arasında geçen hayati ipuçlarını kaçırabiliriz.

Ayrıca, “sorunun bizim bilgisayarımızda” alınmıyor olması, “senelerdir o modülden hata gelmiyor olması” gibi mevcut sorunun çözümüne faydası olmayan gereksiz ayrıntıları müşteriye aktararak vakit kaybetmeyelim. Unutmayalım, müşterimizin vakti en az bizimki kadar değerlidir.

Ekip içinden veya müşteriden, “Bana şöyle çelikten, büyükçe bir çekiç lazım. Nereden bulurum” gibi, bir çözümün uygulamasına dair bir soru ve danışmanlık isteği geldiğinde, ona hemen Koçtaş’ı tarif etmeden önce, bu çekiçle ne yapmak istediğini sorun (Asıl problemi anlayın). Belki bu sorun, o duvarda zaten olmaması gereken çiviyi tekrar çakarak değil, ufak bir pense ile oradan alınarak çözülmelidir. Asıl sorunu anlamayı başarırsanız hem bu konudaki fikrinizi söyleme şansını bulmuş, hem de yanlış bir uygulamanın akıl hocalığını yapmamış olursunuz.

Aynı şekilde; 10 MB’dan büyük EXCEL dosyasını nasıl UPLOAD ederim? CONFIG hatası veriyor dendiğinde, neden bu şekilde bir dosya UPLOAD edilecek önce anlamaya çalışın (aslında çaktırmadan sorgulayın). Belki o bilgilerin girildiği, kopyala yapıştır yapılabilen bir ekran vardır. UPLOAD işlemine gerek yoktur.

Hata Kayıtlarını İncelemek

Her zaman en başta hata kayıtlarını kontrol edelim. En büyük bilgi oradan gelecektir. (ELMAH/LOG4NET/LOG ANALYTICS/…) Bazen ortalık karışabilir, acilen hatayı çözeceğiz diye bu en basit adımı atlayabiliriz.

Bunun yanında elinizin altındaki diğer iz kayıtlarından (LOG) faydalanmayı unutmayalım. (Reporting Service Logs, Projenize özel İşlem/Transaction İz Kayıtları, Özel İz kayıtları (Faks sunucu, Smtp sunucu), EventLogs kayıtları da iş görecektir.)

Her Testte Tek Bileşen Değiştirmek

Klasöre yazma hatası alıyoruz. Hem klasöre everyone verip, hem kod içinde impersonate (Kodu başka bir kullanıcı gibi çalıştırma işlemini) yapıp tekrar denersek sorunu neyin çözdüğünü bilemeyiz. Sorun tespitini, dar kapsamdan geniş kapsama değişiklikler yaparak, yani önce kod değişikliği (BiztalkUser’i ile ilgilidir gibi), çözmedi ise everyone deneyerek yapmalıyız.

Einstein’ın Notu — Kod içinde veya ortamda herhangi bir değişiklik yapmadan hata senaryosunu tekrar tekrar çalıştırıp hata alıp vakit kaybetmeyelim.

Sadece Çözüm İçin Gereken Değişikliği Yapmak

Sorun, yapılan bir dizi değişiklikten (denemeden) sonra en sonunda çözüldü ise. Yapılan tüm değişiklikler (kod veya yapılandırma ayarı) geri alınıp, orijinal soruna geri dönüp, burada gerçekten sorunlu senaryo tekrar çalıştırılmalıdır. Sonra asıl çözüm olan değişikliği yapıp tekrar test edilmelidir. Bunu yapmaz isek çözüm ile alakalı olmayan değişiklikleri sisteme yansıtmış neyin nasıl çözdüğünü kendimize anlatamıyor oluruz.

Örnek: Sorun nedeniyle PRODUCTION kodunda değiştirdiğimiz her şeyi geri alıp (UNDO), sorunu tekrar edip, sadece çözen değişikliği yapıp (test edip) CI yapmalıyız.

Hata Ortamındaki Bileşenleri Tanımlamak

Birden fazla bileşenin olduğu karmaşık süreçlerde, bileşenlerin tamamının çalıştığına emin olalım. Sorun bu bileşenlerin birinde olabilir.

Uygulamamızdan faks gitmiyor diyelim. Sorun uygulamadan, faks Sunucusundan, faks olarak giden PDF in yazıldığı dosya sunucudan veya gönderilen faks numarasından kaynaklanıyor olabilir. İlk başta sorunu nokta atışı tespit edemediysek, hata kayıtlarından da bir ipucu elde edemediysek bu bileşenlerden her seferinde birini değiştirip deneyerek sorunu tespit etmeye çalışırız. (Başka faks numarasına gönderme, başka programdan aynı faks sunucusuna gönderme, dosya sunucu ip değiştirme gibi)

Neyi Nasıl Çözdüğümüzün Farkında Olmak

İnternet’ten bulunan kodlar başa bela açabilir. Aldığımız kodun ne iş yaptığını %100 anlamamız ve değerlendirmemiz gerekir (Check-In yaptığımız diğer tüm kodlar gibi).

Çözüm sunan “entry” lerin altındaki yorumları mutlaka okuyalım. Orada paylaşılan risklerin farkında olalım. Eklenen — değişen kodu mutlaka test edelim.

(Rick Strahl’ın blog’undan da alsak) CI yaptığımız her kod bize aittir. O kodun -ne pahasına- ne iş yaptığına emin olmamız gerekir.

Çalışan Örnek İle Karşılaştırmak

Problem yaşanan işlem başka bir ekrandan, başka bir sunucudan, başka bir “local” makinede çalışıyor ise, burada bileşenler karşılaştırılabilir. Sizin WCF servisiniz patlıyor ise, çalışan wcf servisi ile, webserver1 deki application pool çatlıyor ise, webserver2’deki apppool ile karşılaştırırız. Çalışan örneği yakalamak çok önemlidir. “Pis Hataların” çoğu bu şekilde çözülür.

BONUS:

Yazılım projemizdeki hatanın çözümü uzayacak gibiyse, deneysel işler yapacağımız bir sorun ile uğraşıyorsak, hatayı alabileceğimiz en sade proje solution’unu üzerinden çalışmak gerekir. (Tüm projelerin ekli olduğu .sln dosyasını açmak yerine)

Hele ki (Telerik, Dynatrace, Microsoft gibi) bir firmadan “Ticket” açma gibi süreçler işin içine girecek ise, en güzeli sadece hatayı alacak kadar bileşen ve kodun olduğu örnek bir projede hazırlamaktır. Bu genelde düşünülenden daha az zaman alır. Sorun bu projede çözüldükten sonra asıl problemli ortam düzeltilebilir.

İşimiz Gücümüz Sorun Çözme (Troubleshooting) was originally published in Bimar Teknoloji Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Kod okumanın da bir metodolojisi var mıdır? En azından benim için bir tane oluştu. İşte, Pull Request / Code Review Request önüme geldiğinde kodu okurken, cevap aradığım sorular şunlar;

Yapılan değişikliğin karşılaması gereken asıl ihtiyaç nedir?

Yeni özellik, “user story”, “task” veya talepte istenen nedir? Tek tek kod parçalarına bakarken bu parçaların toplamda neye hizmet ettiği aklımızdan çıkmaması gerekir. Ancak bu şekilde her sınıf içinde yapılacak değişikliklerin alternatifi yanında, resmin tümüne dair, yani toplamda işin daha etkin nasıl yapılabileceğine yönelik bir fikir üretebiliriz.

⚠️ İşlevsel testi üzerimize almıyoruz. Bununla birlikte, yeni bir raporu sisteme eklediğini iddia eden bir isteğin “pull request’i” içinde en azından ilgili raporun olmazsa olmaz tanımlarının yapıldığını görmeliyiz.

Kopyalanan bir mantık-bilgi var mı?

Çok genel bir iş sıfırdan yazıldıysa / veya olması gereken modülden farklı bir yerde yazıldıysa şüphelenmek gerekir. Genel bir işin tekrar yapıldığından veya kopya kod olduğundan şüpheleniyor isek, eklenen kısımdan bir parça (özel bir parça, kullanılmış sabit gibi filtreye eklenen bir alanın filtreye ekleme kodu gibi ) alıp, “solution” içinde arayabiliriz. Birebir aynı kod parçasına rastlama olasılığınız yüksektir. Mevcudu kopyalamanın yanında, toplamda talep için çıkılan kod içinde kendini tekrar eden kısımlar var mı?

Aynı satırlar birden fazla sınıfa aynı şekilde eklenmiş ise muhtemel bir “refactor” ihtiyacı vardır.

❗Bilerek ve isteyerek blok olarak kodun klonlanması ciddiyetle ele alınması gereken uygunsuz bir durumdur. Mutlaka irdelenmelidir ve arkasındaki neden ortadan kaldırılmalıdır.

Yazılan kod içinde bir varsayım var mı?

Özellikle birim ve entegrasyon testleri zayıf projelerde burası tam bir madendir. (Az sonra örnek vereceğim) belli başlı varsayımlar “developer” tarafından (kendim dahil:) “fütursuzca” kodlanabilir. Kod review bunları durdurmak için bir fırsattır. İşin özünde işlem yapan birimler kendini garantiye alıyor mu buna dikkat edilmelidir.

❓Onayla işlemi yapan metot içinde, buraya gelen kayıt zaten “onaya hazır” statüsündedir diye bir varsayım var mı? Yoksa kaydın statüsünün bu işlem için uygun olduğu işlemin başında doğrulanmış mı?

❓Metoda liste geçilmişse bu liste zaten dolu gelmiştir gibi bir varsayım var mı? (En sık yapılan varsayımlardan biridir. Bir sistemi çalışmaz hale getirecek örneğe rastlamışlığım vardır. Sonra “müdürler” aramaya başlar:)

❓ “upload” edilen dosyanın boyutu ile ilgili bir doğrulama var mı yoksa kullanıcının “sistem dosyaları arşivini” zaten buraya yüklemeyeceği mi varsayılıyor. NOT: Kullanıcı bu eylemi istemeden de gerçekleştirebilir. Yazacağımız doğrulama metotları bunların da önüne geçecektir.

Yazılan kod içinde <kaldırılan bir çit> var mı?

Silinen kodlara, değişen “IF-ELSE’lere, filtreleme ve relation ilişkilerindeki değişikliklere özellikle dikkat edilmelidir. Bunlar mevcut veriyi ve akışı değiştiren müdahalelerdir.

Çit kaldırmak (önceden daha özel bir kapsamda çalışan bir kodu daha genel için çalışan bir kod haline getirmek), çit koymaktan (kısıt getirmekten) daha tehlikelidir. Bulması gereken kaydı bulamaz ise iş kesilir hata kaydı açılır. Ama çiti kaldırır ve bulmaması gereken kaydı bulup işlemesine neden olursak bundan hiç bir zaman haberimiz dahi olmayabilir. Bir çit kaldırıldı ise bunun zamanında ne amaçla konulduğu anlaşılmış, artık gerek olmadığından emin olmak gerekir. Biz koda bakınca emin olamıyor isek mutlaka sorgulamalıyız.

Atama ve kontrollerin muhatapları uyumlu mu?

Bu tip hataların bulunmasını beklediğimiz asıl yer kod review değildir aslında. Bununla birlikte kodu okurken (bir yandan kafamızda çalıştırırken) Atamalarda ve kontrollerde, sağ tarafta oluşturulan ifade ve değer ile atama yapılan / kontrol edilen sol taraf uyuma bakmamız çok efor sarf ettirmez, hatta belli bir tecrübeden sonra bu uyumsuzlar hemen göze batar. Yakalarsak iyidir. Yoksa zaten testlerde bu tip hataların yakalanması beklenir.

❓ Listeleme işleminde filtre oluştururken kullanıcının TC Kimlik Nu. bilgisine, ekrandaki vergi numarası alanından mı atama yapılmış?

❓ Mantıksal olarak, çağrılan metot, atama yaptığımız alan ile uygun mu? entitiy.FaturaToplamTutar=BolgeselVergiHesapla();

Build’e etki etmeyen maddi ve mantıksal bir hata yapılmış mı?

Yapılan bir dizi değişiklikle çelişen, genel desenin dışında kalan bir değişiklik var mı? Böyle bir durumda mutlaka kod kontrol ettirilmelidir.

❓ Bir hata maddesi üzerine bir dizi metot içinde kur bilgilerinin TL’ye dönüşümü ile ilgili değişiklikler yapılırken sadece tek bir metotta kurun USD olmasını varsayan bir kısım bırakılmış. Burada hemen “developer”a bilgi vermek, her şey kontrol altında mı diye sormak gerekir.

Standart dışı bir kullanım var mı?

❓Yayınlanmış olan genel veya projeye özel gözden geçirme kontrol listesine aykırı bir kullanım var mı?

Bu işi daha anlaşılır (sade) bir şekilde yapmak mümkün mü?

❓Karmaşık yapılar yerine daha basit düşünülüp, daha basit, okuyanın rahat anlayıp müdahale yapacağı şekilde yazmanın bir yolu (modelleme imkanı) var mı?

Biraz karmaşık algoritma içeren sorunlar, genelde nispeten daha az tecrübeli veya bazen mevcut framework’e tam hakim olmayan yazılımcılar tarafından akla gelen ilk şekliyle, düz mantık ile (muhtemelen deli gibi kaynak tüketecek şekilde) koda dökülerek çözülebilir. Böyle durumlarda gerekirse o kısmı olması gerektiği gibi daha performanslı ve zarif bir şekilde yeniden gerekirse beraber yazmak gerekebilir.

Bu işi daha az kaynak ile daha hızlı yapmanın bir yolu var mı?

Yazılım geliştirme faaliyetinin belki de her aşamasında sorulacak soru budur. Aynı IF / Metot / Sınıf daha az veri çekerek, daha az veri tabanına giderek, daha az kod yazarak yeniden düzenlenebilir mi düşünmemiz gerekir.

Bu konuda yine teknik kabiliyetler öne çıkmaktadır. Hangi framework’te çalışılıyor ise örneğin veri çekmek için değişik senaryolarda en etkili yöntemlerin ekibe aktarıldığından emin olunması kritiktir.

Kod Review Kafası was originally published in Bimar Teknoloji Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Senin bilgisayarında çalışıyor çünkü …

Senin kullanıcın “admin” olarak tanımlı, her sunucuya girer-çıkar yazar-silersin, kullanıcının standart tanımı belki “read-only” bile değil.

Sen uygulamaya tüm yamaları yüklenmiş Windows 10'dan, kullanıcı Windows 2008 R2 TS üzerinden erişiyor.

Sen hatayı o “bug” kaydına sıra geldiğinde, sana uygun zamanda tekrar etmeye çalışıyorsun, hata ise sistemi kilitleyen başka bir sorgunun çalıştığı anlarda meydana geliyor.

Sen Chrome kullanıyorsun, hemen derleyip sayfayı ekrana basıyor, kullanıcıda artık “sistem destek” zamanında ne kurdu ve hangi versiyonda bıraktıysa o var.

Sen bilgisayarını sunucuyla aynı switch’e bağlayabilecek kadar sistem odasına yakınsın, kullanıcın Senegal Telekom — VPN — Türkiye artık nereden kaç hop ile geliyorsa o kadar uzakta.

Yani aslında, sen derleyip, “Check-In” yaptığın şeyde hata ararken, kullanıcı bunu mümkün kılan birçok bileşene bağlı olan, ekranında o anda çalışması gereken uygulamaya yansıyan problemden bahsediyor.

Senin bilgisayarında çalışıyor çünkü … was originally published in Bimar Teknoloji Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Uygulamamızın derlenmesi ve istenilen işi bir şekilde yapması üniversite dönem ödevimiz için yeterli olabilir. Fakat iş kurumsal bir yazılım üretmeye gelince bundan fazlası gerekir.

Yazılım geliştirme faaliyeti sırasında aldığımız bazı kararlar yazılımın kalitesine olumlu katkı sağlarken, kimisi de buna engel olur.

Yazılım kalitesi dediğimiz şey aslında hangi niteliklerdir, bizim hangi faaliyetlerimiz bu niteliklere nasıl etki eder, işte bu yazıda bunlardan bahsetmek istiyorum.

Bir yazılım ondan istenen işi doğru olarak yapacak işlevlere sahiptir. Bununla birlikte …

��KALİTELİ YAZILIM GÜVENLİDİR.

🚫Yetkim olmayan işlemi çalıştıramam.

🚫Yetkim olmayan bilgiyi göremem.

🛡️Bilgi veya iletişimim ifşa olmaz.

🛡️Uygulama ve sistem zayıflık (zafiyet) içermez.

Kaçınalım❗

❌ İhtiyaç olandan daha geniş yetki tanımı (sadece okuma işi olan bir sürece / kullanıcıya admin yetkisi vermek, “everyone” erişim yetkisi verilen klasör vb.)

O an için uygulamamızın “klasöre yazma sorununu” bu şekilde çözerken sonra başımıza gelebilecekleri tahmin etmemiz zor olabilir. Bknz.: https://en.wikipedia.org/wiki/CryptoLocker

Bir token yaratıyorsanız, o token ile yapılacak işin gerektirdiği kadar yetkiyi — işin gerektirdiği süreyle- verdiğinize emin olunuz. API’den okuma sadece okuma yapacaksanız, okuma yetkisi vermek yeterlidir. Bu tip anahtarların kötü niyetli kişilerin eline geçtiğinde hangi işlemleri yapabileceğini bildiğinize emin olun.

💡 Sadece yetkiyi verirken değil, isterken de bu prensibi uygulayın. Bir sisteme bağlanmanız gerekiyor diyelim. Sadece okuma yapacaksanız, readonly yetkisi olan bir kullanıcı adı şifresi isteyin veya TABLO yerine bir VIEW’e yetki vermelerini isteyin.

❌ kullanıcı adı, şifre gibi hassas bilgilerin koda gömülmesi: Bu bilgiler kaynak koddan çıkartılabilir ve istismar edilebilir. Koda gömülü şifre sistemde değiştiğinde ilgili işlev çalışmaz hale gelir. Günceleyip devreye almak için kesinti yapmak gerekir.

Java static code analysis: Hard-coded passwords are security-sensitive

❌ Kimlik, pasaport veya diğer hassas bilgilerin, onay alınmadan sisteme kayıt edilmesi, bunların gizleme ve yetkilendirme işlemlerinin yapılmaması. Bknz.: https://www.kvkk.gov.tr/Icerik/4185/6698-Sayili-Kisisel-Verilerin-Korunmasi-Kanununun-Amaci-ve-Kapsami

Sürdürelim👍

🔏 İşlemlerde şirket, bölge, ofis, kullanıcı, rol gibi tanımlar üzerinde yetki kontrolü yapılır. Bir gruba tanımlanmış işlemi diğer grup çalıştıramaz, onun verisini göremez.

🔏 Bir bilgi özellikle istenmedikçe hiç bir çıktıda (dosya, rapor, ekranda) yer almaz. Çıktılar testler esnasında bu kapsamda kontrol edilmelidir. Bu bilgi neden burada diye her zaman sorgulamak gerekir.

🔏 Yetki — Güvenlik kontrolü yapan bir metodun varsayılan dönüş değeri “false/yetki yok/görünmesin” dir. Önce bu kod yazılır, sonra yetkili olduğu senaryolarda “true” döndüren kodlar yazılır.

🔏 Kullanıcı şifresini karmaşıklığı ayarlamak, periyodik olarak değiştirmeye zorlamak ve bunun gibi bir çok kritik konuyu elle kodlamak gerine bu sorumlukları güvenli alternatiflere devredebiliriz.

🔏 Canlı sistem erişim bilgileri, sadece sorumlusunun erişebileceği modern yöntemler kullanılarak saklanır. (yetkili kaynakta bir yapılandırma dosyası, “Key Management”, “Key Vault” vb. hizmetler )

🔏 Yazılım kalitesi başlığı altında konuştuğumuz “Yazılım Güvenliği” pratikte kendi başına değerlendirilen bir unsurdur. Yazılım ekiplerinin bu konuda eksiklerinin tamamlanması, her aşamada uluslararası güvenlik standartlarının uygulanması, kod gözden geçirme, statik kod tarama gibi faaliyetlerinin güvenlik başlıklarının öncelikli olarak ele alınması gerekir.

🛑 Yazılım güvenliği konusunda hem prensip hem uygulama olarak ortaya konmuştur standartlar vardır. OWASP bunlardan en iyi bilinenidir. Bu konuda rehber olacak en önemli 2 kaynağı aşağıda paylaşıyorum.

• OWASP Top Ten Web Application Security Risks | OWASP Foundation
• AJAX Security - OWASP Cheat Sheet Series

🚲KALİTELİ YAZILIM VERİMLİDİR.

🚀 Yüksek performans gösterir.

🔋 Az kaynak tüketir.

⬇️ Response Time

⬇️ I/O, Bellek, CPU, Ağ Trafiği

Kaçınalım❗

💣 Döngü içinde açıkça veri tabanı çağrısı yapmak (veya arka planda bu çağırımı yapan kod yazmak)

❌ Döngü İçinde string birleştirmek

❌ Sorgularda gereksiz fonksiyon kullanımları. (CAST, DISTINCT, UPPER, REPLACE, SUBSTRING vb.)

❌ SELECT * FROM şeklinde sorgu çalıştırmak veya bu sorguyu oluşturan kod yazmak. ( Hali hazırda “hazır” olan View’lere bir alan da kendimiz ekleyip içinden çıkılamayan performans ve refactor sorunları yaratmak)

Sürdürelim👍

✔ Gerektiği kadar ( ihtiyacımız olan kadar) veriyi çekelim.

✔ Elimizde zaten olan veriyi çekmeyiz. Her zaman ön-belleklemeyi değerlendirmeliyiz. ( I❤CACHE) 🌟

✔ Önce Veri Tabanı Çağrısından Bağımsız Kontrolleri Yapmak

VT çağırımı yapmadan önce, eleyebileceğimiz senaryoları önce kontrol etmek, gereksiz çağırımlara engel olacaktır.

Örneğin, bir IF kontrolünün operatörleri arasında, hali hazırda değeri atanmış bir tane var ise, önce sadece onu içeren bir IF yazarak, veya o ifadeyi IF kontrolü içinde sol tarafa alarak gereksiz veri tabanı sorgusundan kaçınmış oluruz (ifadeler soldan sağa doğru işlenir). Şöyle ki;

IF ( TablodaKayitVarMi() || tutar==0) yerine

IF ( tutar==0 || TablodaKayitVarMi()) şeklinde yazarsak

Metoda vs. gitmeyen zaten değerini almış tutar==0 kontrolünü OR ifadesinin soluna alırsak, tutar==0 olan tüm senaryolarda veri tabanı çağırısı veya başka işlemler yapan TablodaKayitVarMi() metodunu boşuna çalıştırmamış oluruz.

✔ Sadece ihtiyacı karşılayacak kadar kaynak yaratırız. (Örneğin: LOG yazma ihtiyacı için .doc❌ uzantılı dosya kullanılmaz. Bu iş için çok daha az kaynak tüketen .txt✔ uzantılı dosya yeterlidir.)

✔ Kaynaklar (connection, stream, vb.) işi biter bitmez iade edilir. (kapatılır, using{} kapsamında kullanılır, “dispose” edilir vb.)

✔ Uygulama performansı izlenir ve iyileştirilir.( App.Mon. Tools, Veri tabanı logları, IIS logları)

✔ Performans ve kapasite sorunlarında çözüm için donanım kaynak artışına değil, ihtiyaç artışının arkasındaki asıl sorunu çözmeye odaklanılır.

✔ Çıktıların saklanmasını isteyen taleplerde mutlaka saklama süresini (“retention”) sorgulanır. Erişime en az ihtiyaç duyulan dosya en yavaş (en ucuz) kaynakta saklanır.

📐KALİTELİ YAZILIM GÜVENİLİRDİR.

⚙️Kesinti yaşanmaz.

🐞Hata üretmez. (Bu biraz iddialı oldu. Ürünün bilinen risklerini azalttığımız için hata üretmemesi beklenir diyelim:) .

Kaçınalım ❗

❌ “Single Point Of Failure” tasarımlar ( 3 web sunucu var iyi güzel ama tek Authn. sunucun çökerse uygulamalara girilmiyor)

❌ Bire bir aynı olması gereken sistemler arasındaki ( bir uygulamanın test ve canlı sunucusu arasındaki veya aynı uygulamanın tüm canlı sunucuları arasındaki) yapılandırma ( patch, kurulum vs. ) ayarları farklılıkları.

❌ Eksik UC,CC, İş Kuralı doğrulaması (Validation)

❌ Static Değişkenler : ( Birden fazla “instance’in” sanki sadece kendisine aitmiş gibi ortak bir değişkeni güncellemesi veya oradan okuma yapması)

💣 Eksik NULL Kontrolü

“Nullable” nesneler ile iş yaparken, yazdığınız yerde o nesne “null” geldiğinde uygulamanızın nasıl davranması gerektiğini bilmelisiniz ve o senaryoyu kapsayacak (destekleyecek) şekilde kodunuzu yazmalısınız.

💣 Eksik “Count”, “Length” Kontrolü

Bir listenin, referans ettiğimiz elemanının o listede olduğundan emin olmamız, kontrol etmemiz gerekir. En yaygın yapılan hata, boş bir listenin ilk elemanını okumaya çalışmaktır. (collectionX[0].Ad)

💣 Exception yutmak

❌ Doğrulamak yerine, varsayarak kod yazmak (liste dolu gelir, 10’dan fazla seçmez, yetkisi olmayan şirketi seçip buraya gelemez, bu işlem exception almaz, dosyayı diske her durumda yazar varsayımları vb. )

❌ TR/EN, date time format, UTC, regional settings farklılıklarının göz ardı edilmesi

❌ Kodlama ve testlerde sadece mutlu senaryoya odaklanılması, uç senaryoların göz ardı edilmesi ( seçim yapmazsam, birden fazla seçim yaparsam, girmeme izin verilen maksimum karakter sayısını kullanırsam ne olur bakış açısıyla kodlamak / test etmek gerekir)

Sürdürelim👍

✔ Sürekli devreye alım ve kısa kesinti süresi

✔ Load Balancer / Web Application Firewall / Clustering yapıları

✔ Kod gözden geçirme faaliyeti

Kod Review Kafası

✔ Manuel Testler, Onay testleri

✔ Test Otomasyonlar (Unit Testler, Automated UI testler)

🛠️KALİTELİ YAZILIMIN BAKIMI KOLAYDIR.

🔌Değişiklikler rahat yansıtılır.

🔧Kod Bakımı / Refactor kolay yapılır.

🕵️Hata ayıklamak kolaydır.

Kaçınalım❗

❌ Tekrar Eden Kod blokları

Kopyala-Yapıştır; Daha önce benzer veya aynı işi yapan bir kod parçası bulunup, yeni yazılan yere aynen yapıştırır.

Yeni yazılmak istenen işlev, hali hazırda proje içinde olması gereken sınıfların içinde bulunmasına rağmen, proje yapısına hakim olunmadığı veya daha kötüsü özensizlik nedeniyle, oradan çağırmak yerine, kullanıldığı yerde tekrar yazılır.

Bir işlev daha önce ayrı bir metot olarak yazılmadığı için, kod içerisinde farklı parametreler için aynı kod blokları tekrar yazılır. Yapılması gereken şey önce parametre ile farklı iki kullanımı destekleyecek şekilde bir metot yazıp, hem eski kullanımı, hem yeni yazacağımız kodu bu metodu çağıracak şekilde düzenlemektir.

Örneğin Ekle ve Güncelle işlemleri içinde tekrar eden doğrulama ( validation ) kodlarını, validation adında bir sınıf altında tekleştirip, 2 işlem içinden orayı kullanmak iyi bir pratiktir)

❌ Sihirli Sayılar ( IF kullaniciCinsiyet == 1)

👍( IF kullaniciCinsiyet== Cinsiyet.Erkek)

❌ Çarşaf ( Büyük ) Metotlar : Bir metot ne kadar büyük ise, orada tekrar eden kısımların veya metodun asıl işlevini değil de yan işlevleri yapan kod parçalarının olma olasılığı yüksektir. Böyle metotlarda iyileştirme yapılması ve işlevlerin metotlara ayrılması gerekir. Bir ekran boyunu geçen bir metot, uzun olarak ifade edilebilir.

Bir işi yapan tek bir metot olmalıdır.

Bir metot sadece bir iş yapmalıdır.

Yeni bir işlev veya değişiklik, sadece bir parça kodu (veya tanımı), değiştirerek (veya ekleyerek) koda yansıtılabilmelidir

❌ Bağımlı İşlemler ( uygulamada bir işleyişi değiştirmek için 2 veya daha fazla sınıfta değişiklik yapmak zorunda olmak)

❌ Koda gömülü “sabitler” (aslında değişebilecek bilgiler)

Kod içerisinde string bir bilgiyi, sabit olarak bir atama veya kontrolün içinde kullanmamız gerekir. Bu bilgiler çoklu dil desteğini sağlayabilmek ve daha kolay bakım yapabilmek adına ilgili “resource” kullanılarak getirilmelidir.

❌ /* yorum satırı yapılmış kodlar; */

Kodlar yorum satırı haline getirilmek yerine doğrudan silinmelidir. Bu kodlar daha sonra o kodu okuyan kişiyi şüpheye düşürüp kafasını karıştırabilir. (Geri alınacak mı? Neden silinmedi? Bir sebebi varsa öğrenmeliyim kim yorum satırı yapmış? vs.)

Silinen kodlara, ne zaman, hangi istek nedeniyle silindiği bilgisine kaynak kontrol (TFS, GIT) araçlarından daha sonra zaten ulaşabiliriz.

Kod içerinde değişiklik yapan kullanıcı, değişiklik numarası gibi gereksiz bilgiler yorum satırı olarak girilmemelidir. ( /* task-1232 *Apul */ gibi)

Kodun içinde yorum gerektirmeyecek, yapılan işin çok net olduğu kodlar için yorum satırı yazılmamalıdır. (//şimdi kayıt ediliyor, //karşılaştırma gibi)

//****************** gibi kodun okunmasını zorlaştıran yorum satırı yazılmaz. (flowerbox).

Yorum Yalan Söyleyebilir, Kod Asla : Bir metot mümkün olduğunca, yorum satırı gerektirmeyecek sadelikte yazılması, isimlendirmelerin de aynı sadelikte ve anlaşılır şekilde yapılmış olması gerekir. Kodun kendisi yorum satırı gibi net olmalıdır. Yazılan metodu anlatmak için fazlaca yorum satırı gerektiriyor ise, o metoda bir refactor yapılması (iyileştirmesi veya yeniden daha sade/basit yazılması) değerlendirilmelidir.

Metodun başına gelip /// yazığında, “Summary” girişi için gerekli TAG lar otomatik olarak açılır. Metot ne iş yaptığı bir bakışta çok net anlaşılacak ( IkiSayiTopla(long A long B) ) gibi bir metottan bahsetmediğimiz sürece bu “Summary” yorumları mutlaka yazılmalıdır.

🚮 Çöpler (kullanılmayan değişken, metot, sınıf, proje, klasör, site, sunucu, dns tanımı vb.) çöp oldukları (veya öyle oldukları sonradan anlaşıldığı) anda silinmelidir. Çöpler nasıl koku yapar, sinek çeker, ayağa takılır. Yazılımda çöp, dosya boyutlarını artırır. Devreye alımı uzatır. Değişiklik ve iyileştirme (refactor) süresini artırır. İşi gücü bırakır, bu kullanılıyor mu niye burada diye şirket içinde dört dönersiniz.

Sürdürelim👍

✔ Makinenin değil, bir insanın anlayacağı açıklıkta sade kod yazmak.

✔ Constants, Enums kullanılır ( IF kullaniciCinsiyet== Cinsiyet.Erkek)

✔ İsimlendirmeler sade, alakalı, anlaşılır ve ilgili proje standartlarına uygun olmalı. ( bool isSuccessful✔, bool isEmpty✔, bool updated❌)

Sahadan Temiz Kod - İsimlendirmeler

✔ Mevcut Framework’un özelliklerini (Kütüphane, metod, işlevlerini) kullanır.

Mümkün olduğunca çalıştığımız Framework’un sağladığı yapıları kullanmaya çalışmalıyız. Framework şemsiyesinden çıktığımız yerlerde geliştirim ve hata ayıklamalarında kapsam dışında kalırız.

Hem çalıştığımız platformun sağladığı (.NET, JAVA, vb.) hem de özel olarak projede kullandığımız özel Framework’ler buna dâhildir. Bu Framework’lerin sağladığı imkanlara hakim olmalıyız. Gerekirse bu konuda mentorumuzdan / koçumuzdan / ilgili dokümantasyondan veya çevrim içi kaynaklardan destek almalıyız.

Özellikle “string” manipülasyonlar, I/O işlevleri ve matematiksel işlemlerde, sıfırdan kodlamaya başlamadan önce, bu işin acaba ilgili kullandığımız Framework’te yapmanın bir yolu var mıdır diye kısa bir araştırma yapmak faydalı olacaktır.

✔ Kodlar Unit Test ile kapsanır.

✔ Teknik borç yönetilir. Eritilir.

✔ Temiz kod yazımı araçlar ile desteklenir ( Sonarlint, EsLint, Sonarqube, vb.)

Temiz kod, yazılım geliştirme sürecinde anlaşılabilir, sürdürülebilir, okunabilir ve kolayca bakım yapılabilir olan kodu ifade eder. Temiz kodun özellikleri şunlardır;

Okunabilirlik: Temiz kod, anlaşılır ve açık bir şekilde yazılmıştır. İsimlendirme standartlarına uygun değişken ve fonksiyon isimleri kullanılır. Kodun akışı ve yapısal düzenlemeleri anlaşılır ve mantıklı bir şekilde oluşturulur.

Basitlik: Temiz kod, gereksiz karmaşıklıklardan kaçınır. Karmaşık yapılar yerine basit ve anlaşılır tasarımları tercih eder. İşlevler ve sınıflar, tek bir görevi yerine getirmek için küçük ve öz olacak şekilde düzenlenir.

Uyumluluk: Temiz kod, kabul edilen standartlara, en iyi uygulamalara ve tasarım prensiplerine uygun olarak yazılır. Kodlama standartları ve kuralları takip edilir, kodun tutarlılığı ve uyumluluğu sağlanır.

Erişilebilirlik: Temiz kod, diğer geliştiricilerin kolayca anlayabileceği ve üzerinde çalışabileceği şekilde düzenlenir. İçerdiği işlevler ve modüllerin birbirleriyle uyumlu ve bağımsız çalışabilir olması hedeflenir.

Test Edilebilirlik: Yazdığınız kodun unit testini yazmakta zorlanıyorsanız muhtemelen bir şeyde bir şeyi yanlış yaptık demektir. Temiz kod, test etmek için kolayca bölünebilir ve test edilebilir bir yapıda olmalıdır. Kodun bölümleri ayrı ayrı test edilebilir ve hatalar kolayca tespit edilebilir.

Hata Düzeltme Kolaylığı: Temiz kod, hataları tespit etmek ve düzeltmek için uygun yapıda olmalıdır. Hata ayıklama ve sorun giderme süreci daha kolay ve verimli olmalıdır.

Sonuç olarak; Temiz kod yazmak, yazılımın uzun süreli sürdürülebilirliğini, geliştirme sürecini kolaylaştırmayı ve takım çalışmasını iyileştirmeyi sağlar.

The Solution to Technical Debt - Crisp's Blog

❤ KALİTELİ YAZILIM İYİ BİR KULLANICI DENEYİMİ SUNAR.

🎯 Kullanıcı odaklı bir çözüm sunar. Onların ihtiyaçlarını ve beklentilerini anlar. Onların gereksinimlerine göre tasarlanır.

🕹️ Kolay kullanılabilirdir. Basit ve sezgisel bir ara yüz sağlar. Uygulamayı ilk kez kullanan biri eğitime ihtiyaç duymadan onu kolayca kullanmaya başlamalıdır.

💬 Kullanıcı ile açık ve sade bir dil ile iletişime geçer. Jargondan kaçınır, yardımcı yönergeler sağlar, hata mesajları bilgilendirici ve yönlendiricidir.

🎨 Kullanıcılara özelleştirilebilir ve kişiselleştirilmiş deneyimler sunar.

↩️ Hata Toleransına sahiptir. Kullanıcıların hatalar yapabileceğini ön görür. Bunları düzeltmek için uygun geribildirimler ve düzeltme seçenekleri sunar.

📢 Kaliteli bir yazılım, kullanıcısına kulak verir. Hata bildirimlerini ve önerilerini kolayca iletebileceği işlevler sunar. Geri bildirimlere (olumlu veya olumsuz) bir cevap verilir.

🚀 Değişiklikler ve hata çözümleri çabuk devreye girer. Kullanıcı, sorunları ile baş başa bırakılmaz.

💖 Kullanıcı uygulamayı severek kullanır.

Kaçınalım❗

❌ Kullanımı zor, işi zorlaştıran ekranlar.

❌ Özensiz hazırlanmış ve yardımcı olmayan mesajlar.

❌Uygulamada bir işi halletmek için birden fazla ekranda işlem yapılması.

Sürdürelim👍

✔ Kullanıcı uygulamayı kullanırken önemsendiğini hisseder. Bileşenlerin yerleşimi, akış onun istediği gibi, olması gerektiği zamanda olmasını gerektiği gibidir.

✔ Kullanıcı istediği çıktıyı üretebilmek için oradan oraya ekranda dolaşmaz veya birden fazla işlem yapmaz.

✔ Hata çözümleri ve yeni istekler çabuk devreye alınır. Geri bildirimleri karşılık bulur.

Kaliteli Yazılımın Nitelikleri & Temiz Kod+ was originally published in Bimar Teknoloji Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Yazılım geliştirmede isimlendirme işini ne küçümsemek ne de abartmak doğrudur. Önemli olan nokta isimlendirmedeki şansımızı, bizden sonraki yazılımcıya mümkün olan en doğru mesajı verecek şekilde ustaca kullanmaktır.

İsimlendirmelerde dokunduğu yeri en iyi anlatan, en sade tercihi yapmanız gerekir.

Kaliteli bir uygulamanın bakımı kolaydır. Uygun isimlendirme tercihleri kodun bakımına dolayısıyla kalitesine olumlu katkı sunar. İsimlendirme konusunun önemi buradan gelmektedir. Şimdi, daha önce okuduğum kodlarda karşılaştığım bazı geliştirilebilir isimlendirme örneklerini aktarmaya çalışacağım.

Olumsuz İfade Kullanmak ❌

İnsan beyni olumlu bir ifadeyi daha rahat çözer. O nedenle ToplamAgirligaDaraDahilEdilmeyecekMi şeklinde bir ifadeyi anlamakta biraz zorlanabiliriz. Bunun yerine üzerinde biraz düşünüp DaraHaricMi diye bir tercihte bulunabiliriz.

Yapılmamalı yerine EngellensinMi, GözArdiEdilsinMi gibi ifadeleri kullanabiliriz.

Özel İsim Kullanmak ❌

Bir rapor veya kod sınıfını, veya hesap yapan bir metodu isimlendirirken “İspanyaMuhasebeRaporu”, “İzmirKonsimentosu” gibi ifadelerden kaçınalım. “AltToplamDetayliMuhasebeRaporu” “YaldizliKonsimento” gibi sınıfın/raporun içeriğinden esinlenmiş isimler tercih edelim. Böylece bu özelliğe sahip ilerideki kullanımlar ( örneğe göre başka bir ülke) için aynı sınıfı kullanmak aklımıza gelecektir. Tersi durumda genelde kopyalanıp ismi değiştirilir. Kopya kod olacağı için bunu istemeyiz.

(Bu kuralın tek istisnası şudur: Örneğin Aliağa limanı logolu, sadece Aliağa limanındaki sistemde çalışan, başka bir limanda kullanılması hemen hemen imkansız özel rapor ve sayfalar istisnadır. Bunları en iyi ifade eden isim gerçekten AliagaRaporu olacaktır.)

Abartılmış Metot Adları❌

public void FaturaDurumuStopajsaDegistir(…) Metot isminde, metodu çağıran sınıfı ilgilendirmeyen, metodun o işi hangi iş kuralına göre yaptığına dair detaya yer verilmez. Bu detay değişebilir,metot ismi bu değişiklikten etkilenmemelidir.

Doğrusu; public void FaturaDurumuDegistir(…)

Parametrelerden Edineceğim Bilgiyi Metot İsminde Tekrar Etmek ❌

public string TipTurKullanarakSistemDonusumGetir(long tipId, long turId)

Metot adında parametre isimlerini barındırmanın gerek yoktur. Aksi taktirde parametre ara yüzü değişirse metot ismi uygunsuz hale gelir.

Unutmayalım. Metodun ne iş yaptığını ne döndüğünü neler kabul ettiğini sadece adından anlaşılmaz. Parametre setim ve dönüş tipim de, metot ismi ile birlikte bir şeyler söylüyorlar. Bunların aynı şeyi tekrar etmelerine gerek yoktur.

Doğrusu; public string SistemDonusumGetir(long tipId, long turId)

Büyük Metodun İsmine Yansıması ❌

private void FaturaOnaylaVeGonder(..) -> Kendinizi bu şekilde isimlendirme yaparken bağlaç kullanırken buluyorsanız belli ki bir şeyler ters gitmiştir. Bu örnek için metodun birden fazla iş yapıyor olmasından şüphelenebilirsiniz ve bunları ayırmayı düşünebilirsiniz.

Doğrusu ; private void FaturaOnayla(..)

Metot İsminin Dönüş Tipine Uydurulması ❌

private DataTable PersonelAdSoyadTelefonBilgisiDondur(..) -> Bu örnekte metodun dönüş tipini tekrar değerlendirmek gerekir. Bu “ad soyad telefon” bilgilerini bir arada tutan ne ise, başka bir deyişle bunların hepsini kapsayan ifade ne ise onu kullanmak gerekir. Sonrasında bu ifadeye uygun bir sınıf yaratmak ve dönüş tipi olarak bunu kullanmak en uygun çözüm olacaktır.

Doğrusu ; private IletisimBilgi PersonelBilgiDondur(…) (IletisimBilgi,ad, soyad ve telefon bilgisini içeren yeni bir sınıftır)

⭐İsimlendirmedeki Güzel Pratikler ⭐

Tanımladığımız sabitin birimi hakkında net olmak için, değişken ismine bu birimi eklemek güzel bir pratiktir.

long timeOutInSeconds = 60

long maxFileUploadSizeInMb=5

Esen Kalın

Serkan

Sahadan Temiz Kod - İsimlendirmeler was originally published in Bimar Teknoloji Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Bu sözü, yazılım işi için “Teknik borcu kapatamıyorsan, en azından daha fazla borçlanma” diye çevirebiliriz.

Zira, o an için aslında ‘yanlış olduğunu bildiğimiz’ fakat ‘daha az zaman almasının’ cazibesine kapıldığımız bu seçimler, var olan sorunu derinleştiriyor ve eninde sonunda zamanı gelince birinin yapmaya mecbur kaldığı düzeltmeyi/iyileştirmeyi (aslında bir ‘Refactor’ü ) zorlaştırıyor.

Benim tecrübe ettiğim bazı ‘kazmayı bırakma anları’ şunlar;

• Bu class’da zaten hiç yazılmamış diyerek, birim test’i yazmayı es geçmek yerine, artık her değişiklikte ve yeni geliştirimde birim testlerini yazmak.
• İhtiyacımız olduğunda, düşük performanslı veya güvensiz, “önceden yazılmış hazır” bir metodu o şekli ile kullanmaya devam etmek yerine, yenisini yazıp, üstüne önceki çağırımları da iyileştirmek.
• 2 yaşına girmiş 20+ açık Sonarqube Issue’ların (Statik kod taraması sonucunda çıkan bulguların) hepsinin birlikte planlanması beklemeyi bırakıp, artık yeni Issue’ları aynı Sprint’te kapatmaya başlamak.

Sizin de eğer varsa kazmayı bıraktığınız anlarınızı burada paylaşırsanız, minnettar olurum.

Esen Kalın.

Bir çukurun içindeysek, işe kazmayı bırakmakla başlamalıyız. was originally published in Bimar Teknoloji Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Devops, yazılım değişikliklerini hızlı ve güvenli bir şekilde yapma amacı taşıyan yaklaşım ve uygulamalardır.

“Devops yapmak”, “Agile olmak”, bunlar el ele tutuşup hep birlikte karşı tarafa atlayabileceğimiz bir şeyler gibi anlatılabilir, bu şekilde anlaşılabilir. Halbuki bunlar birer süreçtir ve “top yekûn” geçişten önce yapabileceğimiz seçimler, hayata geçirebileceğimiz uygulamalar vardır.

Devops hem taleplerinin hızla gerçekleştirilmesini bekleyen “tez canlı” Developer’ların, hem de her günü sistemlerin güvenli ve kesintisiz çalışması stresi ile geçen “ihtiyatlı” sistemcilerin endişelerini ortadan kaldıracak, onların uyum içinde beraber çalışmasını sağlayacak uygulamalardır diyebiliriz.

Değişiklikler çabuk ve güvenli şekilde gerçekleştirilmelidir.

Devops kaynakların kapasitesini artırmak için kullanılır.

Silolar, üretim ve kalitenin düşmanıdır.

Devops Unsurları (CALMS) : Bu yazının, bir sunumun kopyası olmasını istemiyorum. Linkini bırakıyorum. Burada not düşmek istediğim şudur. Devops unsurlarını gerçekleştirirken araçlara aşırı anlam yüklemeyin. Bu unsurların hepsi eşit derecede önemlidir.

Aşağıdaki unsurlarda yapacağız her iyileştirme ve yeni adım sizi tam gerçekleşmiş bir devops ortamına bir adım daha yaklaştıracaktır.

Tecrübe Edilmiş Gerçekler

En önemli kaynak insan kaynağıdır. Devops dahil tüm değişim hareketlerin başarısını etkileyen, üzerinde en çok düşünülmesi gereken unsurdur. (Google araştırması : bir takımın etkinliğinde en önemli faktör kişinin güvenlik hissi olduğunu ortaya koymuştur. Bakınız Project Aristotle)

Olay sadece araç değişimi değildir. Hiç bir zaman bu olmamıştır. İnsanların toplu uyumu ve mutluluğu önemlidir.

Yönetim kademesinin Devops’a ( veya herhangi bir değişime) inanması başarıyı şansını artırıyor ( bunun tam tersi, yani inanmıyor olması çok büyük ihtimal ile başarısızlık “FAIL” sebebi oluyor.)

Suçlama yapmayan, “post-mortem” kültürünü yüceltmek gerekiyor. Suçlama olursa insanlar risk almaktan çekinmeye başlar. Fikir beyan edilmeyen, risk alınıp bir şey denenmeyen bir ortamda bir şeylerin iyileşme ( değişme ) şansı olmaz.

Efor sarf edilen her iş, sistemde bir iş maddesi olarak ifade edilmelidir. Örneğin yeni bir modül için kodu yazıyorsunuz, bu esnada bu iş için yeni bir sunucunun ayağa kaldırılması gerektiği anlaşıldı. Bu iş için tıpkı sizin “kod yazma” iş maddeniz gibi, “sunucu kurma” iş maddesi de, aynı iş maddesi sisteminde yer almalıdır. Ancak böyle yaparak tüm beklemeleri, bunun yanında müşterinin modülü istemesi ile bu modülün devreye girmesi için geçen süreyi gibi değerleri sistemden çekebilirsiniz.

Araç sayısını ne kadar azaltırsak o kadar iyidir. Az araç entegrasyonu azaltır, iletişimi artırır. Seçilen araç, şirketin stratejisine uygun olmalıdır.

Teknik borç görünür olmalıdır. Mümkünse ekiplerin takip ettikleri ana ekranlarında ( dashboard üstünde)görünmelidir.

Belirlediğiniz KPI’lar müşteriye değer katan, toplam etkiyi ( TOTAL IMPACT ) artıran nitelikte olmalıdır.

Devops’a değişimine uyum sağlayan ve çevresini yeşerten kişiler mükafatlandırılmalıdır. Ödül kriterleri net ise, ödül her zaman olumlu algılanır.

IT dönüşümü zorlayıcıdır. Yolun başında — ortasında — sonunda bu akıldan çıkartılmamalıdır.

Uygulama Dönük Öneriler

💡 XP Çalışma -Cross Functional Ekipler-: Biri kod yazıyor biri test yazıyor sonra rolleri değişiyorlar. Bunu aynı ekip içinde yapmak çapraz olarak yetkinliklerin artmasını sağlıyor.

💡 Uygulamanıza geri bildirim alan bir “widget” yapıp, bunu farklı bir tiple bir “ticket” olarak açabilirsiniz (Örneğin Azure Devops içinde PBI olarak olarak düşünülebilir.) Müşteri memnuniyetini artıracak bir faaliyettir.

💡 BUG açan bir “widget” yapabilirsiniz. Ekran görüntüsü ve detaylı bilgi alabilir. Gerçekten hata ise açabilmelidir. Basit bir form yaparsak istismar edilebilir.

💡 Bug Cap : Hata sayısı belli bir adedi aştığında ekibin kalemi kağıdı bırakıp hataları eritmesidir. Ekip bölünmemek için hata adetlerini aşağıda tutmak için yenilikçi ve kalıcı çözümler bulur. Agile principles in practice — Azure DevOps | Microsoft Docs

💡 Bireysel KPI önerisi: Başkalarının (internal/external/customer centric) başarısı için ne yaptın? Onlara hangi yetkinlikleri kazandırdın? (Contribute to Others success) Birlikte çalışmayı motive eden harika bir performans ölçme kriteri olabilir.

💡 Dev ve Ops ekipleri (katkı verdikleri hizmetler üzerinden) ortak KPI verebilir. (MTTR) Örneğin kurumsal bir ERP uygulamasının yeni bir ülkede zamanında devreye alımı bu iki ekip için ortak bir hedef olmalıdır.

💡 Müşteriyi işin içine katınız. Örneğin Microsoft’ta her ürün için, içinde müşterilerin olduğu bir TEAMS Kanalı açması şarttır. (Uygulamalarımız için düşünebiliriz. X Uygulaması için içinde bir şekilde müşterinin / anahtar kullanıcıların bulunduğu bir kanal olabilir. )

💡 Her türlü kaynak (script, kod, doküman) bir Repository’de tutulmalıdır. Bu, öneriden daha çok bir olmazsa olmazdır.

Yönetimin arkasında durması gerekecek işler

💬Kurumun stratejisi hızlanmak yönünde olmalıdır.

💬 Kurum içinde KPI verme alışkanlığının yerleştirilmesi gerekir.

💬 Devops dönüşümüne hizmet edecek faaliyetler içini, İş listesi uygulamasında ( Örneğin Azure Devops — Backlogs kullanılarak) yeni bir iş maddesi açıp ( IT modernizasyon gibi) kurumun vizyonuna uygun misyonlar ve yapılacak görevler, bitiş tarihi ile hedef olarak verilmesi sağlanmalıdır.

💬 Sisteminizde “Monitoring Reader” rolünün daha fazla kişide olmasının bir sakıncası yoktur. Sistem ve Developer ekipleri bu yetkiyi paylaşabilir.

💬 Kimseyi üzmeyen basit kararlar hemen alınabilir. (Microsoft Teams’de veya SLACK içinde artık kurum neyi kullanıyorsa birlikte çalışan dev ve ops ekiplerinin ortak amaçlarına uygun yeni kanal açması gibi)

💬 Değişim belli bir grupta başlatıldıysa, o grupta devreye aldıktan kısa bir süre sonra (yaygınlaştırma yapmadan önce) mutlaka geri bildirim alınmalıdır.

💬 Devops dahil her değişim planında Sponsor aktivitelerinin ( CEO ‘nun neyi zaman duyuracağı, başlatacağının) belirlenmesi çok önemlidir.

💬 Her üründe mutlaka ( ürünün karlılığından sorumlu, ürünün amacına uygun geliştirilmesinde son kararı verecek) bir ürün sahibi (Product Owner -PO) olmalıdır.

💬Şeffaflık, takımlarda otonomi mümkün olduğunca sağlanmalıdır.

Umarım buraya kadar gelmenizi sağlayabildim. “Devops dönüşümü” notlarımı mümkün olduğunca sade, içerisinden alıp hayata geçirilebilecek şekilde paylaşmaya çalıştım. Biraz uzun oldu farkındayım, bununla birlikte daha fazla fayda sağlayabilme şansımı azaltmak istemediğimden değerli gördüğüm hiç bir noktayı atlamak istemedim.

Sağlıkla ve pozitif kalın 💗🚀

Sevgiler

Serkan

Bir yerden başlamak : Devops was originally published in Bimar Teknoloji Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.