Ders Konusundan Tamamlanabilir Yazılım Projesine

Bir ders konusunu küçük yazılım projesine dönüştürmenin en etkili yolu, doğrudan büyük bir uygulama geliştirmeye çalışmak değil; tek bir kullanıcı problemini seçmek, ilk sürümün sınırlarını belirlemek ve tamamlanmayı ölçülebilir hâle getirmektir. Böylece derslerde öğrenilen kavramlar, dağınık alıştırmalar olarak kalmaz; çalışan, test edilebilen ve açıklanabilen bir ürüne dönüşür.

Bu dönüşüm için izlenebilecek çerçeve şöyledir: konuyu seçin, problemi tek cümlede yazın, minimum kapsamı belirleyin, görevleri sıraya koyun, test senaryolarını oluşturun ve README dosyasını hazırlayın. Algoritma, SQL ve OOP gibi konular da birbirinden kopuk ödevler olmak zorunda değildir; aynı proje içinde algoritma işlem akışını, SQL verinin saklanmasını, OOP ise sorumlulukların sınıflara ayrılmasını sağlayabilir.

Bir Ders Konusu Projeye Nasıl Dönüştürülür?

Ders konusunu projeye çevirirken ilk soru “Hangi büyük uygulamayı yapabilirim?” değil, “Öğrendiğim kavram hangi küçük problemi çözebilir?” olmalıdır. Örneğin algoritma dersinde koşullar, döngüler ve listeler işlendiğinde kapsamlı bir kütüphane otomasyonu kurmak yerine kitap ekleme, kitap listeleme ve ödünç durumunu kontrol etme gibi sınırlı bir akış seçilebilir. Bu yaklaşım, hem konuyu uygulamayı kolaylaştırır hem de projenin yarım kalma riskini azaltır.

Bir proje fikrinin uygulanabilir olup olmadığını anlamak için aşağıdaki altı aşamayı sırayla kullanabilirsiniz:

1. Konuyu seçin: Döngüler, fonksiyonlar, dosya işlemleri, SQL sorguları veya sınıf tasarımı gibi gerçekten uygulamak istediğiniz tek bir ders konusunu belirleyin.
2. Problemi tek cümlede yazın: Kullanıcının hangi işi daha kolay, hızlı veya düzenli yapacağını açıkça ifade edin.
3. Minimum kapsamı belirleyin: İlk sürümde mutlaka bulunması gereken en az sayıdaki özelliği seçin.
4. Görevleri sıralayın: Veri modelini, temel işlemleri, arayüzü ve kontrol adımlarını birbirine bağımlılıklarına göre planlayın.
5. Test senaryolarını oluşturun: Projenin doğru çalıştığını hangi girdilerle ve hangi beklenen sonuçlarla kontrol edeceğinizi yazın.
6. README hazırlayın: Projenin amacını, çalıştırma adımlarını, kapsamını ve örnek kullanımını başkalarının anlayacağı şekilde belgeleyin.

Bu altı aşama, belirli bir programlama diliyle sınırlı değildir. Python ile komut satırı uygulaması, Java ile sınıf tabanlı bir takip sistemi veya başka bir teknolojiyle benzer bir çalışma hazırlanabilir. Önemli olan teknolojinin adı değil, ders bilgisinin somut bir probleme ve doğrulanabilir bir çıktıya bağlanmasıdır.

Örneğin aynı kütüphane ödünç takip fikrini üç farklı ders konusu üzerinden ele alabilirsiniz. Algoritma açısından kitapların listelenmesi, uygun kitabın aranması ve ödünç durumunun kontrol edilmesi incelenir. SQL açısından kitap, üye ve ödünç kayıtları tablolarla modellenir; kayıt ekleme, listeleme ve sorgulama işlemleri yapılır. OOP açısından ise kitap, üye ve ödünç işlemlerinin sorumlulukları ayrı sınıflara dağıtılır. Böylece her konu kendi amacını korurken aynı proje içinde anlamlı bir katman oluşturur.

Buradaki hedef, her dersi tek projede eksiksiz işlemek değildir. Bir dersin temelini uygulamak için küçük bir bölüm yeterli olabilir. Örneğin yalnızca algoritma çalışıyorsanız veritabanı eklemek zorunda değilsiniz; verileri geçici olarak liste veya dosya içinde tutabilirsiniz. SQL konusu ön plandaysa karmaşık bir kullanıcı arayüzü yerine doğru tablo ilişkilerine ve sorgulara odaklanabilirsiniz. OOP çalışıyorsanız sınıfların görevlerini belirginleştirmek, özellik sayısını artırmaktan daha değerlidir.

Başlangıç seviyenizi ve özellikle algoritma mantığındaki eksiklerinizi görmek isterseniz, algoritma bilgi testi üzerinden hangi konuları tekrar etmeniz gerektiğine dair bir başlangıç değerlendirmesi yapabilirsiniz. Bu tür bir kontrol, projeye başlamadan önce eksik kavramları fark etmenize ve görevleri gerçek seviyenize göre seçmenize yardımcı olur.

Bir projenin ders konusuna gerçekten bağlı olup olmadığını anlamak için şu sorulara cevap verin:

• Bu projede hangi ders kavramını kullanacağım?
• Kavramı kullandığım kod veya tasarım kararı nerede görülebiliyor?
• Çalışma sonunda kullanıcı hangi somut sonucu elde edecek?
• Projenin başarılı olduğunu nasıl test edeceğim?

