Makefile: Ekipteki Herkesin Aynı Komutu Çalıştırmasını Sağlamak

Makefile C projeleri için doğmuş olsa da bugün en çok işe yaradığı yer, herhangi bir projede komutları tek bir yerde toplamaktır. README'de yazan komut listesi zamanla gerçekle ayrışır; kimse onu çalıştırmadığı için bozulduğu fark edilmez. Makefile ise her gün çalıştırıldığı için bozulduğu anda kendini belli eder.

Kendini belgeleyen bir başlangıç

.DEFAULT_GOAL := yardim
.PHONY: yardim kur test analiz duzelt goc temizle dagit

## Komut listesini gösterir
yardim:
	@grep -E '^##|^[a-zA-Z_-]+:' $(MAKEFILE_LIST) \
	  | sed -e 's/^## /  /' -e 's/:.*//' \
	  | awk 'NR%2==0 {printf "\033[36m%-12s\033[0m", $$0} NR%2==1 {print}'

## Projeyi sıfırdan çalışır hâle getirir
kur:
	composer install
	npm ci
	cp -n .env.example .env || true
	php spark key:generate
	php spark migrate --all
	@echo "Hazır. 'make test' ile doğrulayın."

## Tüm testleri çalıştırır
test:
	vendor/bin/phpunit --colors=always

## Statik analiz + kod stili kontrolü
analiz:
	vendor/bin/phpstan analyse app --level=6 --no-progress
	vendor/bin/php-cs-fixer fix --dry-run --diff

## Kod stilini otomatik düzeltir
duzelt:
	vendor/bin/php-cs-fixer fix

## Bekleyen göçleri uygular
goc:
	php spark migrate --all

