Apakah ada paradigma pemrograman yang mempromosikan membuat ketergantungan sangat jelas bagi programmer lain?

26

Saya bekerja di Gudang Data yang sumber beberapa sistem melalui banyak aliran dan lapisan dengan dependensi seperti labirin yang menghubungkan berbagai artefak. Hampir setiap hari saya mengalami situasi seperti ini: Saya menjalankan sesuatu, itu tidak berhasil, saya melalui banyak kode tetapi berjam-jam kemudian saya menyadari bahwa saya telah berhasil membuat konsep peta proses dari bagian kecil dari apa yang sekarang saya tahu diperlukan suatu hari nanti, jadi saya bertanya kepada seseorang dan mereka memberi tahu saya bahwa aliran lain ini harus dijalankan terlebih dahulu dan bahwa jika saya memeriksa di sini (menunjukkan beberapa bagian yang tampaknya sewenang-wenang dari setumpuk dependensi kode lainnya), maka saya akan meminta melihat ini. Ini sangat membuat frustrasi.

Jika saya dapat menyarankan kepada tim bahwa mungkin itu ide yang baik jika kita berbuat lebih banyak untuk membuat ketergantungan antara objek lebih terlihat dan jelas, daripada menanamkannya secara mendalam dalam level kode rekursif, atau bahkan dalam data yang harus hadir karena dihuni oleh aliran lain, mungkin dengan merujuk pada paradigma perangkat lunak yang terkenal, dicoba dan diuji - maka saya mungkin dapat membuat pekerjaan saya dan semua orang jauh lebih sederhana.

Agak sulit untuk menjelaskan manfaat ini kepada tim saya. Mereka cenderung hanya menerima hal-hal sebagaimana adanya dan tidak 'berpikir besar' dalam hal melihat manfaat dari dapat mengonseptualisasikan seluruh sistem dengan cara baru - mereka tidak benar-benar melihat bahwa jika Anda dapat memodelkan sistem besar efisien maka itu membuat kecil kemungkinan Anda akan menemukan inefisiensi memori, stream-stopping kendala unik dan duplikat kunci, data omong kosong karena jauh lebih mudah untuk mendesainnya sesuai dengan visi asli dan Anda nantinya tidak akan mengalami semua masalah ini yang kita sekarang mengalami, yang saya tahu tidak biasa dari pekerjaan masa lalu, tetapi yang mereka anggap sebagai tak terhindarkan.

Jadi, adakah yang tahu tentang paradigma perangkat lunak yang menekankan ketergantungan dan juga mempromosikan model konseptual umum suatu sistem dengan tujuan untuk memastikan kepatuhan jangka panjang terhadap suatu cita-cita? Saat ini kami memiliki kekacauan yang sangat besar dan solusi untuk setiap sprint tampaknya adalah "tambahkan saja benda ini di sini, dan di sini dan di sini" dan hanya aku yang khawatir bahwa segalanya benar-benar mulai berantakan.

— Christs_Chin
sumber

2

Bisakah Anda memperjelas "dependensi seperti labirin yang menghubungkan berbagai artefak" seperti apa ini? Apakah mereka membangun dependensi, yang bisa diselesaikan dengan alat build seperti Maven? Apakah mereka input dependensi, di mana salah satu artefak ini tergantung pada beberapa input yang tidak jelas atau tidak jelas? Apakah mereka ketergantungan utama antara tabel database?

— FrustratedWithFormsDesigner

Sistemnya adalah PLSQL, Unix bash, OWB dll jadi ada segala macam dependensi. Kadang-kadang data diperlukan dari format tertentu, di tempat tertentu, pada waktu tertentu, oleh modul tertentu, tetapi itu tidak jelas dari kode dan hanya dapat dilihat dengan dua cara: dengan melalui tumpukan kode, mungkin butuh berhari-hari, untuk mengetahui bahwa beberapa data memiliki titik koma yang membatasi di bagian sistem yang Anda bahkan tidak tahu sedang dirujuk karena terkubur dalam 10 lapisan kode yang disebut secara rekursif, atau dengan bertanya kepada seseorang, semua waktu, setiap saat. Itu tidak mempromosikan kemerdekaan.

— Christs_Chin

4

Secara harfiah semuanya

— Miles Rout