Bu sorulara cevap veremiyorsanız fikir henüz proje hâline gelmemiş olabilir. “Kütüphane uygulaması yapacağım” genel bir fikirdir. “Bir görevli, kitapların ödünçte olup olmadığını görebilecek ve iade edilen kitabın durumunu güncelleyebilecek” ise sınırları daha belirgin bir proje tanımıdır. İkinci cümlede kullanıcı, işlem ve beklenen sonuç birlikte yer alır.

Önce Konuyu ve Kullanıcı Problemini Netleştirin

Proje fikrini netleştirmenin ilk adımı, “uygulama yapacağım” gibi geniş bir ifadeyi tek bir ders konusu ve tek bir kullanıcı ihtiyacıyla sınırlandırmaktır. Birden fazla kullanıcı türünü, çok sayıda ekranı ve onlarca özelliği aynı anda düşünmek başlangıçta üretken hissettirebilir; ancak uygulama geliştirme sürecinde kararları zorlaştırır. Daha iyi başlangıç, bir kişinin belirli bir işi tamamlamasını sağlayan dar bir problem seçmektir.

Konu seçerken kullanabileceğiniz üçlü karar çerçevesi şöyledir:

1. Hangi bilgiyi uygulamak istiyorum? Örneğin algoritma, dosya işlemleri, SQL sorguları veya sınıf tasarımı.
2. Kim hangi işi yapacak? Kütüphane görevlisi kitap kaydı ekleyecek mi, bir öğrenci ödünç durumunu mu görüntüleyecek?
3. İlk sürümde hangi sonucu üretmek yeterli? Kitabın kaydedilmesi, mevcut kitapların listelenmesi ve iade durumunun güncellenmesi yeterli olabilir mi?

Bu soruların yanıtları, projenin gereksiz biçimde büyümesini engeller. Kütüphane ödünç takip senaryosunda ilk problem cümlesi şu şekilde kurulabilir: “Kütüphane görevlisi, kitapların kimde olduğunu ve iade edilip edilmediğini basit bir kayıt sistemi üzerinden takip edebilmelidir.” Bu cümle, projenin temel işini tanımlar: kayıtları tutmak ve ödünç durumunu izlemek.

İlk sürüm için kitap ekleme, üye ekleme, kitabı ödünç verme, kitabı iade alma ve mevcut kayıtları listeleme gibi özellikler yeterli olabilir. Yönetici paneli, e-posta veya telefon bildirimi, mobil arayüz, gelişmiş raporlama, gecikme analizi ve farklı kullanıcı yetkileri ise başlangıç kapsamının dışında bırakılabilir. Bu özellikler ileride düşünülebilir; fakat ilk çalışan sürümün tamamlanması için gerekli değillerdir.

Burada “dışarıda bırakmak”, fikrin kötü olduğu anlamına gelmez. Aksine, proje kapsamını bilinçli yönetmek anlamına gelir. Bir öğrenci önce kitap-üye-ödünç ilişkisini doğru kurarsa daha sonra gecikme hesaplama veya raporlama gibi özellikleri güvenli biçimde ekleyebilir. Temel akış çalışmadan gelişmiş özelliklere geçmek ise hataların hangi katmandan kaynaklandığını anlamayı zorlaştırır.

Bilgisayar programcılığı derslerinin adı, haftalık konu sıralaması, kullanılan dil ve ödev beklentileri üniversiteye ya da programa göre değişebilir. Bu nedenle kütüphane örneğini belirli bir dersin resmî müfredatı veya her öğrenci için zorunlu bitirme projesi gibi değerlendirmemek gerekir. Örneği kendi dersinizde işlenen kavramlara göre sadeleştirebilir, genişletebilir veya farklı bir problem alanına uyarlayabilirsiniz. Aynı karar çerçevesi stok takibi, görev listesi, randevu kaydı veya kişisel harcama takibi gibi başka küçük projelerde de kullanılabilir.

Problemi ve ilk kapsamı doğrulamak için aşağıdaki kısa yazılı alıştırmayı yapın. Cevapları tek bir sayfaya yazın ve her soruya en fazla iki cümle ayırın:

• Projemde hangi ders konusu görünür biçimde kullanılacak?
• Bu projeyi kim kullanacak?
• Kullanıcı hangi tek işi tamamlayacak?
• İlk sürümde bulunacak en fazla beş özellik hangileri?
• İlk sürümde özellikle bulunmayacak üç özellik hangileri?
• Projenin çalıştığını gösterecek en basit çıktı nedir?

Örneğin cevaplarınız “SQL kullanacağım, kullanıcı kütüphane görevlisi olacak, amaç ödünç kayıtlarını takip etmek, ilk sürümde kitap ve üye ekleme ile ödünç-iade işlemleri bulunacak” şeklindeyse fikir uygulanabilir bir başlangıç noktasına yaklaşmıştır. Buna karşılık cevaplarınızda “her kullanıcı türü için ayrı panel, bildirim sistemi, mobil uygulama ve gelişmiş raporlama” gibi çok sayıda bağımsız özellik varsa kapsamı yeniden küçültmeniz gerekir.

Son olarak, temel yazılım kavramlarınızı genel olarak kontrol etmek ve hangi konularda tekrar yapmanız gerektiğini görmek için yazılım bilgisi ölçme testi çözebilirsiniz. Test sonucunu bir başarı etiketi olarak değil, proje planını hangi seviyeden başlatacağınıza yardımcı olan bir yönlendirme olarak kullanın.

