Yazılım Geliştiriciler İçin Test Kavramları

Yazılım geliştirme yaşam döngüsündeki test odaklı geliştirme (TDD), davranış odaklı geliştirme (BDD), sürekli test (CTe) ve sürekli eğitim (CT) gibi kavramları öğreniyoruz.

Özet

Bu yazıda, test odaklı olarak yazılım geliştirmeye yönelik farklı yaklaşımları ele aldık. Öncelikle, Marick’in dörtgenine göre kategorize edilen birim testi, entegrasyon testi, sistem testi, fonksiyonel ve fonksiyonel olmayan testler gibi farklı test senaryolarını tartıştık. Ardından, makine öğrenimi sistemlerinin deterministik olmayan modeller olarak nasıl test edileceğini ve hem verilerin hem de öğrenme programlarının nasıl test edilmesi gerektiğini inceledik. Geliştirme ile paralel yürütülen üç test yaklaşımını tanıdık: Test odaklı geliştirme (TDD), davranış odaklı geliştirme (BDD) ve kabul testine dayalı geliştirme (ATDD). Sonrasında, makine öğrenimi projeleri özelinde sürekli entegrasyon (CI), sürekli teslimat (CD), sürekli test (CTe) ve sürekli eğitim (CT) süreçlerini kullanarak proje geliştirme hattının nasıl otomatikleştirileceğini öğrendik. Makine öğrenimi hattında CI/CD süreci için altı adım olduğunu gördük: Geliştirme ve deney, CI boru hattı, CD boru hattı, sürekli eğitim, sürekli teslimat ve izleme. Daha sonra, yazılım projeleri için sürüm kontrol sistemlerinin temel ilkeleriyle tanıştık ve iki yaygın çözüm olan Git ve GitHub’ı inceledik. Son olarak, komut satırı arayüzleri (CLI) ve tümleşik geliştirme ortamları (IDE) gibi geliştirme araçlarını öğrendik.

Giriş

Bir makine öğrenimi (ML) çözümünün geliştirilmesi tamamlandıktan sonra, proje ekibi yazılımı hemen üretim ortamına alıp müşterilere sunmaz. Geliştirme ve dağıtım arasında test adımı bulunur. Test süreci, tüm ekibin dahil olduğu, fonksiyonlar arası ve sürekli bir faaliyettir. İdeal bir durumda, test ekibi, yazılım projesinin en başındaki aşamalarda geliştiriciler ve kullanıcılarla iş birliği yaparak otomatik testlerin geliştirilmesini ve iyileştirilmesini sağlar. Bu otomatik testler, geliştirme ekibi modülleri oluşturmadan önce test ekibi tarafından geliştirilir. Geliştirilen modüller ilgili testlerden geçerse, bu durum yazılımdaki gerekli işlevselliklerin başarıyla uygulandığını gösterir. Projenin risklerini tanımlama, önceliklendirme ve bu riskleri azaltmaya yönelik önlemler tasarlama sürecine test stratejisi denir. İyi tasarlanmış bir test stratejisi, çalışan yazılım işlevselliğini (daha az hata ve daha düşük destek maliyeti anlamına gelir) garanti eder ve geliştirme uygulamaları için bir çerçeve tanımlar. Projenin farklı paydaşlarının bakış açısından farklı test türlerini ele alacağız, ardından paralel şekilde test ve geliştirme işlemlerinin nasıl yapılacağını tartışacağız. Belirsiz (deterministik olmayan) bir sistem olarak makine öğrenimi çözüm projesi senaryosu daha karmaşıktır ve geleneksel test yöntemlerinin gözden geçirilmesini gerektirir. Bu noktada geliştirme hattının (pipeline) nasıl otomatikleştirileceğini de öğreneceğiz. Daha sonra, değişikliklerin izlenmesinin daha da kritik hale geldiği otomatik geliştirme sürecini tartışacağız.

Test Paradigmaları ve İzleme Yaklaşımları

Yüksek kaliteli bir yazılım çözümü sunmak için Brian Marick, yazılım yayınlanmadan önce proje ekibinin uygulaması gereken çeşitli test senaryoları (Marick’in Dörtgeni olarak bilinir) geliştirmiştir. Bu testler iki boyutta sınıflandırılır:

1. Geliştirmeyi destekleyen testler (yazılımın güvenle inşa edilmesine yardımcı olur) ve ürünü eleştiren testler (yazılımda yetersizlikleri ve eksiklikleri keşfeder).
2. İş odaklı testler (iş bakış açısından geliştirilir) ve geliştirici odaklı testler (teknik bakış açısından geliştirilir).

Q1: Teknoloji Odaklı & Geliştirmeyi Destekleyici Testler

Bu kategoriye birim testleri, entegrasyon testleri ve sistem testleri dahildir. Birim testleri, yazılımın belirli bir birimini diğerlerinden izole şekilde test eder. Ancak, bu izolasyon etkileşimleri test etmediğinden entegrasyon testlerine ihtiyaç duyulur. Entegrasyon testleri, farklı birimlerin birlikte düzgün çalışıp çalışmadığını değerlendirir. Sistem testleri ise yazılımın tümünün, müşteri gereksinimlerine göre doğruluğunu test eder. Ayrıca, yazılım üretime alınmadan önce yapılandırma, kurulum ve hizmetlerle etkileşim gibi unsurların test edildiği dağıtım testleri de önemlidir.

Q2: İş Odaklı & Geliştirmeyi Destekleyici Testler

Bu testler işlevsel kabul testleri olarak bilinir. Fonksiyonların, kapasitenin, kullanılabilirliğin ve güvenliğin doğru çalışıp çalışmadığını doğrular. Geliştirilen birimin doğru uygulandığını göstermek için kullanılır. Uçtan uca (E2E) testler de bu kapsamdadır ve yazılımın baştan sona, kullanıcı perspektifinden beklenen şekilde çalışıp çalışmadığını test eder.

Q3: İş Odaklı & Ürünü Eleştiren Testler

Bu testler çoğunlukla manuel testlerdir ve yazılımın müşteri için beklenen değeri sağlayıp sağlamadığını kontrol eder. Örnekleri arasında:

• Showcase’ler (yeni işlevlerin gösterimi),
• Keşif testleri (test mühendisinin test tasarımını anlık bilgiyle şekillendirmesi),
• Kullanılabilirlik testleri (kullanıcının yazılımı kolaylıkla kullanıp kullanamadığını değerlendirme) bulunur.

Q4: Teknoloji Odaklı & Ürünü Eleştiren Testler

Yazılımın kapasite, kullanılabilirlik ve güvenlik gibi işlevsel olmayan kriterlerini test eder. Bu testler genellikle otomatikleştirilmiştir ama fonksiyonel testlerden daha seyrek uygulanır ve genellikle geliştirme sürecinin sonuna doğru yapılır.

Test Otomasyon Piramidi

Test Automation Pyramid

Testlerin otomasyon stratejisi üç seviyeye ayrılır:

1. Taban: Birim testleri
2. Orta: Entegrasyon testleri
3. Üst: Uçtan uca (E2E: End-to-End) testler

Makine Öğrenmesi (ML) Modellerinde Test

ML Model Oluşturmada Yer Alan Bileşenler

ML modelleri klasik yazılımlardan farklı olarak deterministik değildir; yani aynı girdiye birden farklı yanıt verebilirler. Bu yüzden veri, kod, öğrenme algoritması ve kullanılan çerçeveler (örneğin TensorFlow) test edilmelidir. Ayrıca “test oracle” (test kahini) geliştirmek zaman alıcıdır çünkü alan bilgisi gerektirir.

ML Verilerinin Testi:

• Verinin yeterliliği, temsiliyeti ve gürültü içeriği test edilir.
• Veri türü ve şeması kontrol edilir.
• Örtük kısıtlamalar (örneğin, lisans indirme sayısı ile satın alma sayısının eşit olması) incelenir.
• Google TFX ve Apple Overton gibi platformlar kullanılır.

Öğrenme Programının Testi:

• Doğruluk, adillik ve yorumlanabilirlik ölçülür.
• Precision: Doğru pozitif tahminlerin oranıdır.
• Recall: Gerçek pozitiflerin doğru tahmin edilme oranıdır.
• IBM’in AI Fairness 360 gibi araçları adilliği analiz eder.
• H2O gibi araçlar modelin yorumlanabilirliğini test eder.

