Fiziksel büyüklüklerle çalışan uygulamalarda birim dönüşümleri zorlayıcı olabilir. .NET platformu için geliştirilen UnitsNet kütüphanesi, farklı ölçüm sistemleri ve fiziksel büyüklükler arasında dönüşümü kolay ve güvenilir hale getirir. Bu makalede, UnitsNet kütüphanesinin özelliklerini ve kullanım alanlarını inceleyeceğiz.

UnitsNet Nedir?​

UnitsNet, .NET uygulamalarında fiziksel büyüklüklerin birim dönüşümlerini basit ve güvenilir bir şekilde gerçekleştirmek için geliştirilmiş bir open-source bir kütüphanedir. Birçok ölçüm türünü destekler ve farklı birimler arasında dönüşüm yapmayı sağlar. Örneğin, metre cinsinden bir uzunluğu km olarak almak veya kilogram cinsinden bir ağırlığı pound’a çevirmek gibi işlemler UnitsNet ile son derece kolaydır.

Desteklenen Birim Türleri​

UnitsNet kütüphanesi, geniş bir yelpazede fiziksel büyüklükleri ve birimleri destekler. Bu büyüklükler arasında aşağıdakiler yer alır:

• Uzunluk (Length): metre, kilometre, mil, inç, fit vs.
• Ağırlık/Kütle (Mass): kilogram, gram, ton, pound vs.
• Sıcaklık (Temperature): Celsius, Fahrenheit, Kelvin vs.
• Hacim (Volume): litre, mililitre, galon, kübik metre vs.
• Alan (Area): metrekare, hektar, akre vs.
• Basınç (Pressure): Pascal, bar, atm, psi vs.
• Hız (Speed): metre/saniye, kilometre/saat, mil/saat vs.
• Enerji (Energy): joule, kalori, kilowatt-saat vs.
• Güç (Power): watt, kilowatt, beygir gücü vs.
• Veri Boyutu (Information): byte, kilobyte, megabyte, gigabyte, terabyte vs.

UnitsNet, yukarıdaki büyüklükler ve daha fazlası için destek sağlar ve böylece çok çeşitli mühendislik ve bilimsel hesaplamalar için uygundur.

UnitsNet Implementasyon​

Öncelikle, projeye UnitsNet NuGet paketini ekleyelim;

dotnet add package UnitsNet

UnitsNet ile bir büyüklüğü tanımlayıp, farklı birimlere dönüştürmek oldukça basit;

using UnitsNet;

class Program
{
    static void Main()
    {
        // Define 10km
        var distance = Length.FromKilometers(10);

        Console.WriteLine($"Meters: {distance.Meters}");
        // Meters: 10000
        
        Console.WriteLine($"Miles: {distance.Miles}");
        // Miles: 6.2137119223733395
        
        Console.WriteLine($"Yard: {distance.Yards}");
        // Yard: 10936.132983377078
        
        
        // Define 100 MB
        var fileSize = Information.FromMegabytes(100);

        Console.WriteLine($"Byte: {fileSize.Bytes}");    
        // Byte: 100000000
           
        Console.WriteLine($"Gigabyte: {fileSize.Gigabytes}");
        // Gigabyte: 0.1
    }
}

Bu kodda, Length.FromKilometers(10) ile 10 kilometre cinsinden bir uzunluk tanımlıyoruz ve distance.Meters, distance.Miles gibi özelliklerle farklı birimlerde değerlerini görüntülüyoruz. Ayrıca, 100 MB’lik bir dosya boyutunu byte ve gigabyte olarak çevrimlerini yapıyoruz.

Daha fazlası için lütfen projenin github sayfasına göz atın…

UnitsNet Kullanırken Dikkat Edilmesi Gerekenler​

Kullanım sırasında aşağıdaki konulara dikkat etmek faydalı olacaktır:

1. Doğru Büyüklüğü Seçmek: Her büyüklük için ayrı bir sınıf vardır (Length, Mass, Temperature gibi). Hangi büyüklüğü kullanacağınızı doğru seçtiğinizden emin olun.
2. Birim Hassasiyeti: UnitsNet, bazı birim dönüşümlerinde yuvarlama yapabilir. Eğer çok yüksek hassasiyet gerektiren işlemler yapıyorsanız, sonuçları kontrol etmenizde fayda var.
3. Performans: UnitsNet, büyük veri setleriyle çalışırken dönüşüm işlemlerinin optimize edilmesi gerekebilir. Özellikle büyük döngüler içinde birim dönüşümü yapılacaksa performans testleri yapmakta fayda var.

Sonuç​

UnitsNet, .NET platformunda birim dönüşümlerini güvenilir ve kolay bir şekilde yapmak isteyen geliştiriciler için harika bir çözümdür. Geniş bir birim desteği, basit kullanım ve güçlü dönüşüm özellikleri sayesinde, bilimsel, mühendislik ve günlük uygulamalarda kolaylık sağlar. Projelerinizde birim dönüşümü ihtiyacı varsa, UnitsNet'i denemenizi öneririm.

Bir sonraki yazıda görüşmek dileğiyle…

Expo kullanarak mobil uygulamanıza bildirim eklemek oldukça kolay Bildirimlerle çalışırken, özel ses eklemek, kullanıcı deneyimini kişiselleştirmek için harika bir yöntem olabilir. Ancak Expo’da, özellikle Android cihazlarda bazı özel ayarlar yapmanız gerekebilir.

Bu yazıda, Expo projenize bildirimlerde özel ses eklemeyi adım adım anlatacağız.

Not: Bu makale, expo-notifications paketini ve gerekli izinleri ayarladığınızı varsaymaktadır. Özel bildirim seslerinin sadece EAS Build ile desteklendiğini unutmayın. (Bkz. "Custom notification sounds are only supported when using EAS Build.")

1. Ses Dosyalarını Ekleme ve app.config Ayarları​

Öncelikle, ses dosyanızı proje dosya yapısına göre ekleyin. Örneğin, src/assets/sounds/bip.mp3 yolunu kullanabilirsiniz. Daha sonra, app.config dosyanızda bu dosya yolunu belirtmeniz gerekecek:

export default ({ config }: ConfigContext): ExpoConfig => ({
  ...config,
  assetBundlePatterns: ["./src/assets/sounds/*"], 
  plugins: [    [      "expo-notifications",
      {
        sounds: ["./src/assets/sounds/bip.mp3"],
      },
    ],
  ],
});

2. Bildirim Konfigürasyonları​

