Öncelikle herhangi bir yanlış anlaşılmaya sebebiyet vermemek için, kaynak kodu sevmekten kastımın ona duygusal olarak bağlanmak olmadığını söylemeliyim. Profesyonel iş hayatında geliştirdiğiniz uygulama ve yazılımlar her ne kadar işinizi yaparken size zevk veriyor olsa da kaynak kod size ait olan bir nesne değildir. Tutkuyla bağlanmayi seçeceğiniz olgu, o an yazdığınız uyugulama yerine bilim, teknoloji ve yeni uygulamalar üretmek olursa size daha çok katkı sağlayacağını düşünüyorum. Benim görmediğim istisnalar tabi ki vadır, fakat ne zaman bir uygulama geliştirme uzmanıyla konuşurken şu cümleleri duysam "Bu kod benim bebeğim, bu kodu ben yazdım, kod namustur (Evet, bunu gerçekten duydum)" aklımdaki çevirileri şu şekilde oluyor "Evet, kodu yazdım ama benden başkası okuyamıyor, bazen ben de ne yazdığımı anlayamıyorum. Kendimce harika olduğunu düşündüğüm çözüm yöntemlerini takımımla yeterince tartışmadan uygulamaya dahil ettim. Bu is yapılırken çok zaman harcadım ondan en ufak bir geri bildirime bile tahamülüm yok."

Peki, kaynak kodu sevmekten kastım ne? Eğer takım olarak kaynak kodumuza iyi davranırsak bakımını düzenli yapar ve temiz tutarsak o da bize, sorunsuz release'lere imkan vererek, yeni fonksiyonları uygulamamıza sorunsuz ve hızlı eklememizi sağlayarak, yapılan hataları erken fark ettirerek ve yapılmış hataları en kısa sürede düzeltmemizi sağlayarak bizi ödüllendirecektir. Gördüğünüz gibi benimkisi tamamen çıkar ilişkisi. İtiraf etmem gerekirse iş yerinde stres altında fazla mesai yapıyor olmaktansa kendime zaman ayırmak bana daha cazip geliyor.

Aynı sayfada mıyız?

Beraber çalıştığım ekiplere baktığımda bazı pratikler ve amaçları konusunda aynı sayfada olmadığımızı farkettim. Özellikle kalite dendiğinde insanların aklına yalnızca bir takım üyesi tarafından test edilmiş ve çalışan uygulama geldiğini gözlemledim. Peki bir uygulamanın kalitesini koruduğunun göstergesi sadece çalışıyor olması mıdır?

Benim kaliteli yazılımdan anladığım ilk şey sağlıklı bir kaynak koda sahip olmasıdır. Harika çalışan bir uygulamanız var ama insanlar üzerinde değişiklik yapmaya korkuyor yada uygulamaya yeni bir özellik eklemek, kodun yazımından canlıya alınmasına kadar ki süreçte takımda stres ve huzursuzluk yaratıyorsa, özellikle takımda “Aman çalışıyorsa dokunma.” cümlesi duyuluyorsa kod alt yapınızla ilgili ciddi sıkıntılarınız olabilir.

Sorunlar ve Çözüm Yaklaşımları

