C#'ta Uygulama Genel Planlaması: Tim Corey ile Büyük Resmi Öğrenmek

Genel Planlamaya Giriş

Videonun başlangıcında, Tim Corey 02. Dersi tanıtır ve odak noktasının genel planlama, yani uygulamanın büyük resmi olduğunu açıklar. Tim bu adımın, ayrıntılara dalmadan önce uygulamanın temelini atmakla ilgili olduğunu açıklar. Bu ders diğerlerine göre daha kolay gibi gelebilir, ancak yönetilebilir, ölçeklenebilir ve sürdürülebilir uygulamalar oluşturmak için kritik bir rol oynadığını vurgular.

Genel planlamanın özellikler veya kod yazmakla ilgili olmadığını açıklar. Uygulamanın tamamının nasıl çalışacağını, kullanıcıların onunla nasıl etkileşimde bulunacağını ve geliştiricilerin onu nasıl yapılandıracaklarını anlamakla ilgilidir.

Paydaş Sorularını Gözden Geçirmek

Tim, devam etmeden önce, bir önceki derste sorulan 15 soruya tekrar göz atması gerektiğini açıklar. Bu sorular, uygulamayı talep eden paydaşlardan ek bilgi toplamak üzere tasarlanmıştır. Tim, bir geliştiricinin gerçek dünyadaki bir senaryoda, paydaşlara geri dönüp açıklayıcı sorular sorduğu ve daha ayrıntılı yanıtlar topladığı bir durum simüle eder.

Bu sürecin gerçek iş ortamlarını yansıttığını belirtir. Geliştiricilerin sıklıkla birden fazla soru sorması ve gereksinimleri iyileştirmesi gerekir çünkü kullanıcılar her zaman ne istediklerini teknik terimlerle tanımlayamazlar.

Değişken Oyuncular ve Turnuva Boyutu

Tim, yanıtları gözden geçirirken uygulamanın değişken sayıda oyuncuyu desteklemesi gerektiğini açıklayarak başlar. Turnuva izleyici sabit bir sayı ile sınırlı olmamalıdır. İster iki oyuncu olsun, ister çok daha fazla, uygulama bunu halledebilmeli.

Bu gereksinim uygulamanın işlevselliğini, veri yapılarını ve mantığını doğrudan etkiler. Geliştiricilerin oyuncu sayısı hakkında sabit kodlanmış varsayımlar yapamayacağını açıklar. Bunun yerine, uygulama katılan kişi sayısına göre kullanıcıları ve oyunları dinamik olarak yönetmelidir.

Kusurlu Turnuvalarda Boş Geçme İşlemi

Tim, turnuvaların her zaman ideal sayıda oyuncuya sahip olmayacağını açıklar. Toplam sayı eşit olarak bölünemediğinde, uygulama boş geçmeleri atamalıdır. Bu noktada, Tim önemli bir kuralı vurgular: boş geçmeler rastgele atanmalıdır.

Bu, uygulamanın yinelenen teknik ihtiyaçlarından birini tanıtır—rastgelelik. Uygulama, kimin oynamadan ilerlediğini rastgele seçerek kullanıcıları adil bir şekilde yönetmelidir. Bu gereklilik, uygulama içindeki araçlar, mantık ve olaylarla ilgili sonraki kararlara şekil verir.

Oyuncuların Rastgele Sıralanması

Tim, kimin kime karşı oynayacağının sırasının da rastgele olması gerektiğini açıklayarak devam eder. Uygulama, kullanıcıların girildiği sıraya güvenmemelidir. Tüm oyuncular eklendikten sonra uygulama listeyi rastgele hale getirir.

Bu, adaleti ve yanlılığın önlenmesini sağlar. Tim, rastgeleliğin bir kural, isteğe bağlı bir özellik olmadığını açıkça belirtir. Bu, uygulamanın temel kurallarının bir parçası haline gelir ve geliştirme sürecince saygı gösterilmelidir.