En kritik bölüm bildirim ayarlarını doğru yapılandırmaktır. Android platformunda, özel bir ses ile bildirim gönderebilmek için yeni bir bildirim kanalı (channel) oluşturmanız gerekir. Bu kanal üzerinden gelen bildirimler, belirlediğiniz ses ile kullanıcıya ulaşacaktır. iOS platformunda ise bu tür bir ayara gerek yoktur; ses dosyasını doğrudan bildirim içeriğinde belirterek özel bir bildirim sesi iletebilirsiniz.

Bildirim ayarlarını aşağıdaki gibi tanımlayın:

Notifications.setNotificationHandler({
  handleNotification: async () => ({
    shouldShowAlert: true,
    shouldPlaySound: true,
    shouldSetBadge: true,
  }),
});

Ardından, App.js dosyanızda useEffect içinde konfigürasyonunuzu ayarlayın:

 if (Platform.OS === "android") {
    await Notifications.setNotificationChannelAsync("bip", {
      name: "BipChannel",
      importance: Notifications.AndroidImportance.MAX,
      vibrationPattern: [0, 250, 250, 250],
      sound: "bip.mp3",
    });
  }

3. Bildirim Gönderme

Artık konfigürasyonumuz tamam, özel bildirimleri göndermeye hazırız! Özel sesi içeren bir test bildirimi göndermek için aşağıdaki fonksiyonu kullanabilirsiniz:

  const handleTestNotification = async () => {
    if (Platform.OS === "android") {
      await Notifications.scheduleNotificationAsync({
        content: {
          title: "Test Notification",
          sound: true,
        },
        trigger: {
          seconds: 1,
          channelId: "bip",
        },
      });
    } else {
      await Notifications.scheduleNotificationAsync({
        content: {
          title: "Test Notification",
          sound: "bip.mp3",
        },
        trigger: {
          seconds: 1,
        },
      });
    }
  };

Not: Android için sound: true ve channelId: "bip", iOS için ise sound: "bip.mp3" ayarlarını eklemeyi unutmayın.

Expo ile özel bildirim sesleri kullanmak, mobil uygulamanızın kullanıcı deneyimini kişiselleştirmenin etkili bir yoludur. Android ve iOS için küçük farklılıklar içerse de, bu adımları takip ederek projelerinize hızlıca özel sesler ekleyebilirsiniz. Bu, uygulamanıza özgün bir dokunuş katacak ve kullanıcılarınız için daha unutulmaz bir deneyim sunacaktır.

Bu adımları izleyerek projelerinizde özel sesli bildirimlerin nasıl çalıştığını görmek için hemen bir test bildirimi gönderin!

İyi çalışmalar!

Kaynaklar

Expo Bildirim Dökümantasyonu

Veritabanlarının ölçeklendirilmesi ve bellek içi veri işleme ihtiyaçları arttıkça, bu ihtiyaçları karşılayabilecek güçlü bir araç arayışı da ortaya çıkmaktadır. Apache Ignite, bu ihtiyaca çözüm sunan açık kaynaklı ve dağıtık bir bellek içi veri platformudur. Bu makalede, Apache Ignite'ı tanıyacak, onun temel özelliklerine göz atacak ve .NET Core ile nasıl entegre edileceğini örnek bir proje üzerinden göreceğiz.

Apache Ignite Nedir?​

Apache Ignite, veri saklama ve işleme için bellek içi teknolojiler kullanan, ölçeklenebilir ve yüksek performanslı bir veri platformudur. Ignite, sadece verileri bellek içinde depolamakla kalmaz, aynı zamanda dağıtık veri işleme, SQL ve NoSQL veri yönetimi, data grid ve çok daha fazlasını sunar. Bu özellikleri sayesinde, düşük gecikmeli ve yüksek performanslı uygulamalar geliştirmenize olanak tanır.

Ignite, ölçeklendirme sorunları yaşayan veritabanları veya yoğun veri işleme ihtiyaçlarına çözüm getirmek için yaygın olarak tercih edilen bir araçtır. Özellikle büyük veri ve gerçek zamanlı işleme ihtiyaçları için ideal bir platformdur.

Apache Ignite'in Temel Özellikleri​

• Bellek İçi Depolama: Ignite, verilerinizi bellek içinde saklayarak yüksek hızda erişim sağlar.
• Dağıtık SQL: Verilere SQL sorguları ile erişebilirsiniz, üstelik dağıtık bir ortamda.
• Yatay Ölçeklendirme: Ignite, düğüm ekleyerek kolayca yatay ölçeklenebilir.
• Düşük Gecikme Süresi: Ignite, verileri doğrudan bellekte tuttuğu için milisaniye mertebesinde gecikme süreleri sunar.

.NET Core ile Apache Ignite Entegrasyonu​

Apache Ignite, .NET Core desteği sayesinde, .NET uygulamalarınızda bellek içi veri saklama ve dağıtık veri işleme yeteneklerini kullanmanıza olanak tanır. Ignite'ı .NET Core ile nasıl kullanabileceğimize bir bakalım.

Adım 1: Ignite Kütüphanesini Projeye Dahil Etmek​

Öncelikle, Ignite'ın .NET Core desteği için gerekli olan NuGet paketini yükleyerek başlayacağız. Aşağıdaki komutu kullanarak bu paketi yükleyebilirsiniz:

Install-Package Apache.Ignite

Adım 2: Ignite Sunucusunu Başlatmak​

Ignite sunucusunu başlatmak için basit bir konsol uygulaması oluşturacağız. Ignite sunucusu, verilerinizi depolamak ve dağıtık işlem yapmak için kullanacağımız ana bileşendir. Aşağıdaki kod parçacığı, Ignite sunucusunu başlatmak için kullanabileceğiniz bir örnek gösteriyor:

using Apache.Ignite;
using Apache.Ignite.Core.Cache.Configuration;
using System;

namespace IgniteDotNetExample
{
    class Program
    {
        static void Main(string[] args)
        {
            var igniteConfiguration = new IgniteConfiguration
            {
                IgniteInstanceName = "myIgniteInstance",
                WorkDirectory = "./igniteWorkDir",
                ClientMode = false // Sunucu düğümü olarak çalıştırıyoruz.
            };

            IIgnite ignite = Ignition.Start(igniteConfiguration);

            Console.WriteLine("Ignite sunucusu başlatıldı.");

            // Örnek bir cache oluşturalım.
            var cacheConfiguration = new CacheConfiguration
            {
                Name = "sampleCache",
                CacheMode = CacheMode.Partitioned,
                AtomicityMode = CacheAtomicityMode.Transactional
            };

            var cache = ignite.GetOrCreateCache<int, string>(cacheConfiguration);

            // Cache'e veri ekleyelim.
            cache.Put(1, "Merhaba Ignite!");
            string value = cache.Get(1);

            Console.WriteLine($"Cache'teki veri: {value}");

            Console.ReadLine();
        }
    }
}