Bu yazı dizisinde, uygulama kodunun yazımına başlanmasından itibaren collaboration branch'nizle birleşene kadar olan süreçlerden, sık kullanıldığını gördüğüm bazı araçlardan bahsedeceğim ve bazı yan makaleler ile kod örnekleri paylaşarak yada araçların kullanımını göstererek yazımı desteklemeye çalışacağım.
Bana göre sağlıklı bir kaynak kod kodun yazımıyla değil iyi bir kaynak kod yönetim aracı ve source code repository management tool ile başlar. Takım üyelerinin teknik olarak iş birliği yapmaya başladığı yer tam olarak burasıdır. İyi bir branching stratejisi ile kod yazmak takım içi işbirliği açısından önemli olduğu kadar uygulamanın çıkış günü geldiğinde deployment'ı da kolaylaştıracaktır ama biz şimdilik deployment konusuna değinmeyeceğiz.
Tek başınıza çalışırken de kaynak kod yönetim aracı kullanmak ve düzenli commitler yapmak yaptığınız değişiklikleri gözlemleme, çözdüğünüz problemlere geri dönüp bakma, deneysel kod değisikliklerini ana kodunuzu bozmadan uygulayıp test etmek ve istemediğiniz değişikliği geri almak gibi olanaklar sağlayacağından daima bir kaynak kod yönetim aracı ile calışmak iyi bir fikirdir.
Kaynak kod yönetim aracı işini hallettikten sonra gelelim collaboration branch'imize birleşmeden önce yazılan bir kodun geçirmesi gereken süreçlere.
Hiç kaynak kod yönetim aracından son versiyonunu aldığınız kodun derlenemediği oldu mu? gerçekten çok sinir bozucu bir durum değil mi? Sabah işe geldiniz uygulamanız için yenı bir fonksiyon geliştireceksiniz ve ilk iş olarak kodun son versiyonunu bilgisayaranıza alıp derlemeye başladınız ve … kod derlenemedi 😊 Bu karşılaşmak istemeyeceğimiz ilk durumdur ve olmasının iki sebebi olabilir ya takım arkadaşınız kodunu derlemeden collaboration branch ile birleştirdi yada onun bilgisayarında derlenen kaynak kod belli bir sebepten sizinkinde derlenemiyor. O zaman çözümünüz kodun collaboration branch ile birleşmeden önce bağımsız bir bilgisayarda derlenmesi olabilir. Bunu yapması için ise Continues Integration araçlarına güveniyoruz.
Peki, hiç yazdığınız çalışan ve hatta production sunucusunda hala sorunsuz işleyen bir fonksiyon siz kodun son halini bilgisayarınıza aldıktan sonra bozuldu mu? Bunun sebebini bulmak icin saatlerce debug yaptıktan sonra, bir takım arkadaşınızın yeni bir foksiyon için yaptığı değişiklikten dolayı olduğunu farkettiniz mi? En önemli soru, bu yüzden takım arkadaşınızı suçlu gördünüz mü? Eğer cevap evet ise buradaki tek suçlu sizsiniz diyebilirim. Takım önce şunu anlamalıdır, kaynak koda eklenmiş her bir kod satırı yazan kişinin değil takımın sorumluluğu altındadır. Bunların başımıza gelmemesi için uygulayabileceğimiz pratikler şunlar olabilir: Code Review, test yazmak ve anlaşılır commit mesajları. Anlaşılır commit mesajaları burada önemlidir çünkü ne kadar iyi test yazarsak yazalım ve ne kadar dikkatli kodu incelersek inceleyelim sorun çıkma olasılığı azalsa dahi 0 olmayacaktır. Tüm kaynak kodu debug etmek yerine Kaynak kod yönetim aracındaki tarihçeden son yapilan deiğişiklikleri anlayabilirsek kodu debug etmeye baslayacagimiz yeri kolayca tespit edebiliriz yada değişiklikleri geri alarak kodun çalıştığı noktaya dönebilir ve soruna neyin sebep olduğunu bulabiliriz.
Yazdığımız testlerin collaboration branch'imize her hangi bir kod parçası birleşmeden önce çalışıp, eğer testler geçemiyorsa birleşmemesi gene iyi bir pratiktir. Sonuçta hepimizin dalgınlıkla yada yaptigi değişikliğe çok güvenerek kodu derlemeden yada testleri calıştırmadan kaynak kod ile birleştirdiği anları olabilir. Bu yuzden bu görevleri otomatize ederek insan hatasını ortadan kaldırmak iyi bir fikir olabilir. Tam burada ci araçları imdadımıza yetişecektir.

Özet

Yazılan kodun kaynak koda dahil edilmeden önce geçireceği süreçleri bir daha özetlersek aşağıdaki gibi bir liste oluşturabiliriz:

  • Kod derleniyor mu?
  • Tüm testler başarılı bir şekilde geçiyor mu?
  • Takım arkadaşları kodu inceleyip onayladılar mı?
  • Eğer kod inceleme esnasında herhangi bir yorum yapıldıysa bu yorumlar bir anlaşmaya varılarak kapatıldı mı?

Bu listeyi uygulamamız için gerekli araçlar ise:

  • Source Control ( Git, TFVC, SVN … )
  • Source control repository management tools (Azure devops, TFS, Bitbucket, GitLab, Github)
  • Continues integration tools (Azure devops, TFS, Teamcity, CircularCI)

Son Söz

Her ne kadar bahsettiklerim DevOps kavramını da içerse bilinçli olarak DevOps kelimesini kullanmamaya gayret ettim. Devops yazı da geçen bazı pratikleri içerse de kapsam olarak çok daha geniş içeriğe sahip olduğu için bir gün ayrıca değinmeye çalışacağım.

Proje geliştirme yönteminiz ister waterfall olsun ister agile, uygulamanıza eklenecek herhangi bir fonksiyon bu süreçlerden geçmediği sürece zamanla bakımını yapamadığımız bir kaynak koda sahip olma ihtimalimiz çok yüksek. Bu gerçekleştiğinde ise gelsin mesailer, gelsin stres, gelsin “Geçiş vardı abiiii !!! bütün gece ayaktaydık.” Özellikle çevik yazılım geliştirme metodolojilerini bu pratikler olmak sızın kullanmak faydayı büyük oranda düşürebilir. Bu pratikleri çevik yöntemlerle kullanmak ise takımı tamamen değişime hızlı cevap veren, kendine güvenen ve korkmadan manevra yapabilen bir yapıya dönüştürecektir.