3

Sedikit singgung: Karena Haskell malas, Anda secara efektif tidak menentukan urutan operasi ketika Anda menulis kode. Anda hanya menentukan dependensi. Fungsi C tergantung pada hasil fungsi A dan B. Jadi A dan B harus dijalankan sebelum C, tetapi bisa berfungsi sama baiknya jika A dijalankan terlebih dahulu, atau jika B dijalankan terlebih dahulu. Saya hanya berpikir itu menarik.

— GlenPeterson

1

Ada sebuah buku berjudul Desain pola (buku itu menyebalkan, tetapi sebagian besar dari apa yang dikatakannya bagus, kecuali sedikit tentang singleton). Ini memiliki beberapa bagian tentang mengelola dependensi.

— ctrl-alt-delor

19

Dapat ditemukan

Ketidakhadirannya mengganggu banyak organisasi. Di mana alat yang dibangun Fred lagi? Dalam repositori Git, tentu saja. Dimana?

Pola perangkat lunak yang muncul di pikiran adalah Model-View-ViewModel. Bagi yang belum tahu, pola ini adalah misteri total. Saya menjelaskannya kepada istri saya sebagai "lima widget melayang di atas meja berbicara satu sama lain melalui kekuatan misterius." Pahami polanya, dan Anda memahami perangkat lunaknya.

Banyak sistem perangkat lunak gagal mendokumentasikan arsitektur mereka karena mereka menganggap itu jelas, atau muncul secara alami dari kode. Tidak, dan tidak. Kecuali jika Anda menggunakan arsitektur yang terdefinisi dengan baik, orang-orang baru akan tersesat. Jika tidak didokumentasikan (atau terkenal), orang baru akan tersesat. Dan para veteran juga akan tersesat, begitu mereka telah meninggalkan kode selama beberapa bulan.

Adalah tanggung jawab tim untuk menghasilkan arsitektur organisasi yang masuk akal dan mendokumentasikannya. Ini termasuk hal-hal seperti

Organisasi folder
Referensi proyek
Dokumentasi kelas (apa itu, apa fungsinya, mengapa ada, bagaimana itu digunakan)
Proyek, modul, perakitan, dokumentasi apa pun.

Adalah tanggung jawab tim untuk membuat hal-hal terorganisir dan dapat ditemukan sehingga tim tidak terus-menerus menemukan kembali roda.

By the way, gagasan bahwa "kode harus mendokumentasikan diri sendiri" hanya sebagian yang benar. Meskipun benar bahwa kode Anda harus cukup jelas sehingga Anda tidak perlu menjelaskan setiap baris kode dengan komentar, hubungan antara artefak seperti kelas, proyek, rakitan, antarmuka dan sejenisnya tidak jelas, dan masih perlu didokumentasikan.

— Robert Harvey
sumber

3

Tentu, tetapi orang-orang yang bersandar terlalu keras pada pola desain adalah bagian dari masalah. Merekalah yang menulis kode tanpa dokumentasi, dengan asumsi bahwa semua orang akan mengerti apa yang mereka lakukan hanya dengan melihat kode itu. Juga, pola desain perangkat lunak bukan arsitektur (sebagian besar).

— Robert Harvey

1

Di mana alat yang dibangun Fred lagi? Dalam repositori Git, tentu saja. Dimana? - Tepat! Pola MVC terlalu spesifik untuk pengembangan front-end (saya pikir), dan pola hanya berguna jika semua orang di tim mengenal mereka sehingga ini hanya memindahkan masalah dari ketergantungan tidak menjadi jelas, menjadi jelas JIKA semua orang tahu bagaimana menemukan mereka. Tetapi masalahnya mengandaikan ini tidak terjadi. Karena itu saya berharap ada sesuatu yang mempromosikan cara yang sangat jelas untuk menjelaskan dependensi yang tidak memerlukan kerangka kerja konseptual lain yang dipelajari untuk Anda gunakan.

— Christs_Chin

7

Ini disebut "dokumentasi." Selain itu, Anda memerlukan kerangka kerja ketergantungan yang masuk akal yang didukung semua orang. Sayangnya tidak ada template boilerplate yang bisa Anda masukkan ke proyek Anda; struktur organisasi perangkat lunak adalah sesuatu yang tim Anda ciptakan sendiri, dengan bantuan arsitektur yang masuk akal.