İlk Sürümün Kapsamını Küçültün ve Tamamlanma Ölçütü Koyun

Bir yazılım projesinin tamamlanamamasının en yaygın nedenlerinden biri, öğrencinin ilk sürümde çözebileceğinden daha büyük bir sistemi planlamasıdır. Proje fikri başlangıçta etkileyici görünebilir; ancak kullanıcı hesabı, gelişmiş raporlar, bildirim sistemi, grafikler ve çok kullanıcılı yetkilendirme aynı anda eklenince temel iş akışını doğrulamak zorlaşır.

Bu nedenle ilk sürümün amacı “akla gelen her özelliği eklemek” değil, tek bir problemi baştan sona çalışır hâle getirmek olmalıdır. Kütüphane ödünç takip projesinde bu problem, kitapların ve üyelerin kaydedilmesiyle başlayan, ödünç verme ve iade alma işlemleriyle devam eden temel takip akışıdır.

Özellikleri üç gruba ayırın

Kapsam kontrolü yaparken her özelliği üç gruptan birine yerleştirmek pratik bir başlangıç sağlar:

• Olmazsa olmaz: Projenin ana problemini çözmek için gerekli işlevlerdir.
• Sonraki sürüm: Temel akış çalıştıktan sonra kullanıcı deneyimini veya raporlama gücünü artıracak işlevlerdir.
• Şimdilik dışarıda: İlk sürümün hedefiyle doğrudan ilişkili olmayan ya da ciddi ek mimari gerektiren fikirlerdir.

Kütüphane senaryosunda ilk sürüm için kitap ekleme, üye ekleme, ödünç verme, iade alma ve temel listeleme yeterli bir çekirdek oluşturur. Bu işlevler birlikte çalıştığında uygulama, yalnızca tek tek fonksiyonları gösteren bir ödev olmaktan çıkar ve anlamlı bir kullanım senaryosunu karşılamaya başlar.

“Kod yazıldı” yerine tamamlanma ölçütü yazın

Bir özelliğin kodunun yazılmış olması, o özelliğin tamamlandığı anlamına gelmez. Kod çalışıyor gibi görünse bile geçersiz girişlerde uygulama çökebilir, daha önce ödünç verilmiş bir kitap tekrar ödünç verilebilir veya iade işleminden sonra kitap hâlâ “ödünçte” görünebilir.

Bu nedenle her işlev için gözlemlenebilir bir tamamlanma ölçütü tanımlayın. Örneğin kütüphane projesinde ilk sürüm şu koşulları karşılamalıdır:

• Geçerli başlık ve kitap bilgileri girildiğinde yeni kitap kaydı oluşturulmalıdır.
• Geçerli üye bilgileri girildiğinde üye kaydı oluşturulmalıdır.
• Uygun durumdaki bir kitap, kayıtlı bir üyeye ödünç verilebilmelidir.
• Ödünçte olan bir kitap için ikinci bir ödünç işlemi reddedilmelidir.
• Geçerli bir iade işleminden sonra kitabın durumu “uygun” olarak güncellenmelidir.
• Olmayan kitap, olmayan üye veya geçersiz işlem için anlaşılır bir mesaj gösterilmelidir.
• Listeleme ekranı ya da komut satırı çıktısı, kayıtların güncel durumunu göstermelidir.
• Temel senaryolar aynı girdilerle tekrar çalıştırıldığında tutarlı sonuç vermelidir.

Buradaki ölçütler, projenin değerlendirilmesini kolaylaştırır. “Ödünç verme fonksiyonunu yazdım” demek yerine “ödünçte olan kitap ikinci kez verilemiyor” demek, çalışan davranışı tarif eder. Bu yaklaşım hem hata ayıklamayı hem de test yazmayı daha sistemli hâle getirir.

Kısa proje kapsamı kontrol listesi

Projeye başlamadan önce aşağıdaki listeyi doldurmak, kapsamın gereksiz biçimde büyümesini önler:

1. Tek cümlelik problem: Uygulama hangi kullanıcı problemini çözüyor?
2. Temel özellikler: İlk sürümde en fazla birkaç ana işlev hangileri?
3. Veri girişleri: Kullanıcıdan kitap, üye veya işlem sırasında hangi bilgiler alınacak?
4. Beklenen çıktılar: Her işlemden sonra kullanıcı ne görecek?
5. Hata durumları: Eksik, yanlış veya çakışan girişlerde ne olacak?
6. Çalıştırma komutu: Proje başka bir bilgisayarda hangi komutla başlatılacak?
7. Test listesi: Başarılı ve başarısız senaryolar hangileri?
8. README taslağı: Projenin amacı, kullanım adımları ve bilinen sınırları nasıl anlatılacak?

Bu listeyi yalnızca proje tesliminden önce değil, kodlamaya başlamadan önce hazırlayın. Örneğin “grafik ekleyeceğim” gibi bir fikir ortaya çıktığında şu soruyu sorun: Grafik, ilk sürümde tanımladığım problemi çözmek için zorunlu mu? Yanıt hayırsa bu özelliği sonraki sürüme taşıyın.

İlk sürümü küçültmek projeyi basitleştirmekten ibaret değildir; doğrulanabilir bir ürün sınırı çizmek anlamına gelir. Küçük fakat baştan sona çalışan bir uygulama, yarım kalmış büyük bir tasarımdan daha güçlü bir öğrenme çıktısı sunar. Özellikle bilgisayar programcılığı dersleri farklı üniversitelerde ve müfredatlarda değişebildiği için, proje kapsamını ders başlığına göre değil, elinizdeki bilgi ve ölçülebilir hedeflere göre belirlemek daha sağlıklıdır.