Esnek Oyun Takvimi

Tim, oyunların sistem tarafından planlanmadığını açıklar. Oyuncular istedikleri zaman oynayabilirler. Ancak, uygulama yine de kuralları uygular. Saat 3:04'te, Tim her turun, bir sonraki turun gösterilmeden önce tamamlanması gerektiğini netleştirir.

Bu gereklilik, uygulamanın oyunları nasıl takip ettiğini, verileri nasıl yönettiğini ve olayları nasıl tetiklediğini etkiler. Uygulama, bir turun ne zaman tamamlandığını bilmeli ve kullanıcıların sonraki turlara erken erişimini önlemelidir.

Skorlama ve Veri Esnekliği

Tim sistemin basit sayısal bir skor saklaması gerektiğini açıklar. Bu, uygulamanın farklı türde oyunları destekleyebilmesini sağlayacak kadar esneklik gösterir. Dama, basketbol veya başka bir rekabet olsun, aynı uygulama skorları yönetebilir.

Bu karar, verinin nasıl toplandığını, saklandığını ve görüntülendiğini etkiler. Skorlama basit tutularak uygulama tek bir oyun türüne kilitlenmekten kaçınılır.

Geleceği Düşünerek Kullanıcı Arayüzleri Seçme

Tim, uygulamanın bir masaüstü uygulaması olarak Windows Forms kullanacağını açıklar—şu an için. Ancak, paydaşların, aynı uygulamayı ileride bir web veya mobil platform haline getirmek isteyebileceğini vurgular.

Bunun sonucunda, geliştiricilerin kullanıcı arayüzlerini iş mantığından ayırmaları gerekir. Saat 4:41'de, temel işlevselliğin bir sınıf kütüphanesine yerleştirilmesi gerektiğini, böylece farklı kullanıcı arayüzlerinin daha sonradan uygulamayı yeniden yazmak zorunda kalmadan entegre edilebileceğini açıklar.

Veri Depolama ve Entegrasyon Stratejisi

Tim verinin, ideal olarak Microsoft SQL Server'da saklanması gerektiğini, ancak uygulamanın bir metin dosyası temeli de desteklemesi gerektiğini açıklar. Bu, uygulamanın belirli araç veya hizmetler kullanılamadığında da çalışmasını sağlar.

Bu karar geliştiricilerin veri erişim kodunu nasıl yazdıklarını etkiler. Tim, entegrasyonun esnek olması gerektiğini, böylece aynı uygulamanın farklı kaynaklardan veri saklayıp alabilmesi gerektiğini, işlevselliği bozmadan açıklıyor.

Giriş Ücretleri, Ödüller ve Gerçek Dünya Belirsizlikleri

Tim paydaşların genellikle belirsiz yanıtlar verdiğini açıklar. Başlangıçta, uygulamanın giriş ücretleri ve ödülleri nasıl ele aldığına dair cevap basit bir şekilde "evet"tir. Tim, geliştiricilerin bunun ne anlama geldiğini anlamak için daha derinlemesine araştırma yapmaları gerektiğini açıklar.

Daha sonra netleştirilmiş gereksinimleri özetler: turnuvalar giriş ücretleri alabilir, birden fazla yere ödüller verebilir ve ödemelerin hiçbir zaman geliri aşmaması gerektiğini sağlaması gerekir. Yüzde bazlı ödemeler ve bağış toplama senaryolarını da açıklar.

Bu bölüm, uygulama genel planlamasının, geliştiricilerin uygulamayı fazla karmaşıklaştırmadan gerçek iş kurallarını nasıl öngörebileceğini gösterir.

Raporlama ve Sonuçları Görüntüleme

Tim raporlamanın basit olması gerektiğini açıklar. Uygulamanın, kimin kazandığı ve ne kadar kazandığı dahil olmak üzere, tur sonuçları ve nihai sonuçları sergilemesi gerekir. Raporlar formlar üzerinde gösterilebilir veya e-posta gönderilebilir.