— Robert Harvey

5

@RobertHarvey: Baru-baru ini mendengar: "Kami menulis kode yang tidak memerlukan dokumentasi". Salah. Anda menulis kode tanpa dokumentasi.

— gnasher729

3

Beberapa barang bagus di sini. NB ada perbedaan antara menulis kode yang tidak memerlukan komentar dan menulis dokumentasi pendukung.

— Robbie Dee

10

Cara terbaik untuk mendekati masalah seperti ini adalah secara bertahap. Jangan frustrasi dan mengusulkan perubahan arsitektur yang luas dan meluas. Itu tidak akan pernah disetujui, dan kode tidak akan pernah membaik. Itu dengan asumsi Anda bahkan dapat menentukan lebar, perubahan arsitektur yang benar untuk membuat, yang tidak mungkin.

Apa itu mungkin adalah bahwa Anda bisa menentukan perubahan kecil yang akan membantu Anda dengan masalah khusus Anda hanya dipecahkan. Mungkin pembalik beberapa dependensi, menambahkan beberapa dokumentasi, menciptakan antarmuka, menulis naskah yang memperingatkan dari ketergantungan hilang, dll Jadi mengusulkan bahwa perubahan kecil sebagai gantinya. Lebih baik lagi, tergantung pada budaya perusahaan Anda, mereka mungkin mentolerir atau bahkan mengharapkan Anda untuk melakukan perbaikan seperti itu sebagai bagian dari tugas awal Anda.

Ketika Anda membuat perubahan kecil ini sebagai bagian rutin dari pekerjaan Anda, dan dengan contoh Anda mendorong orang lain untuk melakukannya juga, mereka benar-benar bertambah seiring waktu. Jauh lebih efektif daripada mengeluh tentang satu perubahan besar yang tidak diizinkan Anda lakukan.

— Karl Bielefeldt
sumber

2

Saya setuju dengan gagasan perubahan tambahan. Masalahnya adalah bahwa, tanpa beberapa prinsip organisasi sudah ada, Anda mungkin akan menciptakan lebih banyak kekacauan. Pertimbangkan efek memindahkan hanya satu proyek, kelas atau artefak lainnya (di mana modul lain bergantung) ke lokasi yang lebih masuk akal.

— Robert Harvey

1

Hal yang bagus. Kesusahan saya sering dibuat tidak terlalu sulit oleh beberapa jiwa yang rajin yang memiliki nous untuk menambahkan alat / widget di sana-sini untuk membuat pesanan dari kekacauan. Walaupun saya bukan penggemar rim dan rim dokumentasi, lembar contekan yang ditulis dengan baik atau daftar gotchas / fitur bisa sangat membantu.

— Robbie Dee

+1 untuk mengajukan perubahan kecil yang kemungkinan akan disetujui. Saya mengalaminya dan itu membantu saya menjadi seseorang yang lebih berpengaruh, dan kemudian proposal saya mendapat dampak yang lebih besar.

— RawBean

2

Arsitektur.

Tidak ada tunggal, spesifik, prinsip atau praktik universal yang memecahkan masalah keterjangkauan dan pemeliharaan yang berlaku untuk semua aspek dari semua perangkat lunak. Tapi, istilah umum untuk hal-hal yang membuat proyek waras adalah arsitektur.

Arsitektur Anda adalah seluruh tubuh keputusan di sekitar setiap titik kebingungan potensial (atau historis) - termasuk penunjukan bagaimana keputusan arsitektur dibuat dan didokumentasikan. Segala sesuatu yang berkaitan dengan proses pengembangan, struktur folder, kualitas kode, pola desain, dan sebagainya adalah semua hal yang mungkin masuk ke arsitektur Anda, tetapi tidak satu pun dari mereka adalah arsitektur.

Idealnya, aturan-aturan itu disatukan oleh singularitas pikiran.

Sebuah tim kecil tentu saja dapat membuat arsitektur secara kolaboratif. Tetapi, dengan berbagai pendapat, ini dapat mengarah dengan cepat ke arsitektur yang sangat skizofrenia yang tidak berfungsi untuk menjaga kewarasan Anda. Cara paling sederhana untuk memastikan bahwa arsitektur Anda, dan banyak TLA dan pola di dalamnya, semua melayani keberhasilan tim dengan keunikan pikiran adalah dengan membuat satu pikiran bertanggung jawab untuk mereka.

