Berikut ini kutipan dari Linus Torvalds untuk 2006 :

Saya adalah pendukung besar pengembangan kode di sekitar data, dan bukan sebaliknya, dan saya pikir ini adalah salah satu alasan mengapa git cukup sukses ... Bahkan, saya berpendapat bahwa perbedaan antara programmer yang buruk dan yang baik adalah apakah dia berpikir lebih penting kode Anda atau struktur data Anda. Pemrogram yang buruk khawatir tentang kode. Pemrogram yang baik khawatir tentang struktur data dan hubungan mereka.

Yang sangat mirip dengan "aturan pengiriman" Eric Raymond tahun 2003 :

Ubah pengetahuan menjadi data sehingga logika program menjadi bodoh dan dapat diandalkan.

Berikut ini ringkasan ide-ide seperti pemikiran Rob Pike 1989 :

Data mendominasi. Jika Anda memilih struktur data yang tepat dan mengatur semuanya dengan baik, maka algoritme akan hampir selalu terbukti dengan sendirinya. Struktur data, bukan algoritma, memainkan peran sentral dalam pemrograman.

Ia mengutip Fred Brooks dari 1975 :

Presentasi adalah inti dari pemrograman

Di belakang penguasaan adalah kecerdikan yang membuat
program ekonomis dan cepat. Ini hampir selalu hasilnya
terobosan strategis, bukan keterampilan taktis. Terkadang begitu strategis
terobosan adalah suatu algoritma, seperti transformasi Fourier cepat,
diusulkan oleh Cooley dan Tukey, atau mengganti perbandingan n ² dengan n log n saat menyortir.

Lebih sering, terobosan strategis muncul sebagai hasil dari presentasi
data atau tabel. Inti dari program ada di sini. Tunjukkan pada saya diagram alur tanpa menunjukkan tabel, dan saya akan tetap tersesat. Tunjukkan padaku milikmu
tabel dan diagram alur kemungkinan besar tidak diperlukan: mereka akan jelas.

Jadi, selama hampir setengah abad, orang-orang pintar berkata berulang-ulang: fokus pada data terlebih dahulu. Tetapi kadang-kadang tampaknya ini adalah saran paling cerdas yang dilupakan semua orang.

Saya akan memberikan beberapa contoh nyata.

Sistem sangat skalabel yang gagal

Sistem ini awalnya dibuat dengan harapan skalabilitas luar biasa dengan beban besar pada CPU. Tidak ada yang sinkron. Di mana-mana callback, antrian, dan kolam kerja.

Tapi ada dua masalah. Yang pertama adalah bahwa "beban prosesor" tidak begitu kuat - satu tugas mengambil maksimum beberapa milidetik. Jadi sebagian besar arsitektur tidak lebih berbahaya daripada kebaikan. Masalah kedua adalah bahwa "sistem terdistribusi sangat scalable" sebenarnya hanya bekerja pada satu mesin. Mengapa Karena semua komunikasi antara komponen asinkron dilakukan menggunakan file dalam sistem file lokal, yang sekarang telah menjadi penghambat untuk setiap penskalaan. Desain aslinya tidak terikat dengan data sama sekali, dengan pengecualian melindungi file lokal atas nama "kesederhanaan." Bagian utama dari proyek ini dikhususkan untuk semua arsitektur tambahan ini, yang "jelas" diperlukan untuk mengatasi "beban berat" pada CPU.

Arsitektur Berorientasi Layanan Yang Tetap Berorientasi Data

Sistem ini mengikuti desain microservices dari aplikasi tujuan tunggal dengan REST API. Salah satu komponen adalah database di mana dokumen disimpan (terutama jawaban untuk bentuk standar dan dokumen elektronik lainnya). Secara alami, dia mengatur API untuk menyimpan dan mengambil data, tetapi cukup cepat ada kebutuhan untuk fungsi pencarian yang lebih kompleks. Pengembang menganggap bahwa menambahkan fungsi ini ke dokumen API yang ada bertentangan dengan prinsip-prinsip desain layanan mikro. Karena 'pencarian' pada dasarnya berbeda dari 'get / put', arsitektur tidak boleh menggabungkannya. Selain itu, mereka berencana untuk menggunakan alat pihak ketiga untuk bekerja dengan indeks, sehingga pembuatan 'pencarian' layanan baru juga masuk akal karena alasan ini.

Akibatnya, API pencarian dan indeks pencarian dibuat, yang pada dasarnya menjadi duplikat data dalam database utama. Data ini diperbarui secara dinamis, sehingga setiap komponen yang mengubah data dokumen melalui API basis data utama juga harus mengirim permintaan untuk memperbarui indeks melalui API pencarian. Menggunakan REST API, ini tidak dapat dilakukan tanpa kondisi balapan, sehingga dua set data terkadang tidak sinkron.

Terlepas dari apa yang dijanjikan arsitektur, kedua API terkait erat melalui dependensi datanya. Kemudian, para pengembang mengakui bahwa indeks pencarian harus dikombinasikan dengan layanan dokumen umum, dan ini membuat sistem jauh lebih mudah dikelola. Doing One bekerja pada level data, tetapi tidak pada level kata kerja.

Lumpur yang luar biasa modular dan dapat dikonfigurasi

