Çevik gelişimde, veritabanından önce düz dosyada kalıcılık denemeli miyim?

Biri bana, çevik kalkınmada politika ve uygulama mantığının sebat metodu gibi detaylardan daha önemli olması gerektiği için, sebat kararının sonunda alınması gerektiğini söyledi. Bu nedenle, düz dosyalar gibi daha basit bir ısrarla başlamak, bu yöntemin zayıflığının ortaya çıkacağı noktaya gelinceye kadar ve ancak daha sonra, örneğin ilişkisel veritabanı kullanarak ısrarı değiştirdiğimizde iyi bir fikir olabilir.

Bu doğru mu, yoksa kavramı yanlış mı anladım? Bu nasıl çevik ekip genellikle uygulama oluşturuyor mu? Bunun için gerekçeleri nelerdir ve bu yaklaşıma ne zaman katılmamalıyım?

Aktarılan konsept, kesinlikle çevik ve konuyla ilgili bir şeydir, olayları son sorumlu ana itme fikri.

Bununla birlikte , alınan örnek aslında başlamak için tamamen yanlış bir varsayıma dayanmaktadır:

RDBMS kullanmaktan ziyade bir düz dosya veritabanı uygulamanın daha kolay / az işe yaramasıdır. - Genellikle tamamen yanlış

Örnek şöyle olmalı: Kalıcılık katmanı, karar verilinceye kadar, yetersiz olduğu kararına kadar mümkün olan en basit uygulamaya tutulur.

Birçok geliştirme ekibi için bunu yapmak için bir veritabanının kaldırılması, bir veya iki saat meselesidir (ya da ORM ile küçük veritabanı için 15 dakika); çok büyük acı ve sıkıntı çünkü tüm arama ve veri tablosu yapı tipi kodunu elle yazmak zorunda oldukları için, bir veritabanı bir UI'de bir tablo oluşturmak, bir kaç sütun eklemek ve daha sonra bir ORM oluşturmak için basit olabilir. başka ihtiyacın var.

Ayrıca, kalıcılık katmanınızın başlayacağını bilmiyorsanız, düz dosyadan RDBMS'ye geçişi daha sonra yapmaktan daha büyük bir değişiklik yapmak için ekibinizin iyi bildiği ortak bir RDBMS ile başlamak daha uygun bir eylemdir. Bir RDBMS'den diğerine değiştirme. Herhangi bir ortak RDBMS'den diğerlerine dönüştürmek için pek çok araç vardır ve bunlar iyi seyahat edilmiş bir yol olduğu için ipuçları ve benzerleridir. Bir düz dosyadan herhangi bir RDBMS'ye dönüştürmek için çok az araç vardır; buradaki düz dosya, daha önce kendi kitaplıklarınızdan başka bir şey için yazılmamış özel bir formata sahiptir.

Özetle: Kavram doğru ve doğrudur, ancak örnek çok büyük ve çoğu zaman (neredeyse her zaman) yanlış bir varsayıma dayanmaktadır .

Bir DB kullanacağınızı bildiğinizden, düz dosyaları işlemek için kod yazmanın pek bir anlamı yoktur. Bazı salt okunur CSV'leri kullanarak birkaç yinelemeyle karşılaşabilirsiniz ancak hızlı bir şekilde kendinizi atacağınızı bildiğiniz bir kod yazarken bulabilirsiniz.

İlk karmaşıklığı basitleştirmek için yapabileceğiniz bir şey, SQLite gibi bir şey kullanarak (bir dosyada depolanan sunucusuz bir SQL veritabanı sağlayan bir kütüphane). Esnek bir tip sisteme sahip olduğundan, bir şemayı ciddiye almanıza gerek kalmaz, DB'nizi yapılandıracak / bağlanacak ve DB'nizi yeniden oluşturacak bir dosyayı silmek kadar basittir. Ayrıca gerektiğinde sürüm görüntüsündeki kodla birlikte DB görüntüsünü eklemenizi de sağlar.

Bu, kendi içinde bir kavramdan ziyade bir kavramı göstermek için kullanılan bir örnektir.

Kavramı, son sorumlu ana kadar bir mimari karar vermemeniz , ancak daha sonra olmamanızdır . Ancak, gerçekte, çok erken dönemlerde kullanacağınız veri tabanına karar verdiniz. Bu mükemmel olmayabilir, ama bu bir gerçek.

