Geliştirici Günlüğü Tutmak: Öğrenme Ve Hata Ayıklama

Yazılım geliştirirken her gün yeni bir problemle karşılaşırız.

Bazen saatlerce uğraştığımız bir hatayı tek satırlık değişiklikle çözeriz. Bazen yeni öğrendiğimiz bir yöntem, haftalar sonra başka bir projede tekrar karşımıza çıkar.

Ancak öğrendiklerimizi kaydetmiyorsak aynı problemleri yeniden araştırmak zorunda kalabiliriz.

İşte bu noktada geliştirici günlüğü devreye girer.

Geliştirici günlüğü; karşılaşılan hataların, uygulanan çözümlerin, alınan teknik kararların ve öğrenilen bilgilerin düzenli olarak kaydedildiği kişisel bir bilgi kaynağıdır.

Üstelik uzun yazılar yazmanız gerekmez. Doğru yapılandırılmış birkaç satırlık not bile gelecekte saatler kazandırabilir.

Geliştirici Günlüğü Nedir?

Geliştirici günlüğü, yazılım geliştirme sürecinde edinilen deneyimlerin kayıt altına alındığı teknik bir çalışma günlüğüdür.

Bu günlükte şunlar yer alabilir:

• Karşılaşılan hata mesajları
• Denenen çözüm yöntemleri
• Çalışan ve çalışmayan yaklaşımlar
• Kullanılan komutlar
• Kod parçaları
• Mimari kararlar
• Performans gözlemleri
• Yeni öğrenilen kavramlar
• Araştırılması gereken konular
• Proje sırasında alınan önemli kararlar

Bu yapı klasik bir günlükten farklıdır.

Amaç gün içinde yapılan her şeyi anlatmak değil, daha sonra tekrar ihtiyaç duyulabilecek bilgileri kolayca bulunabilir hâle getirmektir.

Neden Geliştirici Günlüğü Tutmalıyız?

Yazılım geliştirme büyük ölçüde problem çözme sürecidir.

Bir problemi çözmek için:

• Hata mesajlarını inceleriz.
• Log kayıtlarını kontrol ederiz.
• Dokümantasyon okuruz.
• Farklı yöntemler deneriz.
• Kod üzerinde değişiklikler yaparız.
• Sonucu test ederiz.

Problem çözüldüğünde ise çoğu zaman hemen bir sonraki göreve geçeriz.

Bir süre sonra benzer bir hatayla tekrar karşılaştığımızda çözümün ayrıntılarını hatırlamayabiliriz.

Bir problemi ikinci kez çözmek yerine, ilk çözümü tekrar kullanabilmek daha değerlidir.

Geliştirici günlüğü, geçmişte elde edilen deneyimi kişisel bir teknik arşive dönüştürür.

1. Öğrenilen Bilgilerin Kalıcı Olmasını Sağlar

Bir konuyu yalnızca okumak ile kendi cümlelerimizle açıklamak aynı şey değildir.

Yeni öğrendiğimiz bir kavramı günlüğe yazarken:

• Bilgiyi yeniden düşünürüz.
• Önemli noktaları ayırırız.
• Kavramlar arasında bağlantı kurarız.
• Anlamadığımız bölümleri fark ederiz.
• Bilgiyi kendi ifadelerimizle açıklamaya çalışırız.

Bu süreç pasif öğrenmeyi aktif öğrenmeye dönüştürür.

Örneğin Dependency Injection hakkında bir eğitim izledikten sonra yalnızca bağlantıyı kaydetmek yerine şu soruları cevaplamak daha faydalıdır:

• Dependency Injection hangi problemi çözüyor?
• Hangi durumda kullanılmalı?
• Yanlış kullanılırsa ne tür sorunlar oluşabilir?
• Projemde bunu nerede uygulayabilirim?
• Küçük bir kod örneği nasıl görünür?

Bu sorulara kısa cevaplar yazmak, konuyu gerçekten anlayıp anlamadığınızı gösterir.

2. Hata Ayıklama Sürecini Hızlandırır

Hata ayıklama sırasında yalnızca çalışan çözüm değil, çözüme nasıl ulaşıldığı da önemlidir.

Örneğin bir API isteğinde şu hatayı aldığımızı düşünelim:

401 Unauthorized

Bu hata birçok farklı nedenle oluşabilir:

• Token gönderilmiyor olabilir.
• Token süresi dolmuş olabilir.
• Yanlış authentication şeması kullanılmış olabilir.
• Kullanıcının gerekli yetkisi bulunmayabilir.
• Ortam değişkeni yanlış tanımlanmış olabilir.

Yalnızca “token düzeltildi” şeklinde not almak yeterli değildir.

Daha faydalı bir kayıt şöyle olabilir:

Problem:
Mobil uygulamadan gönderilen API isteği 401 dönüyordu.

Neden:
Authorization başlığında "Bearer" ifadesi bulunmuyordu.

Çözüm:
İstek başlığı "Authorization: Bearer {token}" olacak şekilde güncellendi.

Kontrol:
Aynı istek geçerli, süresi dolmuş ve eksik token ile test edildi.

Aylar sonra benzer bir problemle karşılaşıldığında çözüm süreci baştan tekrarlanmaz.

3. Çalışmayan Yöntemleri Kaydetmeyi Sağlar

Geliştirici günlüğünde yalnızca başarılı çözümler bulunmamalıdır.

Çalışmayan yöntemler de değerlidir.

Çünkü bir problem üzerinde çalışırken aynı yöntemleri farkında olmadan tekrar tekrar deneyebiliriz. Ekipteki başka bir geliştirici de daha önce başarısız olan yaklaşımı yeniden uygulayabilir.

Bu nedenle şu bilgiler kaydedilebilir:

• Hangi yöntem denendi?
• Neden işe yaramadı?
• Hangi hata ortaya çıktı?
• Hangi koşullarda çalışabilir?
• Neden başka bir çözüm tercih edildi?

Örneğin:

Deneme:
Verileri her istekte doğrudan veritabanından çekmek.

Sonuç:
Sorgu doğru çalıştı ancak yoğun kullanımda yanıt süresi yükseldi.

Karar:
Sık kullanılan ve nadiren değişen veriler Redis üzerinde önbelleğe alındı.

Not:
Veri güncellendiğinde cache temizleme mekanizması unutulmamalı.

Bu kayıt yalnızca çözümü değil, teknik kararın gerekçesini de korur.

4. Teknik Kararların Nedenini Hatırlatır

Bir projede alınan kararlar aylar sonra anlamsız görünebilir.

“Bu yapı neden böyle kurulmuş?”

“Neden bu kütüphaneyi kullandık?”

“Neden veriyi burada önbelleğe aldık?”

“Neden daha basit bir yöntem tercih etmedik?”

Kod, çoğu zaman ne yapıldığını gösterir. Fakat neden yapıldığını her zaman açıklamaz.

Geliştirici günlüğü şu kararların gerekçelerini kayıt altında tutabilir:

• Teknoloji seçimi
• Veritabanı tasarımı
• API yapısı
• Güvenlik yaklaşımı
• Cache stratejisi
• Mimari desen seçimi
• Performans iyileştirmesi
• Üçüncü taraf servis kullanımı

Bu notlar özellikle uzun süren projelerde ve ekip çalışmalarında değer kazanır.

5. Kişisel Gelişimi Görünür Hâle Getirir

Yazılım geliştirirken ilerlemeyi fark etmek her zaman kolay değildir.

Her gün yeni problemlerle karşılaştığımız için sürekli eksik olduğumuzu düşünebiliriz. Eski notlara bakmak ise zaman içinde ne kadar yol aldığımızı gösterir.

Üç ay önce zorlandığınız bir konu bugün size basit gelebilir.

Geliştirici günlüğü sayesinde:

• Öğrenilen teknolojiler görülebilir.
• Tekrarlanan hatalar fark edilebilir.
• Zayıf olunan konular belirlenebilir.
• Öğrenme hedefleri oluşturulabilir.
• Teknik gelişim somut olarak takip edilebilir.

Bu kayıtlar performans görüşmeleri, öz geçmiş güncellemeleri ve teknik mülakat hazırlıkları sırasında da kullanılabilir.

Geliştirici Günlüğüne Neler Yazılmalı?

Her geliştiricinin çalışma şekli farklıdır. Bu nedenle tek bir doğru günlük yapısı yoktur.

Başlangıç için şu başlıklar kullanılabilir:

Günün Problemi

Bugün hangi teknik problemle karşılaştım?

Problemi tek veya iki cümleyle açıklamak yeterlidir.

Hata Mesajı

Varsa hata mesajı değiştirilmeden kaydedilmelidir.

Hata metninin tamamını saklamak, günlüğün daha sonra aranmasını kolaylaştırır.

