GitHub Repolarımız ve Portfolyamız, Hayati Derecede Önemli

Bir Python geliştiricisi için GitHub, yalnızca kod deposu değil; profesyonel güvenilirlik kanıtı, mühendislik disiplininin görünür hali ve işverenin ilk teknik değerlendirme alanıdır. Özellikle rekabetin yüksek olduğu yazılım rollerinde, CV’den önce incelenen şey çoğu zaman GitHub portföyüdür.

1. GitHub Portföyünün Temel Amacı

Bir işveren GitHub’a baktığında üç şeyi görmek ister:

1. Kod yazabiliyor mu?
2. Gerçek mühendislik disiplini var mı?
3. Projeyi uçtan uca sahiplenebiliyor mu?

Bunları göstermeyen bir repo, ne kadar iyi kod içerirse içersin “tamamlanmamış aday” algısı oluşturur.

2. Profesyonel Repo Yapısı (Standart Mimari)

Her proje aşağıdaki yapıyı takip etmelidir:

project-name/
│
├── src/
│   ├── main.py
│   ├── modules/
│   └── utils/
│
├── tests/
│   ├── test_main.py
│
├── requirements.txt
├── .env.example
├── .gitignore
├── README.md
├── Dockerfile (opsiyonel ama güçlü sinyal)
└── CI pipeline (GitHub Actions)

Neden bu yapı kritik?

İşveren “proje büyüyebilir mi?” sorusuna cevap arar.
Dağınık kod = amatör algı
Modüler yapı = mühendislik olgunluğu

3. README.md: Asıl Kritik Nokta

README, çoğu zaman koddan daha önemlidir.

Profesyonel README akışı

1. Proje Başlığı ve Amaç

Ne yapıyor?
Hangi problemi çözüyor?

2. Teknoloji Mimarisi

Python sürümü
Kütüphaneler
Sistem bağımlılıkları

3. Kurulum Adımları (çok kritik)

git clone https://github.com/username/project.git
cd project
python -m venv venv
source venv/bin/activate  # Windows: venv\Scripts\activate
pip install -r requirements.txt
python src/main.py

4. Kullanım Örneği

python src/main.py --input data/sample.csv

5. Mimari Açıklama

Modüller ne yapıyor?
Veri akışı nasıl ilerliyor?

6. Test Çalıştırma

pytest tests/

7. CI/CD durumu (varsa)

4. Commit Disiplini (En Çok Gözden Kaçan Kısım)

İşverenler commit geçmişine bakar.

Kötü örnek:

update
fix
final
asd

Profesyonel örnek:

feat: add user authentication module
fix: resolve memory leak in data pipeline
refactor: restructure API service layer
test: add unit tests for payment service

Altın kural:

Her commit = bir iş birimi değişiklik

5. İşveren GitHub’ı Nasıl İnceler?

Bir işverenin tipik akışı:

1. README taraması (10-30 saniye)

Proje ne yapıyor?
Gerçek dünya problemi var mı?

2. Repo yapısı

src düzenli mi?
test var mı?
requirements temiz mi?

3. Commit geçmişi

düzenli mi?
tek seferlik dump mı?

4. Kod kalitesi

fonksiyonlar küçük mü?
tekrar eden kod var mı?
naming doğru mu?

5. Test var mı?

test yoksa ciddi eksi puan

6. Çalıştırabilirlik

clone → run mümkün mü?

6. Güçlü Portföy İçin Proje Tipleri

İşverenin “ciddi mühendis” algısı için:

1. API Projeleri

FastAPI / Flask
Auth sistemi
Rate limiting

2. Veri projeleri

ETL pipeline
Pandas + SQL
logging sistemi

3. AI/ML projeleri

model training pipeline
inference API
model versioning

4. Sistem projeleri

queue sistemi (Redis)
background worker
microservice mimarisi

7. .env ve Güvenlik Disiplini

Asla yapılmaması gereken:

API key commit etmek
password paylaşmak

Doğru yaklaşım:

.env
.env.example

.env.example:

DB_HOST=localhost
DB_USER=root
DB_PASS=your_password_here

8. CI/CD (İşveren için güçlü sinyal)

GitHub Actions örneği:

name: Python CI

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3
    - name: Setup Python
      uses: actions/setup-python@v4
      with:
        python-version: 3.11
    - name: Install dependencies
      run: pip install -r requirements.txt
    - name: Run tests
      run: pytest

9. Python + C# Portföy Karşılaştırmalı Yaklaşım

Aynı proje mantığını iki dilde göstermek çok güçlü bir sinyal üretir.

Python (API örneği)

from fastapi import FastAPI

app = FastAPI()

@app.get("/health")
def health():
    return {"status": "ok"}

C# (.NET Minimal API)

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/health", () => new { status = "ok" });

app.Run();

İşverenin algısı:

Çok dil bilen değil
Sistem düşünebilen mühendis

10. En Kritik Gerçek: Portföy Bir “Ürün”dür

GitHub bir arşiv değildir.

Bir işveren şunu görmek ister:

Ürün gibi düşünülmüş proje
Dokümantasyonu olan sistem
Test edilmiş kod
Çalıştırılabilir yapı
Süreklilik gösteren commit geçmişi

11. İleri Seviye Fark Yaratan Unsurlar

Docker containerization
Logging sistemi (structured logs)
Error handling standardı
API documentation (Swagger)
Performance benchmark
Modular architecture

Sonuç

Profesyonel GitHub portföyü şu prensiple çalışır:

“Kod yazmak değil, sistem göstermek”

İşverenin gözünde fark yaratan şey:

Ne kadar kod yazdığın değil
Kodun ne kadar okunabilir, sürdürülebilir ve ölçeklenebilir olduğu