Sekarang, itu tidak selalu memerlukan "arsitek" untuk menjadi kepausan . Dan, sementara beberapa tim mungkin ingin orang yang berpengalaman hanya membuat keputusan itu, poin utamanya adalah bahwa seseorang perlu memiliki arsitektur, terutama ketika tim tumbuh. Seseorang menjaga jari mereka pada denyut nadi tim, diskusi arsitektur yang moderat, mendokumentasikan keputusan, dan memantau keputusan dan bekerja untuk kepatuhan terhadap arsitektur dan etosnya.

Saya bukan penggemar berat seseorang yang membuat semua keputusan; tetapi, mengidentifikasi "arsitek" atau "pemilik produk teknis" yang bertanggung jawab untuk memoderasi diskusi arsitektur dan mendokumentasikan keputusan memerangi kejahatan yang lebih besar: Difusi tanggung jawab yang mengarah ke tidak ada arsitektur yang terlihat.

— svidgen
sumber

Anda benar-benar benar dalam mengidentifikasi difusi tanggung jawab sebagai yang bertanggung jawab atas arsitektur yang tidak terlihat. Keputusan sekarang hanya dibuat untuk memperbaiki masalah ini. Saya selalu berpikir solusi yang baik untuk ini adalah dengan membuat seluruh sistem terdistribusi melalui sistem perangkat lunak lain yang bertindak sebagai pengungkit, di mana Anda memutuskan apa yang masuk ke dalam sistem, tetapi ia memutuskan di mana, sesuai dengan bagaimana arsitek memprogramnya. Anda akan memiliki satu pandangan ke berbagai sistem dan teknologi yang berbeda dan akan menavigasi mereka melalui beberapa diagram arsitektur sistem ...

— Christs_Chin

Saya pikir poin Anda dalam jawaban ini adalah satu-satunya cara terhebat untuk memerangi / mencegah hal-hal yang dibicarakan OP. Bahkan berlaku untuk mewarisi kekacauan seperti yang dimiliki OP.

— GWR

1

Selamat datang di Rekayasa Perangkat Lunak (dalam dua hal);) Ini adalah pertanyaan yang bagus, tetapi sebenarnya tidak ada jawaban yang mudah, karena saya yakin Anda sadar. Ini benar-benar kasus berkembang menjadi praktik yang lebih baik dari waktu ke waktu, melatih orang untuk menjadi lebih terampil (menurut definisi kebanyakan orang di industri ini adalah kompetensi yang biasa-biasa saja) ...

Rekayasa perangkat lunak sebagai suatu disiplin menderita dari membangunnya terlebih dahulu dan mendesainnya sebagai mentalitas, sebagian dari kemanfaatan dan sebagian karena kebutuhan. Itu hanya sifat binatang itu. Dan tentu saja peretasan dibangun atas peretasan dari waktu ke waktu, karena para pembuat kode yang disebutkan sebelumnya menempatkan solusi fungsional dengan cepat yang menyelesaikan kebutuhan jangka pendek sering kali dengan biaya memperkenalkan hutang teknis.

Paradigma yang perlu Anda gunakan pada dasarnya adalah mendapatkan orang yang lebih baik, melatih orang-orang yang Anda miliki dengan baik, dan menekankan pentingnya meluangkan waktu untuk perencanaan dan arsitektur. Seseorang tidak dapat dengan mudah menjadi "Agile" ketika bekerja dengan sistem monolitik. Diperlukan perencanaan yang matang untuk melakukan perubahan kecil sekalipun. Mendapatkan proses dokumentasi tingkat tinggi yang hebat juga akan membantu orang-orang penting memahami kode dengan lebih cepat.

Ide-ide yang dapat Anda fokuskan adalah (dari waktu ke waktu, secara bertahap) mengisolasi dan refactoring bagian-bagian utama dari sistem dengan cara yang membuatnya lebih modular dan dipisahkan, dibaca, dapat dirawat. Kuncinya dalam bekerja ini adalah dengan persyaratan bisnis yang ada, sehingga pengurangan utang teknis dapat dilakukan secara simultan dengan memberikan nilai bisnis yang terlihat. Jadi solusinya adalah meningkatkan praktik dan keterampilan, dan sebagian lagi mencoba bergerak lebih ke arah pemikiran arsitektur jangka panjang, seperti yang sudah saya katakan.

