Uygulama Doğru Planlama Yöntemi: Tim Corey’nin Ders 01'den Bilgiler

İçeriği ve Dersin Hedefini Belirleme

Videonun en başında, Tim Corey Birinci Ders'i tanıtır ve bu dersin başlangıç planlaması hakkında olduğunu açıklar. Senaryoyu tanımlamanın ve herhangi bir geliştirmeden önce uygulamanın ne yapması gerektiğini anlamaya başlamanın hedef olduğunu açıkça belirtir.

Tim bu dersin temel olduğunu açıklar. Projede ardından gelen her şey için bir temel oluşturur. Kodlamaya girmek yerine, izleyicilerin çalışmayı nasıl organize edeceklerini, karmaşıklığı nasıl yöneteceklerini ve doğru bir şekilde planlayarak nasıl odaklanacaklarını anlamalarını ister.

Planlamadan Önce Senaryoyu Anlama

0:53'te, Tim tüm projeyi yönlendirecek senaryoyu tanıtır. Bir arkadaş bir turnuva takipçisi ister—oyunları yönetebilen, eşleşmeleri belirleyebilen ve tek elemeli bir tabloda kazananları takip edebilen bir uygulama.

Tim, bu senaryonun NCAA March Madness turnuvasına benzer olduğunu açıklar. Sistem, oyunculara kiminle oynayacaklarını otomatik olarak söylemeli, sonuçları takip etmeli ve sonunda kazananı belirlemeli.

Bu tanımın tek başına bir uygulama inşa etmek için yeterli olmadığını vurgular ancak planlamaya başlamak için yeterlidir. Pek çok geliştiricinin, her şeyi kısa bir tanıma dayanarak anladıklarını varsayarak hata yaptığını belirtir.

Gereksinimler Kodlamadan Önce Neden Gelir

1:33'te Tim, herhangi bir uygulamayı planlamadaki ilk gerçek adımın gereksinimleri tanımlamak olduğunu açıklar. Uygulama fikri açık görünüyorsa, kodlamaya başlamanın yaygın bir yeni başlayan hatası olduğuna karşı uyarır.

Uygulamanın basit görünmesine rağmen, planlamadan kodlamaya dalmak, daha sonra hatalara, yeniden çalışmaya ve kafa karışıklığına yol açar. Bir kaç ders boyunca kodlamayı kasten geciktirir çünkü güçlü bir temel geliştirmeyi daha kolay ve daha verimli hale getirir.

Bu yaklaşım, iyi bir proje yönetiminin nasıl çalıştığını yansıtır—işi yönetilebilir ve organize etmek için net bir şekilde tanımlamak.

Uygulamayı Başlangıç Görevlerine ve Sorumluluklarına Bölmek

2:06'da Tim, zaten bilinenleri listelemeye başlar. Sistem şunları yapmak zorunda olduğunu açıklar:

• Oynanan oyunları takip et

• Her oyunun kazananını takip et

• Bir sonraki tura kimin geçeceğini belirle

Dört oyuncunun örneğini kullanır ve kazananların nasıl ilerlediğini açıklar. Bu, uygulamanın iç görevlerini ve mantığını nasıl yönetmesi gerektiğini netleştirir.

Tim daha fazla bilinen gereksinimleri ekler:

• Birden fazla rakibi destekleme

• Bir turnuva planı oluşturma

• Oyunları çizelgeleme

• Bir kayıptan sonra oyuncuları eleme

• Nihai kazananı belirleme

Bu noktalar, uygulamanın temel görev yönetimini oluşturur. Tim, liste kısa olmasına rağmen, onu yazmanın sistemin neyle sorumlu olduğunu netleştirdiğini açıklar.

Soru Sormanın Çekirdek Bir Planlama Becerisi Olmasının Nedenleri

3:32'de, Tim her projenin gizli gereksinimlere sahip olduğunu açıklar. Paydaşlar zorlayıcı değildir—sadece teknik terimlerle düşünmezler.

Tim, planlamanın bir kısmının şu soruları sormak olduğunu açıklar:

• En çok ne önemlidir

• Ne önemli değildir

• Hangi varsayımlar kaçınılmalıdır

Bu, planlamanın koddan çok daha fazla şey haline geldiği, iş organizasyonu, netlik ve iletişimle ilgili hale geldiği yerdir.

Oyuncu Sayısını ve Turnuva Boyutunu Yönetmek

4:15'te, Tim turnuvanın kaç oyuncuya ev sahipliği yapacağını sorar. Bunun sistemin tüm yapısını etkilediğini açıklar.

Sabit ve değişken oyuncu sayısını tartışıyor ve iki'nin kuvveti olmayan sayıların neden karmaşık komplikasyonlar yarattığını açıklıyor. Bu, zayıf planlarının herhangi bir sistemde zamanlama ve iş akışını nasıl kırabileceğine benzer.

4:51'de Tim, oyuncu eksikliği olan durumların nasıl ele alınacağını tartışır. Sistem desteklemeli mi veya açıkça önlenmeli mi tartışarak bayraklar fikrini tanıtır.

