Bağımlılıkları diğer programcılar için son derece açık hale getirmeyi destekleyen bir programlama paradigması var mı?


26

Çeşitli eserleri birbirine bağlayan labirent benzeri bağımlılıkları olan birçok akış ve katman aracılığıyla çoklu sistemler sağlayan bir Veri Ambarı'nda çalışıyorum. Neredeyse her gün böyle durumlarla karşılaşıyorum: Bir şey çalıştırıyorum, işe yaramıyor, bir sürü kod geçiyorum ama saatler sonra anladım ki, şimdi bildiklerimin küçük bir bölümünün süreç haritasını kavramsallaştırmayı başardım Günün ilerleyen saatlerinde gerekli, bu yüzden birine soruyorum ve bana bu diğer akıntının ilk önce çalıştırılması gerektiğini ve burayı kontrol edersem (diğer kodlanmış bağımlılıkların çok büyük bir yığınının görünüşte keyfi bir kısmını belirten) gösterirse, o zaman bunu gördüm. İnanılmaz derecede sinir bozucu.

Ekibe, belki de özyinelemeli kod seviyelerinde, hatta bu verilerin tekrarlayan kod seviyelerinde derine gömülmek yerine, nesneler arasındaki bağımlılıkları daha görünür ve açık hale getirmek için daha fazlasını yaparsak iyi bir fikir olacağını önerebilseydim belki de iyi bilinen, denenmiş ve test edilmiş bir yazılım paradigmasına atıfta bulunarak başka bir akım tarafından doldurulmuş olması gerekir - o zaman işimi ve herkesin işini çok daha basit hale getirebilirim.

Bunun faydalarını ekibime açıklamak biraz zor. Her şeyi olduğu gibi kabul etmeye meyillidirler ve tüm sistemi yeni bir şekilde kavramsallaştırabilmenin faydalarını görme açısından 'büyük düşünmezler' - devasa bir sistemi modelleyebilirseniz gerçekten görmezler. verimli bir şekilde bellek verimsizlikleri, durmadan benzersiz kısıtlamalar ve yinelenen anahtarlar, saçma verilerle karşılaşmayı bırakmanız olasılığını azaltır çünkü orijinal vizyona göre tasarlamanız çok daha kolay ve daha sonra tüm bu sorunlara girmeyeceksiniz Şimdi, geçmişte yaptığımız işlerden alışılmadık olduğunu bildiğim, ancak kaçınılmaz olarak düşündükleri görünen, deneyimliyoruz.

Peki, bağımlılıkları vurgulayan ve aynı zamanda bir ideale uzun süre bağlı kalmayı sağlama amaçlı bir sistemin ortak bir kavramsal modelini destekleyen bir yazılım paradigması bilen var mı? Şu anda devasa bir karmaşaya sahibiz ve çözüm her sprintin “sadece bu şeye, buraya ve buraya ekle” gibi görünüyor ve işlerin gerçekten dağılmaya başlamasıyla ilgilenen tek kişi benim.


2
Bunlar ne tür "çeşitli eserler bağlayan labirent benzeri bağımlılıklar" açıklayabilir misiniz? Maven gibi bir inşa aracıyla çözülebilen bağımlılıklar inşa ediyorlar mı? Girdi bağımlılıkları mı? Bu eserlerden birinin açık ve net olmayan bazı girdilere dayandığı durumlarda girdi bağımlılıkları mı? Veritabanı tabloları arasındaki anahtar bağımlılıklar mı?
SinirliFormsDesigner ile

Sistem PLSQL, Unix bash, OWB vb. Olduğundan her türlü bağımlılık vardır. Bazen veriler belirli bir formatta, belirli bir yerde, belirli bir zamanda, belirli bir modül tarafından istenebilir, ancak koddan uzaktan açıkça anlaşılmaz ve sadece iki şekilde ayırt edilebilir: bir kod dağını geçerek, belki de birkaç gün sürdü, bazı verilerin, bilmediğiniz bir sistemde sınırlayıcı bir noktalı virgül olduğunu fark etmek için, tekrarlanan kod adı verilen 10 katmana gömüldüğünden, ya da birinden tüm soruları isteyerek zaman, her zaman. Bağımsızlığı desteklemez.
Christs_Chin