Algoritma, SQL ve OOP Konularını Uygulamaya Çevirin

Aynı kütüphane fikri, farklı ders konularını görünür hâle getirebilir. Algoritma açısından uygun kitabı bulma ve koşul kontrolü yapılır; SQL açısından kitap, üye ve ödünç kayıtları arasındaki ilişkiler yönetilir; OOP açısından ise her sınıfa belirli bir sorumluluk verilir. Böylece konu, yalnızca teorik tanımlarla değil, kullanıcı tarafından gözlemlenebilen davranışlarla öğrenilir.

Algoritma: Komut satırında uygun kitabı bulma

Algoritmayı projeye aktarmanın en kolay yollarından biri, tek bir kullanıcı isteğini adım adım çözmektir. Kullanıcı bir başlık aradığında uygulama listedeki kitapları dolaşır, başlığı karşılaştırır ve yalnızca durumu “uygun” olan kayıtları ekrana getirir.

Aşağıdaki örnek, harici kütüphane gerektirmeden doğrudan çalıştırılabilir. Liste içindeki kitaplardan yalnızca ödünç verilebilir durumda olan ve aranan ifadeyi başlığında taşıyan kayıtlar seçilir.

kitaplar = [
    {"baslik": "Python Temelleri", "durum": "uygun"},
    {"baslik": "Algoritmalar", "durum": "oduncte"},
    {"baslik": "Python ile Projeler", "durum": "uygun"}
]

aranan = input("Aranacak ifade: ").lower()
uygunlar = [kitap["baslik"] for kitap in kitaplar
            if aranan in kitap["baslik"].lower()
            and kitap["durum"] == "uygun"]

print("Uygun kitaplar:", uygunlar)

Kullanıcı python yazdığında beklenen çıktı şu biçimde olur:

Aranacak ifade: python
Uygun kitaplar: ['Python Temelleri', 'Python ile Projeler']

Bu küçük örnekte birkaç temel algoritmik beceri birlikte kullanılır:

• Kitap listesindeki kayıtlar sırayla incelenir.
• Başlık karşılaştırması büyük-küçük harf farkından arındırılır.
• Arama ifadesini içeren kayıtlar filtrelenir.
• Kitabın durum alanı “uygun” değilse sonuçlara eklenmez.

Bir sonraki adımda bu filtreleme işlemi komut satırından seçilen kitabın ödünç verilmesiyle birleştirilebilir. Ancak önce arama algoritmasının doğru sonuç ürettiği ayrı olarak doğrulanmalıdır. Python temellerinizi hangi konularda pekiştirmeniz gerektiğini görmek için Python bilgi testi gibi kısa bir değerlendirme de kullanılabilir.

SQL: Kayıt ekleme, listeleme ve üyeye göre sorgulama

SQL katmanında amaç, uygulamadaki bilgileri düzenli biçimde saklamak ve ihtiyaç duyulduğunda geri getirmektir. Kütüphane projesi için başlangıçta üç tablo yeterli bir model sunar:

• books: Kitap kimliği, başlık, yazar ve durum bilgilerini tutar.
• members: Üye kimliği, ad ve iletişim gibi temel bilgileri tutar.
• loans: Hangi üyenin hangi kitabı ne zaman ödünç aldığını ve iade edilip edilmediğini tutar.

Her tabloda birincil anahtar, kaydı diğerlerinden ayırır. loans tablosundaki kitap ve üye alanları ise ilgili kitabı ve üyeyi gösteren ilişki noktalarıdır. Durum alanı, kitabın uygun olup olmadığını veya ödünç kaydının açık mı kapalı mı olduğunu takip etmeye yarar.

İşlem sırası basit tutulabilir:

1. Önce kitap ve üye kayıtları eklenir.
2. Ödünç verme işleminden önce kitabın uygun durumda olup olmadığı kontrol edilir.
3. Uygunsa ödünç tablosuna yeni kayıt eklenir.
4. Kitabın durumu ödünçte olarak güncellenir.
5. İade işleminde ödünç kaydı kapatılır ve kitap yeniden uygun duruma getirilir.
6. Listeleme sorguları ile kitapların ve açık ödünçlerin mevcut durumu görüntülenir.

Örnek sorgu akışı kavramsal olarak şöyle kurulabilir:

INSERT INTO books (title, author, status)
VALUES ('Algoritmalar', 'Robert Sedgewick', 'available');

INSERT INTO members (name)
VALUES ('Ayşe Yılmaz');

SELECT id, title, author, status
FROM books;

SELECT book_id, loan_date, return_date, status
FROM loans
WHERE member_id = 1;

Bu sorguların amacı, tek seferde bütün sistemi kurmak değil, veri akışını görünür hâle getirmektir. Gerçek bir uygulamada ödünç verme işleminden önce kitap durumunu kontrol eden bir sorgu veya uygulama katmanı bulunmalıdır. Aynı kitabın iki açık ödünç kaydına sahip olmasını engellemek, yalnızca tabloya kayıt eklemekten daha önemli bir iş kuralıdır.

