Ana içeriğe geç
Software Dictionary

Yol haritası · Başlangıç

Bir yazılım ekibinde çalışmak

Git, ekiplerin işi nasıl planladığı ve kodu sağlıklı tutan alışkanlıklar.

Bir ekipteki ilk haftanızın nasıl geçtiği: Git ile kod paylaşmak, agile çalışmanın ritmi ve kod tabanını formda tutan test ve inceleme alışkanlıkları.

35 sayfa3 bölümyaklaşık 1 saat okuma

  • Sürüm Kontrolü
  • Ekipler ve Süreç
  • Test ve Kalite
  • DevOps ve Bulut
  • Yazılım Mimarisi

Henüz başlanmadı0/35 okundu

Git ile başla

İlerleme, yalnızca bu tarayıcıda tutulan okuma geçmişinizden gelir.

1. bölümKod paylaşmak

  1. 1GitSürüm Kontrolü, s. 10Git, dosyalardaki değişiklikleri zamanla izleyen ücretsiz, açık kaynaklı dağıtık sürüm kontrol sistemidir; iş birliğini ve hataları geri almayı kolaylaştırır.
  2. 2RepositorySürüm Kontrolü, s. 34Repository, bir projenin tüm dosyalarını ve sürüm kontrol sisteminin kaydettiği her değişikliğin eksiksiz geçmişini barındıran depolama alanıdır.
  3. 3GitHubSürüm Kontrolü, s. 25GitHub, Git depolarını barındırıp birlikte kod yazmaya yarayan; pull request, kod incelemesi, issue ve en büyük açık kaynak topluluğunu sunan platformdur.
  4. 4CommitSürüm Kontrolü, s. 5Commit, Git'te projenin dosyalarının; benzersiz bir kimlik, yazar, zaman damgası ve değişikliği anlatan bir mesajla kaydedilmiş anlık görüntüsüdür.
  5. 5Conventional CommitsSürüm Kontrolü, s. 6Conventional Commits, feat: add search gibi yapılandırılmış commit mesajları için bir şartnamedir; araçlar değişiklik günlüğü üretip sürümü otomatik seçer.
  6. 6Staging AreaSürüm Kontrolü, s. 37Git'teki staging area, dosyalarınız ile bir sonraki commit arasındaki bekleme alanıdır; o commit'e girecek değişiklikleri tam olarak buraya koyarsınız.
  7. 7BranchSürüm Kontrolü, s. 2Git'te branch, bir özellik ya da düzeltme üzerinde, birleştirene kadar ana kodu etkilemeden çalışmanızı sağlayan bağımsız bir geliştirme hattıdır.
  8. 8Git CheckoutSürüm Kontrolü, s. 12git checkout başka bir branch'e ya da commit'e geçer veya dosyaları önceki sürüme döndürür; yeni Git sürümleri bu işleri git switch ve git restore'a ayırır.
  9. 9MergeSürüm Kontrolü, s. 29Git'te merge, bir branch'teki değişiklikleri başka bir branch'e katarak ayrı geliştirme hatlarını tek ve ortak bir geçmişte yeniden birleştirir.
  10. 10Fast-Forward MergeSürüm Kontrolü, s. 8Fast-forward merge, hedef branch'te diğer branch ayrıldığından beri yeni commit yoksa olur; Git merge commit'i oluşturmaz, işaretçiyi yalnızca ileri taşır.
  11. 11Merge ConflictSürüm Kontrolü, s. 30Merge çakışması, iki branch bir dosyanın aynı satırlarını değiştirdiği için Git'in otomatik birleştiremediği, sonuca birinin karar vermesi gereken durumdur.
  12. 12Pull RequestSürüm Kontrolü, s. 32Pull request, bir branch'teki değişiklikleri başka bir branch'e birleştirme önerisidir; kod birleşmeden önce ekibe inceleme, tartışma ve test alanı sunar.
  13. 13Code ReviewSürüm Kontrolü, s. 4Code review, kod değişikliklerinin birleştirilmeden önce başka geliştiricilerce incelenmesidir; hataları yakalar, kaliteyi artırır, bilgi paylaşımını sağlar.