Bu karar verildiğinde, aktif olarak kaçınmazsınız. Bir şeyi mevcut bir veritabanında saklamak, genellikle düz bir dosyada saklamak kadar kolaydır.

Ancak Linux'ta MySql'den Windows'ta SQL Server'a geçmek, düz bir dosyadan Windows'ta SQL Server'a geçmek kadar basit olmayabilir. Gerçek nokta bu. Bu nedenle, nihai çözümle ilgili şüphe olsa da, değişimi hesaba katan en basit seçeneği kullanın. Bir karar verildiğinde, buna bağlı kal.

Neye ısrar ediyorsun?

Çevik bir ekibindeyim ve bir uygulama için neredeyse her şeyi veritabanına saklıyoruz. Dikkat edin, o zaman olmasaydık bu uygulamanın yapması için çok fazla bir şey olmayacaktı - veritabanına bir şeyleri devam ettirmek, varoluş sebebinin büyük bir bölümünü oluşturuyor .

Öyleyse: Neye devam ediyorsunuz ve başvurunuz ne yapıyor? Uygulama verisinin nerede durduğunu gerçekten umursamıyorsa , o zaman karar vermesini sağlayan küçük bir katman yazabilirsiniz (bu karar bir yerde bir yapılandırma dosyasında saklanabilir) ve veritabanı. Uygulamanızı ve verilerinizi değerlendirmeniz ve özel durumunuzda veritabanının sürekliliğine zaman ayırmanın mantıklı olup olmadığına ya da sadece düz dosyaları okuyup / yazmanın ( muhtemelen geliştirme süresi açısından daha hızlı olacak) karar vermeniz gerektiğini düşünüyorum.

Pek çok insan, çevikliğin bu yönünü gelecekteki özellikler için önceden planlama yapmamaları gerektiği anlamında yanlış algılıyor. Hiçbir şey gerçeklerden daha fazla olamaz. Yapmadığınız şey, gelecekteki özelliklerin planlanmasına şimdi müşterilerinize değer kazandırmayı geciktirmektir.

Bunun kalıcılık gibi bir şey için nasıl uygulanacağı, uygulamanıza çok bağlıdır. Mevcut hobi projelerimden biri bir hesap makinası. Sonunda, kullanıcı tanımlı sabitleri ve fonksiyonları saklayabilmek ve programı kapattığımda durumu kaydetmek istiyorum. Bu sebat gerektirir, ama ne biçim alacağını düşünmeye bile başlamadım. Programım kalıcı olmadan çok kullanışlı olacak ve şimdi eklenmesi ilk sürümüme önemli bir gecikme ekleyecektir. Mükemmel olmasını beklerken hiçbir şeyden daha az özellikli çalışan bir hesap makinem olmasını tercih ederim.

Bir başka hobi projem ise video ve fotoğraf renk düzeltmesi için. Yaptığım çalışmaları devam ettiremeden bu uygulama tamamen kullanılamaz olacak ve bunun için gereken kod tüm program boyunca yaygın. En başından doğru alamazsam, değiştirmek o kadar zor olabilir ki, ısrarla başa çıkmak için biraz çaba sarf ettim.

Projelerin çoğu aralarında bir yere düşecek, ancak şimdi fazladan bir çaba göstermeyecek kadar az eklerse gelecek özellikleri planlamak konusunda asla kötü hissetmemelisiniz. Veritabanları karmaşık olabilir, ancak bu karmaşıklığın çoğu sağlam ve iyi test edilmiş bir arayüzün arkasına gizlenmiştir. Uygulamanızda yapmanız gereken iş, bir veritabanı için ücretsiz olarak sunduğu tüm özellikler nedeniyle, bir veritabanı için çok az olabilir. Henüz bir veritabanı sunucusuyla uğraşmak istemiyorsanız, SQLite gibi "karma" seçenekler var.

Bence yanlış değerlere odaklanıyorsun. Çevik, iş değeri odakta. Bazı son kullanıcılara iş değeri sunmak için bir ürün yaratıyorsunuz.