SQL öğrenirken tablo tasarımını gereksiz alanlarla büyütmek yerine, önce projenin işlemleri için gereken verileri belirleyin. Daha sonra kitap kategorisi, teslim tarihi, ceza tutarı veya bildirim tercihi gibi alanlar ihtiyaç doğuruyorsa eklenebilir. Böylece veri modeli de ilk sürümün kapsamına uyum sağlar.

OOP: Sorumlulukları sınıflara ayırma

OOP yaklaşımında temel soru, “Kaç sınıf yazmalıyım?” değil, “Hangi sorumluluklar birbirinden ayrılmalı?” sorusudur. Kütüphane örneğinde tüm veriyi, tüm kuralları ve tüm raporları tek bir sınıfa koymak kısa vadede kolay görünebilir; fakat sınıf büyüdükçe değişiklik yapmak ve test yazmak zorlaşır.

Başlangıç için şu sorumluluk dağılımı yeterlidir:

• Book: Kitabın kimliğini, başlığını, yazarını ve mevcut durumunu tutar.
• Member: Üyenin kimliğini ve temel bilgilerini tutar.
• Loan: Belirli bir kitabın belirli bir üyeye hangi işlemle bağlandığını ve iade durumunu temsil eder.
• LibraryService veya Library: Kitap ekleme, üye ekleme, ödünç verme ve iade alma işlemlerinin akışını yönetir.
• Report veya listeleme katmanı: Verileri kullanıcıya okunabilir biçimde sunar.

Ödünç verme kuralı, doğrudan Book sınıfına rastgele bir değer atayarak değil, işlemi yöneten servis üzerinden uygulanabilir. Servis önce kitabın uygun olup olmadığını kontrol eder, sonra üye ve kitap arasında bir Loan nesnesi oluşturur ve kitabın durumunu günceller.

Bu ayrımın amacı her sınıfı tamamen bağımsız hâle getirmek değildir. Sınıflar birbirleriyle ilişki kurabilir; ancak her sınıfın neden değişeceği açık olmalıdır. Kitabın başlığını değiştirme ihtiyacı ile aylık ödünç raporu hazırlama ihtiyacı aynı sınıfı değiştirmeyi gerektiriyorsa sorumluluklar muhtemelen fazla iç içe geçmiştir.

OOP tasarımını kontrol etmek için şu soruları kullanabilirsiniz:

• Kitap bilgisi ile ödünç işlemi aynı veri yapısına gereksiz biçimde mi doldurulmuş?
• Bir kitabın uygun olup olmadığını kontrol eden kural tek bir yerde mi bulunuyor?
• Üye bilgilerini yöneten sınıf, raporların metin biçimini de oluşturuyor mu?
• İade işleminde hangi nesnelerin değiştiği açıkça görülebiliyor mu?
• Bir sınıfı test etmek için bütün uygulamayı çalıştırmak gerekiyor mu?

İyi bir ilk tasarım, gelecekteki her ihtiyacı şimdiden çözmeye çalışmaz. Önce kitap, üye ve ödünç ilişkisini anlaşılır hâle getirir; daha sonra gecikme cezası, bildirim veya yetkilendirme gibi yeni kurallar ayrı bileşenler olarak eklenebilir. Böyle bir yaklaşım, algoritma, SQL ve OOP bilgisini birbirinden kopuk başlıklar olmaktan çıkarıp aynı projenin farklı katmanlarında gözlemlenebilir hâle getirir.

Kütüphane Ödünç Takip Fikrini Beş Katmana Ayırın

Kütüphane ödünç takip uygulaması, tek parça hâlinde düşünüldüğünde geniş ve belirsiz görünebilir. Ancak fikri özellik, veri, sınıf, test ve dokümantasyon katmanlarına ayırdığınızda, hangi işi neden yaptığınızı daha kolay görebilirsiniz. Böylece yalnızca çalışan bir komut satırı uygulaması değil, ders konularını gerçek bir yazılım akışında birleştiren tamamlanabilir bir proje ortaya çıkar.

Bu örnekte amaç; kitapları ve üyeleri kaydetmek, uygun bir kitabı üyeye ödünç vermek, iade almak ve kitabın durumunu takip etmektir. İlk sürümde kullanıcı girişi, web arayüzü, gelişmiş yetkilendirme veya bildirim sistemi bulunmak zorunda değildir. Önemli olan seçilen kapsamın baştan sona çalışmasıdır.

1. Özellik katmanı: Kullanıcı uygulamada ne yapacak?

Özellik katmanı, projenin kullanıcı açısından görünen yüzüdür. Önce sınıfları veya SQL tablolarını yazmak yerine, kullanıcının uygulamada izleyeceği akışı cümlelerle tarif etmek daha sağlıklıdır.

Kütüphane uygulamasının ilk sürümündeki temel kullanıcı akışı şöyle olabilir:

• Yeni kitap kaydı oluşturulur.
• Kayıtlı kitaplar kitap numarası, başlık ve yazar bilgileriyle listelenir.
• Yeni üye kaydı oluşturulur.
• Uygun durumdaki bir kitap, kayıtlı bir üyeye ödünç verilir.
• Ödünçte olan kitap tekrar ödünç verilmek istendiğinde işlem reddedilir.
• İade alınan kitabın durumu yeniden “uygun” olarak işaretlenir.
• Geçersiz kitap veya üye numarası girildiğinde kullanıcıya anlaşılır bir hata mesajı gösterilir.