2. bölümÇalışma biçimleri

  1. 14AgileEkipler ve Süreç, s. 3Agile, çalışan yazılımı küçük ve sık parçalar halinde teslim eden ve planları düzenli geri bildirime göre ayarlayan bir yazılım geliştirme yaklaşımıdır.
  2. 15ScrumEkipler ve Süreç, s. 21Scrum, küçük bir ekibin tanımlı roller, olaylar ve çıktılarla ürünü sprint denen sabit uzunluklu döngülerde teslim ettiği bir Agile framework'üdür.
  3. 16KanbanEkipler ve Süreç, s. 11Kanban, işi sütunlardan oluşan bir panoda görselleştiren ve iş akışının düzgün ilerlemesi için aynı anda devam eden iş sayısını sınırlayan bir Agile yöntemidir.
  4. 17SprintEkipler ve Süreç, s. 25Sprint, bir Scrum ekibinin tek hedefe doğru çalışıp kullanılabilir bir ürün artışı ürettiği, bir ay veya daha kısa, çoğunlukla iki haftalık sabit dönemdir.
  5. 18Sprint PlanningEkipler ve Süreç, s. 26Sprint planning, her sprint'i başlatan Scrum etkinliğidir; ekip bir sprint hedefinde anlaşır, bitirebileceği backlog öğelerini seçer ve işi planlar.
  6. 19User StoryEkipler ve Süreç, s. 29User story, bir özelliğin kullanıcının bakış açısından, kimin neyi neden istediğini açıklayan kısa ve sade bir dille yazılmış tanımıdır.
  7. 20Story PointsEkipler ve Süreç, s. 27Story point, Agile ekiplerin iş öğelerinin göreli büyüklüğünü saat yerine karmaşıklık, iş miktarı ve belirsizliği birleştirerek tahmin ettiği birimdir.
  8. 21Planning PokerEkipler ve Süreç, s. 16Planning poker, ekip üyelerinin bir görev için birer tahmin kartını gizlice seçip aynı anda açtığı, sonra farkları tartıştığı bir tahminleme tekniğidir.
  9. 22Daily StandupEkipler ve Süreç, s. 7Daily standup, ekibin hedefe doğru ilerlemeyi kontrol ettiği, günü planladığı ve engelleri dile getirdiği, genellikle 15 dakikayı geçmeyen günlük toplantıdır.
  10. 23TimeboxingEkipler ve Süreç, s. 28Timeboxing (zaman kutulama), bir etkinliğe önceden sabit bir süre sınırı koyup süre dolunca durmaktır; işi odaklı tutar ve kapsam kararlarını zorunlu kılar.
  11. 24RetrospektifEkipler ve Süreç, s. 20Retrospektif, ekibin her sprint sonunda nasıl çalıştığını değerlendirip bir dahaki sefer için somut iyileştirmelerde anlaştığı toplantıdır.
  12. 25Definition of DoneEkipler ve Süreç, s. 8Definition of Done, bir işin ekip tarafından tamamlanmış sayılabilmesi için karşılaması gereken kalite standartlarının ortak kontrol listesidir.

3. bölümKodu sağlıklı tutmak

  1. 26Birim TestiTest ve Kalite, s. 4Birim testi, bir fonksiyonun, metodun ya da sınıfın programın geri kalanından yalıtılmış olarak doğru davrandığını doğrulayan küçük ve otomatik bir kontroldür.
  2. 27JestTest ve Kalite, s. 10Jest; test çalıştırıcıyı, doğrulamaları, mock'lamayı, snapshot'ları ve kod kapsamını az kurulumla tek pakette sunan popüler JavaScript test framework'üdür.
  3. 28Entegrasyon TestiTest ve Kalite, s. 7Entegrasyon testi, kod, veritabanı ve API gibi bir sistemin birkaç parçasının birlikte doğru çalışıp çalışmadığını kontrol eden otomatik bir testtir.
  4. 29Test PiramidiTest ve Kalite, s. 33Test piramidi, otomatik testleri dengelemek için bir modeldir: çok sayıda hızlı birim testi, daha az entegrasyon testi ve tepede birkaç yavaş uçtan uca test.
  5. 30Test Odaklı GeliştirmeTest ve Kalite, s. 31Test odaklı geliştirme, önce başarısız bir test yazdığınız, sonra onu geçirecek kadar kod yazıp ardından tasarımı temizlediğiniz bir kodlama pratiğidir.
  6. 31LintingTest ve Kalite, s. 15Linting, kaynak kodu çalıştırmadan otomatik olarak analiz edip olası hataları, stil sorunlarını ve şüpheli kalıpları kod yayına çıkmadan işaretleme işlemidir.
  7. 32CI/CDDevOps ve Bulut, s. 9CI/CD, kod değişikliklerini sık sık derleyen, test eden ve yayınlayan otomatik pratikler bütünüdür; yazılım kullanıcılara hızlı ve güvenli biçimde ulaşır.
  8. 33Teknik BorçYazılım Mimarisi, s. 43Teknik borç, daha uzun sürecek daha iyi bir yaklaşım yerine şimdi hızlı ya da sınırlı bir çözüm seçilmesiyle doğan, gelecekteki ek iş maliyetidir.
  9. 34Code SmellEkipler ve Süreç, s. 6Code smell (kod kokusu), kod hâlâ çalışsa bile çoğu zaman daha derin bir tasarım sorununa işaret eden yüzeysel bir belirtidir.
  10. 35RefactoringYazılım Mimarisi, s. 32Refactoring, mevcut kodun dışarıdan görünen davranışını değiştirmeden daha temiz ve bakımı kolay hâle getirmek için yeniden yapılandırılması sürecidir.

Yol boyunca karşılaştırın

Bu yol haritasında kolayca karıştırılan çiftler, yan yana.

Daha fazla

Ayarlar

EnglishTürkçe