Terminal mi IDE mi: Hangi Araç Ne Zaman Kullanılır

Yazar:komut.io ekibi Rehber & İpuçları
0 Yorum

Yıllarca “her şeyi terminalde yaparım, IDE kullanmak tembellik” diyerek geçirdim. Sonra bir gün 3000 satırlık bir Python servisini pure vim ile debug etmeye çalışırken kendime sordum: “Neden bunu böyle yapıyorum?” O gün bir şeylerin değişmesi gerektiğini anladım. Ama tam tersine dönenler gibi “artık her şeyi IDE’de yapacağım” da demedim. Çünkü gerçek hayatta araç seçimi, ideoloji meselesi değil, verimlilik meselesidir.

Önce Şunu Anlayalım: Bu Bir Din Savaşı Değil

Sysadmin ve DevOps dünyasında araç tartışmaları çabuk kişisel bir hal alıyor. “Vim kullanmıyorsan gerçek sysadmin değilsin” ya da “terminal kullanmak zaman kaybı, VSCode varken neden uğraşıyorsun” gibi cümleler duymuşsunuzdur. İkisi de saçmalık.

Asıl soru şu: Elinizdeki görevi en hızlı, en güvenilir şekilde nasıl tamamlarsınız?

Bunu belirleyen faktörler ortam, bağlam, görevin karmaşıklığı ve tekrar sıklığıdır. Hepsini bir arada değerlendirmeden “şu araç daha iyi” demek, tornavida mı yoksa çekiç mi daha iyi sorusuna cevap aramak gibidir.

Terminal Ne Zaman Tartışmasız Kazanır

Uzak Sunucu Yönetimi

Bunu kimse tartışamaz. Production sunucusuna SSH açtınızda terminalden başka seçeneğiniz zaten yok. Ama burada önemli olan, terminali verimli kullanmayı öğrenmiş olmak.

# Birden fazla sunucuda aynı anda komut çalıştırma
for host in web01 web02 web03; do
    ssh $host "systemctl status nginx | grep -E 'Active|Main PID'"
done

Bu komutu bir IDE’den çalıştıramazsınız. Çalıştırsanız bile, bu kadar hızlı olamazsınız. Sunucu parkınız büyüdükçe terminal scriptlerinin değeri katlanarak artar.

Otomasyon ve Pipeline İşleri

CI/CD pipeline’larının içinde, cron job’larda, systemd servislerinde çalışan kodlar terminal komutlarına dayanır. Bu ortamlarda IDE yoktur, olamaz da.

#!/bin/bash
# Basit bir deployment sonrası health check scripti
SERVICE_URL="http://localhost:8080/health"
MAX_RETRY=5
RETRY_COUNT=0

until curl -sf "$SERVICE_URL" > /dev/null 2>&1; do
    RETRY_COUNT=$((RETRY_COUNT + 1))
    if [ $RETRY_COUNT -ge $MAX_RETRY ]; then
        echo "HATA: Servis $MAX_RETRY denemeden sonra ayaga kalkmadi"
        exit 1
    fi
    echo "Deneme $RETRY_COUNT/$MAX_RETRY, 5 saniye bekleniyor..."
    sleep 5
done

echo "Servis basariyla ayaga kalktı"
exit 0

Bu script bir GitHub Actions workflow’unun içinde çalışacak. Burada VSCode açmanın alemi yok.

Hızlı Tek Seferlik İşlemler

Log dosyasında bir şey aramak, birkaç dosyanın izinlerini değiştirmek, disk kullanımına bakmak; bunlar için IDE açmak zaman kaybıdır.

# Son 1 saatte 500 status kodu dönen IP'leri bul ve sırala
awk '$9 == 500 {print $1}' /var/log/nginx/access.log | 
    sort | uniq -c | sort -rn | head -20

Bu satırı yazmak 10 saniye sürer. Aynı işi bir IDE’nin GUI’sinden yapmaya çalışırsanız, önce projeyi açmanız, dosyayı import etmeniz, bir şeyler kurmanız gerekir. Log analizi için terminal, rakipsizdir.

Sistem Kaynaklarının Kısıtlı Olduğu Ortamlar

Container içinde, minimal bir Alpine image’ında, embedded sistemlerde, kısıtlı RAM’e sahip VPS’lerde IDE çalıştırmak mümkün değildir. Terminali iyi kullanmak burada survival becerisidir.

IDE Ne Zaman Açık Ara Daha İyi

Büyük Kod Tabanlarında Gezinme

Diyelim ki şirketinizin monorepo’su var. 50 microservice, her birinde onlarca dosya. Bir fonksiyonun nerede tanımlandığını, nerede çağrıldığını, hangi testlerin onu kapsadığını bulmak istiyorsunuz.