Perhatikan bahwa saya telah menjawab pertanyaan ini dari perspektif metodologi pengembangan perangkat lunak daripada perspektif teknik pengkodean karena sebenarnya ini adalah masalah yang jauh lebih besar daripada detail pengkodean atau bahkan gaya arsitektur. Ini benar-benar pertanyaan tentang bagaimana Anda merencanakan perubahan.

— Brad Thomas
sumber

6

Saya mendengar apa yang Anda katakan, tetapi jawaban Anda pada akhirnya tidak memuaskan, dan terus terang sedikit menghina. Ini masalah yang lebih besar daripada hanya mempekerjakan orang yang lebih baik; bahkan di toko kecil tempat saya bekerja, kita bergumul dengan ini, dan saya pikir itu lebih dari sekadar masalah orang; Saya pikir ini memiliki beberapa poin nyeri teknis yang spesifik.

— Robert Harvey

1

Saya setuju ada aspek teknis, tetapi saya pikir itu relatif kecil dibandingkan dengan penekanan pada metodologi yang lebih kuat untuk perencanaan perubahan. Saya tidak melihat ini sebagai tentang pola desain sebanyak pergeseran budaya menuju lebih banyak perencanaan dan analisis, perencanaan dan analisis sebelumnya dan perencanaan dan analisis yang lebih baik .

— Brad Thomas

Baiklah, saya akan memposting jawaban saya sendiri sebagai perbandingan. Saya tidak berpikir itu ada hubungannya dengan pola perangkat lunak.

— Robert Harvey

Brad, terima kasih atas jawabannya. Tanggapan Anda dihargai karena saya tahu saya tidak sendirian karena menyadari masalah ini. Sepertinya ini di tim saya. Saya juga setuju dengan Robert Harvey, bahwa masalah ini tersebar luas dan saya tidak ingin menyerah pada keyakinan bahwa ada solusi, baik dalam jenis perangkat lunak baru atau praktik kerja baru.

— Christs_Chin

2

Persis pengalaman saya: Anda harus membuat anggota tim Anda mengerti apa yang mereka lakukan. Saya melihat orang-orang mencampur MVVM dan MVC, yang lain menggunakan kontrol WPF dengan cara yang normal dengan Windows Forms (atau lebih tepatnya: VB6), orang pemrograman di C # tanpa pemahaman dasar tentang orientasi objek ... Ajari mereka. Ajari mereka lagi. Frustrasi. Ajari mereka lagi, ... Sering berpikir untuk menyerah. Dan mengajar mereka lagi ...

— Bernhard Hiller

1

Saya suka ide @ RobertHarvey tentang konvensi dan berpikir itu membantu. Saya juga suka ide @ KarlBielefeldt untuk "mendokumentasikan saat Anda pergi" dan tahu itu penting karena itulah satu-satunya cara untuk menjaga dokumentasi terkini. Tapi saya pikir ide yang terlalu melengkung adalah bahwa mendokumentasikan cara menemukan semua bagian dari kode Anda, membangun, dan menyebarkannya adalah penting!

Baru-baru ini saya mengirim email ke proyek open source yang signifikan yang memiliki beberapa konfigurasi XML yang menghasilkan kode sama sekali tidak berdokumen. Saya bertanya kepada pengelola, "Di mana proses pembuatan kode XML ini didokumentasikan? Di mana pengaturan basis data pengujian didokumentasikan?" dan dia berkata, "Tidak." Ini pada dasarnya adalah proyek kontributor tunggal dan sekarang saya tahu mengapa.

Dengar, jika Anda orang itu dan Anda membaca ini, saya sangat menghargai apa yang Anda lakukan. Saya praktis menyembah hasil kerja Anda! Tetapi jika Anda menghabiskan waktu satu jam untuk mendokumentasikan bagaimana barang-barang Anda yang benar-benar kreatif disatukan, saya mungkin menghabiskan beberapa hari mengkodekan fitur baru yang dapat membantu Anda. Ketika dihadapkan dengan dinding bata "kurangnya dokumentasi bukanlah masalah," Aku bahkan tidak akan mencoba.