Bu liste, proje için bir başlangıç sözleşmesi gibi düşünülebilir. Örneğin “kitap arama” özelliği ilk sürümde yalnızca kitap numarasıyla çalışabilir. Başlıkta kelime arama, yazara göre filtreleme veya gecikme süresi hesaplama gibi özellikler sonraki sürümlere bırakılabilir.

2. Veri katmanı: Book, Member ve Loan kayıtları

Veri modeli, uygulamanın hangi bilgileri saklayacağını gösterir. Temel modelde üç ana kayıt türü kullanılabilir:

• Book: book_id, title, author ve status alanlarını içerebilir. status değeri “available” veya “borrowed” gibi kontrollü değerlerden oluşmalıdır.
• Member: member_id, name, email ve üyelik durumunu belirten bir alan içerebilir.
• Loan: loan_id, book_id, member_id, borrowed_at, returned_at ve işlem durumunu içerebilir.

SQL kullanılıyorsa bu kayıtlar ayrı tablolar şeklinde tasarlanabilir. Loan.book_id kitabı, Loan.member_id ise ödünç alan üyeyi işaret eder. Böylece ödünç işlemi yalnızca “kitap ödünçte mi?” bilgisinden ibaret kalmaz; hangi üyenin ne zaman aldığı ve ne zaman iade ettiği de izlenebilir.

Burada önemli bir ayrım vardır: veri modeli ile sınıf modeli aynı şey değildir. SQL tablosundaki bir kayıt, her zaman tek bir sınıfın bütün sorumluluklarını temsil etmez. Örneğin Book tablosundaki bir satır kitap başlığını ve durumunu saklayabilir; fakat ödünç verilebilirlik kuralını, veri tabanına kayıt işlemini ve kullanıcıya hata mesajı gösterilmesini aynı nesneye yüklemek doğru olmayabilir.

Bu nedenle tablo ile sınıf arasında birebir eşleşme kurmak zorunlu değildir. Bir Book sınıfı kitap verisini temsil ederken, LibraryService ödünç verme kurallarını, BookRepository ise veri erişimini yönetebilir. Bu ayrım, özellikle OOP konularını uygulamaya aktarırken gereksiz büyüyen sınıfların önüne geçer.

3. Sınıf katmanı: Sorumlulukları dağıtın

OOP yaklaşımında hedef, her şeyi tek bir Library sınıfına doldurmak değildir. Sınıfları, değişmesi muhtemel sorumluluklara göre ayırmak daha sürdürülebilir bir başlangıç sağlar.

• Book: Kitabın kimlik, başlık, yazar ve mevcut durum bilgisini taşır.
• Member: Üye kimliği ve üye bilgilerini temsil eder.
• Loan: Bir kitap ile üye arasındaki ödünç ilişkisini ve tarihleri temsil eder.
• LibraryService: Kitap ekleme, ödünç verme ve iade alma kurallarını uygular.
• BookRepository: Kitap kayıtlarını ekleme, bulma ve listeleme işlemlerini yürütür.
• LoanRepository: Ödünç kayıtlarını oluşturma, aktif ödünçleri bulma ve iade durumunu güncelleme işlemlerini yönetir.

Örneğin “kitap zaten ödünçteyse tekrar verilemez” kuralı yalnızca kullanıcı arayüzünde kontrol edilmemelidir. Bu kontrol servis katmanında da bulunmalıdır. Çünkü ileride komut satırı yerine farklı bir arayüz eklenirse aynı iş kuralının korunması gerekir.

books = {1: {"title": "Algoritmalar", "status": "available"}}

def borrow_book(book_id):
    book = books.get(book_id)
    if book is None:
        return "Kitap bulunamadı."
    if book["status"] == "borrowed":
        return "Kitap zaten ödünçte."
    book["status"] = "borrowed"
    return "Ödünç verme başarılı."

print(borrow_book(1))
print(books[1]["status"])

Bu kısa örnekte beklenen çıktı sırasıyla “Ödünç verme başarılı.” ve “borrowed” değeridir. Gerçek projede sözlük yerine SQL sorguları veya repository sınıfları kullanılabilir; ancak temel karar değişmez: önce kitabın varlığı, sonra mevcut durumu kontrol edilir ve başarılı işlemden sonra durum güncellenir.

4. Test katmanı: Kuralları örneklerle sınayın

Testleri yalnızca geliştirme bittikten sonra yapılacak son bir işlem olarak görmek yerine, kapsamı belirleyen bir araç olarak kullanın. Bir özelliğin test edilebilir bir beklenen sonucu yoksa, özelliğin tanımı muhtemelen hâlâ belirsizdir.

Aşağıdaki senaryolar, kütüphane projesinin ilk sürümü için yeterli bir başlangıç test seti oluşturur:

Test 1: Kitap ekleme başarılı olur

• Başlangıç verisi: Veri tabanında aynı kimliğe sahip bir kitap bulunmuyor.
• İşlem: “Algoritmalar” başlıklı ve “Berk Keskin” yazarlı kitap eklenir.
• Beklenen sonuç: Kayıt başarıyla oluşturulur, kitap listesinde görünür ve başlangıç durumu “available” olur.

Test 2: Bulunmayan kitapla ödünç verme reddedilir

• Başlangıç verisi: Üye kaydı vardır, ancak istenen kitap kimliği veri tabanında yoktur.
• İşlem: Bulunmayan kitap kimliğiyle ödünç verme isteği gönderilir.
• Beklenen sonuç: İşlem reddedilir, yeni bir Loan kaydı oluşturulmaz ve kullanıcıya kitabın bulunamadığı bildirilir.