ML Modellerinin İzlenmesi

Modellerin zamanla davranış değiştirmemesi için sürekli izlenmeleri gerekir. İzleme dört kategoriye ayrılır:

1. Özellik izleme
2. Model işlem izleme (örneğin RAM kullanımı)
3. Model performans izleme
4. Model önyargı izleme Amazon’un SageMaker Model Monitor aracı, kavram kaymasını (concept drift) tespit eder ve uyarı verir.

Geliştirme ve Test İlişkisi

Yazılım mühendisliğinde, yazılım geliştirme metodolojisi (yaşam döngüsü olarak da bilinir), bir projeyi belirli aşamalara ayırarak daha verimli planlama ve yönetim sağlar. Geleneksel yöntemlerden biri şelale modeli iken, Kanban ve Scrum gibi çevik (agile) yöntemler daha modern yaklaşımlardır.

Refactoring (Yeniden Düzenleme)

Mevcut kodun davranışını veya işlevini değiştirmeden, tasarımını sadeleştirme ve temizleme işlemidir.

Test Tabanlı Geliştirme (TDD)

Geliştirici odaklı bir test yöntemidir. Her işlevsellik için önce test yazılır, ardından işlevselliği sağlayacak en basit kod yazılır. TDD döngüsü şu adımları içerir:

1. Test yazılır (henüz kod yoktur).
2. Test çalıştırılır ve başarısız olması beklenir.
3. Testi geçmek için gerekli kod yazılır.
4. Kod tekrar test edilir; geçmesi gerekir.
5. Kod sadeleştirilir, tekrar eden bölümler temizlenir.

Bu süreç sürekli “test yaz, geçmesini sağla, refactor et” döngüsüyle devam eder.

Davranış Tabanlı Geliştirme (BDD)

TDD’nin belirsizliklerini azaltmak amacıyla Dan North tarafından 2006'da geliştirilmiştir. “Uygulama nasıl davranmalı?” sorusuna odaklanır. “Given/When/Then” (Verildiğinde / Olduğunda / O zaman) yapısıyla kullanıcı hikayeleri anlatılır. Örneğin:

• Given: Kullanıcı geçerli bilgilerle giriş yapar.
• When: Giriş butonuna tıklar.
• Then: Başarı mesajı görüntülenir.

Bu yapı, tüm paydaşların (geliştiriciler, müşteriler) süreci anlamasını kolaylaştırır. Gherkin dili, bu yapıdaki test senaryolarını sade İngilizceyle tanımlar.

Kabul Testi Tabanlı Geliştirme (ATDD)

BDD’ye çok benzerdir, ancak odak noktası işlevselliğin doğruluğudur. Kabul testleri, yazılımdaki işlevselliği müşterinin bakış açısından tanımlar ve bu testler, işlevsellik yazılmadan önce oluşturulur. Tüm paydaşlar (geliştiriciler, testçiler, müşteriler) bu süreçte yer alır.

Çiftli Programlama (Pair Programming)

Çifli programlama çevik geliştirme yöntemlerinden biridir. İki programcı bir istasyonda (ekranda/cihazda) çalışır: Driver (sürücü) kodu yazar, navigator (yönlendirici) planlamaya odaklanır. %15 zaman maliyetiyle tasarımın kalitesi, iletişim ve beceri yetenekleri gelişir; hatalar ve insan hatası azalır. Çiftli programlama ilk olarak 1999 yılında Beck tarafından ekstrem programlama (extreme programming) içinde tanıtılmıştır.