Yukarıdaki kodda, Ignite sunucusu başlatılmakta ve sampleCache isimli bir cache oluşturulmaktadır. Bu cache, verilerimizi bellek içinde saklamak için kullanılacaktır.

Adım 3: İki Ignite Instance ve Persistent Çalışma Yapısı​

Apache Ignite'ın iki instance ile nasıl çalıştığını ve verilerin kalıcı olarak saklanmasını (persistent storage) nasıl sağlayacağınızı gösteren bir örnek hazırlayalım. Bu örnekte iki Ignite düğümü başlatacak ve persistent yapılandırma ile verilerin disk üzerinde saklanmasını sağlayacağız.

using Apache.Ignite.Core;
using Apache.Ignite.Core.Cache.Configuration;
using Apache.Ignite.Core.Configuration;
using System;

namespace IgnitePersistentExample
{
    class Program
    {
        static void Main(string[] args)
        {
            // İlk Ignite instance'ını başlatma
            var igniteConfig1 = new IgniteConfiguration
            {
                IgniteInstanceName = "igniteInstance1",
                WorkDirectory = "./igniteWorkDir1",
                DataStorageConfiguration = new DataStorageConfiguration
                {
                    DefaultDataRegionConfiguration = new DataRegionConfiguration
                    {
                        Name = "Default_Region",
                        PersistenceEnabled = true // Kalıcı depolama etkinleştirildi.
                    }
                }
            };

            IIgnite ignite1 = Ignition.Start(igniteConfig1);
            ignite1.GetCluster().Active(true);
            Console.WriteLine("Ignite Instance 1 başlatıldı.");

            // İkinci Ignite instance'ını başlatma
            var igniteConfig2 = new IgniteConfiguration
            {
                IgniteInstanceName = "igniteInstance2",
                WorkDirectory = "./igniteWorkDir2",
                DataStorageConfiguration = new DataStorageConfiguration
                {
                    DefaultDataRegionConfiguration = new DataRegionConfiguration
                    {
                        Name = "Default_Region",
                        PersistenceEnabled = true // Kalıcı depolama etkinleştirildi.
                    }
                }
            };

            IIgnite ignite2 = Ignition.Start(igniteConfig2);
            ignite2.GetCluster().Active(true);
            Console.WriteLine("Ignite Instance 2 başlatıldı.");

            // Cache oluşturma ve veri ekleme
            var cacheConfiguration = new CacheConfiguration
            {
                Name = "persistentCache",
                CacheMode = CacheMode.Partitioned,
                AtomicityMode = CacheAtomicityMode.Transactional
            };

            var cache = ignite1.GetOrCreateCache<int, string>(cacheConfiguration);
            cache.Put(1, "Persistent Merhaba Ignite!");
            string value = cache.Get(1);

            Console.WriteLine($"Persistent Cache'teki veri: {value}");

            Console.ReadLine();
        }
    }
}

Yukarıdaki kodda, iki farklı Ignite instance'ı başlatılmakta ve kalıcı depolama (persistent storage) yapılandırması etkinleştirilmektedir. Bu sayede Ignite sunucuları yeniden başlatılsa bile veriler disk üzerinde saklanacak ve kaybolmayacaktır.

Adım 4: Ignite ile Verilere Erişmek​

Ignite'ın en güçlü özelliklerinden biri SQL desteğidir. Ignite üzerinde saklanan verileri SQL sorguları kullanarak işleyebilirsiniz. Örneğin, bir kullanıcı tablosunu Ignite üzerinde saklamak ve SQL sorguları ile bu tablodaki verilere erişmek mümkündür:

[Serializable]
public class User
{
    [QuerySqlField(IsIndexed = true)]
    public int Id { get; set; }

    [QuerySqlField]
    public string Name { get; set; }
}

class Program
{
    static void Main(string[] args)
    {
        IIgnite ignite = Ignition.Start();

        var cache = ignite.GetOrCreateCache<int, User>(new CacheConfiguration("userCache", typeof(User)));

        // Kullanıcı ekleyelim.
        cache.Put(1, new User { Id = 1, Name = "Ali" });
        cache.Put(2, new User { Id = 2, Name = "Ayşe" });

        // SQL sorgusu ile kullanıcıları getirelim.
        var query = new SqlFieldsQuery("SELECT Id, Name FROM User WHERE Name = ?", "Ali");
        var cursor = cache.Query(query);

        foreach (var row in cursor)
        {
            Console.WriteLine($"Kullanıcı: Id={row[0]}, Name={row[1]}");
        }

        Console.ReadLine();
    }
}

Yukarıdaki örnekte, User isimli bir sınıf oluşturduk ve bu sınıfı userCache isimli bir cache içinde sakladık. Daha sonra, SQL sorguları kullanarak bu cache içinde saklanan verilere eriştik.

Sonuç​

Apache Ignite, ölçeklenebilir ve yüksek performanslı bellek içi veri yönetimi ve işleme çözümleri sunan güçlü bir platformdur. Ignite, verileri bellek içinde saklayarak ve dağıtık SQL desteği sunarak, .NET uygulamalarınızı hızlandırmanıza ve verimliliğini artırmanıza yardımcı olabilir. Bu makalede, Apache Ignite'ın temel özelliklerini ve .NET Core ile nasıl entegre edilebileceğini örneklerle ele aldık. Ayrıca, iki Ignite instance'ı kullanarak kalıcı depolama özellikleriyle çalışan bir yapı kurmayı öğrendik.

Ignite'ın sunduğu diğer güçlü özellikleri keşfetmek ve daha fazla bilgi edinmek için Apache Ignite resmi dokümantasyonuna göz atabilirsiniz.

Yorumlar ve Katkılar​

Apache Ignite ve .NET Core ile ilgili deneyimlerinizi paylaşmak veya sorular sormak için yorum yapmaktan çekinmeyin. Apache Ignite ile gerçek zamanlı veri işleme uygulamaları geliştirmek konusunda daha fazla bilgi edinmek isteyenler için Ignite'ın güçlü özellikleri gerçekten keşfetmeye değer.

Yazılım geliştirme süreçlerinde unit testler, kod kalitesini ve güvenilirliğini artırmak için vazgeçilmez bir araçtır. Ancak, unit testlerimizin gerçekten etkili olup olmadığını nasıl anlayabiliriz? İşte bu noktada Mutation Testing devreye giriyor. Bu makalede, Mutation Testing kavramını, manuel olarak nasıl uygulanabileceğini ve .NET ekosisteminde popüler bir araç olan Stryker.NET ile nasıl otomatize edilebileceğini inceleyeceğiz.

Mutation Testing Nedir?​

