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.
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? Bir monolitin geliştiği, bir istemci sunucusu sistemi, eşler arası bir çözüm, dağıtılmış hizmete dayalı bir uygulama veya başka bir şey olan bir uygulama her zaman aynı kalır, yani verilerin depolanması. 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 bir yazılım yazarsanız, kitap envanterde dahil edildiğinde ve kitap her kitap için her kitap için bir veri kaydı oluşturulması ve kitabın her bir ödünç alındığında, genişletilip döndürüldüğünde ve nihayetinde, kitap belirli bir noktada bu kadar uygunsa elimine edildiğinde büyük olasılıkla. 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ü hepimiz erken yaştan itibaren başardık – yapmış olsanız da çalıştığınızdan bağımsız olarak, bir üniversitede mi yoksa bir üniversitede mi yoksa hangi programlama dilini büyüdüğünüze: verileri tam olarak saklamayı, aynı zamanda veri kaydı oluşturmak ve nihayet belirli bir noktada ortadan kalkmayı öğrendiğiniz olasılık.
Verileri yönetmenin bu yolu için teknik bir terim de vardır, yani “Crud”: Bu “Oluştur”, “Okuma”, “Güncelleme” ve “Sil” veya verilere bir veritabanında erişebileceğimiz dört fiildir. 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 bir kez böyle bir senaryo yaşadığımdan çok eminim, yani: Genellikle ortadan kaldırıyor 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 ve 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. Eliminates, veritabanının dilinde bu sürece en yakın olan kelimedir, ancak örneğin, birisi bir kitap çalırsa, o zaman aynı zamanda bir eleme (veya daha kesin olarak bir güncelleme) olacak teknik bir bakış açısından da elendi – ancak tamamen iki farklı süreç vardır.
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 aslında banal 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, böylece 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 bir şekilde aynı konuşur, ancak kimse ilgili muadili gerçekten anlamıyor.
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? Bir monolitin geliştiği, bir istemci sunucusu sistemi, eşler arası bir çözüm, dağıtılmış hizmete dayalı bir uygulama veya başka bir şey olan bir uygulama her zaman aynı kalır, yani verilerin depolanması. 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 bir yazılım yazarsanız, kitap envanterde dahil edildiğinde ve kitap her kitap için her kitap için bir veri kaydı oluşturulması ve kitabın her bir ödünç alındığında, genişletilip döndürüldüğünde ve nihayetinde, kitap belirli bir noktada bu kadar uygunsa elimine edildiğinde büyük olasılıkla. 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ü hepimiz erken yaştan itibaren başardık – yapmış olsanız da çalıştığınızdan bağımsız olarak, bir üniversitede mi yoksa bir üniversitede mi yoksa hangi programlama dilini büyüdüğünüze: verileri tam olarak saklamayı, aynı zamanda veri kaydı oluşturmak ve nihayet belirli bir noktada ortadan kalkmayı öğrendiğiniz olasılık.
Verileri yönetmenin bu yolu için teknik bir terim de vardır, yani “Crud”: Bu “Oluştur”, “Okuma”, “Güncelleme” ve “Sil” veya verilere bir veritabanında erişebileceğimiz dört fiildir. 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 bir kez böyle bir senaryo yaşadığımdan çok eminim, yani: Genellikle ortadan kaldırıyor 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 ve 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. Eliminates, veritabanının dilinde bu sürece en yakın olan kelimedir, ancak örneğin, birisi bir kitap çalırsa, o zaman aynı zamanda bir eleme (veya daha kesin olarak bir güncelleme) olacak teknik bir bakış açısından da elendi – ancak tamamen iki farklı süreç vardır.
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 aslında banal 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, böylece 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 bir şekilde aynı konuşur, ancak kimse ilgili muadili gerçekten anlamıyor.