Dalam sebuah bisnis, kurangnya dokumentasi adalah pemborosan waktu dan energi. Proyek-proyek seperti itu sering kali dihabiskan untuk konsultan yang harganya lebih mahal, hanya agar mereka bisa mengetahui hal-hal dasar seperti, "di mana semua bagian dan bagaimana mereka cocok bersama."

Kesimpulannya

Yang dibutuhkan bukanlah teknologi atau metodologi, tetapi perubahan budaya; keyakinan bersama yang mendokumentasikan bagaimana hal-hal dibangun dan mengapa itu penting. Itu harus menjadi bagian dari tinjauan kode, persyaratan untuk pindah ke produksi, terkait dengan kenaikan gaji. Ketika semua orang percaya itu dan bertindak berdasarkan itu, segalanya akan berubah. Kalau tidak, itu akan menjadi seperti kontribusi open source saya yang gagal.

— GlenPeterson
sumber

2

Saya menduga bahwa bagian dari masalah budaya terletak pada keyakinan Agile bahwa "jika itu bukan bagian dari Kisah Pengguna (yaitu tidak berkontribusi langsung ke nilai pemangku kepentingan), maka itu tidak penting." Omong kosong. Pembicaraan terkait di sini: Dengan gesit, bagaimana tugas infrastruktur dasar pada awal proyek direncanakan dan dialokasikan?

— Robert Harvey

@RobertHarvey Ya. Semua orang di tim saya sangat cerdas dan sangat mudah bergaul. Para master scrum dan manajer proyek memiliki niat dan dorongan yang kuat, dan praktiknya adalah yang paling gesit di mana saya pernah bekerja. Tetapi dokumentasinya kurang, mungkin karena alasan yang Anda sarankan. Ditambah lagi ketika dokumentasi dibuat, lapisan keacakan lebih lanjut dalam efektivitas komunikatif diperkenalkan pada kemampuan orang untuk mengidentifikasi konsep-konsep terkait dan juga untuk menjelaskannya, belum lagi sikap mereka terhadap keharusan melakukan tugas semacam itu. Biasanya ini hanya "Tanya seseorang"

— Christs_Chin

@ GlenPeterson Ya, saya setuju ini akan membantu. Tetapi harus ditentukan tidak hanya bahwa itu harus dibangun, tetapi juga bagaimana dan apa yang memenuhi syarat sebagai dokumentasi. Misalnya sebagai contoh terbaru di sini, seseorang memasukkan daftar nomor baru yang akan diidentifikasi oleh sistem kami. Itu dia. Tidak disebutkan bagaimana angka-angka ini masuk ke sistem, di mana, mengapa, oleh siapa, seberapa sering atau apa pun yang bermanfaat, hanya saja mereka lakukan. Tidak ada titik saya bertanya-tanya nomor apa sistem kami akan mengidentifikasi sebagai relevan. Tapi saya sering bertanya-tanya, ke mana mereka masuk, ke mana mereka pergi dan apa yang terjadi di jalan. Itu masih misteri.

— Christs_Chin

1

@Christs_Chin Begitu banyak komunikasi didasarkan pada konteks. Tanpa konteks itu, kebanyakan komunikasi hampir tidak ada artinya. Aku merasakan sakitmu. Tapi saya pikir sulit untuk menulis (bahasa Inggris) sehingga orang lain dapat mengerti Anda. Terkadang spesifikasi awal untuk suatu sistem memiliki konteks yang Anda perlu memahaminya bahkan jika mereka sudah ketinggalan zaman, konteksnya biasanya membantu.

— GlenPeterson

1

Untuk menjawab pertanyaan seperti yang diajukan (daripada memberi Anda saran untuk situasi khusus Anda):

Paradigma pemrograman yang dikenal sebagai pemrograman fungsional murni mensyaratkan bahwa segala sesuatu yang memengaruhi output suatu fungsi harus ditentukan dalam parameter input. Tidak ada dependensi tersembunyi atau variabel global atau kekuatan misterius lainnya yang bertindak tanpa terlihat di seluruh basis kode. Tidak ada "sementara Anda harus melakukan ini" penggabungan sementara.

