Get best of the week

Insinyur Data atau mati: kisah pengembang tunggal

Pada awal Desember, saya membuat kesalahan fatal, membuat keputusan penting dalam hidup saya sebagai pengembang, dan dipindahkan ke tim Rekayasa Data (DE) di dalam perusahaan. Dalam artikel ini saya akan membagikan beberapa pengamatan yang saya buat selama dua bulan bekerja di tim DE.




Mengapa Rekayasa Data?


Perjalanan saya ke DE dimulai pada musim panas 2019, ketika kami Xnegpergi ke Sekolah Komputer Terdistribusi , dan di sana saya mencapai pencerahan. Saya mulai tertarik pada topik, mempelajari algoritma dan bahkan menulis tentangnya , dan kemudian saya berpikir tentang bidang aplikasi dan dengan cepat menemukan bahwa aplikasi praktis di perusahaan kami adalah database terdistribusi.

Apa yang dilakukan tim kami secara umum? Kami, seperti semua anak laki-laki dan perempuan modis, ingin menjadi Perusahaan Berbasis Data. Dan untuk memungkinkan hal ini, kita harus setidaknya membangun repositori yang andal, yang memungkinkan untuk membuat laporan yang diperlukan oleh perusahaan. Tetapi yang paling penting adalah bahwa data dalam penyimpanan ini harus dipercaya. Selain itu, menurut data ini, seseorang harus dapat mengembalikan keadaan sistem pada waktu t. Semua ini diperumit oleh kenyataan bahwa kita hidup dalam dunia baru dari layanan-layanan mikro, dan ideologi ini menyiratkan bahwa setiap layanan mengimplementasikan fungsi kecilnya, basis datanya adalah bisnisnya sendiri, dan dapat menghapusnya setidaknya setiap hari, tetapi pada saat yang sama kita harus Mampu menerima dan memproses status layanan.

Ingin menjadi Data Driven, pertama-tama menjadi Event Driven


Tidak sesederhana itu. Peristiwa berbeda, dan pengembang dan insinyur tanggal melihatnya secara berbeda. Pembicaraan tentang peristiwa adalah topik dari artikel yang terpisah, jadi di sini saya tidak akan membahasnya. Selain itu, seseorang Martin Fowler sudah menulis artikel seperti itu , saya tidak akan mengambil kemenangan darinya, biarkan dia menjadi terkenal juga.

Secara umum, ada sesuatu untuk dipikirkan dan daerah itu menarik. Kebetulan di perusahaan kami Data Engineer adalah area tanggung jawab yang jauh lebih luas daripada hanya orang yang menulis saluran pipa ETL / ELT (jika Anda tidak tahu apa arti singkatan ini - datanglah ke mitap . Sebagai iklan kontekstual ).

Kami terlibat dalam arsitektur membangun gudang, dan memodelkan data, dan masalah yang terkait dengan keamanan data, dan jaringan pipa itu sendiri, tentu saja. Dan kita perlu memastikan bahwa, di satu sisi, pengembang produk tidak terlalu membebani kehadiran kita dan harus sesedikit mungkin terganggu oleh persyaratan kita ketika mereka melihat fitur-fitur baru dalam sistem, dan di sisi lain, kita perlu menyediakan penyimpanan yang nyaman data untuk analis dan tim BI. Begitulah cara kita hidup.

Kesulitan dalam bergerak dari pembangunan


Pada hari pertama pekerjaan saya, saya menghadapi sejumlah kesulitan yang ingin saya bagikan dengan Anda.

1. Hal pertama yang saya lihat adalah kurangnya penyetelan dan beberapa latihan. Ambil, misalnya, cakupan kode dengan tes. Dalam pengembangan, kami memiliki ratusan kerangka kerja untuk pengujian. Saat bekerja dengan data, semuanya lebih rumit. Ya, kami dapat menguji pipa ETL pada data uji, tetapi kami harus melakukan semua ini dengan tangan kami sendiri dan mencari solusi untuk setiap kasus tertentu. Akibatnya, cakupan tes jauh lebih buruk. Untungnya, ada lapisan umpan balik lain dalam bentuk pemantauan dan log, tetapi ini sudah mengharuskan kita untuk bereaksi daripada proaktif, yang membuat kita marah .

2. Dunia dari posisi DE, sama sekali tidak seperti pengembang produk biasa (well, tentu saja, pembaca tidak seperti itu, dan dia sudah tahu segalanya, tapi saya tidak tahu dan sekarang dia menyapu). Sebagai seorang pengembang, saya melihat layanan mikro saya, memasukkan data ke dalam [basis data pilihan Anda], menyimpan status saya di sana, mendapatkan sesuatu dengan ID dan itu normal. Layanan berputar, pesanan berlumpur, itu saja. Mereka meminta saya di layanan lain untuk meraba-raba keadaan saya, well, saya akan mengadakan suatu acara ke RabbitMQ dan hanya itu. Dan di sini kita kembali lagi ke masalah peristiwa yang dijelaskan di atas.