Vim’de bunu yapabilirsiniz, evet. ctags kurar, fzf entegre edersiniz, bir sürü plugin yüklersiniz. Sonunda elde ettiğiniz şey, bir IDE’nin size kutudan çıkar çıkmaz verdiği şeydir. Kendi zamanınıza saygı gösterin.

VSCode’da Go to Definition ile bir tuşa basarak fonksiyonun tanımına atlarsınız. Find All References ile o fonksiyonun tüm kullanım yerlerini görürsünüz. Bunlar gerçek zaman tasarrufu sağlar.

Refactoring İşlemleri

Bir değişkenin adını 200 farklı dosyada değiştirmeniz gerekiyor. Terminal ile bunu yapabilirsiniz:

# Basit find-replace, ama bağlam habersiz
find . -name "*.py" -exec sed -i 's/old_variable_name/new_variable_name/g' {} +

Bu çalışır. Ama dikkatli olun: Bu komut “old_variable_name” ifadesinin geçtiği her yeri değiştirir. Yorum satırlarını, string’lerin içini, farklı scope’lardaki benzer isimleri. IDE’nin refactor aracı ise anlam bağlamını anlayarak sadece o değişkeni, doğru yerlerde değiştirir. Production’da yanlış refactor’ın bedelini bir kez ödedikten sonra bu farkı asla küçümsemezsiniz.

Aktif Geliştirme Süreci

Yeni bir servis yazıyorsunuz. Kodun akışını takip etmeniz, type hintlere bakmanız, otomatik tamamlamayı kullanmanız, inline hata mesajlarını görmeniz gerekiyor. Bu işler için IDE’nin sağladığı Language Server Protocol (LSP) desteği, terminal tabanlı editörlerden kategorik olarak üstündür.

# Bu kodu IDE'de yazarken, her adımda type inference,
# otomatik import, hata uyarısı alırsınız.
# Terminalde bunları kendiniz takip etmek zorunda kalırsınız.

from typing import Optional
import boto3
from botocore.exceptions import ClientError

def get_secret(secret_name: str, region: str = "eu-west-1") -> Optional[dict]:
    client = boto3.client("secretsmanager", region_name=region)
    try:
        response = client.get_secret_value(SecretId=secret_name)
        return response
    except ClientError as e:
        # IDE burada hangi exception türlerinin mevcut olduğunu gösterir
        raise e

Debugging

Bu konuda tartışma yok. Görsel debugger, breakpoint, watch variable, call stack görselleştirme. Bunları terminal tabanlı araçlarla (pdb, gdb) da yapabilirsiniz, ama ciddi bir verimlilik farkı vardır. Karmaşık bir bug’ı araştırırken IDE debugger’ı saatlerce zaman kazandırır.

Gerçek Dünya: İkisi Bir Arada Çalışır

Teorik tartışmayı bırakalım, gerçek bir iş gününe bakalım.

Senaryo: Production’da bir servis yavaşlamaya başladı. Kullanıcılar şikayet ediyor.

İlk adım terminal:

# Hızlı sistem durumuna bak
top -bn1 | head -20
df -h
free -m
ss -tulpn | grep LISTEN

Log’lara bak, terminal:

# Son 100 satır hata logu
journalctl -u myapp.service -n 100 --no-pager | grep -i error

# Son 5 dakika içindeki loglar
journalctl -u myapp.service --since "5 minutes ago"

Bir şeyler buldunuz, kod seviyesinde bir sorun var gibi görünüyor. IDE’yi açıyorsunuz, ilgili servisi buluyorsunuz, kodu inceliyorsunuz, muhtemelen bir N+1 query sorunu ya da bir timeout ayarı eksikliği. Kodu düzeltiyorsunuz, test yazıyorsunuz, IDE üzerinden.

Değişikliği deploy ediyorsunuz, gene terminal:

# Değişikliği çek ve servisi yeniden başlat
git pull origin main
systemctl restart myapp.service
systemctl status myapp.service

# Deployment sonrası log takibi
journalctl -fu myapp.service

Gördünüz mü? Tek bir iş akışında her ikisi de kullanıldı. Birini diğerinin yerine koymak yapay bir kısıtlamadır.

Terminali Verimli Kullanmak İçin Gerçekten Öğrenmeniz Gerekenler

Terminal kullanıyorum diyorsanız ama bunları bilmiyorsanız, aslında terminali verimli kullanmıyorsunuzdur.

tmux veya screen: Uzun süren işleri arka planda çalıştırmak, birden fazla terminal paneli yönetmek için şarttır.

# tmux ile yeni oturum aç ve isim ver
tmux new-session -s production-debug

# Oturumdan çık ama çalışmaya devam etsin
# Ctrl+b, d

# Oturuma geri dön
tmux attach -t production-debug

Alias ve fonksiyonlar: Tekrarlayan komutlar için zaman kazandırır.