4
Kelimenin tam anlamıyla hepsi
Miles Rout

3
Küçük teğet: Haskell tembel olduğu için, kod yazarken işlemlerin sırasını etkili bir şekilde belirtmezsiniz. Sadece bağımlılıkları belirlersiniz. C işlevi, A ve B işlevlerinin sonuçlarına bağlıdır. Bu nedenle, A ve B'nin C'den önce çalıştırılması gerekir, ancak A ilk çalıştırıldığında veya B ilk çalıştırıldığında eşit şekilde çalışabilir. Bunun ilginç olduğunu düşündüm.
GlenPeterson

1
Tasarım kalıpları adında bir kitap var (kitap berbat, ama söylediklerinin çoğu iyi, singleton ile ilgili olmayanlar hariç). Bağımlılık yönetimi konusunda çeşitli bölümleri vardır.
ctrl-alt-delor

Yanıtlar:


19

keşfedilebilirlik

Yokluğu birçok kuruluşu rahatsız ediyor. Fred'in tekrar yaptığı bu alet nerede? Git deposunda, elbette. Nerede?

Akla gelen yazılım deseni Model-View-ViewModel'dir. Başlatılmamış olanlara göre, bu model tam bir gizemdir. Eşime, "masanın üstünde yüzen, gizemli bir güçle birbirleriyle konuşan beş alet" olarak açıkladım. Deseni anlayın ve yazılımı anlayın.

Birçok yazılım sistemi mimarisini belgelemekte başarısız olur çünkü kendi kendini açıkladığını ya da koddan doğal olarak çıktığını varsaymaktadır. Öyle değil ve değil. İyi tanımlanmış bir mimari kullanmıyorsanız, yeni insanlar kaybolacak. Belgelenmemişse (veya iyi bilinirse), yeni insanlar kaybolacak. Gaziler de birkaç aydır kodlardan uzaklaştıklarında kaybolurlar.

Makul bir organizasyonel mimari oluşturmak ve onu belgelemek takımın sorumluluğundadır . Bu gibi şeyler içerir

  • Klasör organizasyonu
  • Proje referansları
  • Sınıf dökümantasyonu (ne olduğu, ne olduğu, neden olduğu, nasıl kullanıldığı)
  • Proje, modül, montaj, ne olursa olsun belgeler.

İşlerin düzenli ve keşfedilebilir olması, ekibin tekerleği sürekli olarak yeniden icat etmemesi sorumluluğudur.

Bu arada, "kodun kendi kendini belgelemesi gerektiği" kavramı sadece kısmen doğrudur. Her kod satırını bir yorumla açıklamak zorunda kalmamanız için kodunuzun yeterince açık olması gerektiği doğru olsa da, sınıflar, projeler, montajlar, arabirimler ve benzeri gibi yapay nesneler arasındaki ilişkiler açık değildir ve yine de açıktır. belgelenmesi gerekiyor.


3
Tabii, ama tasarım desenlerine çok fazla eğilen insanlar bu sorunun bir parçası. Belgelenmeden kod yazanlar, başkalarının sadece koda bakarak ne yaptıklarını anlayacağını varsayarsak. Ayrıca, yazılım tasarım kalıpları mimari değildir (çoğunlukla).
Robert Harvey,

1
Fred'in tekrar yaptığı bu alet nerede? Git deposunda, elbette. Nerede? - Kesinlikle! MVC paterni ön uç gelişime çok özgüdür (bence) ve paternler sadece takımdaki herkes onları tanıyorsa faydalıdır, bu yüzden bu problemi sadece herkesin nasıl bulunacağını bilmesi durumunda, sorunu açıkça görülmeyen bağımlılıklardan uzaklaştırır. onlar. Ancak sorun bunun böyle olmadığını varsayıyor. Dolayısıyla, kullanmanız için başka bir öğrenilmiş kavramsal çerçeve gerektirmeyen bağımlılıkları açıklamanın gerçekten açık bir yolunu destekleyen bir şey olduğunu umuyorum.
Christs_Chin

