Biliyor musun? Yazılım geliştirirler (bir müşteri veya dahili uzman departmanı için ne olursa olsun) ve yaptıkları anda, ilk değişiklik ve adaptasyon talepleri gelir: yeni işlevler, daha karmaşık analizler, daha fazla rapor vb. Ve çoğu zaman doğru veriler vardır veya kod ayarlamaları olması gerekenden daha karmaşık ve daha belirgindir. Ve bu hayal kırıklığına yol açar: sizinle ve ayrıca kullanıcılarınızla.
Duyuru
Golo Roden, yerel web GmbH'nin kurucusu ve CTO'sudur. Olaylara ve hizmetlere dayalı olarak dağıtılmış mimarilere özellikle dikkat ederek web ve bulut uygulamalarının ve arıların anlayışı ve geliştirilmesi ile ilgilidir. Yol gösterici ilkesi, yazılımın gelişiminin kendi başına bir son olmaması, ancak her zaman aşağıda bir profesyonellik izlemesi gerektiğidir.
Ya yazılım bu tür değişiklikler ve uzantılar çok daha kolay ve daha esnek olacak şekilde geliştirilebiliyorsa? Tam olarak bugünkü şey bu: bakalım çünkü bu zorluklar için birçok sistem yapılmaz ve onu nasıl daha iyi çözebiliriz. Ve eğer yazılımın geliştirilmesinde daha esnek ve verimli olmak istiyorsanız, tam olarak buradasınız.
Verilerle Nasıl Çalışırız
Sorun nedir? Mimarlık, bir monolit gelişiyor, bir istemci sunucusu sistemi, eşler arası bir çözüm, dağıtılmış hizmete dayalı bir uygulama veya başka bir şey-her zaman aynı kalır, yani veri depolama anlamına gelir. Belki şimdi bunun doğru olmayacağını cevaplarsınız, çünkü en azından sadece ilişkisel veritabanları değil, aynı zamanda Databasenna veya Dosya depolama ve bu ve bu, ama bir şeyin ortak bir yanı vardır: her zaman statükoyu depolarlar.
Önerilen editoryal içerik
Rızanızla, burada harici bir YouTube videosu (Google Ireland Limited) burada davet edilir.
YouTube videosu her zaman yüklenir
YouTube videosu artık yüklüyor
Etkinlik Kaynak Kullanımı-İhtiyacınız Olduğunuz Tek Video // Almanca
Örneğin, kitapları ödünç alabileceğiniz, genişletebileceğiniz ve iade edebileceğiniz bir kütüphane için yazılım yazarsanız, kitap envanterde dahil edildiğinde ve bu veri kaydının her şey güncellendiğinde her kitap için bir veri kaydı oluşturulması çok muhtemeldir. Kitap ödünç alınır, genişletilir veya iade edilir ve nihayetinde, kitap stoktan kaldırıldığı belirli bir noktada püskü. Ve bu çok mantıklı ve açık görünüyor, genellikle bunun gerçekten yararlı olup olmadığını sormaz.
Çiğ …
Ama neden bu kadar mantıklı ve açık görünüyor? Peki, çok basit: çünkü erken yaşlardan itibaren – bir çıraklık yapmış olsanız da çalıştığınızdan bağımsız olarak, uygulamalı bir üniversitede veya bir üniversitede veya hangi programlama diliyle büyüdüğünüze bakılmaksızın: verileri tam olarak bu şekilde kaydetmeyi öğrendik, yani gerekirse, gerekirse veri kaydı oluşturmak ve bir noktada bunları ortadan kaldırmak için neredeyse her zaman verilir.
Verileri yönetmenin bu yolu için, teknik bir terim de vardır, yani “crud”: “yaratmak”, “yasalar”, “güncelleme” ve “ortadan kaldırma”, yani yükselttiğimiz dört fiil Kendimiz bir veritabanı verileri erişebilir. Ve bu aslında PostgreSQL veya Microsoft SQL Server gibi ilişkisel bir veritabanı kullanıyorsanız veya MongoDB veya Redis gibi bir veritabanı ile çalışıyorsanız, her yerde bulunur. Ve tam olarak bu demek istediğim: Verileri saklama ve verileri yönetme şekli her zaman aynıdır.
… ve onun sorunları
Başlangıçta, bu kötü görünmüyor, çünkü onlarca yıldır sorunsuz çalıştı. Ve veriler artık oluşturuluyor, değiştirildi ve ortadan kaldırıldı. Bu evrensel bir ilkedir. Ancak: Işık olduğu yerde, her zaman gölge vardır. Ve elbette bu ham yaklaşımla iyi çalışmayan yönler var. En azından böyle bir senaryo yaşadığımdan çok eminim, yani genellikle iyi bir fikir değil.
Çünkü bir şey ortadan kaldırılırsa, daha sonra – sürpriz! – mesafe. Ancak bu genellikle istenmeyendir, çünkü belki de kullanıcı sadece tıkladı ve yok olmayı iptal etmek istiyor. Sorun sadece: Veriler zaten kaybolmuşsa, geri yüklenmeyin. Ne yapalım? Eh, ortadan kaldırmaz, bir IsDeleted-Flag, bu nedenle bir güncellemeyi ortadan kaldırmak yerine ve bu bayrağı giyer true.
Bu bir yandan iptal edilebilir ve diğer yandan, kalan uygulamada bu işaretli veri kayıtları kolayca göz ardı edilebilir, bu yüzden aslında ortadan kaldırılmış gibi görünüyor. Bu, teknik olarak teknik açıdan bir eliminasyona karşılık gelen bir güncelleme gerçekleştirdiğimiz anlamına gelir.
Teknik Düşünce Vs. teknisyen
Gerçekte, bu tamamen doğru değildir, çünkü teknik açıdan bir kitabın “eliminasyonu” değil, bir kitabın envanterden kaldırılmasıdır. Elimine edici, veritabanının dilinde bu sürece en yakın olan kelimedir, ancak örneğin, birisi bir kitap çalırsa, aynı zamanda bir eleme (veya daha fazlası da olacak teknik bir bakış açısından da ortadan kaldırılmalıdır. tam olarak bir güncelleme) – ancak bunlar tamamen farklı iki işlemdir.
Bu zaten üç seviyemiz olduğu anlamına gelir: bir kitabın cüzdandan çıkarıldığı teknik olan IsDeleted-Bürün ortasında bulunan ve aslında teknik niyeti ifade eden üçüncü bir seviye, çünkü başlangıçta bir eleme yapmak istedik.
VE? Seni zaten karıştırmayı başardım mı?
Yanlış anlamalar
Bu durumda: Tebrikler! Bu noktada bunun gerçekte önemsiz bir süreç için oldukça karmaşık olduğunu düşünüyorsanız, iyi bir şirkettesiniz, çünkü birçok geliştirici aynıdır: önemsiz bir örnek için üç farklı dilsel seviye oluşturmayı başardık, bu nedenle, bu yüzden Bu süreçler hakkında her konuştuğumuzda, en kötü durumda iki kez değiştirmeliyiz. Yanlış anlamalar açıkça kaçınılmazdır.
Bunu gerçekten büyük ve karmaşık bir uygulamada büyük ölçekte hayal edin. Dolayısıyla birisi uzmanlaşmış bölümden gelir ve belirli bir sürecin genişletilmesi ve bu kişinin ne anlama geldiğini düşündüğünü açıklar, çünkü teknik dile aşina değildir ve düşünürler:
“Ah, kesinlikle bir elemeyi yönettiğimiz yer!”
Öyleyse veritabanını yöneten ve size söylenirken başka bir yıldızdan geliyormuş gibi görülen biriyle konuşun:
“Burada bir eleme yapmıyoruz, sadece bir güncelleme yapıyoruz.”
Her şeyi bir kenara bırakmak ve şu anda kodda nerede olduğunu, nedeni, neden, neden ve nasıl ve nerede etkilediğini açıklığa kavuşturmak çok büyük bir zevk var. Yanlış anlamalar neredeyse kaçınılmazdır, çünkü herkes gerçekten aynı şeyi anlar, ancak kimse ilgili muadili gerçekten anlamaz.
Duyuru
Golo Roden, yerel web GmbH'nin kurucusu ve CTO'sudur. Olaylara ve hizmetlere dayalı olarak dağıtılmış mimarilere özellikle dikkat ederek web ve bulut uygulamalarının ve arıların anlayışı ve geliştirilmesi ile ilgilidir. Yol gösterici ilkesi, yazılımın gelişiminin kendi başına bir son olmaması, ancak her zaman aşağıda bir profesyonellik izlemesi gerektiğidir.
Ya yazılım bu tür değişiklikler ve uzantılar çok daha kolay ve daha esnek olacak şekilde geliştirilebiliyorsa? Tam olarak bugünkü şey bu: bakalım çünkü bu zorluklar için birçok sistem yapılmaz ve onu nasıl daha iyi çözebiliriz. Ve eğer yazılımın geliştirilmesinde daha esnek ve verimli olmak istiyorsanız, tam olarak buradasınız.
Verilerle Nasıl Çalışırız
Sorun nedir? Mimarlık, bir monolit gelişiyor, bir istemci sunucusu sistemi, eşler arası bir çözüm, dağıtılmış hizmete dayalı bir uygulama veya başka bir şey-her zaman aynı kalır, yani veri depolama anlamına gelir. Belki şimdi bunun doğru olmayacağını cevaplarsınız, çünkü en azından sadece ilişkisel veritabanları değil, aynı zamanda Databasenna veya Dosya depolama ve bu ve bu, ama bir şeyin ortak bir yanı vardır: her zaman statükoyu depolarlar.
Önerilen editoryal içerik
Rızanızla, burada harici bir YouTube videosu (Google Ireland Limited) burada davet edilir.
YouTube videosu her zaman yüklenir
YouTube videosu artık yüklüyor
Etkinlik Kaynak Kullanımı-İhtiyacınız Olduğunuz Tek Video // Almanca
Örneğin, kitapları ödünç alabileceğiniz, genişletebileceğiniz ve iade edebileceğiniz bir kütüphane için yazılım yazarsanız, kitap envanterde dahil edildiğinde ve bu veri kaydının her şey güncellendiğinde her kitap için bir veri kaydı oluşturulması çok muhtemeldir. Kitap ödünç alınır, genişletilir veya iade edilir ve nihayetinde, kitap stoktan kaldırıldığı belirli bir noktada püskü. Ve bu çok mantıklı ve açık görünüyor, genellikle bunun gerçekten yararlı olup olmadığını sormaz.
Çiğ …
Ama neden bu kadar mantıklı ve açık görünüyor? Peki, çok basit: çünkü erken yaşlardan itibaren – bir çıraklık yapmış olsanız da çalıştığınızdan bağımsız olarak, uygulamalı bir üniversitede veya bir üniversitede veya hangi programlama diliyle büyüdüğünüze bakılmaksızın: verileri tam olarak bu şekilde kaydetmeyi öğrendik, yani gerekirse, gerekirse veri kaydı oluşturmak ve bir noktada bunları ortadan kaldırmak için neredeyse her zaman verilir.
Verileri yönetmenin bu yolu için, teknik bir terim de vardır, yani “crud”: “yaratmak”, “yasalar”, “güncelleme” ve “ortadan kaldırma”, yani yükselttiğimiz dört fiil Kendimiz bir veritabanı verileri erişebilir. Ve bu aslında PostgreSQL veya Microsoft SQL Server gibi ilişkisel bir veritabanı kullanıyorsanız veya MongoDB veya Redis gibi bir veritabanı ile çalışıyorsanız, her yerde bulunur. Ve tam olarak bu demek istediğim: Verileri saklama ve verileri yönetme şekli her zaman aynıdır.
… ve onun sorunları
Başlangıçta, bu kötü görünmüyor, çünkü onlarca yıldır sorunsuz çalıştı. Ve veriler artık oluşturuluyor, değiştirildi ve ortadan kaldırıldı. Bu evrensel bir ilkedir. Ancak: Işık olduğu yerde, her zaman gölge vardır. Ve elbette bu ham yaklaşımla iyi çalışmayan yönler var. En azından böyle bir senaryo yaşadığımdan çok eminim, yani genellikle iyi bir fikir değil.
Çünkü bir şey ortadan kaldırılırsa, daha sonra – sürpriz! – mesafe. Ancak bu genellikle istenmeyendir, çünkü belki de kullanıcı sadece tıkladı ve yok olmayı iptal etmek istiyor. Sorun sadece: Veriler zaten kaybolmuşsa, geri yüklenmeyin. Ne yapalım? Eh, ortadan kaldırmaz, bir IsDeleted-Flag, bu nedenle bir güncellemeyi ortadan kaldırmak yerine ve bu bayrağı giyer true.
Bu bir yandan iptal edilebilir ve diğer yandan, kalan uygulamada bu işaretli veri kayıtları kolayca göz ardı edilebilir, bu yüzden aslında ortadan kaldırılmış gibi görünüyor. Bu, teknik olarak teknik açıdan bir eliminasyona karşılık gelen bir güncelleme gerçekleştirdiğimiz anlamına gelir.
Teknik Düşünce Vs. teknisyen
Gerçekte, bu tamamen doğru değildir, çünkü teknik açıdan bir kitabın “eliminasyonu” değil, bir kitabın envanterden kaldırılmasıdır. Elimine edici, veritabanının dilinde bu sürece en yakın olan kelimedir, ancak örneğin, birisi bir kitap çalırsa, aynı zamanda bir eleme (veya daha fazlası da olacak teknik bir bakış açısından da ortadan kaldırılmalıdır. tam olarak bir güncelleme) – ancak bunlar tamamen farklı iki işlemdir.
Bu zaten üç seviyemiz olduğu anlamına gelir: bir kitabın cüzdandan çıkarıldığı teknik olan IsDeleted-Bürün ortasında bulunan ve aslında teknik niyeti ifade eden üçüncü bir seviye, çünkü başlangıçta bir eleme yapmak istedik.
VE? Seni zaten karıştırmayı başardım mı?
Yanlış anlamalar
Bu durumda: Tebrikler! Bu noktada bunun gerçekte önemsiz bir süreç için oldukça karmaşık olduğunu düşünüyorsanız, iyi bir şirkettesiniz, çünkü birçok geliştirici aynıdır: önemsiz bir örnek için üç farklı dilsel seviye oluşturmayı başardık, bu nedenle, bu yüzden Bu süreçler hakkında her konuştuğumuzda, en kötü durumda iki kez değiştirmeliyiz. Yanlış anlamalar açıkça kaçınılmazdır.
Bunu gerçekten büyük ve karmaşık bir uygulamada büyük ölçekte hayal edin. Dolayısıyla birisi uzmanlaşmış bölümden gelir ve belirli bir sürecin genişletilmesi ve bu kişinin ne anlama geldiğini düşündüğünü açıklar, çünkü teknik dile aşina değildir ve düşünürler:
“Ah, kesinlikle bir elemeyi yönettiğimiz yer!”
Öyleyse veritabanını yöneten ve size söylenirken başka bir yıldızdan geliyormuş gibi görülen biriyle konuşun:
“Burada bir eleme yapmıyoruz, sadece bir güncelleme yapıyoruz.”
Her şeyi bir kenara bırakmak ve şu anda kodda nerede olduğunu, nedeni, neden, neden ve nasıl ve nerede etkilediğini açıklığa kavuşturmak çok büyük bir zevk var. Yanlış anlamalar neredeyse kaçınılmazdır, çünkü herkes gerçekten aynı şeyi anlar, ancak kimse ilgili muadili gerçekten anlamaz.