Bagaimana DBA bisa lebih 'ramah programmer'?

Jawaban dan komentar pada versi dba.se dan versi programmer dari pertanyaan "Apa argumen yang menentang atau untuk menempatkan logika aplikasi di lapisan database?" sangat mengungkapkan tentang kesenjangan antara DBA dan programmer di beberapa tempat kerja.

Apa yang bisa dilakukan DBA secara berbeda untuk bekerja lebih baik dengan programmer pada masalah seperti ini?

Haruskah kita:

• Pelajari alat dan bahasa yang digunakan oleh programmer kami untuk memahami kesulitan yang mereka hadapi, terutama ketika bekerja dengan database yang dirancang dengan baik?
• Mendorong pemrogram untuk lebih terdidik tentang database dan keuntungan memiliki logika bisnis di tingkat basis data?
• Ubah cara kami mendefinisikan antarmuka ke data kami - seperti dengan menggunakan API transaksional yang lebih ramah bagi programmer (mis. Untuk masalah seperti kompatibilitas mundur)?

Dari sudut pandang Programmer, saya akan mengatakan hal yang paling kita inginkan adalah standar yang konsisten, didefinisikan dengan baik dan diimplementasikan untuk bagaimana lapisan data akan dirancang dan dibangun. Saya bersedia untuk bermain seperti yang Anda inginkan di kotak pasir Anda, Anda hanya perlu memberi tahu saya apa yang Anda inginkan, dan tidak mengubah aturan setiap saat. Itu harus diimplementasikan sama untuk semua orang, bahkan superprogrammergod. Jika Anda membuat pengecualian untuknya maka Anda ingin saya mendukung dan mengubahnya tetapi menerapkannya kembali dengan cara yang benar yang tidak berhasil untuk saya.

Dan tolong jangan katakan padaku untuk tidak melakukannya dan berjalan pergi. Bekerjalah dengan saya untuk menunjukkan kepada saya apa yang Anda inginkan, dan mengapa cara Anda lebih baik. Jika saya mengerti saya akan mematuhi setiap waktu. Ketika saya tidak mengerti maka lebih sulit untuk mematuhinya. Saya tidak ingin menjadi DBA. Saya suka pemrograman Saya tidak ingin pekerjaan Anda dan jika Anda seorang DBA yang baik maka saya akan menjadi penggemar terbesar Anda.

Saya telah menjadi DBA MySQL selama 6,5 ​​tahun terakhir. Saya juga menghabiskan 16 tahun sebagai pengembang dan telah berinteraksi dengan banyak DBA. Banyak dari mereka yang pragmatis. Beberapa dari mereka menjengkelkan. Beberapa tidak tahu apa artinya menjadi DBA.

Saya sampai pada kesimpulan ini:

Secara teknis, DBA yang memiliki satu atau lebih kualitas berikut adalah yang terbaik untuk digunakan:

1. Selama bertahun-tahun sebagai pengembang sendiri
2. Pahami teori basis data
3. Memiliki pemahaman yang baik tentang bagaimana RDBMS bekerja secara internal
4. Memiliki pengetahuan yang unggul tentang sistem operasi

DBA yang sangat disiplin dan berpengetahuan memiliki banyak hal untuk dibagikan dan ditawarkan. Mereka mungkin melihat kinerja database dari perspektif yang tidak benar-benar dipertimbangkan oleh Pengembang. Pengembang tahu apa yang mereka inginkan dari database. DBA tahu bagaimana bersikap "sopan" ke database.

Sejauh kepribadian pergi, akan selalu ada konflik, kepicikan, dan bahkan mungkin iri. Satu hal yang pasti: Tanpa urutan tertentu, DBA dan Pengembang seperti suami dan istri (saya sudah menikah bahagia selama 16 tahun dengan proyek yang sedang berjalan [4 anak]).

Terlepas dari siapa yang dipandang sebagai suami dan siapa yang dipandang sebagai istri, prinsip-prinsip ini berlaku:

1. yang satu harus berkonsultasi dengan yang lain
2. yang satu harus menghargai perspektif yang lain
3. kita harus membuat keputusan untuk kebaikan kedua belah pihak
4. seseorang harus mendukung, dan bukan sabatoge, keputusan yang diambil
5. seseorang tidak boleh merendahkan yang lain jika keputusan menghasilkan konsekuensi buruk
6. kita harus bersukacita dalam kontribusi kedua belah pihak untuk keberhasilan keputusan
7. seseorang harus berkonsultasi dengan otoritas yang lebih tinggi (HA) jika keputusan tidak dapat disepakati bersama