Mutation Testing, testlerinizin etkinliğini değerlendirmek için kullanılan bir tekniktir. Bu yöntemde, kodunuzda küçük değişiklikler (mutasyonlar) yapılarak testlerinizin bu değişiklikleri yakalayıp yakalayamadığı kontrol edilir. Eğer testleriniz bu mutasyonları tespit edemezse, bu durum test senaryolarınızın geliştirilmesi gerektiğini gösterir.

Neden Önemlidir?​

• Test Kalitesini Artırır: Sadece kodun test edilip edilmediğini değil, testlerin ne kadar etkili olduğunu da ölçer.
• Hata Yakalama Yeteneğini Geliştirir: Potansiyel hataları erken aşamada tespit etmeyi sağlar.
• Güvenilirlik Sağlar: Kodunuzun değişikliklere karşı ne kadar dayanıklı olduğunu gösterir.

Manuel Olarak Mutation Testing Nasıl Yapılır?​

Otomatik araçlar kullanmadan da mutation testing prensiplerini uygulayabilirsiniz. Bu bölümde, manuel olarak nasıl mutation testing yapabileceğinizi basit bir örnekle göstereceğiz.

Öncelikle, test etmek istediğimiz basit bir sınıf ve buna ait unit testleri yazalım.

MathOperations.cs:

namespace MutationDemo;

public class MathOperations
{
    public int Add(int a, int b) => a + b;
}

Unit Test:

using Xunit;
using FluentAssertions;

namespace MutationDemo.UnitTests;

public class MathOperationsTests
{
    [Fact]
    public void Add_ShouldReturnCorrectSum()
    {
        // Arrange
        var mathOperations = new MathOperations();

        // Act
        var result = mathOperations.Add(2, 3);

        // Assert
        result.Should().Be(5);
    }
}

Test projesinin bulunduğu dizinde dotnet test komutu ile yazdığımız testi çalıştırdığımızda testimizin başarıyla geçtiğini göreceğiz;

Passed!  - Failed:     0, Passed:     1, Skipped:     0, Total:     1, Duration: < 1 ms

Şimdi, kodumuzda bilinçli bir hata yaparak mutasyon oluşturalım. Örneğin, + operatörünü - operatörüyle değiştirelim:

public int Add(int a, int b) => a - b;

Değişiklikleri kaydettikten sonra dotnet test komutu ile testi tekrar çalıştıralım: Test çıktısı aşağıdaki şekilde olmalı:

Failed!  - Failed:     1, Passed:     0, Skipped:     0, Total:     1, Duration: < 1 m

Testin başarısız olması, testimizin bu mutasyonu yakaladığını gösterir. Süper bir unit test yazmışız, testimiz koddaki bu hatayı tespit edebiliyor.

Diğer olası mutasyonları da deneyebilirsiniz. Örneğin, return a + b; satırını return a; olarak değiştirebiliriz:

public int Add(int a, int b) => a;

Testleri tekrar çalıştırdığınızda, testin yine başarısız olması gerekir. Eğer testler başarılı olursa, bu durum testlerinizin yeterince kapsamlı olmadığını gösterir ve testlerinizi gözden geçirmeniz gerekir.

Stryker.NET Nedir?​

Manuel olarak mutation testing yapmak, küçük projelerde uygulanabilir olsa da, büyük projelerde zaman alıcı ve karmaşık olabilir. İşte bu noktada Stryker.NET devreye giriyor. Stryker.NET, .NET platformu için geliştirilmiş açık kaynaklı bir mutation testing aracıdır. Kodunuzda otomatik olarak mutasyonlar oluşturarak, testlerinizin bu mutasyonları yakalayıp yakalayamadığını analiz eder.

Özellikleri​

• Kolay Entegrasyon: Mevcut .NET projelerinize hızlıca entegre edilebilir.
• Esnek Yapılandırma: Farklı test çerçeveleri (xUnit, NUnit, MSTest) ile uyumludur.
• Detaylı Raporlama: Mutasyon skorları ve hangi mutasyonların tespit edilemediği gibi detaylı raporlar sunar.

Stryker.NET ile Mutation Testing​

Biraz önce manuel olarak gerçekleştirdiğimiz mutasyon testini, Stryker.NET'i kullanarak aynı projede otomatikleştirelim.

Gereksinimler​

• .NET 6 veya daha yeni bir sürüm

• Unit testler için xUnit

• Stryker.NET'in kurulu olması

  Stryker.NET'i global bir araç olarak kurmak için komut satırında aşağıdaki komutu çalıştırın;

  dotnet tool install -g dotnet-stryker
  

Stryker.NET ile Mutation Testing'i Çalıştırma​

Test projenizin dizininde aşağıdaki komutu çalıştırın:

dotnet stryker

Bu komut, Stryker.NET'in varsayılan ayarlarla mutation testing'i başlatmasını sağlar. Testler tamamlandıktan sonra Stryker.NET size bir rapor sunacaktır.

Stryker tarafından üretilen html raporunu incelediğimizde Stryker'ın kodun hangi kısmında kaç tane ve nasıl mutasyon oluşturduğunu görebiliriz;

Mutasyon skorunun %100 olduğunu görüyoruz. Yani bu, testlerimizi Add methodunda yaptığımız değişiklikleri kapsayacak şekilde yazdığımız anlamına geliyor.

Stryker.NET, hangi mutasyonların öldürüldüğünü (testler tarafından yakalandığını) ve hangilerinin hayatta kaldığını (testlerin yakalayamadığını) detaylı bir şekilde raporlar. Bu raporları inceleyerek, testlerinizde hangi senaryoların eksik olduğunu tespit edebilirsiniz.

Sonuç​

Mutation Testing, unit testlerinizin gerçekten etkili olup olmadığını anlamak için güçlü bir yöntemdir. Manuel olarak uygulanabilir olsa da, Stryker.NET gibi araçlar sayesinde bu süreci otomatikleştirerek zaman ve emek tasarrufu sağlayabilirsiniz. Bu sayede kod kalitenizi artırabilir ve olası hataları erken aşamada tespit edebilirsiniz.

Dipnot: Emek emek yazdığım 2000’e yakın test barındıran canım kütüphanemde, mutasyon skorunun %40 olduğunu görünce yaşadığım hüsranı size tarif edemem 😟 Sizde aynı hüsranı yaşamak istemiyorsanız test yazım tekniklerinizi mutasyon raporlarını inceleyerek iyileştirebilirsiniz.

Bir sonraki yazıda görüşmek dileğiyle…

Ekipler büyüdükçe artık belirli standartları uygulamak zorunlu hale gelmeye başlar. Aksi takdirde projelerin veya kaynak kodların yönetimini sağlamak ve çalışma ortamının verimliliğini sürdürmek zorlaşır.