# .bashrc veya .zshrc'ye eklenecek yararlı aliaslar
alias ll='ls -lah'
alias gst='git status'
alias k='kubectl'
alias tf='terraform'

# Daha karmaşık işler için fonksiyon
deploy_check() {
    local env=${1:-staging}
    echo "=== $env ortamı kontrol ediliyor ==="
    kubectl get pods -n "$env" | grep -v Running
    echo "=== Son 20 log satırı ==="
    kubectl logs -n "$env" deployment/myapp --tail=20
}

grep, awk, sed üçlüsü: Bu araçları iyi bilmek, terminal verimliliğinin bel kemiğidir.

# Nginx loglarından ortalama response time hesapla
# Log formatı: ... [response_time] ...
awk '{sum += $NF; count++} END {print "Ortalama:", sum/count, "ms"}' 
    /var/log/nginx/timing.log

IDE Seçimi ve Konfigürasyonu

IDE kullanacaksanız, onu düzgün konfigüre etmeden açmanın anlamı yoktur. Yarım konfigürasyonlu bir IDE, iyi konfigürasyonlu bir terminal editörden kötü olabilir.

VSCode için temel eklentiler (sysadmin/DevOps perspektifinden):

  • Remote – SSH: Uzak sunuculardaki dosyaları lokal IDE’nizde düzenleyin. Bu eklenti gerçekten oyun değiştirici.
  • GitLens: Git blame, history, karşılaştırma.
  • Docker: Container yönetimi entegrasyonu.
  • Kubernetes: Cluster yönetimi.
  • Terraform: HCL syntax desteği ve doğrulama.
  • YAML: Schema validation ile Kubernetes manifest yazımı.

VSCode’un Remote SSH özelliği ayrıca vurgulamayı hak ediyor. Sunucuya SSH bağlantısı açarsınız, sunucudaki bir klasörü VSCode’da lokal gibi açarsınız. Sunucunun hesaplama gücünü kullanırken kendi klavye kısayollarınız, temalarınız, eklentilerinizle çalışırsınız. Terminal ile IDE arasındaki en iyi köprülerden biridir.

Bir Kariyer Tavsiyesi

Kariyerinin başında olan sistem yöneticilerine net bir şey söyleyeyim: Terminali önce öğrenin, IDE’yi sonra ekleyin.

Neden? Çünkü terminali gerçekten öğrenmek, bilgisayarın nasıl çalıştığını anlamanızı zorlar. Dosya izinlerini, process yönetimini, pipe ve redirect mantığını, script yazımını kavramanızı sağlar. Bu kavrayış olmadan IDE kullanmak, arabanın nasıl çalıştığını bilmeden sürücü olmak gibidir. Bir şeyler bozulduğunda ne yapacağınızı bilmezsiniz.

IDE’yi öğrendikten sonra ise terminal alışkanlıklarınızı kaybetmeyin. Her işi IDE’den yapmaya çalışmak da tuzaktır. Özellikle Cloud ve Kubernetes dünyasında terminal scriptleri hala temel iş akışının parçasıdır.

Pratik Karar Ağacı

Hangi aracı kullanacağınıza karar verirken kendinize şunları sorun:

  • Uzak sunucuda mısınız ve GUI erişiminiz yok mu? Terminal.
  • Otomasyona gidecek bir script mi yazıyorsunuz? Terminal.
  • 100 satırdan fazla kod mu yazacaksınız ve bu kod uzun süre yaşayacak mı? IDE.
  • Hızlı log analizi veya sistem durumu kontrolü mü? Terminal.
  • Karmaşık bir bug mı araştırıyorsunuz? IDE debugger.
  • Büyük bir refactoring mı yapacaksınız? IDE.
  • Tek seferlik bir dosya düzenlemesi mi? Terminalden hızlı bir vim/nano.
  • Uzak sunucuda sürekli geliştirme yapıyor musunuz? VSCode Remote SSH.

Sonuç

İki araç arasında savaş yok. Var olan tek şey, göreve uygun araç seçimi. Sysadmin ve DevOps işinin güzelliği de zaten bu çok katmanlı doğasında yatıyor; bazen bir bash one-liner ile saatlerce sürecek işi dakikaya indiriyorsunuz, bazen karmaşık bir servis kodu yazarken IDE’nin tüm gücünü kullanıyorsunuz.

Terminal ve IDE’yi birbirinin alternatifi değil, tamamlayıcısı olarak görün. Terminali o kadar iyi öğrenin ki, ihtiyaç duyduğunuzda elinizi kolunuzu bağlamadan çalışın. IDE’yi de o kadar iyi konfigüre edin ki, geliştirme süreçlerinizde gerçek bir hız kazanın.

Araç tartışmasına takılıp kalan sysadmin ile her ikisini de ustalıkla kullanan sysadmin arasındaki fark, zamanla giderek açılır. Hangisi olmak istediğiniz size kalmış.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir