ViraStack
  • Akademi
  • Hakkında
  • Destek
Genel BakışKaynaklarKatkı
ViraStack

Frontend geliştiricileri için DX odaklı araç seti: starter’lar, ajan kuralları, form hook’ları ve rehber.

Ürünler

  • ViraStack Start
  • ViraStack AI
  • ViraStack Mask
  • ViraStack Password
  • ViraStack Guide

Keşfet

  • Akademi
  • Hakkında
  • Marka
  • Destek

© 2026 ViraStack.

Açık kaynak · MIT

Sektör Sözlüğü

04 / 04

Kod ve Takım

PR ve code review kültürü, tech debt, release ve versiyonlama.

Pull Request ve Code Review

Pull request (PR), yazdığınız kod değişikliğini ana koda eklemeden önce takıma sunduğunuz değişiklik teklifidir.2 Code review (kod incelemesi) ise takım arkadaşlarınızın bu değişikliği okuyup yorum yaptığı ve onayladığı süreçtir. Amaç hataları erkenden yakalamak, kodun okunabilir kalmasını sağlamak ve bilgiyi takım içinde yaymaktır.

Sağlıklı bir review kültüründe PR'lar küçük tutulur, çünkü büyük bir değişikliği dikkatle incelemek zordur.3 Yorumlar kişiye değil koda yöneliktir ve neden önerildiğini açıklar.4 Review beklemek işi yavaşlattığı için takımlar genellikle review'lara hızlı dönmeyi bir alışkanlık hâline getirir.5

Tech Debt (Teknik Borç)

Tech debt, bugün işi hızlı bitirmek için seçilen kısa yolların ileride ek iş çıkarması durumudur. Eski bir kütüphaneyi güncellememek, testsiz kod yazmak ya da geçici bir çözümü kalıcı bırakmak buna örnektir. Finansal borca benzer: ödemezseniz faizi büyür, yani sonraki her değişiklik daha yavaş ve riskli hâle gelir.6

Her teknik borç kötü değildir. Takımlar bilinçli olarak borç alabilir, önemli olan bunu görünür kılmaktır.6 Genellikle borç için ticket açılır ve sprint içinde belirli bir pay ayrılarak ödenir.

Release (Sürüm Çıkarma)

Release, kodun kullanıcıya ulaşması için canlıya alınmasıdır. Bazı takımlar belirli aralıklarla toplu release yapar, bazıları değişiklikler hazır oldukça günde birkaç kez canlıya çıkar. Sık ve küçük release'ler, bir sorun çıktığında nedenini bulmayı ve düzeltmeyi kolaylaştırır.7

Versiyonlama

Versiyonlama, her release'e bir numara vermektir. En yaygın yöntem Semantic Versioning'dir (Anlamsal Versiyonlama) ve numara MAJOR.MINOR.PATCH biçimindedir.

MAJOR sürüm, eski kullanımı bozan uyumsuz bir değişiklik yapıldığında artar. MINOR sürüm, geriye dönük uyumlu yeni bir özellik eklendiğinde, PATCH sürüm ise geriye dönük uyumlu bir hata düzeltmesi yapıldığında artar.1

Örneğin 2.4.1 sürümüne bir hata düzeltmesi gelirse 2.4.2, yeni bir özellik gelirse 2.5.0, uyumsuz bir değişiklik gelirse 3.0.0 olur. 0.y.z sürümleri ilk geliştirme aşamasındadır ve her şey değişebilir.1 npm paketlerinde sürüm numarası bu yönteme göre okunur, bu yüzden bir paketin MAJOR sürümünü yükseltirken değişiklik notlarını okumak gerekir.8

Kaynaklar

  • 1DokümanSemantic Versioning 2.0.0

    Anlamsal sürümleme kuralları: MAJOR, MINOR, PATCH ve 0.y.z sürümleri.

  • 2DokümanGitHub Docs: About pull requests

    PR'ın kod değişikliklerini bir projeye birleştirme önerisi olması ve inceleyicilerin yorum yapması.

  • 3DokümanGoogle Engineering Practices: Small CLs

    Küçük değişikliklerin daha hızlı ve daha dikkatli incelendiği.

  • 4DokümanGoogle Engineering Practices: How to write code review comments

    Yorumların kişiye değil koda yapılması ve gerekçenin açıklanması.

  • 5DokümanGoogle Engineering Practices: Speed of Code Reviews

    Yavaş review'ların takım hızını düşürdüğü.

  • 6MakaleMartin Fowler: Technical Debt

    Borcun faizi, anaparanın kademeli ödenmesi ve bilinçli borç.

  • 7AraştırmaDORA: Working in small batches

    Küçük partilerin geri bildirimi kısaltması, sorunları ayıklamayı ve gidermeyi kolaylaştırması.

  • 8Dokümannpm Docs: About semantic versioning

    npm paketlerinde MAJOR, MINOR, PATCH ve `^`, `~` davranışı.

Bu sayfayı düzenle

Son güncelleme tarihi: 16 Ekim 2026

Önceki adım03. İş Takibi