## Önbellek ve geçici dosyaları temizler
temizle:
	php spark cache:clear
	rm -rf writable/debugbar/* writable/logs/*.log

.PHONY neden var?

Make aslında dosya üretmek için tasarlanmıştır: test hedefini çalıştırırken aynı adda bir dosya varsa, onu güncel sayıp hiçbir şey yapmaz. .PHONY ile hedefin dosya değil komut olduğunu belirtirsiniz. Bu satırı atlamak, "make test hiçbir şey yapmıyor" şeklinde uzun süre çözülemeyen bir şaşkınlık üretir.

Değişkenler ve ortam farkları

PHP  ?= php
COMPOSER ?= composer

# Docker kullanan ekip üyeleri: make PHP="docker compose exec app php" test
test:
	$(PHP) vendor/bin/phpunit

# Argüman geçirme: make goc-geri ADIM=2
goc-geri:
	$(PHP) spark migrate:rollback -b $(ADIM)

?= operatörü "tanımlı değilse ata" anlamına gelir; böylece Docker ile çalışan ekip üyesi kendi komutunu dışarıdan verebilir. Yerel ortamı tek komutla kurma konusunu yerel geliştirme ortamı yazımızda ele almıştık — Makefile bu yaklaşımın en az bağımlılıklı biçimidir.

CI ile aynı komutu paylaşın

Makefile'ın en büyük ikinci faydası burada ortaya çıkar: sürekli tümleştirme yapılandırmasında komutları tekrar yazmak yerine aynı hedefleri çağırırsınız.

jobs:
  kontrol:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Bağımlılıklar
        run: make kur
      - name: Analiz
        run: make analiz
      - name: Testler
        run: make test

Böylece "CI'da geçiyor ama bende geçmiyor" durumlarının büyük kısmı ortadan kalkar; iki taraf birebir aynı komutu çalıştırır. CI/CD kurulumunuz büyüdükçe bu tekilleştirme daha da değerli hâle gelir.

Kurulum hedefleri arasında test verisi üretimi de yer alabilir; kurucu deseniyle hazırlanan veri tek komutla tekrar üretilebilir olur.

Ne zaman yetmez?

Karmaşık koşullar, döngüler ve hata yönetimi gerektiren işlerde Make sözdizimi hızla okunmaz hâle gelir. Kural şudur: hedef üç satırı geçiyorsa gövdeyi ayrı bir betiğe alın ve Make'ten onu çağırın. Ayrıca Windows'ta make varsayılan kurulu değildir; ekipte Windows kullanıcısı varsa alternatif olarak composer scripts veya npm scripts düşünülmelidir. Tekrarlayan işleri ne zaman betiğe dönüştürmek gerektiğini otomasyon eşiği yazımızda tartışmıştık. GNU Make'in tüm özellikleri için resmî GNU Make kılavuzu kapsamlı kaynaktır.

Sonuç

Bir projede komutların nerede yazılı olduğu, o projeye yeni katılan kişinin ilk gününü belirler. Makefile bu bilgiyi hem okunur hem çalıştırılabilir tek bir dosyada toplar; bayatladığında sessiz kalmaz, hata verir. Başlarken beş hedef yeterlidir: kurulum, test, analiz, göç ve temizlik. Hedefleri kısa tutun, uzun gövdeleri betiklere taşıyın, .PHONY satırını unutmayın ve sürekli tümleştirme yapılandırmanızı aynı hedefleri çağıracak şekilde sadeleştirin. Bir sonraki yeni ekip üyeniz make kur yazıp on dakikada çalışır bir ortam elde ettiğinde, bu dosyanın değerini göreceksiniz.

Pratik Uygulama Kontrol Listesi

Bu yazıdaki önerileri kendi ekibinize uyarlarken aşağıdaki adımları sırasıyla uygulamanız, teoriden pratiğe geçişi kolaylaştırır:

1. Mevcut durumu ölçün. Değişiklik yapmadan önce bugünkü performansı/süreyi/hata oranını kaydedin; aksi halde iyileşmeyi kanıtlayamazsınız.
2. Küçük bir pilot seçin. Tüm sisteme veya tüm ekibe birden uygulamak yerine tek bir modülde veya tek bir sprintte deneyin.
3. Sonuçları ekiple paylaşın. Elde ettiğiniz veriyi (olumlu ya da olumsuz) kısa bir notla ekibe aktarın; kararın gerekçesi belgelenmemişse aynı tartışma birkaç ay sonra tekrar açılır.
4. Süreci tekrarlanabilir hale getirin. İşe yarayan pratiği bir kontrol listesine veya şablona dönüştürün ki yeni katılan ekip üyeleri de aynı standardı hızlıca öğrensin.

Sık Yapılan Yanlışlar

Bu konuda ekiplerin en çok düştüğü tuzak, çözümü tek bir kişiye ya da tek bir araca yüklemektir. Oysa kalıcı iyileşme, sürecin ekibin günlük rutinine (code review kontrol listesi, sprint planlama, onboarding dokümanı gibi) gömülmesiyle mümkün olur. İkinci yaygın hata ise "en iyi pratiği" olduğu gibi kopyalamaktır — başka bir ekipte işe yarayan bir yaklaşım, farklı bir ölçekte veya farklı bir teknoloji yığınında aynı sonucu vermeyebilir; önce kendi bağlamınızda küçük ölçekte test edin, sonra genişletin. Üçüncü tuzak ise ölçmeden karar vermektir: "daha iyi hissettiriyor" öznel bir gerekçedir, ekip içi tartışmalarda nesnel veriyle desteklenmeyen kararlar er ya da geç sorgulanır ve geri alınır. Son olarak, dokümantasyonu atlamak da sık görülen bir hatadır: bir kararın "neden" alındığı yazılı değilse, ekip altı ay sonra aynı tartışmayı sıfırdan yeniden yapmak zorunda kalır ve önceki deneyimden öğrenilenler kaybolur.

Sonuç

Makefile: Ekipteki Herkesin Aynı Komutu Çalıştırmasını Sağlamak konusunda burada değindiğimiz noktalar, konuyu ilk kez ele alan ekipler için de deneyimli geliştiriciler için de pratik bir kontrol listesi görevi görür. makefile üzerine çalışırken en çok fayda sağlayan yaklaşım, tek seferde her şeyi mükemmelleştirmeye çalışmak yerine küçük, ölçülebilir adımlarla ilerlemektir. Ekibinizde bu konuyu bir sonraki sprint retrospektifinde veya teknik tartışma toplantısında gündeme getirmenizi, burada anlatılan pratiklerden hangilerinin sizin bağlamınıza uyduğunu birlikte değerlendirmenizi öneririz. Sonuç olarak, doğru araçları seçmek kadar bunları ekip kültürüne oturtmak da başarıyı belirleyen asıl etkendir.