Sistem ini adalah semacam pipa penyebaran otomatis. Tim pengembangan asli ingin membuat alat yang cukup fleksibel untuk menyelesaikan masalah penyebaran di seluruh perusahaan. Mereka menulis satu set komponen plug-in dengan sistem file konfigurasi yang tidak hanya mengkonfigurasi komponen, tetapi juga bertindak sebagai bahasa khusus domain (DSL) untuk pemrograman bagaimana komponen masuk ke dalam pipa.

Maju cepat ke beberapa tahun, dan alat berubah menjadi "program yang sebenarnya." Ada daftar panjang kesalahan yang diketahui yang tidak pernah diperbaiki oleh siapa pun. Tidak ada yang mau menyentuh kode karena takut merusak sesuatu. Tidak ada yang menggunakan fleksibilitas DSL. Semua pengguna menyalin dan menempel konfigurasi yang dijamin bekerja sama seperti orang lain.

Apa yang salah? Meskipun dokumen proyek asli sering menggunakan kata-kata seperti "modular," "terputus," "diperluas," dan "kebiasaan," ia tidak mengatakan apa-apa tentang data tersebut. Dengan demikian, ketergantungan data antara komponen diproses dengan cara yang tidak diatur menggunakan gumpalan JSON yang umum secara global. Seiring waktu, komponen membuat asumsi yang semakin tidak berdokumen tentang apa yang termasuk atau tidak termasuk dalam gumpalan JSON. Tentu saja, DSL memperbolehkan komponen untuk diatur ulang dalam urutan apa pun, tetapi sebagian besar konfigurasi tidak berfungsi.

Pelajaran

Saya memilih ketiga proyek ini, karena mudah untuk menjelaskan tesis umum menggunakan contoh mereka, tanpa menyentuh yang lain. Suatu kali saya mencoba membuat sebuah situs web, dan malah menggantungkan semacam database XML yang tidak berguna yang bahkan tidak menyelesaikan masalah data saya. Ada proyek lain yang berubah menjadi kemiripan setengah dari fungsi make , lagi karena saya tidak berpikir apa yang sebenarnya saya butuhkan. Saya sudah menulis tentang waktu yang dihabiskan untuk membuat hierarki kelas OOP tanpa akhir yang seharusnya disandikan dalam data .

Perbarui:

Rupanya, banyak yang masih berpikir bahwa saya mencoba mengolok-olok seseorang. Rekan kerja saya yang sebenarnya tahu bahwa saya jauh lebih tertarik untuk memperbaiki masalah nyata, dan tidak menyalahkan mereka yang menghasilkan masalah ini, tetapi, oke, ini yang saya pikirkan tentang pengembang yang terlibat dalam proyek ini.

Jujur, situasi pertama jelas terjadi karena arsitek sistem lebih tertarik untuk menerapkan karya ilmiah daripada menyelesaikan masalah nyata. Banyak dari kita dapat disalahkan untuk ini (saya juga), tetapi itu benar-benar mengganggu rekan-rekan kita. Bagaimanapun, mereka harus membantu dalam dukungan ketika kita bosan dengan mainan. Jika Anda mengenali diri Anda sendiri, jangan tersinggung, silakan berhenti saja (meskipun saya lebih suka bekerja dengan sistem terdistribusi pada satu node daripada dengan sistem apa pun di "database XML" saya).

Dalam contoh kedua, tidak ada yang pribadi. Terkadang tampaknya semua orang di sekitar mengatakan betapa indahnya berbagi layanan, tetapi tidak ada yang membicarakan kapan lebih baik tidak melakukan ini. Orang sepanjang waktu belajar dari pengalaman pahit mereka sendiri.

Kisah ketiga sebenarnya terjadi pada beberapa orang terpintar yang pernah bekerja dengan saya.

(Akhir pembaruan).

Pertanyaan "Apa yang dikatakan tentang masalah yang dibuat oleh data?" Ternyata tes lakmus cukup berguna untuk desain sistem yang baik. Juga sangat mudah untuk mengidentifikasi "ahli" palsu dengan saran mereka. Masalah dengan arsitektur sistem yang rumit dan rumit adalah masalah data, sehingga para pakar palsu suka mengabaikannya. Mereka akan menunjukkan kepada Anda arsitektur yang sangat indah, tetapi mereka tidak akan mengatakan apa-apa tentang data apa yang cocok untuknya, dan (penting) data apa yang tidak cocok untuk itu.

Sebagai contoh, seorang ahli palsu mungkin mengatakan bahwa Anda harus menggunakan sistem pub / sub karena sistem pub / sub digabungkan secara longgar dan komponen yang digabungkan secara longgar lebih dapat dipelihara. Kedengarannya indah dan memberikan diagram yang indah, tetapi itu adalah kebalikan dari pemikiran. Pub / sub tidak membuat komponen Anda digabungkan secara longgar; pub / sub itu sendiri secara longgar digabungkan, yang mungkin atau mungkin tidak sesuai dengan kebutuhan data Anda.

Di sisi lain, arsitektur berorientasi data yang dirancang dengan baik sangat penting. Pemrograman fungsional, service mesh, RPC, pola desain, loop acara, apa pun, setiap orang memiliki kelebihannya masing-masing. Tetapi secara pribadi, saya melihat bahwa sistem produksi yang jauh lebih berhasil bekerja pada DBMS lama yang membosankan .