Test 3: Zaten ödünçte olan kitap tekrar verilemez

• Başlangıç verisi: Kitap kaydı mevcut ve durumu “borrowed” değerindedir. Üye kaydı da geçerlidir.
• İşlem: Aynı kitap başka bir üyeye ödünç verilmeye çalışılır.
• Beklenen sonuç: İşlem reddedilir, kitabın mevcut ödünç kaydı değişmez ve ikinci bir aktif Loan oluşturulmaz.

Test 4: İade işleminden sonra durum uygun değere döner

• Başlangıç verisi: Bir kitap aktif Loan kaydıyla ödünçtedir.
• İşlem: İade işlemi gerçekleştirilir.
• Beklenen sonuç: Loan kaydına iade tarihi yazılır, aktif ödünç durumu kapanır ve kitabın durumu “available” olur.

Python ile basit bir proje geliştiriyorsanız standart kütüphanedeki unittest modülüyle testleri çalıştırabilirsiniz. Örneğin test dosyaları uygun biçimde düzenlendiğinde python -m unittest discover komutu test keşfini başlatır; ayrıntılı çıktı için -v seçeneği kullanılabilir. Komutun güncel kullanım biçimi için Python unittest belgeleri incelenebilir.

5. README katmanı: Projeyi başkasına aktarın

README, projenin yalnızca tanıtım metni değildir. Bir başka kişi, sizin bilgisayarınızdaki özel ayarları bilmeden projeyi kurup çalıştırabiliyorsa README görevini yerine getiriyor demektir.

Kütüphane projesinin README dosyasında şu başlıklar bulunmalıdır:

• Proje amacı: Uygulamanın hangi problemi çözdüğünü bir veya iki paragrafla açıklayın.
• İlk sürüm kapsamı: Kitap ekleme, üye ekleme, listeleme, ödünç verme ve iade alma özelliklerini belirtin.
• Kapsam dışı bırakılanlar: Kullanıcı girişi, gelişmiş rol yönetimi, e-posta bildirimi, gecikme cezası hesaplama veya web arayüzü gibi özelliklerin bu sürümde bulunmadığını açıkça yazın.
• Kurulum adımları: Proje dosyalarının nasıl edinileceğini, gerekli ortamın nasıl hazırlanacağını ve veri tabanının nasıl oluşturulacağını açıklayın.
• Örnek komutlar: Kitap ekleme, kitap listeleme, ödünç verme ve iade alma işlemlerinin nasıl başlatılacağını gösterin.
• Testlerin çalıştırılması: Test klasörünün nerede olduğunu ve test komutunun nasıl kullanılacağını belirtin.
• Bilinen sınırlılıklar: Aynı kitabın eş zamanlı isteklerde nasıl ele alındığı, tarih doğrulamasının ne kadar kapsamlı olduğu veya kullanıcı arayüzünün bulunup bulunmadığı gibi sınırlamaları yazın.

README içinde örnek komutların yalnızca isimlerini vermek yerine, beklenen kullanım biçimini de açıklayın. Örneğin “ödünç verme işlemini çalıştırın” demek yerine, hangi parametrelerin gerektiğini ve başarılı işlemden sonra hangi durumun görülmesi gerektiğini belirtin. Bu açıklama, projenin nasıl çalıştığını anlamayı kolaylaştırır ve eksik tasarım kararlarını fark etmenizi sağlar.

Görevleri Sıralayın, Test Edin ve README ile Kapatın

Bir yazılım projesi çoğu zaman teknik zorluktan değil, işlerin yanlış sırada yapılmasından uzar. Önce arayüz tasarlayıp sonra veri modelini düşünmek, kapsamı belirsiz bırakıp son gün test yazmaya çalışmak veya README’yi tamamen unutmak sık görülen sorunlardır. Aşağıdaki sıra, kütüphane ödünç takip uygulamasını küçük çıktılarla ilerletmek için doğrudan uygulanabilir.

1. Problem cümlesini yazın. Kütüphanede kitapların ve ödünç işlemlerinin düzenli takip edilemediğini anlatan tek paragraf oluşturun. Çıktı: Projenin amacını açıklayan problem cümlesi.
2. İlk sürüm özelliklerini seçin. Kitap ekleme, üye ekleme, listeleme, ödünç verme ve iade alma işlemlerini belirleyin. Çıktı: “İlk sürümde var” ve “sonraki sürüme bırakıldı” listeleri.
3. Veri alanlarını belirleyin. Book, Member ve Loan için gerekli kimlik, ad, tarih ve durum alanlarını yazın. Çıktı: SQL tablo taslağı veya sınıf alanlarını gösteren bir şema.
4. Örnek kayıtları oluşturun. En az birkaç kitap, üye ve ödünç kaydıyla uygulamanın başlangıç verisini hazırlayın. Çıktı: Seed dosyası, SQL ekleme komutları veya başlangıç nesneleri.
5. Temel listeleme akışını yazın. Önce kitapları ve üyeleri ekranda gösterebilen basit akışı tamamlayın. Çıktı: Çalışan kitap ve üye listeleme komutu.
6. Ödünç verme ve iade kurallarını ekleyin. Kitabın bulunması, üyenin bulunması ve kitabın uygun durumda olması kontrollerini uygulayın. Çıktı: Başarılı ödünç verme ve iade senaryosunun çalışan akışı.
7. Hata durumlarını ele alın. Boş alan, bulunmayan kimlik, tekrar ödünç verme ve geçersiz iade gibi durumlar için anlaşılır sonuçlar üretin. Çıktı: Hata durumları listesi ve her biri için beklenen mesaj veya sonuç.
8. Test senaryolarını çalıştırın. Başarılı ve başarısız akışları test ederek kapsam kararlarınızı yeniden değerlendirin. Çıktı: Tekrar çalıştırılabilir test dosyaları ve sonuç kaydı.
9. README’yi tamamlayın. Proje amacı, kurulum, kullanım, test komutları, kapsam dışı maddeler ve sınırlılıkları yazın. Çıktı: Başka bir kişinin izleyebileceği eksiksiz kullanım belgesi.
10. Son kontrolü yapın. Projeyi temiz bir klasörde baştan kurup ana akışı tekrar çalıştırın. Çıktı: Tamamlanma kontrol listesinin işaretlenmiş hâli ve gerekiyorsa düzeltme listesi.