Kalıcılık katmanını geç yaparsanız veya yol boyunca telafi ederseniz, müşteriye iş değeri sağlama stratejinizdir. "Çevik" teriminin kendisinin bir başkasını yapıp yapmamanız gerektiğini belirttiğine inanmıyorum.

Veri depolama stratejisini erteleme konusundaki bakış açısı bu sunumda savunulmaktadır. Robert C. Martin (çevik manifestoların yazarlarından biri) tarafından .

Çok güzel bir sunum, izlemenizi tavsiye ederim.

Ama buna katılmıyorum! En azından bir dereceye kadar.

Kullanıcı hikayesi kalıcı olması gereken verileri içeriyorsa ve aslında herhangi bir sebat uygulanmadıysa, "Tamamlandı" için bir kullanıcı hikayesi arayabileceğinize inanmıyorum.

Ürün sahibi, şimdi yayına girme zamanı olduğuna karar verirse, bunu yapamazsınız. Sürekliliği uygulamaya geçmeden projenin sonuna kadar başlamadıysanız, kalıcılık katmanını uygulamanın ne kadar süreceği konusunda hiçbir bilginiz yok ve bu da büyük bir proje riskidir.

Üzerinde çalıştığım çevik projeler, veri erişim stratejisini ertelemedi. Ancak, yol boyunca değiştirmemize izin verecek şekilde ayrıldı. Ve tüm veritabanı şeması önceden tasarlanmamıştır. Tablolar ve sütunlar, saklanan kullanıcıyı, sonuçta işletme değeri sağlayacak şekilde uygulamak için gereken şekilde oluşturulur.

Yeni bir projeye başlarken ilk olarak hangi soruların cevaplanması gerektiğini görmek iyi bir karar ve tecrübe gerektirir.

Nihai ürün hala bilinmiyorsa, hızlı bir şekilde oluşturma / prototipleme işlemi bunu anlamanıza yardımcı olur ve evet, çevik bir şekilde yineleme yapmak yardımcı olacaktır. Elbette, kalıcılık uygulamasının paydaşlarınıza ilettiğinizden daha uzun süreceği sürecin geç saatlerinde ortaya çıkma gibi riskler ortaya çıkacaktır.

Son ürün iyi biliniyorsa, uygulamanızda ısrarın nasıl işe yarayacağını anlamak, daha erken bilmek daha önemli olabilir. Buradaki risk, geliştirme sürecinde daha sonra ürün spesifikasyonunuzla ilgili sorun bulma.

Düz dosyalar basit değildir!

Depolamaya izin veriyorlar ve hepsi bu. Verilerin yapısı, erişim yolları vb. Tamamen size bağlıdır ve bunu yanlış almanın çeşitli yolları vardır.

Veritabanlarının var olmasının sebeplerinden biri vardır ve bunlardan biri geliştiriciler için işleri basitleştirmektir.

Gelişimimin çoğu, büyük şirketlerdeki büyük sistemler için yapıldı. Başka bir tasarım veya geliştirmeye başlamadan önce her zaman eksiksiz ve iyi düşünülmüş bir veri modeline sahibiz. Bir veri modeli, sorununuzu anlamanıza yardımcı olur ve temiz bir uygulama yapmanızı sağlar.

Unutulmuş veri öğeleri, uyuşmayan veri yapıları ve diğer kabuslar önden bir veri modeli üretilerek önlenebilir.

Gerçek veri tabanı seçiminizi veri modelinin sonuna kadar bırakabilirsiniz. Ancak “kalıcılık” teknolojilerinin çoğu, programlama ve hatta tasarım stilleriyle yakından ilişkilidir. İlişkisel bir veritabanını kodlarsanız ve daha sonra bulutlu bir anahtar değerine geçmeye karar verirseniz, kodunuzun yarısını tamamen yeniden yazmanız gerekir.

Düz dosyalar ile başlarsanız ve ilişkisel bir DB'ye geçerseniz, geliştiricilerin bir piss zayıf veritabanı uygulayarak zamanlarını boşa harcadığı için muhtemelen kodunuzun yarısını atmak zorunda kalırsınız.

Sürekliliği düz bir dosyada veritabanından önce denemeli misiniz?

Evet, denemelisin. Özellikle daha önce hiç denemediyseniz. Nasıl olursa olsun, bir şeyler öğreneceksiniz.