[https://hasandogn.medium.com/test-driven-development-tdd-nedir-b78c7a6ef10b]

Sürekli Entegrasyon ve Sürekli Teslimat

Bu bölümde, makine öğrenimi (ML) modelleri için sürekli entegrasyon (CI), sürekli teslimat (CD) ve sürekli eğitim (CT) süreçlerinin uygulanması ve otomasyonu ele alınmaktadır. Bu süreçlerin başarıyla yürütülebilmesi için MLOps prensiplerinin ML projelerine entegre edilmesi gerekir. MLOps, ML sistem geliştirme (ML) ile operasyonlarının (Ops) birleşmesini amaçlayan bir yaklaşımdır. Bu, sistemin tüm aşamalarında (entegrasyon, test, dağıtım, altyapı yönetimi) otomasyon ve izleme gerektirir.

Sürekli Entegrasyon (CI)

CI, geliştiricilerin kodlarını sık ve düzenli olarak (genellikle günlük) sürüm kontrol sistemine yüklemeleri esasına dayanır. Amaç, büyük kod blokları yerine küçük değişikliklerde hataları erken tespit etmektir. CI uygulaması için gerekenler:

• Sürüm kontrolü: Tüm proje unsurları (kod, test, veritabanı, yapılandırma dosyaları) Git gibi bir sistemde tutulmalıdır.
• Otomatik yapı: Komut satırından otomatik olarak derleme yapılabilmelidir.
• Takım uzlaşısı: CI bir araç değil, bir ekip disiplini işidir.

CI araçları arasında GoCD, CruiseControl, Jenkins yer alır. Bu araçlar, kaynak kod deposu, derleme ve test komutları gibi ayarlarla yapılandırılır.

Kod Kapsamı (Code Coverage): Testlerin yazılımı ne ölçüde kapsadığını gösteren bir metriktir (örneğin, fonksiyon veya satır kapsama).

Sürekli Test (CTe)

Otomatik testler, geliştirme sürecinde birim testten sistem ve regresyon testlerine kadar farklı test türlerinin yürütülmesini sağlar. Regresyon testleri, yazılımda yapılan değişikliklerin önceki işlevselliği bozup bozmadığını denetler. Bu testler performans, API ve güvenlik testlerini de içerir. Otomasyon sonrası, bu testler CI/CD hattına entegre edilir:

• CI: Birim ve işlevsellik testleri entegre edilir.
• CD: Performans ve güvenlik gibi kapsamlı testler bu aşamaya entegre edilir.

Sürekli Teslimat (CD)

CD, yazılımın kısa döngülerle güvenilir şekilde teslimini sağlayan bir mühendislik yöntemidir. Geliştirme ekipleri birden fazla test ortamı kullanarak değişiklikleri test eder. Bu süreç Jenkins, CircleCI, Travis CI gibi araçlarla otomatikleştirilebilir.

Tipik bir CD hattı şu adımlardan oluşur:

1. Kod Yükleme: Kod yüklendiğinde, testler çalıştırılır. Hata varsa, geliştiriciye bildirilir.
2. Derleme: Birim testler tekrar çalıştırılır, kapsama raporu oluşturulur, çıktılar (artifacts) üretilir ve depolanır.
3. Kabul Testi: Kullanıcı gereksinimlerinin karşılanıp karşılanmadığını test eder. Yazılım sunuculara yüklenir ve yapılandırılır.
4. Performans Testi: Kod değişikliklerinin performansa etkisi ölçülür.
5. Üretim: Son adımda yazılım üretim ortamına aktarılır.

Jenkinsfile gibi dosyalarla tüm bu adımlar tanımlanabilir.

Sürekli Eğitim (CT)

CT, ML boru hattının otomasyonu ile gerçekleştirilir. Yeni verilerle modelin otomatik eğitilmesi için aşağıdaki adımlar uygulanır:

• Otomatik veri doğrulama: Model eğitimi öncesi veriler kontrol edilir.
• Otomatik model doğrulama: Eğitim sonrası yeni verilerle model doğrulanır.
• Tetikleme: Manuel, zamanlayıcıya bağlı, yeni veri varlığı, performans düşüşü veya veri dağılımı değişikliği gibi durumlarla tetiklenebilir.
• Meta veri yönetimi: Her çalıştırma sonrası meta veriler (başlangıç/zaman, sürümler, parametreler) kaydedilir.

CT özellikleri:

• Hızlı deneysel döngüler
• Üretimde otomatik eğitim
• Geliştirme ve üretim arasında boru hattı tutarlılığı
• Modülerleştirilmiş bileşenler

ML Sistemleri için CI/CD Özellikleri

ML sistemleri yazılım sistemlerine benzer görünse de farklıdır:

• ML geliştiricileri genelde yazılım geliştirme bilgisine sahip olmayabilir.
• Geliştirme süreci deneyseldir; farklı algoritmalar ve parametreler denenir.
• Kodun yanı sıra veri ve model doğrulama testleri de yapılmalıdır.
• Dağıtım, çok aşamalı olabilir ve karmaşıktır.
• ML sistemlerinde model bozulması (model degradation) riski daha yüksektir.

ML sistemlerinde CI/CD farklılıkları:

• CI, kod ile birlikte veri ve model doğrulaması da yapar.
• CD, sadece bir servis değil, bir model eğitim boru hattını da dağıtır.
• CT, ML sistemlerine özgüdür ve otomatik model eğitimi sağlar.

ML CI/CD Süreci:

1. Geliştirme ve Deney: Yeni algoritmalar test edilir, uygun kod sürüm kontrolüne yüklenir.
2. CI: Kod çalıştırılır, test edilir, bileşenler üretilir.
3. CD: Bu bileşenler hedef ortama aktarılır.
4. Otomatik Tetikleme: Üretimde boru hattı otomatik çalıştırılır, model eğitilir.
5. Modelin CD’si: Eğitimli model servis olarak sunulur.
6. İzleme: Model performansı izlenir, gerekirse boru hattı tekrar çalıştırılır.

Bu şekilde ML sistemleri için CI/CD/CT otomasyonu sağlanmış olur.

Continuous Delivery (CD) Pipeline

Orchestrated Experiment

CI/CD for an ML Model

Sürüm Kontrolü

Yazılım geliştirme yaşam döngüsü boyunca, geliştirme ekibinin kaynak kodu, proje belgeleri veya derleme betikleri gibi uygulamalardaki her değişikliği geçmişe dönük olarak takip etmesi gerekir. Bu gereksinime karşılık olarak onlarca yıldır kullanılan çözüm sürüm kontrol sistemleri (VCS) olmuştur. VCS, projede birden çok geliştirici ve ekip paralel olarak farklı bölümlerde çalışırken kayıt sisteminin korunmasını sağlar. Bir VCS sayesinde, belirli dosyalar ya da tüm proje önceki bir duruma döndürülebilir. İlk VCS, 1972’de Marc J. Rochkind tarafından Bell Labs’te geliştirilen SCCS’dir(Source Code Control System). Bunu RCS (Tichy, 1982), CVS (Price, 2005), Apache Subversion, Git gibi açık kaynaklı sistemler ve Perforce, StarTeam, IBM Rational ClearCase, Mercurial, Microsoft Teams Foundation System gibi ticari çözümler izlemiştir. Bu bölümde yalnızca Git’e odaklanılacaktır.

VCS sistemleri üç kategoriye ayrılır:

1. Yerel VCS: Basit bir yöntemdir. Geliştirici, değiştirdiği dosyaları tarihli klasörlere kopyalayarak ilerler. Hatalara açıktır; dosya üzerine yazma veya klasör takibini kaybetme gibi sorunlar oluşabilir. Bunu aşmak için değişiklikleri izleyen basit bir yerel veritabanı kullanılabilir.
2. Merkezi VCS (CVCS): Birden fazla geliştirici olduğunda kullanılır. Değişiklik bilgileri merkezi bir sunucuda tutulur ve istemcilere paylaşılır. Subversion, Perforce ve CSV merkezi VCS örnekleridir. Avantajı, herkesin (yetkisi varsa) diğerlerinin ne yaptığını görebilmesidir. Ancak, merkezi sunucu çökerse tüm sistem etkilenir (tek hata noktası — SPOF).
3. Dağıtık VCS (DVCS): Yerel ve merkezi sistemlerdeki sorunları çözer. Git ve Mercurial gibi sistemlerde geliştiriciler yalnızca en son sürümü değil, tüm depo kopyasını alır. Böylece merkezi sunucunun çökmesi veri kaybına neden olmaz çünkü herhangi bir kullanıcının deposu sunucuyu geri yüklemek için kullanılabilir.

Git 2005 yılında Linux Kernel ekibi tarafından BitKeeper’a alternatif olarak geliştirildi. Git, hızlı, basit ve çok dallı (branch) geliştirme için uygundur. Diğer VCS’lerden farklı olarak Git, dosya değişikliklerini değil, her commit sonrası tüm projenin bir “anlık görüntüsünü” (snapshot) alır. Değişmeyen dosyalar için sadece önceki sürüme referans verilir, bu da Git’i küçük bir dosya sistemi gibi yapar.

Git’in avantajlarından biri checksum (sağlama toplamıdır). Her değişiklik SHA-1 algoritması ile 40 karakterlik bir hash’e dönüştürülerek kaydedilir. Bu sayede değişiklikler tespit edilebilir ve veri kaybı önlenir.

Git’te dosyalar üç durumda olabilir:

1. Modified: Değiştirildi ama commit edilmedi.
2. Staged: Commit edilmek üzere işaretlendi.
3. Committed: Veritabanına kaydedildi.

Bu durumlara göre Git projeleri üç ana bileşenden oluşur:

• Çalışma dizini (working directory): Projenin bir sürümünün yerel kopyasıdır.
• Hazırlık alanı (staging area): Bir sonraki commit’te kaydedilecek değişikliklerin listelendiği alandır.
• Git dizini (Git directory): Metadata ve nesne veritabanını içerir. Klonlama işlemi bu dizini kopyalar.

Git iş akışı:

1. git init komutuyla repo başlatılır.
2. git clone ile repo kopyalanır.
3. Yerel repo üç “ağaç” yapısından oluşur: çalışma dizini, index (staging area) ve HEAD.
4. git add <dosya> ile değişiklikler staging area’ya alınır.
5. git commit -m "mesaj" ile commit yapılır.
6. git push origin master ile uzak sunucuya gönderilir.
7. git checkout -b branch_1 ile yeni bir dal (branch) oluşturulur.
8. git checkout master ile ana dala geri dönülür.
9. git push origin <branch> ile yeni dal uzak sunucuya gönderilir.
10. git pull komutuyla uzak depo güncellemeleri alınır.

GitHub, Git tabanlı, bulut tabanlı bir geliştirici platformudur (GitHub, n.d.-a). Git yerel çalışmaya imkan tanırken, GitHub geliştiricilerin projelerini paylaşmasını, iş birliği yapmasını ve kod incelemesi gibi araçlara erişmesini sağlar. GitHub deposu; dosyaları, klasörleri, veri setlerini ve genellikle proje bilgilerini içeren README dosyasını barındırır. Varsayılan olarak “master” adında bir ana dal vardır. Geliştiriciler, bu daldan yeni bir dal oluşturarak değişiklikleri test eder ve ana dala entegre eder.

Lokal Versiyon Kontrol Sistemi

Merkezi ve dağıtık versiyon kontrol sistemi karşılaştırması

Git’teki kayıt ortamları, onlar arası geçişe verilen isim ve komutlar

Github Dallanma (Branching)

Geliştirme Araçları

IDE’lerin temel kısımları

Yazılım geliştirme araçları veya programlama araçları, yazılım geliştiricilerini ve geliştirme ekiplerini yazılım projelerini hayata geçirme süreçlerinde destekleyen bilgisayar programlarıdır. Bu araçlar; metin düzenleyicileri ile kaynak kod oluşturma ve düzenleme, grafiksel kullanıcı arayüzü düzenleyicilerinden yardım alma, derleyici veya assembler kullanarak kaynak kodu makine diline çevirme, test ve hata ayıklama araçlarıyla çözüm denemeleri yapma ve sürüm kontrol sistemleriyle programları ve belgeleri yönetme gibi işlevler sunar. Bu bölümde en yaygın geliştirme araçlarını inceleyeceğiz.

Komut Satırı Arayüzü (CLI): En temel ve yaygın geliştirme aracı olan komut satırı arayüzü, kullanıcıdan bir metin satırı alarak bunu yorumlayarak işletim sistemi veya programlama dili bağlamında çalıştırır. CLI, bir “kabuk” (shell) aracılığıyla işletim sistemiyle etkileşim kurmayı sağlar. Örnekler arasında Unix Shell, PowerShell, Z Shell ve Python Shell bulunur. Komutlar genellikle şu yapıdadır: prompt komut parametre_1 … parametre_n. CLI, başlangıç seviyesindeki kullanıcılar için kod düzenleme ve hata ayıklama gibi konularda her zaman en uygun çözüm değildir; fakat Vim (metin düzenleyici), Wget (dosya indirme aracı), Gzip (veri sıkıştırma aracı) gibi yardımcı entegre araçlar CLI kullanımını kolaylaştırır.

Tümleşik Geliştirme Ortamı (IDE: Integrated Development Environment): IDE, yazılım geliştirme sürecini kolaylaştırmak için birçok işlevi bir araya getiren tek bir program ya da platformdur. Örnekler: Microsoft Visual Studio, Eclipse, NetBeans, PyCharm.

Tipik işlevler:

• Akıllı kod tamamlama: Fonksiyon isimleri yazıldığında açıklama ve parametre listesi gösterilir (örnek: IntelliSense).
• Kaynak kod düzenleyici: Kod yazımı ve düzenlemesi yapılır, kod tamamlama gibi özelliklerle desteklenir.
• Yapı otomasyonu: Derleme, paketleme ve kurulum dosyası oluşturma işlemleri otomatikleştirilir.
• Hata ayıklayıcı (debugger): Çalışma zamanında değişkenlerin değerleri izlenebilir veya değiştirilebilir.
• Sözdizimi vurgulama: Farklı renk ve yazı tipleriyle programlama dillerinin söz dizimi vurgulanır.
• Yapay zeka destekli kod üretimi işlemleri.

Eclipse IDE: IBM tarafından başlatılmış ve 2001'de açık kaynak haline gelmiş bir IDE’dir. Başlangıçta Java için geliştirilmiş olsa da, C, C++, Python, PHP, Ruby gibi dilleri de destekler. Eclipse bileşenleri arasında menü çubukları, görünüm değiştirme aracı, proje/klasör listeleyici, düzenleyici bölümü, çıktı konsolu, görev listesi ve dosya hiyerarşisi bölümleri yer alır.

Java geliştiriciler IntelliJ, .net geliştirenler ise VisualStudio kapalı kaynaklı IDE’leri severler. Visual Studio ise Typescript ile Microsoft tarafından yazılmış açık kaynaklı bir IDE’dir ve Cursor veya Windsurf gibi yapay zeka destekli IDE’ler bu IDE’yi temel alarak projelerini geliştirmişlerdir.

Jupyter Notebook: Jupyter Notebook, web tabanlı etkileşimli bir programlama uygulamasıdır. Özellikle veri bilimciler tarafından Python başta olmak üzere yaklaşık 40 programlama dili için kullanılır. Kullanım alanları arasında veri temizleme, sayısal simülasyon, istatistiksel modelleme, görselleştirme ve makine öğrenmesi yer alır.
İki temel bileşeni vardır:

1. Web uygulaması: Açıklayıcı metin, matematiksel ifadeler, kod ve çıktıları bir arada barındıran belge yönetimi sağlar. Tarayıcı üzerinden yazım, çalıştırma ve çıktılar (PNG, SVG, HTML vb.) mümkündür. Matematiksel ifadeler LaTeX ile desteklenir.
2. Notebook belgeleri: Kod, açıklamalar, görseller ve çıktılarla birlikte .ipynb uzantılı JSON formatında kaydedilir. Bu format versiyon kontrolünü kolaylaştırır ve herkese açık bağlantılarla paylaşım yapılabilir.

Jupyter Notebook Kullanımı:

1. Komut satırından jupyter notebook komutu ile başlatılır.
2. Varsayılan olarak açılan web uygulaması (127.0.0.1:8888) “dashboard” olarak adlandırılır.
3. Yeni defter (notebook) oluşturulur ve içerisine kod yazılır.
4. Kod çalıştırılır, çıktı doğrudan hücrede görüntülenir.
5. Markdown dili ile açıklayıcı metinler eklenebilir (italik, kalın yazı, liste vb.).
6. Grafikler ve görselleştirmeler doğrudan Jupyter Notebook içinde gösterilebilir.