Testleri sekizinci adımda görünür hâle getirmek, onların yalnızca sona bırakıldığı anlamına gelmez. Örneğin “iade işlemi olacak” dediğiniz anda, iade sonrasında kitabın hangi değere dönmesi gerektiğini de tanımlayabilirsiniz. Eğer bunu netleştiremiyorsanız özellik henüz yeterince tasarlanmamıştır. Bu nedenle test senaryoları, kapsamı küçültmek ve belirsiz kararları erkenden fark etmek için kullanılmalıdır.

Tamamlandı kararını vermek için son kontrol listesi

• Kurulum, temiz bir klasörde baştan sona yapılabiliyor mu?
• Kitap ekleme, listeleme, ödünç verme ve iade alma ana akışı çalışıyor mu?
• Bulunmayan kayıtlar, boş alanlar ve tekrar ödünç verme gibi hatalı girişler yönetiliyor mu?
• Testler aynı başlangıç verisiyle tekrar çalıştırıldığında aynı sonucu veriyor mu?
• README, projeyi daha önce görmemiş başka bir kişinin uygulamayı çalıştırmasına yetiyor mu?
• Kapsam dışı bırakılan maddeler açıkça yazılmış mı?
• Bilinen sınırlılıklar saklanmadan belirtilmiş mi?
• Proje dosyalarında kullanılmayan kod, geçici denemeler ve açıklanmamış komutlar temizlenmiş mi?

Bu kontrol listesindeki maddelerden biri eksikse proje başarısız olmuş sayılmaz; ancak “tamamlandı” kararını vermeden önce eksik noktayı görünür hâle getirir. Çalışmalarınızı düzenli sürdürürken proje ve yazılım geliştirme içeriklerini incelemek, farklı ders konularını benzer biçimde küçük ve uygulanabilir çıktılara ayırmanıza yardımcı olabilir.

Sık Sorulan Sorular

Bir ders konusunu projeye dönüştürürken ilk özellikleri nasıl seçmeliyim?

Önce dersin bütün başlıklarını projeye eklemeye çalışmak yerine, kullanıcının tek bir problemini çözen en küçük akışı seçmelisiniz. Kütüphane örneğinde bu akış; kitap ekleme, kayıtlı kitabı listeleme, ödünç verme ve iade alma olabilir. Her özellik için “başarılı olduğunda ne olacak?” ve “hatalı durumda ne olacak?” sorularını yanıtlayamıyorsanız özellik henüz yeterince net değildir.

Küçük bir yazılım projesinin gerçekten tamamlandığını nasıl anlayabilirim?

Kurulumun temiz bir ortamda yapılabilmesi, ana kullanıcı akışının çalışması, hatalı girişlerin yönetilmesi, testlerin tekrarlanabilir olması ve README dosyasının yeterli açıklamayı içermesi temel ölçütlerdir. Ayrıca kapsam dışı maddeler açıkça yazılmalıdır. Bir projeye yeni özellik eklenebiliyor olması, mevcut sürümün tamamlanmadığı anlamına gelmez; tamamlanma, önceden belirlenen ölçütlerin karşılanmasıyla değerlendirilir.

Algoritma, SQL ve OOP aynı projede birlikte kullanılabilir mi?

Evet. Algoritma; kitabın bulunması, uygunluk kontrolü ve işlem sırasının belirlenmesinde kullanılabilir. SQL; Book, Member ve Loan kayıtlarının saklanması, eklenmesi, listelenmesi ve sorgulanmasını sağlar. OOP ise bu işlemleri sorumlulukları ayrılmış sınıflar içinde düzenler. Bu üç konu aynı görevi yapmaz; aynı uygulamanın farklı katmanlarında birbirini tamamlar.

README dosyasında öğrenci projesi için hangi bilgiler bulunmalı?

README içinde projenin amacı, çözdüğü problem, ilk sürüm kapsamı, kapsam dışı bırakılan özellikler, kurulum adımları, örnek kullanım komutları, testlerin nasıl çalıştırılacağı ve bilinen sınırlılıklar bulunmalıdır. Kullanılan teknoloji veya veri tabanı belirtiliyorsa, bunun projedeki rolünü de açıklayın. README’nin amacı projeyi övmek değil, başka bir kişinin projeyi anlayıp çalıştırabilmesini sağlamaktır.

Ders bilgisini küçük, sınanabilir ve belgelenmiş adımlara ayırdığınızda proje fikri belirsiz bir ödev olmaktan çıkar; üzerinde düşünerek geliştirebileceğiniz somut bir çalışma hâline gelir.