- Konu sahibi
- #1
Java için doğru planlama; önce hedefi ve çalışma ortamını netleştirip ardından gereksinimleri küçük parçalara ayırmak, mimariyi belirlemek, uygulanabilir görevler oluşturmak ve her aşamayı çalışan bir çıktı ile doğrulamaktır. İyi bir plan, yalnızca hangi sınıfların yazılacağını değil, uygulamanın ne yapacağını, hangi koşullarda başarılı sayılacağını ve değişikliklerin nasıl kontrol edileceğini de açıklar.
İlk olarak projenin neyi çözeceğini tek veya birkaç cümleyle yazın. Örneğin varsayımsal bir Java uygulamasının amacı, "kullanıcıların görev ekleyip tamamlandı olarak işaretleyebileceği basit bir görev yönetimi uygulaması" olabilir. Bu tanım belirsiz kaldığında proje; kullanıcı girişi, bildirim, raporlama ve mobil uygulama gibi birbirinden farklı alanlara kontrolsüz biçimde genişler.
Ardından hedef kullanıcıyı, çalışacağı ortamı ve ilk sürümde bulunması gereken işlevleri belirleyin. Java ile geliştirilen masaüstü, web, sunucu veya Android projelerinin gereksinimleri aynı değildir. Android hedefleniyorsa cihaz ekranı, yaşam döngüsü ve uygulama izinleri; sunucu uygulamasında ise API, veritabanı, eşzamanlılık ve gözlemlenebilirlik daha erken planlanmalıdır.
İlk sürüm için gerekli olmayan özellikleri ayrıca yazın. Bu liste, planın dışında bırakılan işleri görünür kılar ve geliştirme sırasında her yeni fikrin hemen projeye eklenmesini önler.
"Görev uygulamasını geliştir" gibi bir madde planlama için fazla büyüktür. Bunun yerine işi, tamamlandığı kontrol edilebilecek parçalara bölün:
Küçük bir uygulamada bile sorumlulukları ayırmak, kod büyüdüğünde değişiklik yapmayı kolaylaştırır. Sınıfların her şeyi üstlenmesi yerine veri modeli, iş kuralları ve dış sistemlerle iletişim ayrı tutulmalıdır. Yaygın bir yaklaşım şöyledir:
Java sürümünü, yapı aracını ve ek kütüphaneleri yalnızca popüler oldukları için seçmeyin. Her seçimin projedeki bir ihtiyaca karşılık gelmesi gerekir. Örneğin bir sunucu uygulamasında HTTP API, kalıcı veri ve otomatik test gerekiyorsa bu gereksinimleri karşılayan araçlar değerlendirilebilir. Ancak kullanılmayacak kütüphaneleri baştan eklemek, bağımlılık güncellemelerini ve güvenlik takibini gereksiz yere artırır.
Planlama sırasında şu bilgileri tek bir yerde kaydetmek yararlıdır:
Bu kararları birer varsayım olarak yazın. Örneğin "veri hacmi küçük olduğu için ilk sürümde dosya tabanlı saklama kullanılacak" denebilir. Daha sonra veri hacmi veya sorgu ihtiyacı artarsa bu varsayım yeniden değerlendirilir. Böylece ilk kararlar değişmez kurallar gibi kodun içine gömülmez.
En doğru sıra, tüm sınıfları önce yazıp en son çalıştırmak değildir. Önce projenin en küçük uçtan uca akışını çalıştırın. Görev uygulaması örneğinde bu akış; bir görevi oluşturmak, kaydetmek, listelemek ve tamamlandı durumuna geçirmek olabilir. Bu akış basit olsa bile model, iş kuralları, veri erişimi ve giriş katmanı arasındaki uyumu erken gösterir.
Her adımda şu döngüyü kullanın:
Plan, geliştirme başladıktan sonra sabit bir belge olarak kalmamalıdır. Bir görevin beklenenden büyük olduğu anlaşılırsa onu daha küçük parçalara ayırın. Bir teknoloji seçimi yeni bir bağımlılık veya bakım yükü getiriyorsa kararın nedenini yeniden değerlendirin. Gereksinim değiştiğinde önce hangi iş kuralının etkilendiğini, sonra hangi sınıfların, testlerin ve veri yapılarının güncelleneceğini belirleyin.
Bir görevin başarılı görünmesi yalnızca kodun derlenmesine bağlı değildir. Sonucu değerlendirirken şu ayrımı yapın: Derleme hatasının olmaması sözdizimi ve tür sorunlarının çözüldüğünü gösterir; testlerin geçmesi tanımlanmış davranışların doğrulandığını gösterir; gerçek ortama yakın deneme ise yapılandırma, veri erişimi ve çalışma zamanı sorunlarını ortaya çıkarabilir. Bu sonuçlardan birini diğerinin kanıtı gibi yorumlamayın.
İlk sürümün kapsamı tamamlandığında planı; gerçekleştirilen işler, ertelenen işler, bilinen sınırlamalar ve sonraki sürüm için gerekli adımlar olarak güncelleyin. Böylece Java projesi, belirsiz bir özellik listesinden izlenebilir ve doğrulanabilir bir geliştirme planına dönüşür.
Planlamaya başlamadan önce hedefi sınırlandırın
İlk olarak projenin neyi çözeceğini tek veya birkaç cümleyle yazın. Örneğin varsayımsal bir Java uygulamasının amacı, "kullanıcıların görev ekleyip tamamlandı olarak işaretleyebileceği basit bir görev yönetimi uygulaması" olabilir. Bu tanım belirsiz kaldığında proje; kullanıcı girişi, bildirim, raporlama ve mobil uygulama gibi birbirinden farklı alanlara kontrolsüz biçimde genişler.
Ardından hedef kullanıcıyı, çalışacağı ortamı ve ilk sürümde bulunması gereken işlevleri belirleyin. Java ile geliştirilen masaüstü, web, sunucu veya Android projelerinin gereksinimleri aynı değildir. Android hedefleniyorsa cihaz ekranı, yaşam döngüsü ve uygulama izinleri; sunucu uygulamasında ise API, veritabanı, eşzamanlılık ve gözlemlenebilirlik daha erken planlanmalıdır.
İlk sürüm için gerekli olmayan özellikleri ayrıca yazın. Bu liste, planın dışında bırakılan işleri görünür kılar ve geliştirme sırasında her yeni fikrin hemen projeye eklenmesini önler.
Gereksinimleri ölçülebilir görevlere ayırın
"Görev uygulamasını geliştir" gibi bir madde planlama için fazla büyüktür. Bunun yerine işi, tamamlandığı kontrol edilebilecek parçalara bölün:
- Görev verisini temsil edecek modeli oluşturun.
- Yeni görev ekleme işlemini tanımlayın.
- Görevleri listeleme ve tamamlanma durumunu değiştirme işlemlerini ekleyin.
- Verilerin uygulama kapanıp açıldığında korunacağı yöntemi belirleyin.
- Geçersiz veya eksik girdiler için doğrulama kuralları yazın.
- Her temel işlem için birim testleri hazırlayın.
Java projesinin yapısını erken belirleyin
Küçük bir uygulamada bile sorumlulukları ayırmak, kod büyüdüğünde değişiklik yapmayı kolaylaştırır. Sınıfların her şeyi üstlenmesi yerine veri modeli, iş kuralları ve dış sistemlerle iletişim ayrı tutulmalıdır. Yaygın bir yaklaşım şöyledir:
- Model: Uygulamanın kullandığı veriyi temsil eder.
- Servis: İş kurallarını ve işlem akışını yürütür.
- Repository veya veri erişim katmanı: Dosya, veritabanı ya da başka bir kaynaktan veri okur ve yazar.
- Controller, arayüz veya giriş katmanı: Kullanıcıdan ya da istemciden gelen isteği alır ve sonucu iletir.
Teknoloji seçimini gereksinime bağlayın
Java sürümünü, yapı aracını ve ek kütüphaneleri yalnızca popüler oldukları için seçmeyin. Her seçimin projedeki bir ihtiyaca karşılık gelmesi gerekir. Örneğin bir sunucu uygulamasında HTTP API, kalıcı veri ve otomatik test gerekiyorsa bu gereksinimleri karşılayan araçlar değerlendirilebilir. Ancak kullanılmayacak kütüphaneleri baştan eklemek, bağımlılık güncellemelerini ve güvenlik takibini gereksiz yere artırır.
Planlama sırasında şu bilgileri tek bir yerde kaydetmek yararlıdır:
| Planlanan unsur | Karar ölçütü |
|---|---|
| Java sürümü | Çalışacağı ortam, ekip desteği ve projenin uyumluluk ihtiyacı |
| Yapı aracı | Bağımlılık yönetimi, test çalıştırma ve otomasyon gereksinimi |
| Veri saklama | Verinin kalıcılığı, sorgu ihtiyacı ve beklenen veri hacmi |
| Mimari | Uygulamanın boyutu, değişiklik sıklığı ve test edilebilirlik |
| Test yaklaşımı | Kritik iş kurallarının nasıl doğrulanacağı |
Geliştirme sırasını çalışan çıktıya göre kurun
En doğru sıra, tüm sınıfları önce yazıp en son çalıştırmak değildir. Önce projenin en küçük uçtan uca akışını çalıştırın. Görev uygulaması örneğinde bu akış; bir görevi oluşturmak, kaydetmek, listelemek ve tamamlandı durumuna geçirmek olabilir. Bu akış basit olsa bile model, iş kuralları, veri erişimi ve giriş katmanı arasındaki uyumu erken gösterir.
Her adımda şu döngüyü kullanın:
- Küçük bir işlev seçin.
- Beklenen girdiyi ve çıktıyı yazın.
- Kodu mümkün olan en küçük kapsamda geliştirin.
- Birim veya bütünleşme testiyle davranışı doğrulayın.
- Kod biçimini, hata yönetimini ve isimlendirmeyi gözden geçirin.
- Çalışan sonucu kaydedip bir sonraki işlevi planlayın.
addTask("Raporu hazırla") çağrısının yeni bir görev döndürmesi bekleniyorsa testte başlığın korunması ve görevin başlangıçta tamamlanmamış olması kontrol edilebilir. Testin geçmesi, yalnızca bu davranışın koşulları sağlandığında doğru olduğunu gösterir; uygulamanın performansını, güvenliğini veya gerçek veritabanı ortamındaki davranışını tek başına kanıtlamaz.Planı değişikliklere göre güncelleyin
Plan, geliştirme başladıktan sonra sabit bir belge olarak kalmamalıdır. Bir görevin beklenenden büyük olduğu anlaşılırsa onu daha küçük parçalara ayırın. Bir teknoloji seçimi yeni bir bağımlılık veya bakım yükü getiriyorsa kararın nedenini yeniden değerlendirin. Gereksinim değiştiğinde önce hangi iş kuralının etkilendiğini, sonra hangi sınıfların, testlerin ve veri yapılarının güncelleneceğini belirleyin.
Bir görevin başarılı görünmesi yalnızca kodun derlenmesine bağlı değildir. Sonucu değerlendirirken şu ayrımı yapın: Derleme hatasının olmaması sözdizimi ve tür sorunlarının çözüldüğünü gösterir; testlerin geçmesi tanımlanmış davranışların doğrulandığını gösterir; gerçek ortama yakın deneme ise yapılandırma, veri erişimi ve çalışma zamanı sorunlarını ortaya çıkarabilir. Bu sonuçlardan birini diğerinin kanıtı gibi yorumlamayın.
İlk sürümün kapsamı tamamlandığında planı; gerçekleştirilen işler, ertelenen işler, bilinen sınırlamalar ve sonraki sürüm için gerekli adımlar olarak güncelleyin. Böylece Java projesi, belirsiz bir özellik listesinden izlenebilir ve doğrulanabilir bir geliştirme planına dönüşür.