Bu, karmaşık bir raporlama sistemi inşa etmekten kaçınırken yine de kullanıcı beklentilerini karşılar. Odak noktası gereksiz özellikler değil, işlevsellikte kalır.

Kullanıcı Erişimi ve Sadelik

Tim uygulamayı kullanan herkesin oyun sonuçlarını girebileceğini açıklar. Uygulama içinde değişen erişim seviyeleri yoktur. Bu, hesaplar, parolalar ve güvenlik katmanlarından kaçınarak geliştirmeyi basitleştirir.

Uygulamanın praktikte yöneticinin cihazında bulunabileceğini, diğer kullanıcıların ise sadece e-posta yoluyla etkileşime geçtiğini açıklar.

E-posta Bildirimleri ve Otomasyon

Tim, e-posta işlevselliğinin önemli olduğunu vurgular. Uygulama, yaklaşan oyunlar ve tur sonuçları hakkında kullanıcıları otomatik olarak bilgilendirmelidir. Bu, geliştiricilerin tasarım sürecinin başında e-posta entegrasyonunu ve otomasyonu anlamalarını gerektirir.

Tim, bu gereksinimin birçok kez ortaya çıktığını ve önemini işaret eder.

Ekipleri ve Grup Kullanıcılarını Desteklemek

Tim uygulamanın sadece bireyleri değil, ekipleri de desteklemesi gerektiğini açıklar. Tüm takım üyeleri eşit şekilde değerlendirilir ve aynı e-postaları alır. Takımların da isimleri olmalıdır.

Bu, kullanıcıların nasıl gruplandığını, verinin nasıl yapısallaştırıldığını ve olayların nasıl bildirimleri tetiklediğini etkiler.

Büyük Resim Tasarımını Tanımlamak

Tim, büyük resim tasarımını bir resim analojisi kullanarak tanıtır. Bu aşamanın sınırları, ayrıntıları değil tanımladığını açıklar. Saat 18:48'de, yapıyı: bir Windows Forms uygulaması, bir sınıf kütüphanesi, SQL veya metin dosyası veri depolaması ve her seferinde tek bir aktif kullanıcı olarak özetler.

Bu sınırlar, geliştiricilerin daha sonra gereksiz kararlara dalmasını engeller.

Geliştiriciler İçin Ana Konseptleri Belirlemek

Tim geliştiricilerin araştırmaları gereken ana kavramları belirlemeleri gerektiğini açıklar. E-posta, SQL, özel olaylar, hata yönetimi, arayüzler ve rastgele sıralama gibi konuları listeler.

Özel olayların tur tamamlanmasını algılama ve e-posta gibi işlevleri tetikleme amacıyla nasıl kullanılabileceğini açıklar.

Gereksinimleri Bozmayan Bonus Fikirler

Tim, kısa mesajlaşmayı gelecekteki bir iyileştirme olarak tanıtır. Bonus özelliklerin yalnızca temel gereksinimleri değiştirmedikleri veya teslimatı geciktirmedikleri sürece kabul edilebilir olduğunu açıklar.

Bu, genel planlama sırasında tanımlanan kurallara saygı göstermenin önemini pekiştirir.

Özet ve Sonraki Adımlar

Tim, videosunu tamamlayarak süreci özetler: paydaş soruları gereksinimlere, gereksinimler genel tasarıma, ve genel tasarım anahtar kavramlara yol açar. Bir sonraki derste veri tasarımına odaklanacağımızı ve bilgilerin nasıl birbirine uyacağını göstereceğini açıklar.

Bu ders, dikkatlice yapılan genel planlamanın geliştiricilerin kod yazılmadan önce yapılandırılmış, esnek ve sürdürülebilir uygulamalar oluşturmasına nasıl yardımcı olduğunu gösterir.