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
Top comments (0)