Tujuh (7) prinsip ini berlaku sama banyaknya di tempat kerja, terutama di bidang TI.

Dengan mengkomunikasikan setiap langkah, semua harus:

1. tata letak harapan mereka
2. menimbulkan rasa hormat untuk kemampuan pihak lain untuk melakukan bagian mereka berdasarkan kinerja masa lalu
3. memiliki kepercayaan dan keyakinan bahwa pihak lain dapat menyelesaikan tugas mereka
4. memenuhi harapan kita sendiri
5. menyetujui di bawah bimbingan HA (lihat prinsip # 7)

Tidak ada ruang untuk manajemen mikro dalam hal ini. DBA TIDAK HARUS MENGATAKAN Pengembang bagaimana berpikir seperti DBA. Pengembang TIDAK HARUS MENGATAKAN DBA bagaimana menjadi Pengembang. Keputusan akhir tentang kinerja dan penggunaan basis data harus ada pada DBA . Keputusan akhir tentang kebutuhan aplikasi harus berada di tangan Pengembang . Simbiosis ini harus selalu dijaga.

PIKIRAN FINAL

Prinsip # 7 membutuhkan partisipasi aktif dan pengawasan oleh OTORITAS TINGGI (HA), yaitu manajer proyek, pemimpin tim, pengembang utama. HA Anda lebih tahu bagaimana kedua belah pihak bekerja secara individual dan bagaimana kedua belah pihak harus bekerja sama. Jika HA tidak menetapkan aturan dasar untuk kedua belah pihak, atau jika HA gagal untuk memandu para pihak secara individu dan bersama-sama, proyek akan selalu berhenti di beberapa titik dan membahayakan keberadaan (pekerjaan) dari Pengembang, DBA, atau bahkan HA.

Memiliki tim yang duduk di berbagai bagian / lantai entah bagaimana tampaknya mendorong mentalitas "kita vs mereka".

Duduk DBA tepat di tengah-tengah tim pengembangan adalah cara yang bagus untuk merobohkan tembok programmer / DBA. Baik DBA dan programmer akan mendapat manfaat dari ini, jika mereka tetap berpikiran terbuka dan mengesampingkan ego mereka.

Komunikasi tatap muka, terutama ketika berbagi ide, jauh lebih efektif daripada email dan memiliki lebih sedikit kesempatan untuk menimbulkan perasaan sulit karena kesalahpahaman.

Hal semacam ini sangat bervariasi dari satu tempat ke tempat lain. Di situs saya saat ini, garis antara pengembang dan DBA memang sangat kabur - kami (DBA) juga menulis PL / SQL, dan mereka (pengembang) membedah rencana permintaan. Kita semua melihat diri kita sebagai teman sebaya, hanya dengan keahlian dan tanggung jawab yang berbeda. Ini sangat lucu: baru-baru ini perusahaan telah ikut-ikutan DevOps . Komunitas basis data tidak memahami ini sama sekali; kami selalu bekerja seperti itu. Tidak perlu dikatakan kita sangat produktif bekerja seperti ini: tingkat basis data sejauh inibagian paling andal dari tumpukan teknologi perusahaan, mudah dioperasikan (karena kami memiliki keterampilan dalam tim DBA untuk memahami aplikasi pada tingkat yang dalam, dan pengembang memiliki paparan DBA untuk memahami operasi 24/7/365 dan bagaimana untuk menyusun aplikasi mereka untuk itu).

Tapi saya tahu apa yang Anda maksud ketika Anda berbicara tentang jenis pengembang yang "salah". Dia otodidak, yang dengan sendirinya adalah hal yang mulia, tetapi sepanjang jalan dia mengambil ketidakpercayaan terhadap segala macam instruksi formal. Dia tidak tahu apa yang tidak dia ketahui , dan dia membenci siapa pun yang mencoba mencerahkannya, dia melihatnya sebagai penghinaan terhadap keterampilan belajar mandiri. Dia telah mempelajari gaya pemrograman yang sangat penting, karena Anda dapat mempelajarinya tanpa teori apa pun yang selalu dikerjakan oleh tipe CS (well, bad; semua orang perlu tahu besar-Odan bit teori serupa). Dia juga belajar sedikit OO, hanya karena dia harus menggunakan Java. Tetapi profesional basis data yang baik - pengembang atau DBA - harus berpikir nyaman dalam gaya deklaratif, berpikir tentang teori himpunan, bentuk normal, bahkan mampu memahami aljabar dan kalkulus relasional. Sangat, sangat sulit untuk berkomunikasi dengan orang-orang ini, karena mereka secara aktif memusuhi apa pun yang mungkin menyentak mereka keluar dari zona nyaman mereka, yang pada umumnya terbatas pada cara memformat sesuatu di halaman web. Jika mereka berpikir tentang database sama sekali, mereka berpikir bahwa tabel seperti kelas dan baris seperti objek. Orang-orang ini benar-benar hanya akan melakukan SELECT * FROM TABLEdan memfilter dan mengurutkan hasil dalam kode mereka sendiri. Mereka benar-benar tidak mengerti mengapa database lebih baik daripada file flat (dan mereka tidak begitu diam-diam berpikir siapa pun yang menggunakan database relasional adalah idiot).

Biarkan saya memberi Anda contoh nyata: baru-baru ini saya berbicara dengan salah satu dari jenis ini tentang masalah yang terlibat dalam memutar kembali rilis perangkat lunak kami setelah masuk ke produksi, jika masalah telah melewati QA. Saya menjelaskan bahwa sementara kita mungkin memutar kembali aplikasinya (salah satu dari banyak mengakses database), itu harus dapat beroperasi dengan database masih dikerahkan. Dia bertanya mengapa, dan saya berkata, yah, di tabel dan kolom baru itu, akan ada data pelanggan nyata. Dia kemudian berkata, jadi salin saja ke tabel sementara, apa masalahnya. Saya menatapnya dengan tak percaya: ketika seorang pelanggan menelepon dan mengatakan, uang saya telah hilang dari akun saya, apa yang kami katakan kepadanya, bahwa tidak apa-apa, itu ada di meja sementara? Dia sama sekali tidak mengerti bahwa ketika Anda berurusan dengan uang orang lain, Anda harus bertindak seperti orang dewasa yang bertanggung jawab. Sejauh yang saya tahu dia masih belum; dia tidak lagi bersama kita.

Camp MySQL seperti ini untuk waktu yang lama; mereka akan mengatakan Anda tidak perlu transaksi, kunci asing, dll, jika Anda pikir Anda melakukannya hanya karena Anda tidak tahu apa yang Anda lakukan, dll, dll (kemudian ketika mereka dewasa, mereka diam-diam menambahkannya). Ini adalah jenis ORM seperti ActiveRecord atau Hibernate yang dikembangkan untuk orang, sehingga mereka dapat menulis aplikasi basis data tanpa perlu menyentuh SQL. Penggunaan teknologi ini saya anggap sebagai bendera merah - ini bukan perusahaan yang menghargai keterampilan DBA. Apa yang sebenarnya mereka inginkan adalah pengasuh ...

Sebagai seorang programmer yang memahami database dengan lebih baik, menjadikan saya seorang programmer yang lebih baik. Ketika saya menjadi administrator basis data, ini menjadi lebih penting, oleh karena itu saya percaya bahwa pendidikan adalah kuncinya.

DBA harus dengan sabar memandu pengembang memperlakukan mereka sebagai profesional yang kompeten. Beberapa programmer ketika ditunjukkan perbedaan antara operasi yang ditetapkan dan operasi baris demi baris di sisi klien akan menolak gagasan itu. Kami berbagi beberapa tujuan yang sama - kecepatan aplikasi, keamanan data, pemeliharaan, dll. Ini berlaku tidak hanya untuk pertanyaan logika aplikasi, tetapi juga untuk semua aspek interaksi basis data. Pemrogram ingin menggunakan alat mereka lebih baik dan semakin banyak DBA dapat menunjukkan kepada mereka cara menggunakan alat basis data lebih baik, semakin banyak manfaat bagi mereka berdua.

Apa pun infrastruktur yang kami dukung, kami harus mendukung pengguna itu. Banyak pengguna adalah pengembang, jadi kami mendukung pengembang untuk memungkinkan mereka memanfaatkan sebaik mungkin infrastruktur itu. Untuk dapat melakukan ini, kita perlu saling memahami, dengan pemikiran dan pandangan yang berbeda. Memiliki wawasan untuk pandangan dari kedua belah pihak membantu untuk membuat hal-hal yang lebih baik untuk bisnis dan itulah tujuan gabungan kami. Jadikan TI mendukung bisnis seefektif mungkin.

Di banyak organisasi kita melihat beberapa tipe dba berjalan dalam mode dewa. Sebagian besar kali ini bukan yang skor sangat baik jika kompetensi diukur ..... Seringkali mereka hanya menyembunyikan - kurangnya - pengetahuan mereka di balik dinding kata-kata.

Menurut pendapat saya itu tidak ada hubungannya dengan menjadi 'ramah programmer' lebih dengan menjadi profesional. Untuk dba itu berarti kita harus dapat menjelaskan mengapa kita melakukan hal-hal yang kita lakukan dan bersiap untuk mengambil keputusan mempertimbangkan kembali jika itu membantu, tanpa kehilangan tujuan normal seperti ketersediaan, skalabilitas, pemulihan dan kinerja. Untuk programmer itu berarti dia harus berkomunikasi dengan dba, kadang-kadang untuk mengajar dba, kadang-kadang belajar dari dba. Moto saya tentang ini adalah: biarkan hari pertama yang saya tidak pelajari menjadi hari peti mati ditutup di atas kepala saya. Kolaborasi normal, memiliki tim gabungan dengan pengembang dan dba tentu saja membantu mempermudah.

Saya pikir bagian dari masalah adalah perspektif. DBA dan analis data serta pengembang basis data harus berurusan dengan data seiring waktu. Pengembang aplikasi peduli dengan cara membuat sesuatu bekerja ketika mereka mengirimkannya ke produksi. Mereka tidak begitu khawatir tentang bagaimana data akan terlihat dalam enam bulan selama tidak ada kesalahan saat digunakan.

Tetapi orang-orang data harus hidup dengan hasil keputusan picik yang menyebabkan data kehilangan integritas atau menyebabkan duplikat catatan untuk dimasukkan dan kemudian mencoba menjelaskan mengapa data itu buruk. DBA adalah orang-orang yang harus berurusan dengan masalah kinerja dari proses yang bekerja dengan baik ketika hanya ada seribu catatan, tetapi sekarang membutuhkan berjam-jam dengan 100.000.000 catatan.

Database lebih sulit untuk di-refactor, jadi DBA prihatin dengan memperbaikinya pertama kali. Pengembang tidak melihat ada masalah dalam refactoring di jalan.

Pengembang tidak melihat masalah dengan membuat basis data bertindak seolah-olah berorientasi objek, basis data orang tahu bahwa itu bukan cara yang paling efektif atau efisien untuk menyimpan atau mendapatkan data.

Pengembang aplikasi seringkali hanya berurusan dengan sebagian kecil catatan tetapi tidak dengan impor / ekspor atau pelaporan data yang besar. Hal-hal yang bekerja dengan baik untuk memasukkan satu catatan, jangan bekerja ketika Anda berbicara tentang mengimpor satu juta. Logika bisnis dalam aplikasi (yang seringkali tidak dapat diakses oleh aplikasi pelaporan) tidak membantu penulis laporan mendapatkan hasil yang sama untuk sejuta catatan seperti apa yang ditampilkan di layar satu catatan pada satu waktu.

Bagian lain dari masalah adalah rasa tidak hormat di kedua sisi. Saya telah bertemu lebih dari beberapa pengembang aplikasi yang menganggap pekerjaan data tidak sulit atau menarik dan yang percaya bahwa Anda hanya akan melakukan pekerjaan ini jika Anda tidak dapat meretasnya di dunia mereka. Orang cenderung tidak bereaksi dengan baik diperlakukan seolah-olah mereka bodoh dan tidak berguna. Beberapa DBA di sisi lain cenderung memperlakukan pengembang aplikasi dengan tidak hormat juga dan cenderung menempatkan tugas mereka meninjau apa yang dilakukan pengembang terhadap basis data sebagai prioritas rendah (yang ketika Anda memiliki basis data produksi kompleks yang besar, mungkin). Mereka dapat menolak untuk mendengar atau bersikap responsif. Siapa yang ingin seluruh proyeknya ditunda sampai DBA meninjaunya dua minggu kemudian? Dan kemudian dia mengatakan itu tidak dapat diterima dan Anda harus menulis ulang semuanya?

Selama bertahun-tahun sejak saya mulai dengan SQL Server (1998), saya memiliki banyak pengembang yang memberi tahu saya bagaimana melakukan pekerjaan saya. Sangat menarik bahwa mereka semua tahu lebih dari saya dan juga menjadi pengembang .net yang hebat . Bahkan, mereka juga arsitek dan harus melakukan hal-hal yang lebih besar daripada kode monkeying.

Mungkin itu sikap yang salah dari saya: tetapi itu adalah sikap pengembang yang cukup umum di banyak toko. Mereka juga melakukannya satu sama lain, ingat: saksikan pertarungan dimulai ketika Anda menyarankan peer review.

Saya akan menyerahkan perbaikan ke jawaban lain (saya setuju 100% dengan 2 sejauh ini) tetapi menambahkan bahwa manajemen dan budaya toko harus mendukung dan memelihara kolaborasi juga.

Sebagai pengembang, yang saya butuhkan dari Anda hanyalah mengetahui bagaimana Anda ingin saya mengomunikasikan apa yang saya butuhkan. Jika saya meminta sesuatu yang konyol, saya perlu Anda memberi tahu saya - dan jika Anda memberi tahu saya, saya akan mempercayainya karena Anda memiliki rekam jejak integritas. Jika Anda tidak mengerti apa yang saya minta, luangkan waktu untuk menjelaskan kepada saya apa yang Anda pikir saya maksud - dan saya akan meluangkan waktu untuk mendengarkan.

... Tema umum, benar ... Komunikasi ... komunikasi ... komunikasi.

Sebenarnya tidak ada cara yang lebih baik untuk mengatakannya. Pengembang dikecewakan karena, "bahwa DBA mengatakan kepada saya bahwa itu tidak dapat dilakukan - saya benar-benar membuktikannya salah kali." DBA dicentang karena, "pengembang itu tidak mengerti apa yang harus saya lakukan setiap kali ia mengubah spesifikasinya."

Pengembang dan DBA, seperti yang dinyatakan @Rolando, harus saling memahami. Ketika semuanya berakhir, kita berdua berbicara "Yang & Nol" - Anda akan berpikir itu akan menjadi pasangan yang baik. Kami memiliki 2 ranah tanggung jawab: DBA memiliki data, Pengembang mendapatkan sisa komputer. Tetapi tanpa data, programmer benar-benar tidak akan banyak yang bisa dilakukan.

Kami tidak memiliki DBA dan kadang-kadang menyakitkan. Sepotong saya yang ingin menjadi DBA satu dekade lalu akan merasa ngeri ketika saya melihat beberapa hal yang kita lakukan. Jika kita menyewa DBA besok, saya pikir saya akan mencium tanah yang dia jalani.

Di beberapa perusahaan, mungkin banyak, pengembangan produk cenderung mengabaikan siapa pun yang tidak menulis dalam bahasa yang dikompilasi. Datang waktu rilis, ada perlawanan karena admin jaringan, DBA, admin sistem, dukungan pengguna, dll. Masing-masing memiliki uji tuntas untuk diselesaikan. Sering ada sakit kepala karena aspek kunci dari lingkungan tidak dipertimbangkan. Ini secara alami menyebabkan ketegangan antar tim.

Siapa yang harus disalahkan di sini? Ms. Komunikasi.

Pengembang perlu memahami kode lingkungan yang akan digunakan. Orang-orang perlu diberi peringatan yang adil untuk beradaptasi. Ketika lingkungan tidak dapat beradaptasi karena alasan apa pun (keamanan, peralatan, kebijakan), perangkat lunak perlu beradaptasi. Jika ini terjadi selama proses desain & implementasi, semua orang senang. Jika tidak dimulai sampai waktu penyebaran, itu adalah dunia yang terluka.

Ya, tim perlu berbicara (dan mendengarkan) satu sama lain, tetapi manajer proyek / produk perlu menciptakan lingkungan tempat ini dapat terjadi.

Saya beruntung, di sebagian besar tempat saya bekerja, saling menghormati dan komunikasi telah menjadi bagian dari budaya.

Satu hal yang harus dipahami DBA yang baik adalah politik data. Saya mengajar pemrograman dan desain basis data untuk programmer berpengalaman dan beberapa DBA yang disusun selama beberapa tahun. Satu pertanyaan yang akan muncul secara teratur adalah ini: mengapa semua basis data di toko saya begitu politis?

Inilah jawaban standar saya: Jika database berguna, maka Anda berbagi data. Jika Anda berbagi data, maka Anda berbagi kekuatan. Ketika kekuasaan dibagi, politik terjadi.

Tidak masalah apakah Anda suka politik atau benci politik. Jika Anda akan melakukan pekerjaan basis data yang baik, biasakanlah.

Kebetulan, beberapa dari Anda hanya bekerja di lingkungan pengembangan. Ada DBA yang bekerja di sisi produksi pagar, dan memiliki sedikit interaksi dengan pengembang. Anda mungkin berpikir ada lebih sedikit politik dalam produksi. Masih ada lagi. Basis data produksi besar cenderung luas perusahaan dan misi penting.

Sedikit kerendahan hati mungkin bisa membantu sebagian dari Anda. ;)

Jelas ada argumen yang valid untuk kedua pendekatan, saya sarankan Anda mulai dengan mengakui itu. Pengembangan perangkat lunak adalah tentang membuat pengorbanan yang tepat. Jika ini adalah jalan dua arah, mungkin DBA juga harus tetap berpikiran terbuka.