7
Buna "dokümantasyon" denir. Bunun ötesinde, herkesin desteklediği makul bir bağımlılık çerçevesine ihtiyacınız var. Ne yazık ki projenize ekleyebileceğiniz bir boyler şablonu yoktur; Yazılımın organizasyonel yapısı, ekibinizin mantıklı bir mimarinin yardımı ile kendi yarattığı bir şeydir.
Robert Harvey,

5
@RobertHarvey: Son zamanlarda duydum: "Belgelere ihtiyaç duymayan bir kod yazıyoruz". Yanlış. Belgelendirme olmadan kod yazıyorsunuz.
gnasher729

3
Burada iyi şeyler var. Not: Yorum gerektirmeyen kod yazma ile destekleyici belgeler yazma arasında bir fark vardır .
Robbie Dee

10

Bu tür sorunlara yaklaşmanın en iyi yolu aşamalı olarak. Sinirlenmeyin ve geniş kapsamlı mimari değişiklikler önermeyin. Bunlar asla onaylanmayacak ve kod asla iyileşmeyecek. Bu, yapılacak muhtemel geniş, kapsamlı mimari değişiklikleri bile belirleyebileceğinizi varsayar.

Ne olduğunu olasılıkla size sadece çözüldü belirli sorun size yardımcı olacak küçük bir değişiklik belirleyebilir olmasıdır. Belki Yani teklif, vb bazı belgeleri ekleyerek bir arayüz oluşturarak, bir eksik bağımlılık uyaran bir senaryo yazıyor, bazı bağımlılıkları tersini yani yerine daha küçük bir değişiklik. Daha da iyisi, şirket kültürünüze bağlı olarak, asıl görevinizin bir parçası olarak böyle iyileştirmeler yapmanıza tahammül edebilir veya hatta beklemenizi sağlayabilirler.

Bu küçük değişiklikleri yaptığınızda işinizin düzenli bir parçası haline gelir ve örneğinize göre başkalarını da yapmaya teşvik eder, gerçekten zamanla eklenirler. Yapmanıza izin verilmeyen tek büyük değişiklikler hakkında sızlanmaktan çok daha etkili.


2
Artımlı değişiklikler fikrine katılıyorum. Sorun şu ki, bazı örgütsel ilkeler mevcut değilse, sadece daha fazla kaos yaratıyor olabilirsiniz. Sadece tek bir proje, sınıf veya başka bir eserin (diğer modüllerin bağlı olduğu) daha mantıklı bir yere taşınmasının etkisini düşünün.
Robert Harvey

1
Harika şeyler. Travalarım, burada ve orada bir kaostan düzen yaratmak için bir araç / gereç ekleyebilecek olan bir çok çalışkan ruh tarafından daha da zorlaştırıldı. Her ne kadar belgelemenin ve belgelendirmenin hayranı olmasam da, iyi yazılmış bir aldatmaca levha ya da bulgur işaretlerinin listesi / özellikleri çok yardımcı olabilir.
Robbie Dee

Onaylanması muhtemel küçük değişiklikleri önermek için +1. Bunu deneyimledim ve daha etkili bir insan olmamı sağladı ve önerilerim daha etkili oldu.
RawBean

2

Mimari.

Tüm yazılımın tüm yönleriyle uygulanan keşfedilebilirlik ve bakım edilebilirlik sorunlarını çözen tek, özel, evrensel bir ilke veya uygulama yoktur. Ama, için geniş bir terimdir proje SANE yapan şeyler olduğunu mimarisi.

Mimarlığınız, mimari kararların nasıl verildiğinin ve belgelendirildiğinin belirlenmesi de dahil olmak üzere her potansiyel (veya tarihsel) karışıklığın etrafındaki kararların bütünüdür. Geliştirme sürecinin, klasör yapısı, kod kalite, tasarım desenleri ait her şey ve benzeri gidebilir bütün şeylerdir içine mimarinize ama onlardan biri olan bir mimari.