Apa yang dibutuhkan layanan untuk pekerjaan operasional tidak sesuai dengan kami untuk data historis, pertanyaan tentang pemrosesan kontrak layanan dan bekerja sama dengan tim pengembangan dimulai. Anda bahkan tidak dapat membayangkan berapa jam yang diperlukan untuk menyetujui: acara apa yang didorong olehnya di perusahaan kami.

3. Anda harus berpikir dengan kepala Anda. Tidak, saya tidak bermaksud bahwa pengembang tidak berpikir (walaupun siapa saya harus berbicara untuk semua orang), hanya saja dalam pengembangan produk Anda sering sudah memiliki semacam arsitektur, dan Anda memotong berbagai jaminan simpanan. Tentu saja, ini memerlukan perencanaan dan refleksi, tetapi ini adalah pekerjaan streaming, di mana masalah utamanya cukup bagus dan berkualitas tinggi untuk dilakukan.

Ini tidak begitu sederhana di sini karena transfer berbagai komponen sistem dari monolit yang hangat dan nyaman ke dunia hutan layanan mikro liar tidak begitu sederhana. Ketika layanan mulai disiram dengan peristiwa, Anda perlu merevisi logika mengisi penyimpanan, karena data sekarang terlihat berbeda. Di sini Anda perlu berpikir banyak dan menyeluruh, bukan sebagai pengembang, tetapi sebagai insinyur data. Ini adalah cerita normal ketika Anda menghabiskan berhari-hari dengan buku catatan dan pena atau dengan spidol di dekat papan tulis. Sangat sulit, saya tidak suka berpikir, saya suka ara dan produksi.

4. Mungkin yang paling penting adalah informasi. Apa yang kita lakukan ketika kita kekurangan pengetahuan? Siapa bilang stackoverflow? Bawa orang ini keluar dari kamar. Kami akan membaca dokumen, buku tentang topik tersebut, dan masih ada komunitas yang menyelenggarakan forum, pertemuan, dan konferensi. Dokumentasinya keren, tapi sayangnya tidak lengkap. Kami menggunakan Cosmos DB di sejumlah proyek. Selamat membaca dokumentasi untuk produk ini. Buku adalah satu-satunya keselamatan, untungnya, mereka ada dan dapat ditemukan, mereka memiliki banyak pengetahuan mendasar dan Anda harus banyak membaca dan terus-menerus. Namun komunitas tersebut dalam kesulitan.

Sekarang dalam arahan kami, sulit untuk menemukan setidaknya satu konferensi atau pertemuan yang memadai. Tentu saja, ada banyak mitaps dengan kata Data, tetapi singkatan aneh seperti ML atau AI biasanya muncul di sebelah kata ini. Jadi, ini bukan untuk kita, kita berbicara tentang cara membangun fasilitas penyimpanan, dan bukan cara mengolesi neuron. Hipsters ini mengisi segalanya. Akibatnya, kami tanpa komunitas. Omong-omong, jika Anda seorang Insinyur Data dan mengenal komunitas yang baik, silakan tulis di komentar.

Kesimpulan dan pengumuman mitap


Apa yang kita miliki pada akhirnya? Pengalaman pertama saya memberi tahu saya bahwa merasa seperti seorang insinyur akan bermanfaat bagi setiap pengembang. Itu hanya memungkinkan Anda untuk melihat hal-hal secara berbeda dan tidak terkejut ketika mata kita berdarah melihat bagaimana pengembang memperlakukan data mereka. Jadi, jika perusahaan Anda memiliki DE, cukup mengobrol dengan orang-orang ini dan belajar banyak (tentang diri Anda).

Dan akhirnya, pengumuman. Karena tidak mungkin menemukan mitaps pada topik kami di siang hari, kami memutuskan untuk membuatnya. Dan apa, apa yang lebih buruk dari kita? Untungnya kami punya yang luar biasaSchvepsssdan teman-teman kita dari Lab Profesi Baru , yang, seperti kita, berpikir bahwa insinyur kencan tidak mendapat perhatian secara adil.

Saya mengambil kesempatan ini untuk mengundang semua yang terkait untuk datang ke pertemuan komunitas pertama kami dengan nama yang menjanjikan "DE atau DIE", yang akan diadakan pada 02.27.2020 di kantor Dodo Pizza. Detail tentang TimePad .

Jika ada, saya akan berada di sana, Anda dapat memberi tahu saya secara pribadi, betapa salahnya saya tentang pengembang.

More articles:


All Articles