— JacquesB
sumber

0

Setiap gudang data berbeda tetapi ada banyak yang dapat Anda lakukan untuk membuat segalanya lebih mudah bagi diri Anda sendiri.

Sebagai permulaan, setiap baris dalam database memiliki DATE_ADDED dan DATA_UPDATED kolom sehingga kita bisa melihat ketika ditambahkan ke database dan ketika itu berubah. Kami juga memiliki kolom SOURCE_CODE sehingga kami dapat melacak di mana setiap bit data masuk ke sistem.

Selanjutnya kami memiliki alat umum yang berlari di seluruh gudang data kami seperti jenis, pencocokan tabel, slicers dan dicers dll.

Kode dipesan lebih dahulu disimpan ke minimum absolut dan bahkan kemudian, itu harus mengkonfirmasi ke berbagai gaya pengkodean dan pelaporan.

Saya akan menganggap Anda sudah terbiasa dengan suite ETL . Ada banyak fungsi yang Anda dapatkan secara gratis akhir-akhir ini yang tidak ada ketika saya berada dalam permainan sekitar satu dekade yang lalu.

Anda mungkin juga ingin melihat data mart untuk menyajikan versi gudang data Anda yang lebih ramah dan bersih. Bukan peluru perak tentu saja tetapi bisa membantu dengan masalah tertentu daripada harus membangun kembali / memperbaiki gudang data Anda.

— Robbie Dee
sumber

terima kasih atas tanggapannya. Ya, kami menggunakan semua bidang ini, tetapi mereka hanya benar-benar membantu mengidentifikasi satu baris, bukan dengan ketergantungan antara aliran, lapisan, dan sistem. Anda benar tentang suite ETL - kami sedang dalam proses memutakhirkan ke alat ETL yang terkenal dari salah satu yang keluar dari dukungan tetapi sebaliknya, akhirnya kembali ke PLSQL. Tidak masalah untuk kode, tetapi untuk pemeliharaan dan untuk memahami sistem secara keseluruhan dari tingkat kode, itu benar-benar mengerikan.

— Christs_Chin

1

Yang ideal adalah bahwa Anda dapat melacak data ujung ke ujung baik itu melalui staging tables atau flat file tetapi jika Anda tidak memilikinya, Anda tinggal membawa kode jalan.

— Robbie Dee

0

Saya tidak tahu seberapa relevan dengan kasus Anda, ada beberapa strategi untuk membuat ketergantungan lebih terlihat dan pemeliharaan kode secara umum.

Hindari variabel global, sebagai gantinya gunakan parameter. Ini berlaku untuk panggilan lintas bahasa juga.
Hindari mengubah / mengubah nilai variabel, sebanyak yang Anda bisa. Buat variabel baru dan gunakan, saat Anda perlu mengubah nilainya, jika memungkinkan.
Buat kode menjadi modular. Jika tidak mungkin untuk menggambarkan apa yang sebenarnya (tidak seberapa) porsi lakukan dalam kalimat sederhana, pisahkan menjadi modul yang memenuhi kondisi.
Beri nama bagian kode Anda dengan benar. Ketika Anda benar-benar dapat menggambarkan apa yang dilakukan sebagian kode dalam istilah sederhana, istilah itu menjadi nama bagian tersebut. Dengan demikian, kode menjadi mendokumentasikan diri melalui nama-nama modul / kelas / fungsi / prosedur / metode dll.
Uji kode Anda. Uji apakah entitas dalam kode Anda membenarkan nama mereka, dibahas pada poin sebelumnya.
Catat peristiwa dalam kode. Setidaknya pertahankan dua level log. Yang pertama selalu diaktifkan (bahkan dalam produksi) dan hanya mencatat peristiwa penting. Dan gunakan yang lain untuk mencatat semuanya pada dasarnya, tetapi bisa dinyalakan atau dimatikan.
Temukan dan gunakan alat yang sesuai untuk menelusuri, memelihara, dan mengembangkan basis kode Anda. Bahkan pilihan "Cari Segalanya" sederhana dari Visual Studio Code membuat hidup saya jauh lebih mudah untuk kasus-kasus tertentu.

— Gulshan
sumber