Birazdan anlatacağımız standartlar için gelebilecek; "neden yapıyoruz ki?" veya "o kadar işin arasında birde bu vakit kaybı değil mi?" gibi sorularının genel bir cevabını vererek giriş yaptığımıza göre, bu dökümanda neleri ele alacağımıza bir göz atalım;

• Semantic Versioning
• Perfect Commit;
  • Perfect Commit Messages
  • Conventional Commits
• Branch Naming

Semantic Versioning(SemVer)

Source Control Standarts isimli bir dökümanda neden versioningle ilgili bir bölüm olduğunu merak ediyorsan sabırsızlanma ve okumaya devam et 😉

Semantic Versioning Nedir?​

Semantic versioning (semantik sürümleme), yazılım projelerinde sürüm numaralarını belirlemenin standart bir yoludur. Bu standart, sürüm numaralarının anlamlı ve öngörülebilir olmasını sağlar. Semantic versioning, genellikle MAJOR.MINOR.PATCH formatında kullanılır.

Her bölümün ne anlama geldiğine ve ne zaman artırılacağına bir göz atalım:

1. MAJOR (Ana Sürüm): Geriye dönük uyumluluğu bozan değişiklikler yapıldığında artırılır.
2. MINOR (Alt Sürüm): Geriye dönük uyumlu yeni özellikler eklendiğinde artırılır.
3. PATCH (Yama): Geriye dönük uyumlu hata düzeltmeleri yapıldığında artırılır.

Neden Semantic Versioning Kullanmalısın?​

• Anlaşılabilirlik: Sürüm numarasından yazılımın ne kadar değiştiğini ve bu değişikliklerin uyumluluk üzerinde ne tür etkileri olduğunu kolayca anlayabilirsin.
• Güvenilirlik: Yazılımı kullananlar, sürüm numarasına bakarak güncellemelerin risklerini daha iyi değerlendirebilirler.
• İşbirliği: Takım arkadaşların ve kullanıcılar, sürüm numaralarının anlamını bildiklerinde, projeye katkı sağlama ve yazılımı kullanma konusunda daha güvenli hissederler.

Semantic Versioning Nasıl Yapılır?​

Ekip olarak bir e-ticaret sitesi için API geliştirdiğimizi varsayalım. Aşağıda buna göre senaryolar ve bu senaryolarda sürüm numarasının nasıl değişeceği yer almakta:

• API temel özelliklerini ekliyorsun ve henüz kullanıcıların kullanımına uygun değil, yani stable bir sürüme sahip değilsin. Bu durumda ilk sürüm numarası 0.1.0 şeklinde olmalı.
• Kullanıcıların giriş yapmaları için gerekli endpointleri ekledin. Bu durumda bir sonraki sürüm numarası 0.2.0 olmalı.
• Yeni eklediğin endpointlerde hatalar olduğunu farkettin ve bunları düzelttiğin bir sürüm yayınladın. Bu durumda sürüm numarası 0.2.1 olmalı.
• API'ın temel özelliklerini tamamladın ve artık api kullanıcıların kullanabileceği bir hale geldi. Bu durumda ilk sürüm numaran 1.0.0 olmalı.
  • Stable bir sürüm yayınlamak, aslında son deneme sürümünü teslim etmek anlamına da gelir. Yani 0.2.1 ve 1.0.0 sürüm numaraları aslında aynı olabilir. Bu durumda geriye dönük uyumsuzluk beklenmez. Geriye dönük uyumsuzluklar genellikle 1.0.0'dan sonraki sürümlerde ortaya çıkar.
• API'ına belirli özellikler ekledin ve şuanki sürüm numarası 1.17.4. API performans iyileştirmesi ve güvenlik zafiyetlerini gidermek amacıyla kullandığın framework ve paketlerin versiyonunu güncelledin ve buna bağlı olarak API'da artık geriye dönük uyumluluğu olmayan değişiklikler yaptın. Bu durumda bir sonraki sürüm numaran 2.0.0 olmalı.
• İş birimin senden yeni bir ödeme altyapısı eklemeni istedi. Bu durumda yeni sürüm numaran 2.1.0 olmalı

Hayali e-ticaret sitemizi semantik bir şekilde versiyonladığımıza göre SONUÇ ;

Semantic versioning, projeni düzenli ve anlaşılır tutmanın bir standardıdır. Projenin her aşamasında, sürüm numaralarını doğru bir şekilde güncelleyerek projenin kullanıcılarına ve ekip arkadaşlarımıza projenin durumu hakkında daha net bilgiler verebiliriz. Bu standardı kullanarak, yazılım geliştirme sürecini daha yönetilebilir ve güvenilir hale getirebiliriz.

Semantic Versioning uygularken uyman gereken kurallar ve daha fazla bilgi için SemVer Resmi Sitesi'ne göz atabilirsin.

Perfect Commit Messages

Her ne kadar önemsiz görülse de, commit mesajları yazılım geliştirme sürecinin önemli bir parçasıdır. İyi yazılmış bir commit mesajı, hem senin hem de takım arkadaşlarının projeyi daha iyi anlamasını sağlar. "Bu değişikliği kim neden yaptı abi?" gibi soruların tarih olmasını sağlayıp, özellikle sürekli farklı projelerde görev alan ekip üyeleri için ciddi bir zaman kazancı sağlar.

Mükemmel commit mesajını yazmak işin sadece yarısı, mükemmel commitleri oluşturmak için değişiklikleri parçalara bölmek ve bu parçalara neler eklenmesi gerektiğini planlamak da aynı şekilde önemlidir. Commit'ler bir task'ı ele alış biçiminde önemli bir rol oynayabilir. Değişiklikleri mantıksal olarak commit'lere gruplandırmak, bir task'ı planlama ve onu daha küçük parçalara bölerek yazılım geliştirme sürecini iyileştirmen için de olanak sağlar.

Bu, task'ın ve bu task'a ürettiğin çözüm hakkında daha fazla düşünmeni sağlayacak, sadece işin başında değil, aynı zamanda değişiklikleri commitlere parçalayıp bölerken ve commit mesajını yazarken de bunu yapmanı sağlayacak. Bu da, uygulamanı yeniden gözden geçirmeni ve belki de gözden kaçan edge caseleri, eksik testleri veya unuttuğun başka herhangi bir şey fark etmeni sağlayabilir.

Peki Nasıl?​

Yaptığımız geliştirmeyi uygun şekilde commitlere parçalama işini sana bıraktığımıza göre, commit mesajını nasıl yazmalıyız sorusuna cevap verelim. Burada tutarlılık çok önemlidir, bu yüzden ekipler önce aşağıdaki üç konuda tartışmalı ve anlaşmalıdır;