Problemin Nedeni

Hata neden oluştu?

İlk tahmin ile doğrulanan neden birbirinden ayrılmalıdır.

Denenen Yöntemler

Hangi çözümler denendi?

Çalışmayan yöntemlerin neden başarısız olduğu da yazılmalıdır.

Uygulanan Çözüm

Problem hangi değişiklikle çözüldü?

Gerekirse kısa bir kod örneği veya ilgili dokümantasyon bağlantısı eklenebilir.

Öğrenilen Ders

Bu problem tekrar yaşanmasın diye ne yapılmalı?

Test, doğrulama veya geliştirme sürecine yeni bir kontrol eklenebilir mi?

Sonraki Adım

Araştırılması veya iyileştirilmesi gereken başka bir konu var mı?

Bu bölüm, yarım kalan işlerin unutulmasını önler.

Basit Bir Geliştirici Günlüğü Şablonu

Aşağıdaki şablon günlük kullanım için yeterlidir:

# Tarih ve Konu

## Problem
Karşılaştığım problemi kısa şekilde açıkla.

## Ortam
- Proje:
- Teknoloji:
- Sürüm:
- Çalışma ortamı:

## Hata Mesajı
Hata mesajını veya önemli log kaydını ekle.

## Denediğim Yöntemler
1. Denenen ilk yöntem ve sonucu
2. Denenen ikinci yöntem ve sonucu

## Temel Neden
Problemin gerçek nedenini yaz.

## Çözüm
Uygulanan çözümü ve gerekiyorsa kod örneğini ekle.

## Doğrulama
Çözümün çalıştığını nasıl test ettiğini yaz.

## Öğrendiğim Ders
Bu deneyimden çıkarılan sonucu özetle.

## Sonraki Adım
Daha sonra araştırılacak veya geliştirilecek konuyu ekle.

Her başlığın doldurulması zorunlu değildir. Önemli olan günlüğün sürdürülebilir olmasıdır.

Günlük Tutmak İçin Hangi Araçlar Kullanılabilir?

Kullanılacak araçtan çok, notlara daha sonra kolayca ulaşabilmek önemlidir.

Geliştirici günlüğü için şu yöntemler tercih edilebilir:

• Markdown dosyaları
• Git deposu
• Not alma uygulamaları
• Wiki sistemleri
• Proje dokümantasyonu
• Fiziksel defter
• Kişisel blog

Markdown ve Git Kullanmak

Teknik notlar için Markdown oldukça kullanışlıdır.

Markdown sayesinde:

• Kod blokları eklenebilir.
• Başlıklar oluşturulabilir.
• Bağlantılar saklanabilir.
• Dosyalar metin tabanlı tutulabilir.
• Değişiklikler Git ile takip edilebilir.

Örnek bir klasör yapısı şöyle olabilir:

developer-journal/
├── debugging/
├── dotnet/
├── database/
├── architecture/
├── performance/
└── daily-notes/

Notların konulara göre ayrılması, büyüyen arşivde bilgi bulmayı kolaylaştırır.

Kişisel Blog Kullanmak

Öğrenilen konuları blog yazısına dönüştürmek de etkili bir yöntemdir.

Bir konuyu başkasına anlatabilecek kadar açık yazmak, bilgiyi daha iyi anlamayı sağlar. Aynı problemle karşılaşan geliştiriciler de bu içerikten yararlanabilir.

Ancak günlükte bulunan:

• Şirket bilgileri
• Kullanıcı verileri
• Şifreler
• API anahtarları
• Erişim bilgileri
• Özel kaynak kodlar
• Güvenlik ayrıntıları

herkese açık bir blogda paylaşılmamalıdır.

Özel notlar ile yayımlanabilir teknik içerikler birbirinden ayrılmalıdır.

Etkili Bir Geliştirici Günlüğü İçin İpuçları

Notu Problem Çözülür Çözülmez Yazın

Üzerinden zaman geçtikçe çözümün önemli ayrıntıları unutulur.

Mümkünse not, problem çözüldikten hemen sonra tamamlanmalıdır.

Kısa ve Aranabilir Başlıklar Kullanın

“Bugünkü çalışmalar” gibi genel başlıklar yerine problemi açıklayan başlıklar tercih edilmelidir.

Örneğin:

ASP.NET Core JWT 401 Unauthorized Hatası

Bu başlık gelecekte kolayca aranabilir.

Hata Mesajlarını Olduğu Gibi Kaydedin

