Bu 8 haftalık plan neyi hedefler?
Bu eğitim planı, “bir dili öğretmekten” çok ürün odaklı yazılım geliştirme alışkanlıklarını kazandırmayı amaçlar: kullanıcı ihtiyacını netleştirme, kapsamı küçük tutma (MVP), iteratif teslim (sprint), ölçülebilir kalite (test), ekip içi çalışma (kod inceleme) ve üretime yakın bir çalışma ritmi.
Hedef kitle & önkoşullar (beklentiyi netleştirme)
Kimler için: Temel programlama bilgisi olan (değişkenler, fonksiyonlar, veri yapıları) ve Git/komut satırına giriş yapmış geliştiriciler veya ekipler.
Önkoşullar: En az 1 küçük uygulama geliştirmiş olmak, Git ile branch/commit atabilmek, test çalıştırma mantığını bilmek.
Kapsam dışı: Bu plan belirli bir teknoloji yığını seçtirmez ve “işe yerleştirme” gibi kesin sonuçlar vaat etmez; amaç ölçülebilir proje çıktıları ve tekrar edilebilir ekip pratikleridir.
Zaman planı programdan programa değişir. Örnek olarak bir bootcamp program sayfasında 8 haftalık part-time bir faz için haftada 20–25 saat civarı bir taahhüt ifadesi yer alır; bu sayı burada “genel bir pazar standardı” olarak değil, tek bir örnek olarak iş yükünü kaba taslak planlamaya yardımcı olması için anılır (S4).
Programın omurgası: Sprint + Proje-Temelli Öğrenme
8 haftaya sığan pratik bir kurgu genellikle 2–3 sprint ya da tek bir capstone projenin sprint mantığıyla ilerlemesidir. Proje-temelli öğrenme yaklaşımında öğrenme, ders anlatımından çok “gerçekçi bir problem” etrafında yapılandırılır ve ara teslimlerle takip edilir; bu da geri bildirim döngüsünü görünür kılar (S3).
Bu nedenle planı şu üç eksende tasarlıyoruz:
- Ürün ekseni: kullanıcı hikâyeleri, kabul kriterleri, MVP ve backlog yönetimi
- Mühendislik ekseni: test stratejisi (TDD ve test piramidi), kod kalitesi, gözden geçirme
- Takım ekseni: PR akışı, rol paylaşımı, demo ve retrospektif
Başlamadan: Araçlar, repo düzeni ve çalışma kuralları
Önerilen minimum araç seti
- Git + GitHub (branch, PR, review, issues)
- Test çerçevesi (seçtiğiniz dile göre: ör. Jest/Pytest/JUnit vb.)
- CI (ör. GitHub Actions) ile testlerin PR’da otomatik çalışması
- Baseline kalite kontrolleri: linter/formatter, basit güvenlik taramaları (imkâna göre)
Kod inceleme (PR) için temel kurallar
Kod inceleme, sadece “hata bulma” değil; ekip standartlarını öğretmek, tasarımı tartışmak ve bilgi paylaşmaktır. GitHub’ın önerileri; küçük ve odaklı PR’lar, net bağlam ve otomasyonla desteklenen kontroller gibi pratiklerin gözden geçirme kalitesini artırmaya yardımcı olabileceğini vurgular (S1).
- PR başına hedef: tek bir kullanıcı hikâyesi ya da tek bir teknik iş
- PR açıklaması: “Ne değişti, neden, nasıl test edilir?”
- En az 1 bağımsız inceleyici; kritik dosyalarda 2 inceleyici (ekip uygunsa)
- İnceleme checklist’i: güvenlik, performans, test, okunabilirlik, hata durumları
Test yaklaşımı: TDD ve test piramidi (özet ve uygulama)
Testleri “en sona” bırakmak, 8 haftalık yoğun bir programda risk oluşturur: hızlanmak için kalite borcu birikir ve proje ilerledikçe değişiklik maliyeti artar. Bu yüzden TDD ve test piramidi gibi yaklaşımları daha ilk haftalardan sisteme bağlamak faydalıdır. Burada araçlardan çok, uzun süredir kullanılan mühendislik prensiplerine odaklanıyoruz (S2).
Test piramidi ile pratik hedefler
- Çok sayıda birim testi: iş kuralları, edge-case’ler
- Daha az entegrasyon testi: API + DB gibi kritik akışlar
- En az sayıda UI/E2E testi: “en kritik kullanıcı yolculuğu” için
Bu rehber bir “kapsama yüzdesi” hedefi dayatmaz; ölçülebilir hedef olarak şunları kullanabilirsiniz: kritik kullanıcı akışlarının test edilmesi, PR’larda test ekleme alışkanlığı ve regresyon hatalarının daha erken yakalanması.
8 haftalık ürün odaklı eğitim planı (hafta hafta)
Aşağıdaki plan, tek bir ana projeyi 8 hafta boyunca büyütmeye uygundur. İsterseniz aynı yapıyı 2 daha küçük projeye bölebilirsiniz; ancak ürün odaklı akışın oturması için tek proje daha tutarlı olabilir.
| Hafta | Odak | Öğrenme hedefi | Teslim (ölçülebilir çıktı) |
|---|---|---|---|
| 1 | Problem ve MVP | Kullanıcı hikâyesi yazma, kabul kriterleri, repo/CI kurulumu | Backlog + MVP tanımı, çalışan CI, “Hello feature” PR’ı |
| 2 | Temel mimari | Modüler yapı, veri modeli, API sözleşmesi | İlk endpoint’ler + birim testleri, küçük PR’larla ilerleme |
| 3 | TDD ile çekirdek özellik | İş kuralı geliştirme, test piramidi mantığı | Çekirdek akış için testler + özellik demo’su |
| 4 | Entegrasyon ve hata yönetimi | Validation, hata cevapları, logging temelleri | Entegrasyon testi eklenmiş 1–2 kritik API akışı |
| 5 | Ön yüz/istemci | İstemci-API entegrasyonu, durum yönetimi | Minimum arayüz + API bağlantısı, kullanılabilir MVP |
| 6 | Kalite ve gözden geçirme | Kod inceleme kalitesi, refactor, teknik borç azaltma | Refactor PR’ları, checklist uygulanması, testlerin güçlenmesi |
| 7 | Üretime yakınlaştırma | Basit güvenlik kontrolleri, performans temelleri | Deploy denemesi (ortama göre), kritik akış için E2E testi |
| 8 | Sunum ve değerlendirme | Demo, ölçüm, dokümantasyon, retrospektif | Capstone demo + teknik dokümantasyon + öğrenilenler raporu |
Her hafta uygulanacak sprint ritmi (checklist)
Proje-temelli öğrenme yaklaşımını güçlü kılan şey “haftalık ritim”dir: planla, yap, göster, ölç, iyileştir. Ara teslimler ve düzenli geri bildirim döngüleri özellikle önemlidir (S3).
- Pazartesi/başlangıç: Sprint hedefi, 3–6 kullanıcı hikâyesi seçimi, görev kırılımı
- Günlük 10–15 dk: blokajlar ve PR sırası (kim neyi review ediyor?)
- Hafta ortası: ara demo + backlog yeniden önceliklendirme
- Hafta sonu: demo + retrospektif (1 iyileştirme kararı)
Pratik şablonlar: PR açıklaması ve demo rubriği
Aşağıdaki şablonlar, “ne yaptık?”tan çok “nasıl doğruladık?” sorusunu standartlaştırır. Kod incelemeyi küçük PR’lar ve net bağlamla güçlendirme önerileri için GitHub’ın kılavuzunu referans alabilirsiniz (S1).
PR açıklama şablonu (kopyala-yapıştır)
| Alan | Ne yazılmalı? |
|---|---|
| Özet | Bu PR neyi değiştiriyor? (1–3 madde) |
| Neden | Hangi kullanıcı hikâyesi / sorun / kabul kriteri? |
| Nasıl test edilir? | Komutlar, senaryolar, örnek istek/yanıt |
| Riskler | Geriye dönük uyumluluk, veri değişimi, kritik akış etkisi |
| Ekran görüntüsü / çıktı | UI varsa ekran görüntüsü; yoksa log/çıktı örneği |
Haftalık demo için mini rubrik
| Kriter | Minimum kanıt |
|---|---|
| Ürün | 1–2 kullanıcı hikâyesi + kabul kriterine göre gösterim |
| Kalite | En az 1 yeni test + CI çıktısı |
| Süreç | PR linkleri + 1–2 önemli review yorumu |
| Öğrenme | Bu hafta neyi iyileştirdik? (retrospektiften 1 karar) |
Örnek proje brifleri (ürün odaklı, 8 haftaya uygun)
Proje 1: “Randevu Takip” mini SaaS (B2C)
Kullanıcı problemi: Hizmet alan kullanıcıların randevularını kaçırmaması, hizmet verenin çakışmaları azaltması.
- MVP: kayıt/giriş, randevu oluşturma, listeleme, iptal
- Hafta 3–4: çakışma kontrolü (iş kuralı) + TDD ile geliştirme
- Hafta 5: basit takvim görünümü (istemci)
- Hafta 7: validation ve temel istek sınırlandırma gibi korumalar (ihtiyaca göre)
Değerlendirme ipucu: “Randevu çakışması” kuralı için birim testlerini zorunlu tutmak, TDD mantığını somutlaştırır (S2).
Proje 2: “Okuma Listesi + Notlar” (İçerik/Blog odaklı)
Kullanıcı problemi: İçerik üreticilerinin/link toplayanların kaynaklarını etiketleyip not alması.
- MVP: link ekleme, etiketleme, arama, not ekleme
- Hafta 2: API sözleşmesi + veri modeli
- Hafta 4: arama ve filtreleme (edge-case’lerle test)
- Hafta 6: refactor: servis katmanı / modülerleşme (dile göre)
Kod inceleme odağı: Arama/filtre PR’larını küçük tutun ve inceleme checklist’ine “performans ve hata durumları” maddesi ekleyin (S1).
Proje 3: “IT Envanter ve Ticket” (Basit iç araç)
Kullanıcı problemi: Küçük ekiplerde cihaz/envanter takibi ve basit destek talepleri.
- MVP: cihaz ekle, kullanıcıya ata, ticket aç/kapat, durumlar
- Hafta 3: rol bazlı yetkilendirme taslağı (basit seviyede)
- Hafta 5: yönetim paneli sayfaları
- Hafta 8: kısa teknik dokümantasyon + kurulum adımları
Kod inceleme pratikleri: Eğitimde nasıl öğretilir?
Kod inceleme becerisi, “yorum yazmayı” değil, risk yönetimini öğretir: değişikliğin kapsamını küçültme, geri alma kolaylığı, test edilebilirlik ve okunabilirlik. GitHub’ın kılavuzu, küçük PR’lar ve otomasyon kontrolleriyle desteklenen incelemelerin ekip içinde tutarlılığı artırmaya yardımcı olabileceğini anlatır (S1).
İnceleme egzersizi
Her hafta 1 kez, ekipteki herkesin aynı PR’a asenkron review yaptığı bir egzersiz planlayın. Ardından 15 dakika “hangi riski neden vurguladık?” tartışması yapın. Amaç, tek bir doğru yorum seti üretmek değil; ortak standartları görünür kılmaktır.
AI destekli araçlar: Nerede işe yarar, nerede yetmez?
AI kod tamamlama ve metin asistanları (marka bağımsız) hız kazandırabilir; ancak eğitim hedefiniz, “kod üretmek” kadar doğru kodu doğrulamak olmalıdır. Bu yüzden AI kullanımını ölçülebilir ve kontrol edilebilir işlere bağlamak daha sağlıklıdır:
- PR açıklaması için taslak üretme (son düzenleme geliştiricide)
- Test senaryosu fikirleri üretme (son karar ekipte; testlerle doğrulama şart)
- Refactor seçenekleri önermek (CI ve test kapılarıyla doğrulamak)
Bu yaklaşım, kod inceleme ve otomasyon kontrollerinin önemini vurgulayan genel PR disiplinine uyumludur (S1).
Değerlendirme: Not vermekten çok, kanıt üretmek
8 haftalık programlarda en yaygın hata, sadece “proje çalışıyor mu?” üzerinden değerlendirmektir. Bunun yerine süreç kanıtı toplayın: PR geçmişi, testlerin evrimi, demo düzeni, retrospektif çıktıları. Proje-temelli öğrenme yaklaşımı ara teslim ve süreç değerlendirmesini özellikle öne çıkarır (S3).
- Ürün düşüncesi: MVP netliği, kullanıcı hikâyeleri, kabul kriterleri
- Mühendislik kalitesi: test stratejisi, hata yönetimi, okunabilirlik
- Takım süreci: küçük PR’lar, review kalitesi, sprint ritmi
- Dokümantasyon ve sunum: kurulum, demo akışı, öğrenilenler
Part-time ve full-time varyantı nasıl uyarlanır?
- Part-time: Kapsamı daraltın, UI’yı minimal tutun, test ve PR disiplinini koruyun. İş yükü tahmini yaparken tekil program örneklerinden ilham alabilir, kendi kohortunuzla kalibre edebilirsiniz (S4).
- Full-time: Daha yoğun bloklarla ikinci bir entegrasyon (örn. bildirimler, arka plan işleyicileri) eklenebilir; yine de sprint hedefini küçük tutun.
Hızlı başlangıç: İlk 48 saatte yapılacaklar
- Tek bir proje seçin ve 10–15 kullanıcı hikâyesi yazın (MVP için 3–5 tanesini işaretleyin).
- Repo + CI kurun: testler PR’da çalışsın.
- PR şablonu ve review checklist’i ekleyin.
- Test stratejisi sayfası oluşturun: birim/entegrasyon/E2E kapsamı.
- Hafta 1 demo tarihini belirleyin ve demo kriterini yazın.
Sonuç
8 haftalık ürün odaklı bir yazılım eğitimi, doğru kurgulandığında katılımcılara “tek seferlik proje”den çok tekrar edilebilir geliştirme alışkanlığı kazandırabilir. Ana kaldıraçlar: ara teslimli proje-temelli öğrenme (S3), testleri erken kurmak (TDD ve test piramidi prensipleri) (S2) ve küçük PR’larla yapılandırılmış kod inceleme kültürü (S1).
Planı doğrudan uygulayabilir veya hedef kitlenize göre sadeleştirip pilotlayabilirsiniz. En iyi iyileştirmeler genellikle ilk kohortun PR verilerinden, demo geri bildirimlerinden ve haftalık retrospektiflerden çıkar.