İdeal olarak, bu kurallar aklın tekilliği ile birleştirilir .

Küçük bir ekip kesinlikle birlikte mimarlık yaratabilir. Ancak, çeşitli görüşlerle bu, akıl sağlığınızı korumaya hizmet etmeyen çok şizofrenik bir mimariye yol açabilir . Mimarlığınızın ve buradaki birçok TLA'nın ve desenlerin hepsinin tekil bir zihinle takımın başarısına hizmet etmesini sağlamanın en basit yolu, onlardan tek bir zihin sorumlu hale getirmektir.

Şimdi, bu her zaman için bir "mimar" gerektirmez papalığı . Ve bazı takımlar deneyimli bir kişinin bu kararları almasını isterken, asıl mesele, bir başkasının , özellikle takım büyüdükçe, mimariye sahip olması gerektiğidir. Biri parmağını ekibin nabzına tutuyor, ılımlı mimari tartışmalar yapıyor, kararları belgeliyor ve kararları izliyor ve mimariye ve onun ahlakına uygunluk için ileriye dönük çalışmalar yapıyor.

Tüm kararları veren hiç kimsenin büyük bir hayranı değilim; ancak, bir "mimar" veya mimari tartışmalar ılımlı ve kararları belgeleyen sorumludur "teknik ürün sahibini" tanımlayan bir büyük kötülüğü mücadele: sorumluluk difüzyon buna yol açar hiçbir fark edilebilir mimarisi.


Belirgin bir mimariden sorumlu olmamakla ilgili sorumluluk dağılımını belirlemede kesinlikle haklısınız. Şimdilik bu sorunu gidermek için son zamanlarda kararlar verildi. Bunun için her zaman iyi bir çözümün, sisteme neyin girdiğine karar vereceğiniz, mimarın nasıl programladığına göre nereye karar vereceğini belirten başka bir yazılım sistemi aracılığıyla tümüyle dağıtılmış bir sistem oluşturmak olacağını düşünüyorum. Birden fazla farklı sistem ve teknolojiye tek bir bakış
açınız

Bence bu cevaptaki amacınız, OP'nin bahsettiği şeyle mücadele etmek / önlemek için en iyi yoldur. OP'nin sahip olduğu karmaşayı miras almak için de geçerlidir.
GWR

1

Yazılım Mühendisliğine Hoş Geldiniz (her iki anlamda);) Bu iyi bir soru, ama bildiğinizden emin olduğum için gerçekten kolay bir cevap yok. Bu, zamanla daha iyi uygulamalara dönüşmenin, insanları daha yetenekli olmaları için eğitmekle ilgili bir durumdur (tanımı gereği sektördeki çoğu insan vasat yetkinliktir) ...

Bir disiplin olarak yazılım mühendisliği ilk önce onu inşa etmekten ve bizzat zihniyetini tasarlamaktan, çaresizlikten ve gereklilikten mahrum olmaktan muzdariptir. Bu sadece canavarın doğası. Ve tabii ki, söz konusu kodlayıcılar, kısa vadeli ihtiyacı sıklıkla teknik borcun getirilmesi pahasına karşılayan hızlı bir şekilde çözen işlevsel çözümler ortaya koyduğundan, zamanla kesmeler üzerine kesmeler inşa edilir.

Kullanmanız gereken paradigma, temel olarak daha iyi insanlar elde etmek, sahip olduğunuz insanları eğitmek ve planlama ve mimarlıkta zaman ayırmanın önemini vurgulamaktır. Bir monolitik sistemle çalışırken kolayca bu "Çevik" olamaz. Küçük değişikliklerin bile yapılmasının ciddi bir planlaması olabilir. Harika bir üst düzey dokümantasyon sürecinin hayata geçirilmesi aynı zamanda kilit kişilerin kodla daha hızlı başa çıkmalarına yardımcı olacaktır.