• Style: Commit geçmişinin okunabilir olmasını sağlamak için önemli bir rol oynar. Dil bilgisi, noktalama işaretleri, büyük harf kullanımı ve satır uzunlukları gibi konuları içerir.
• Content: Content'i standardize etmek kolay değildir. Fakat yapılan değişikliklerin neden yapıldığı ve nasıl gerçekleştirildiği hakkında bilgiler ve gerektiğinde, yapılan değişikliklerin teknik detaylarını ve etkilerini içermelidir.
• Metadata: Issue Tracking Id'leri, değişikliklerin test edilip edilmediğini belirten notlar veya gerekirse, kod inceleme sürecinde elde edilen bulgular veya yorumlar gibi ek bilgiler içermelidir.

Bu üç konuyu ele almanın tek bir yolu yoktur yani tartışmaya açıktır, ancak çoğu Git commit mesajı belirli bir deseni takip eder. Aşağıda bu yaygın kullanılan deseni inceleyeceğiz.

Şablon​

[subject]

[optional body]

[optional footer(s)]

Subject (Başlık)​

Tıpkı bir e-postada olduğu gibi, başlık çok önemli bir parçadır. Genellikle insanların okuyacağı ilk, belki de tek kısım burasıdır, bu yüzden görsel olarak çekici ve kolay anlaşılabilir olmalıdır, gereksiz büyük harf ve noktalama işaretlerinden kaçınmalı ve doğru anahtar kelimeler kullanılmalıdır.

Emir kipi standarttır; Git, senin adına bir commit oluşturduğunda (örneğin git merge veya git revert komutlarını çalıştırdığında) emir kipini kullanır. Bu, "Added" veya "Adds" yerine "Add" yazman gerektiği anlamına gelir. Başlıkta yazan metin, şu cümleyi tamamlamalıdır: "Eğer uygulanırsa, bu commit...". Çoğu ekip commit subject için aşağıdaki kuralları uygular;

• Büyük harfle başlamalı
• Nokta ile bitmemeli
• 50 karakter veya daha kısa olmalı
  • Karakter sınırı elbette aşılabilir, ancak commit mesajının net ve sade olmasını sağlamak için bunu uygulamak iyi bir pratik olacaktır.

İyi bir commit başlığına örnek : Update configuration files with new staging URL

Tekrar edelim, bu kurallar "bunu yapamazsın, yaparsan taş olursun" gibi katı kurallar değildir. İstersen commit mesajlarına emoji bile ekleyebilirsin 😊

Body (Gövde)​

Başlık çoğu zaman kendini açıklayıcıdır, ancak bazen "body" alanına daha fazla bilgi eklemek gerekebilir. Bu alanı, NEYİN ve NEDEN değiştiği hakkında daha fazla bağlam sağlamak için kullanırız.

Çoğu ekip commit body için aşağıdaki kuralları uygular;

• Subject'ten ayırmak için bir boş satır kullanılmalı
• Paragraflar boş satırlarla veya bullet list vb. stillerle düzenlenmeli
• Satır uzunluğu 72 karakter veya daha kısa olmalı

"Bi dakika arkadaşım bu karakter sınırı neden 72" dediğini duyar gibiyim;

72 karakter sınırı, terminal genişliği ve e-posta istemcileri gibi sistemlerin metin kaydırmayı(wrapping) düzgün şekilde işleyebilmesi ve okunabilirlik gibi tarihsel ve pratik nedenlerden dolayı yaygın olarak kullanılır. Bu, eski donanımlar ve yazılımlar için önemli bir gereklilikti ve artık bunu uygulamamıza pek ihtiyaç yok gibi gözüküyor. Fakat bu sınır, mesajların daha düzenli ve anlaşılır olmasını sağlamak için günümüzde de bir standart olarak kullanılabilir. Özellikle open-source projelerde hala yaygın kullanılan bir konvansiyondur.

Subject alanındaki karakter sınırlamasına benzer şekilde, bu daha çok bir yönerge olmakla birlikte, katı bir kural değildir. Bunu uygulayıp uygulamamak daha çok commit mesajlarını sıklıkla görüntülediğimiz editörün yeteneklerine bağlı olarak değişmelidir.

Tim Pope'un aşağıdaki örneği, stil olarak ulaşmamız gereken hedefin bir örneği olarak gösterilebilir:

Short(50 chars or less) summary of changes

More detailed explanatory text, if necessary. Wrap it to 72 characters.
The blank line separating the summary from the body is critical (unless
you omit the body entirely); tools like rebase can get confused if you run
the two together.

Further paragraphs come after blank lines. Bullet points are okay, too.

- Use a hyphen or asterisk for bullet points.
- Capitalize the first letter of each point.

Metadata/Footer​

Footer'a commit'in ilgili olduğu Azure DevOps taskları veya user storyleri, Pull Request'ler veya Jira ticket'larını ekleyebiliriz. Aynı zamanda bu alan, kullanımdan kaldırılan özelliklerin ve geriye dönük uyumsuz değişikliklerin belirtilmesi gereken yerdir. Örnek;

BREAKING CHANGE: <summary>
<blank line>
Fixes #<user story>
Closes #<pr>

"Bir commit mesajına bu kadarda uğraşmak overengineering be!" diye hayıflanan ve takımın standartlarını yakalayamamış arkadaşım bir önceki atttığın commit mesajını düzeltebileceğin bir yöntemde sana gelsin. Git'in --amend seçeneğini kullanarak çirkince yazdığın o commit mesajını düzenleyip hatandan geri dönebilirsin 😑

Şablonu parça parça inceledik. Hepsini bir araya getirdiğimizde, commitlerimiz aşağıdaki örnekteki gibi olmalıdır;

Add user authentication feature

- Implemented user authentication using JWT tokens for secure login.
- Added user registration functionality with password hashing for security.

Fixes #123
Closes #456
Not Tested

Conventional Commits

Gelelim fasulyenin faydalarına 🫘

Bir önceki sectionda oluşturduğumuz perfect commit'in üzerine, Conventional Commit şartnamesinde belirlenen standartları uygulayarak, commit mesajının üstünde bir çatı oluşturmaya çalışıyoruz ki anlamlı bir commit geçmişi elde edip, bu geçmişten çeşitli raporlar elde edebilelim ve bize belli başlı yetenekler kazandırsın. Yani human-readable olan commit mesajlarımızı human & machine-readable hale getireceğiz. Ayrıca bu şartname Semantic Versioning ile uyumludur.

Şablon​

<type>[optional scope]: <subject>

[optional body]

[optional footer(s)]