Eşleşmelerin Sıralanması ve İşin Çizelgelenmesi

6:13'te, Tim eşleşmelerin rastgele mi yoksa sıralı mı olması gerektiğini tartışır. Bu kararın, uygulamanın içsel olarak görevleri nasıl oluşturup zamanladığını etkilediğini açıklar.

Ardından oyun programlamasına geçer, iki olası yaklaşımı açıklayarak:

• Oyuncular istedikleri zaman oynar

• Oyunlar belirli zamanlarda programlanır

Bu kararın, sistemin zamanı, ilerlemeyi ve akışı nasıl yöneteceğini—bir planlama uygulamasının günlük programları ve zaman dilimlemeyi nasıl yönetmesi gerektiğine benzer şekilde—etkilediğini açıklar.

İlerlemeyi ve Oyun Akışını Kontrol Etmek

7:26'da, Tim ilk turlar tamamlanmadan sonra turların oynanıp oynanamayacağını sorar. Bu durumun esneklik sağladığını ancak aynı zamanda karmaşıklık getirdiğini açıklar.

Bu tartışma, kuralların sistemin davranışını nasıl etkilediğini vurgular. Tim, uygulamanın görevleri doğru yönetebilmesi ve geçersiz eylemleri önleyebilmesi için bu kuralların önceden karar verilmiş olması gerektiğini vurgular.

Sonuçları ve Görev Ayrıntılarını Saklamak

8:22'de, Tim sistemin sadece kazananları mı yoksa aynı zamanda skorları mı saklaması gerektiğini sorar. Daha fazla ayrıntı saklamanın değer kazandırdığını ancak aynı zamanda karmaşıklığı da artırdığını açıklar.

Bu daha geniş bir planlama prensibini yansıtır: sisteminizin ne kadar bilgiyi izlemesi gerektiğine erken karar verin, böylece gereksiz yere aşırı yüklenmezsiniz.

Arayüz Hakkında Varsayım Yapmaktan Kaçınmak

8:54'te, Tim diğer bir yeni başlayan hatası hakkında uyarıda bulunur: arka ucu varsaymak.

Şunları sormadan:

• Masaüstü uygulama mı?

• Bir web sitesi mi?

• Bir mobil uygulama mı?

Geliştiriciler tahmin yapmak zorunda kalır. Tim, tahminin yeniden çalışmalara yol açtığını vurgular. Planlama bunu önler.

Veri Depolama, Para ve Raporlama

Saat 9:37'de, Tim veri depolamayı tanıtır. Verinin nerede yaşadığını sormanın, paydaşlarla önemli konuşmaları tetiklediğini açıklar.

Daha sonra şu konuları tartışır:

• Giriş ücretleri

• Ödüller

• Ödemeler

• Sonuçların raporlanması

Bu özellikler hemen gerekli olmayabilir, ancak Tim, bu özelliklerin planlamasının projenin uzun vadeli yönünü şekillendirmeye yardımcı olduğunu açıklar.

Erişim Seviyeleri, Bildirimler ve Ekipler

Saat 12:11'de, Tim sonuçları kimin girebileceğini ve farklı erişim seviyelerinin olup olmadığını tartışır. Bu, kimin hangi görevleri yapabileceğini kontrol etmekle ilgilidir.

Saat 12:51'de, sistemin kullanıcılara yaklaşan oyunlar hakkında bildirim yapması gerekip gerekmediğini sorar, bu sorunun genellikle gelecekteki özellik fikirlerini ortaya çıkardığını açıklar.

Saat 13:42'de, Tim rakiplerin birey mi yoksa takım mı olduğunu sorar. Bu durumun katılımcıların sistemde temsil edilme şeklini etkilediğini açıklar.

Tim'in Son Planlama Tavsiyesi

Saat 15:20'de, Tim önemli bir hatırlatma ile kapanışı yapar: mükemmel olmanız gerekmez. Ancak, başlangıçta mümkün olduğunca fazla bilgi toplamanız gerekir.

İyi planlamanın geliştiricilerin düzenli kalmasına, karmaşıklığı yönetmesine ve güvenle ilerlemesine yardımcı olduğunu açıklar. Amaç, mükemmellik değil, netliktir.

Tim sonunda, bu soruların cevaplarının uygulamanın genel yönünü belirleyeceği İkinci Dersin ön izlemesini sunarak bitirir.

Kapanış Düşünceleri

Ders 01'de, Tim Corey bir uygulamayı planlamanın kod yazmadan önce görevleri, yapıyı ve akışı anlamakla ilgili olduğunu gösterir. Gereksinimleri tanımlayarak ve düşünceli sorular sorarak, geliştiriciler verimli bir geliştirme süreci için kendilerini hazırlarlar, daha az hata yaşarlar ve daha iyi sonuçlar elde ederler. Bu ders, tüm başarılı uygulamalara uygulanacak bir zihniyet oluşturur: önce planlayın, sonra oluşturun.