Odaklanabileceğiniz fikirler (zaman içinde, kademeli olarak) sistemin temel parçalarını daha modüler ve ayrıştırılabilir, okunabilir ve bakımını yapabilecek şekilde yalıtmak ve yeniden yapılandırmak olacaktır. İşin püf noktası şu andaki iş gereksinimlerine göre, teknik borçlardaki düşüşün gözle görülür iş değeri sağlamakla eşzamanlı olarak yapılabilmesi. Bu yüzden çözüm, geliştirme becerilerindeki uygulamaları ve becerileri ve size zaten söyleyebileceğim gibi uzun vadeli mimari düşünceye doğru daha fazla ilerlemeye çalışan bir parça.

Bu soruya kodlama tekniği perspektifinden ziyade bir yazılım geliştirme metodolojisi perspektifinden cevap verdiğime dikkat edin, çünkü bu gerçekten kodlamanın detaylarından ya da mimari tarzdan çok daha büyük bir problemdir. Bu gerçekten değişimi nasıl planladığınızla ilgili bir soru.


6
Ne dediğini duyuyorum, ama cevabın sonuçta tatmin edici değil ve açıkçası biraz hakaret ediyor. Daha iyi insanları işe almaktan daha büyük bir problem; Çalıştığım küçük dükkanda bile bununla mücadele ediyoruz ve bence bu sadece bir insan probleminden daha fazlası. Bazı teknik ağrı noktalarının olduğunu düşünüyorum.
Robert Harvey,

1
Teknik yönlerin olduğu konusunda hemfikirim, ancak değişimin planlanması için daha güçlü bir metodoloji vurgusuyla karşılaştırıldığında bunların nispeten küçük olduğunu düşünüyorum. Bunu daha çok planlama ve analiz, daha erken planlama ve analiz ve daha iyi planlama ve analiz için kültürel bir değişim kadar tasarım kalıpları olarak görmüyorum .
Brad Thomas

Tamam, kendi cevabımı karşılaştırma olarak gönderirim. Ben sanmıyorum şey yazılım desenleri ile ilgisi yok.
Robert Harvey,

Brad, cevap için teşekkürler. Cevabınız, bu sorunun farkında olma konusunda yalnız olmadığımı bildiğim için takdir ediliyor. Takımımda bu gibi görünüyor. Ayrıca Robert Harvey ile aynı fikirdeyim, bu sorunun yaygın olduğu ve yeni bir yazılım türünde ya da yeni bir çalışma uygulamasında bir çözüm olduğu inancından vazgeçmek istemiyorum.
Christs_Chin

2
Kesinlikle benim deneyimim: ekip üyelerinizin ne yaptıklarını anlamalarını sağlamalısınız. MVVM ve MVC'yi karıştıran insanları gördüm, diğerleri WPF kontrollerini Windows Forms ile normal olan bir şekilde kullanıyorlar (veya daha doğrusu: VB6), C # dilinde programlama yapanlar, nesne yönelimi hakkında temel bir anlayış olmadan ... Onları öğretin. Onlara tekrar öğret. Sinirli ol. Onlara tekrar öğret, ... Genellikle pes etmeyi düşünüyor. Ve onları tekrar öğretmek ...
Bernhard Hiller

1

@ Robert Harvey'in sözleşmeler fikrini seviyorum ve yardımcı olduklarını düşünüyorum. Ayrıca @ KarlBielefeldt'in "giderken belgeleme" fikrini ve bunun gerekli olduğunu bilmesini seviyorum, çünkü dokümantasyonu güncel tutmanın tek yolu bu. Ama bence asıl mesele , kodunuzun tüm parçalarını nasıl bulacağınızı, inşa edeceğinizi ve dağıtacağınızı belgelemek önemlidir!

Kısa bir süre önce, kod üretilen tüm belgelenmemiş bazı XML yapılandırmasına sahip olan önemli bir açık kaynaklı projeyi e-postayla gönderdim. Bakıcıya, "Bu XML kod oluşturma işlemi nerede belgelenmiştir? Test veritabanı kurulumu nerede belgelenmiştir?" Diye sordum. ve dedi ki, "Değil." Temelde tek katılımcı bir proje ve şimdi nedenini biliyorum.