Conventional Commit, aşağıdaki yapısal unsurları içermelidir;

1. fix: fix tipi bir commit kodunuzdaki bir hatayı düzeltir (Semantik versiyonlamadaki PATCH ile paraleldir).
2. feat: feat tipi commit kodunuza yeni bir özellik ekler (Semantik versiyonlamadaki MINOR ile paraleldir).
3. BREAKING CHANGE: BREAKING CHANGE: ile başlayan bir footer ya da type/scope sonuna eklenmiş bir ! içeren commit geriye dönük uyumluluğu olmayan bir değişiklik getiriyordur (Semantik versiyonlamadaki MAJOR ile paraleldir). Bir BREAKING CHANGE harhangi bir tip commit içinde olabilir.

Yukarıdakiler Conventional Commit şartnamesinde yazılı olan ve semantic versioning'e paralel olan tiplerdir. Bunlar dışında yaygın kullanılan fakat semantic versioning'e etkisi olmayan tipler ve kodumuza olan etkileri;

1. docs: Sadece dökümantasyon ile ilgili değişiklikler yapar. Örneğin, README dosyasını güncellemek.
2. style: Kodun stilini ve formatını değiştirir, ancak işlevini etkilemez. Örneğin, boşlukları düzenlemek veya satır sonu karakterlerini değiştirmek.
3. refactor: Kodun işlevselliğini değiştirmeden yeniden düzenler. Örneğin, bir fonksiyonu daha okunabilir hale getirmek.
4. perf: Performans iyileştirmeleri yapar. Örneğin, bir algoritmayı daha hızlı çalışacak şekilde optimize etmek.
5. test: Test ekler veya mevcut testlerde değişiklik yapar. Örneğin, bir fonksiyonun yeni bir test senaryosunu eklemek.
6. build: Build sistemini veya dış bağımlılıkları etkileyen değişiklikler Örneğin (örnek: nuget, npm)
7. ci: Sürekli entegrasyon (CI) yapılandırmasında değişiklikler yapar. Örneğin, CI araçlarının yapılandırma dosyalarını güncellemek.
8. chore: Diğer kategorilere uymayan değişiklikler yapar. Örneğin, .gitignore dosyasına yeni exclusionlar eklemek.
9. revert: Önceki bir commit'i geri alır. Örneğin, yanlışlıkla yapılan bir değişikliği geri almak.

Örnekler​

Subject ve geriye dönük uyumluluğu olmayan bir değişiklik içeren footer'a sahip bir commit mesajı;

feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files

Geriye dönük uyumluluğu olmayan bir değişikliği! ile belirten bir commit mesajı;

feat!: send an email to the customer when a product is shipped

Kapsamı(scope) belirten ve geriye dönük uyumluluğu olmayan bir değişikliği ! ile belirten bir commit mesajı;

feat(api)!: send an email to the customer when a product is shipped

! içeren ve BREAKING CHANGE içeren footer'a sahip commit mesajı;

chore!: drop support for Node 6

BREAKING CHANGE: use JavaScript features not available in Node 6.

Body'si olmayan commit mesajı;

docs: correct spelling of CHANGELOG

Scope belirtilen commit mesajı;

feat(lang): add Polish language

Çok paragraflı bir body ve birden çok footer metadatası içeren commit mesajı;

fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.

Reviewed-by: Z
Refs: #123

Şablonu ve içeriğini aklımızda canlandırabildiğimize göre dökümanı daha da uzatmamak adına, kalan detayları Conventional Commits Şartnamesi'nden okuyup öğrenmekte senin üzerine düşen görev. Şimdi diğer bölümlerde yaptığımız gibi neden kullanıyoruz sorusuna cevap verip bu bölümü sonlandıralım;

• CHANGELOG'ları otomatik olarak human&machine-readable şekilde oluşturmamızı sağlar.

  

• Kolayca semantik versiyonlama yapmamıza olanak sağlar.

• Hangi projenin, hangi kapsamında, hangi türde geliştirmeler, iyileştirmeler, hata düzeltmeleri yapıldığı raporlanabilir.