Hata mesajını özetlemek yerine asıl metni saklamak arama yapmayı kolaylaştırır.

Gizli veya kişisel bilgiler varsa not kaydedilmeden önce temizlenmelidir.

Kodu Değil, Kararı Açıklayın

Kod zaten projede bulunabilir. Günlüğün asıl değeri, kodun neden o şekilde yazıldığını açıklamasıdır.

Bu nedenle şu sorulara odaklanın:

• Neden bu çözüm seçildi?
• Hangi alternatifler değerlendirildi?
• Hangi riskler bulunuyor?
• Hangi durumda çözüm yeniden ele alınmalı?

Etiketler Kullanın

Notlara teknoloji ve problem türüne göre etiket eklemek faydalıdır.

Örneğin:

#dotnet #api #authentication #debugging

Bu etiketler benzer notların daha sonra birlikte bulunmasını sağlar.

Düzenli Olarak Gözden Geçirin

Günlüğü yalnızca yazmak yeterli değildir.

Haftalık veya aylık olarak eski notlar incelenebilir. Tekrarlanan problemler tespit edilerek daha kalıcı çözümler geliştirilebilir.

Örneğin aynı hata farklı projelerde sürekli yaşanıyorsa:

• Ortak bir kütüphane hazırlanabilir.
• Otomatik test eklenebilir.
• Kod standardı oluşturulabilir.
• Ekip dokümantasyonu güncellenebilir.
• Geliştirme kontrol listesi hazırlanabilir.

Böylece günlük yalnızca geçmişin kaydı değil, süreç iyileştirme aracı hâline gelir.

En Sık Yapılan Hatalar

Geliştirici günlüğü tutarken yapılan en yaygın hata, sistemi gereğinden fazla karmaşıklaştırmaktır.

Her not için uzun açıklamalar, çok sayıda kategori ve kusursuz biçimlendirme zorunlu hâle gelirse günlük tutmak ek bir işe dönüşür.

Diğer yaygın hatalar şunlardır:

• Yalnızca başarılı çözümleri yazmak
• Problemin nedenini belirtmemek
• Çok genel başlıklar kullanmak
• Kopyalanan kodu açıklamamak
• Kaynak bağlantılarını eklememek
• Gizli bilgileri notlara taşımak
• Notları bir daha gözden geçirmemek

En iyi geliştirici günlüğü, düzenli olarak kullanılan günlüktür.

Geliştirici Günlüğü İçin 10 Dakikalık Rutin

Günlük tutmayı alışkanlığa dönüştürmek için çalışma gününün sonunda 10 dakika ayrılabilir.

Bu sürede şu üç soru cevaplanabilir:

1. Bugün hangi problemi çözdüm?
2. Bugün ne öğrendim?
3. Yarın hangi konudan devam edeceğim?

Yoğun bir günde yalnızca birkaç madde yazmak bile yeterlidir.

Örneğin:

Bugün:
- Yavaş çalışan SQL sorgusunun execution plan çıktısını inceledim.
- Eksik indeks nedeniyle table scan yapıldığını fark ettim.
- İndeks sonrasında sorgu süresi 820 ms'den 95 ms'ye düştü.
- Yarın benzer sorguların performansını kontrol edeceğim.

Bu kayıt kısa olmasına rağmen problem, neden, çözüm, ölçüm ve sonraki adım bilgilerini içerir.

Sonuç

Geliştirici günlüğü tutmak basit fakat etkili bir alışkanlıktır.

Düzenli tutulan bir günlük:

• Öğrenilen bilgileri kalıcı hâle getirir.
• Hata ayıklama süresini kısaltır.
• Çalışmayan yöntemlerin tekrarlanmasını önler.
• Teknik kararların gerekçesini korur.
• Kişisel gelişimi görünür hâle getirir.
• Teknik içerik üretmeyi kolaylaştırır.
• Ekip içindeki bilgi paylaşımını güçlendirir.

Başlangıçta kapsamlı bir sistem kurmak gerekmez.

Bugün çözdüğünüz tek bir problemi; nedeni, denediğiniz yöntemler ve çalışan çözümüyle birlikte kaydederek başlayabilirsiniz.

Zamanla bu küçük notlar, kullandığınız teknoloji ve projelere özel değerli bir bilgi tabanına dönüşecektir.

İyi bir geliştirici her şeyi ezbere bilen değil, öğrendiği bilgiye yeniden nasıl ulaşacağını bilen kişidir.