Bak, eğer o kişiyseniz ve bunu okuyorsanız, yaptığınız işi gerçekten takdir ediyorum. İşçilerinizin meyvelerine pratik olarak tapıyorum! Fakat gerçekten yaratıcı şeylerinizin nasıl bir araya getirildiğini belgelemek için bir saat harcadıysanız, size yardımcı olabilecek yeni özellikleri kodlamak için birkaç gün geçirebilirim. Tuğla duvarla karşılaştığımda "dokümantasyon eksikliği sorun değil" denemeyeceğim bile.

Bir işletmede, dokümantasyon eksikliği çok büyük bir zaman ve enerji kaybıdır. Bunun gibi projeler genellikle daha pahalıya mal olan danışmanlara yönelir, böylece “bütün parçalar nerede ve nasıl bir araya gelir?” Gibi temel şeyleri anlayabilirler.

Sonuç olarak

İhtiyaç duyulan şey bir teknoloji ya da metodoloji değil, bir kültür değişimidir; işlerin nasıl yapıldığını ve neden önemli olduğunu belgeleyen ortak bir inanç. Kod incelemelerinin bir parçası olmalı, üretime geçmenin bir gereği, zamlara bağlı olmalı. Herkes buna inandığında ve buna göre hareket ettiğinde işler değişecektir. Aksi halde, başarısız olan açık kaynak kodlu katkım gibi olacak.


2
Kültürel sorunun bir kısmının Çevik inançtan kaynaklandığından şüpheleniyorum, "Kullanıcı Hikayesinin bir parçası değilse (yani paydaş değerine doğrudan katkıda bulunmuyorsa), o zaman önemli değil." Hogwash. İlgili konuşma burada: Çevik, bir projenin başlangıcındaki temel altyapı işleri nasıl planlanır ve tahsis edilir?
Robert Harvey,

@RobertHarvey Evet. Takımımdaki herkes inanılmaz derecede parlak ve üstesinden gelmek çok kolay. Scrum ustaları ve proje yöneticileri iyi niyetli ve yönlendirmeli ve uygulamalar içinde çalıştığım en çevik. Ancak belgelerde eksiklik var, muhtemelen önerdiğiniz nedenle. Ayrıca, dokümantasyon oluşturulduğunda, kişinin ilgili kavramları tanımlaması ve ayrıca böyle bir görevi üstlenme zorunluluğu konusundaki tutumundan bahsetmemesi gibi açıklayabilmesi için iletişimsel etkinlikte daha fazla bir rastgelelik katmanı ortaya çıkar. Genellikle sadece "
Somone

@GlenPeterson Evet, bunun faydalı olacağını kabul ediyorum. Ancak, sadece inşa edilmesi gerektiğini değil, dokümantasyon olarak nasıl ve neyin nitelendirileceği de belirtilmelidir. Mesela buradaki son örnek olarak, birileri sistemimizin tanımlayacağı yeni numaraların bir listesini içeriyordu. Bu kadar. Bu sayıların sisteme nasıl girdiği, nerede, niçin, kimler tarafından, ne sıklıkta veya yararlı bir şey olduğu, yalnızca yaptıklarından söz edilmedi. Hiçbir noktada, sistemimizin hangi numaraları alakalı olarak tanımlayacağını merak etmedim. Ama sık sık, nereye girdiklerini, nereye gittiklerini ve yolda neler olduğunu merak etmişimdir. Hala bir gizem.
Christs_Chin

1
@Christs_Chin Çok fazla iletişim bağlam dayanmaktadır. Bu bağlam olmadan, çoğu iletişim neredeyse anlamsızdır. Acını hissediyorum. Ama bence başkalarının seni anlayabilmesi için yazması zor (İngilizce). Bazen bir sistem için ilk özellikler, güncel olmayan olsalar bile, onu anlamanız gereken içeriğe sahiptir, bu genellikle yardımcı olur.
GlenPeterson

1

Soruyu olduğu gibi yanıtlamak için (özel durumunuz için size tavsiyede bulunmak yerine):