• Belirtilen tiplere göre otomasyon araçları geliştirmeye veya operasyonel işlemler yürütmeye (tip alanında "ci" görülen commit mesajlarının deployment pipeline'larını tetiklemesi, "test" görülenlerin birim veya uçtan uca testleri tetiklemesi vs. gibi.) imkânlar tanınıyor.

• Kalabalık ekiplerde aynı dilin konuşulmasını, kişilerin, başkalarının yaptığı değişiklikleri çok daha kolay anlaması sağlanır.

• Jira, Trello gibi proje yönetim araçlarındaki iş detaylarından spesifik olarak ilgili işin yaşam döngüsü izlenebilir.

• İnsanların daha yapılandırılmış bir commit geçmişini kendi kendilerine keşfetmelerine imkan vererek projelerinize katkıda bulunmalarını kolaylaştırmak.

• Çıktı olarak sürüm takibi tarihçeleri üzerine analiz yapabilecek araçlar için düzenli bir veri seti oluşturuyor.

Bonus​

• Bunlar adı üstünde bir standart ve herhangi bir standartı mükemmel şekilde uyguladığınızda gerekliliği olmayan ama fantastik faydalar da elde edilebiliyor. Bunlardan bir tanesine örnek;
  • Resolve work items on commit
• PR Reviewerların herkesin commit mesajları bu şablona uyuyor mu diye bakmaması adına kullanılan platforma göre farklılık oluşacak şekilde commit mesajlarının conventional commit şartnamesine uygunluğunu kontrol edebilecek mekanizmalar geliştirmek mümkün;
  • Check Azure Devops Pr for Conventional Commit Title
• Conventional Commitlere göre otomatik semantic versioning yapmak mümkün;
  • How To Do Automatic Semantic Versioning in Azure DevOps with Commitizen
  • Semantic Versioning with Azure DevOps : An automated solution with standard version

Branch Naming

Commitlerimizin bir standardı olur da commitlerimizi pushladığımız branchlerin olmaz mı? Tabi ki var!

Kod base'de yapacağımız değişiklikleri yapmadan önce hepimiz bir branch oluşturuyoruz. Bu branchlerin yönetimi bazı durumlarda zorlaşabiliyor. Bunun önüne geçmek için branchleri etkili bir şekilde adlandırmak ve organize etmek, geliştirme sürecinin verimliliğini artırabilir. Branch isimlendirme konusunda dikkate alınması gereken yaygın kullanılan standartları incelemeden önce Regular Branches adını verdiğimiz uzun ömürlü branchlere bir göz atalım;

Git'teki regular branches, devam eden çalışmaları organize etmek için stable ve structured bir yol sunan uzun ömürlü branchlerdir. Bu branchler, repoda kalıcı olarak bulunur ve isimlendirmeleri basittir. Bazı regular Git branchleri şunlardır;

• Master (master/main) Branch: Git reposundaki varsayılan production branchidir ve sürekli olarak stable olması gerekir. Geliştiriciler, kod review ve testten sonra değişiklikleri master branchine birleştirebilirler. Projedeki tüm ekip arkadaşları, master branchini stable ve up-to-date tutmalıdır.
• Development (dev) Branch: Ana geliştirme branchidir ve geliştiricilerin yeni özellikleri, hata düzeltmelerini ve diğer değişiklikleri entegre etmesi için bir merkez olarak hizmet eder. Ana amacı, geliştiricilerin değişiklikleri doğrudan master branchine uygulamaktan kaçınmalarını sağlamaktır. Geliştiriciler, değişiklikleri dev branchinde test eder, inceler ve daha sonra master branchine birleştirirler.
• QA (QA/test) Branch: QA ve otomasyon testi için hazır olan tüm kodları içeren branchtir. Production ortamına herhangi bir değişiklik uygulamadan önce QA testleri gereklidir, böylece stable bir kod base oluşturulur.

Regular branchler şimdi bahsedeceğimiz isimlendirme kurallarını uygulamazlar.

Style​

• Küçük harf ve "-"(tire): Branch isimleri için küçük harfler ve kelimeleri ayırmak için tire kullanmalısın. Örneğin, feature/new-login veya bugfix/header-styling.
• Alphanumeric karakterler: Yalnızca alphanumeric karakterler (a-z, 0–9) ve tireler kullanmalısın. Noktalama işaretleri, boşluklar, alt çizgiler veya alphanumeric olmayan herhangi bir karakter kullanımından kaçınmalısın.
• Ardışık tireler: Ardışık tirelerden kaçınmalısın. Örneğin feature--new-login karışık ve okunması zor olabilir.
• Tire ile bitiş: Branch adını tire ile bitirmemelisin. Örneğin, feature-new-login- şeklinde bir branch ismi oluşturmamalısın.
• Açıklayıcı: Yaptığın isimlendirme açıklayıcı ve öz olmalıdır, ideal olarak branch'te yapılan çalışmayı yansıtmalıdır.

Branch Prefix​

Branchlerin amaçlarını hızlıca tanımlamak için prefixlerin kullanılması, branch türlerinin tanımlanmasına yardımcı olur;

• Feature Branch: Bu branchler yeni özellikler geliştirmek için kullanılır. Örneğin, feature/login-system
• Bugfix Branch: Kod içindeki hataları düzeltmek için kullanılır. Örneğin, bugfix/header-styling
• Hotfix Branch: Production ortamındaki kritik hataları düzeltmek için doğrudan production branchinden oluşturulur. Örneğin, hotfix/critical-security-issue
• Release Branch: Yeni bir production sürümü için hazırlık yapmak için kullanılır. Örneğin, release/v1.0.1
• Documentation Branch: Döküman yazmak, güncellemek veya düzeltmek için kullanılır. Örneğin, docs/api-endpoints
• Experimental Branch: Bir release'in veya sprintin parçası olmayan yeni ve henüz test edilmemiş özellikler veya fikirler geliştirmek için kullanılır. Bu branchler, deneme amaçlıdır ve mevcut projede uygulanıp uygulanmayacağı belli değildir. Örneğin; experimental/new-order-process-algorithm
• WIP Branch: Geliştiricilerin üzerinde çalıştıkları, ancak henüz tamamlanmamış olan özellikler veya görevler için kullanılır. Düzenli geliştirme sürecinin bir parçası olabilir veya olmayabilir. Genellikle belirli bir görev veya özellik üzerinde çalışırken kullanılır. Örneğin; wip/refactor-auth-system
• Merging Branch: Merge conflict'leri ****çözmek veya iki farklı branch'i birleştirmek için geçici olarak kullanılır. Örneğin; merge/feature-login-with-dev

Bazı iş akışlarında, özellikle daha büyük ekiplerde, Jira, Azure DevOps gibi bir proje yönetimi aracından gelen ticket/task numarasını branch adına dahil etmek yaygındır. Bu, belirli bir ticket/task için yapılan işin takibini kolaylaştırır. Örneğin, iş biriminiz kullanıcıların google ile login olabilmesini istedi. Bu özelliği eklemek için "T-123" numaralı bir jira ticket'ı açıldı, bu durumda branch adı feature/T-123-new-login-system olabilir. Konuya örnek olması açısından örnek branch isimleri;

• Bir hata düzeltmesi için elinizde bir jira var ise örnek branch adı bugfix/EMJ-1789-fix-header-styling olmalı
• Yeni bir geliştirme için elinizde bir User Story var ise örnek branch adı feature/US-1288-new-login-system olmalı
• Yeni bir geliştirme için elinizde bir Task var ise örnek branch adı feature/T-1289-new-login-system olmalı

Git'te branch isimlendirme kuralları, sistem tarafından zorunlu tutulmasa da, özellikle bir ekip içinde çalışırken temiz ve anlaşılır bir kod base sağlamak için önemlidir. Bu kurallara uyarak, branchlerin kolayca anlaşılabilir olmasını sağlayabiliriz.

Yukarıda anlatılanları uygulayıp uygulamamak veya iş yoğunluğundan dolayı buna ayıracak vaktimiz yok gibi cümlelerle bunları ertelemek sana kalmış. Fakat Robert C. Martin'in Clean Code kitabında atıfta bulunduğu LeBlanc yasasının "Sonra asladır. (Later equals never.)" varsayımını unutmamak gerekiyor 🙂

Kaynaklar;

• https://www.gitkraken.com/learn/git/best-practices/git-commit-message
• https://www.linkedin.com/pulse/7-best-practices-writing-good-git-commitmessages-kirinyet-brian/
• https://www.git-tower.com/blog/how-to-write-the-perfect-commit-message/
• https://www.pullrequest.com/blog/mastering-the-art-of-git-commit-messages/
• https://semver.org/
• https://www.freecodecamp.org/news/how-to-write-better-git-commit-messages/
• https://gist.github.com/robertpainsi/b632364184e70900af4ab688decf6f53
• https://learn.microsoft.com/en-us/azure/devops/repos/git/resolution-mentions?view=azure-devops
• https://dev.to/shinjithdev/git-good-best-practices-for-branch-naming-and-commit-messages-oj4
• https://medium.com/@abhay.pixolo/naming-conventions-for-git-branches-a-cheatsheet-8549feca2534
• https://phoenixnap.com/kb/git-branch-name-convention
• Assolist: ChatGPT