Saf fonksiyonel programlama olarak bilinen programlama paradigması , bir fonksiyonun çıktısını etkileyen her şeyin giriş parametrelerinde belirtilmesini gerektirir. Kod bazında görünmez bir şekilde hareket eden gizli bağımlılıklar veya global değişkenler veya diğer gizemli kuvvetler yoktur. "İlk önce bunu yapmak zorundasın" diye bir geçici bağlantı yok.


0

Her veri ambarı farklıdır ancak işleri kolaylaştırmak için yapabileceğiniz çok şey vardır.

Yeni başlayanlar için, veritabanındaki her satırın bir DATE_ADDED ve DATA_UPDATED sütunu vardı, böylece veritabanına ne zaman eklendiğini ve ne zaman değiştirildiğini görebildik. Ayrıca bir SOURCE_CODE vardı böylece her bir veri parçasının sisteme nereden girdiğini takip edebildik.

Ardından çeşitler, masa kibritleri, dilimleyiciler ve dikerler vb.

Ismarlama kod mutlak minimumda tutuldu ve o zaman bile, çeşitli kodlama ve raporlama stillerini onaylaması gerekiyordu.

ETL'ye zaten aşina olduğunuzu farz edeceğim süitlerine . On yıl önce oyunda olduğumda bulunmayan bu günlerde ücretsiz olarak alabileceğiniz bir çok işlev var.

Ayrıca , veri ambarınızın daha dostane ve temiz bir versiyonunu sunmak için veri martlarına bakmak isteyebilirsiniz . Tabii ki gümüş bir mermi değil, veri ambarınızı yeniden düzenlemek / düzeltmek yerine belli konularda yardımcı olabilir.


cevap için teşekkürler. Evet, tüm bu alanları kullanıyoruz, ancak bunlar akışlar, katmanlar ve sistemler arasındaki bağımlılıklara değil, yalnızca tek bir sıranın tanımlanmasına gerçekten yardımcı oluyorlar. ETL süitleri konusunda haklısınız - iyi bilinen bir ETL aracına destek vermeyen birinden yükseltme sürecindeydik ama bunun yerine PLSQL'e geri döndük. Kodlamak iyi, fakat bakım ve genel sistemi kod seviyesinden anlamak, kesinlikle korkunç.
Christs_Chin

1
İdeal olan, verileri sıraya yerleştirme tabloları veya düz dosyalar aracılığıyla izleyebilmenizdir, ancak elinizde değilse, yürüme koduyla kalırsınız.
Robbie Dee

0

Davanızla ne kadar ilgili olduğunu bilmiyorum, bağımlılıkları daha görünür hale getirmek ve kodların genel bakımını yapmak için bazı stratejiler var.

  • Genel değişkenlerden kaçının, bunun yerine parametreleri kullanın. Bu, çapraz dil çağrıları için de geçerlidir.
  • Değişkenlerin değerlerini değiştirmek / mutasyona uğramaktan kaçının. Yeni bir değişken yapın ve mümkünse değeri değiştirmeniz gerektiğinde kullanın.
  • Kodu modüler hale getirin. Kısmen gerçekte ne yaptığını (basitçe değil) açıklamak mümkün değilse, durumu sağlayan modüllere ayırın.
  • Kod bölümlerinizi doğru şekilde adlandırın. Kodun bir kısmının basit terimlerle ne yaptığını gerçekten tanımlayabildiğinizde, bu terimler kısmın adı olur. Böylece, kod modüller / sınıflar / fonksiyonlar / prosedürler / metodlar vb.
  • Kodunu test et. Kodunuzdaki varlıkların, önceki bölümde tartışılan adlarını haklı gösterip göstermediğini test edin.
  • Kodda olayları günlüğe yaz. En azından iki günlük seviyesini koru. Birincisi her zaman etkindir (üretimde bile) ve yalnızca kritik olayları kaydeder. Ve diğerini temelde her şeyi kaydetmek için kullanın, ancak açılabilir veya kapatılabilir.
  • Kod tabanınıza göz atmak, bakımını yapmak ve geliştirmek için uygun araçları bulun ve kullanın. Visual Studio Kodunun basit bir "Her şeyi Ara" seçeneği bile bazı durumlarda hayatımı çok kolaylaştırdı.
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.