Haruskah kode internal dibagikan dengan non-pengembang dalam suatu organisasi?

Di tempat saya bekerja, kami memiliki banyak pengembang dan banyak sekali kode yang menjalankan aplikasi milik kami yang digunakan oleh staf & pelanggan.

Kami juga memiliki banyak staf pendukung cerdas yang suka memahami cara kerja sistem kami untuk mendukung pelanggan kami dengan lebih baik, dan bahkan mungkin mengirimkan tambalan dari waktu ke waktu.

Haruskah kita membuka kode kita agar staf non-pengembangan kita dapat membaca? Faktor apa yang harus kita perhitungkan ketika membuat keputusan ini? Saya telah menemukan banyak argumen dan kontra-argumen dalam setiap cara & ingin membuat keputusan berdasarkan pengalaman orang lain serta risiko yang dipahami dengan baik.

Beberapa argumen sejauh ini:

• Kata sandi dalam VCS terbuka (solusi: singkirkan kata sandi - kata kunci tersebut seharusnya tidak ada di sana untuk memulai)
• Kode terbuka untuk serangan keamanan kotak putih (argumen balasan: ini hanya membuat penyerang jujur ​​/ malas)
• Staf pendukung dapat menanyakan pengembang "bagaimana" hal-hal bekerja (konter: mengajar pria memancing, dll)

Adakah yang membuka kode mereka kepada staf di organisasi mereka? Apakah itu menyebabkan masalah?

Saya kira tidak ada jawaban umum untuk ini. Organisasi sangat berbeda dalam ukuran, penyebaran geografis, budaya perusahaan, kebijakan hak cipta, jenis perangkat lunak yang dikembangkan, dll. Dll. Dll.

Misalnya untuk perusahaan yang mengembangkan jenis komoditas / infrastruktur perangkat lunak, mungkin mudah untuk membuka kode sumber, bahkan untuk membuka sumbernya, seperti yang dilakukan Cisco beberapa tahun lalu dengan perangkat lunak driver printer (IIRC).

Untuk perusahaan yang mengembangkan beberapa perangkat lunak berpemilik yang langka, yang berpotensi menyertakan algoritme khusus atau hal-hal yang memberi mereka keunggulan kompetitif di atas pesaing mereka, saya bisa sangat memahami jika mereka berusaha untuk menjaga kerahasiaan kode mereka. Misalnya AFAIK Google sangat membatasi jumlah orang yang diberikan akses penerapan algoritma pencarian inti mereka.

Juga sebuah organisasi multinasional saat ini tersebar di banyak negara, zona waktu dan budaya, dan untuk alasan keamanan, mereka mungkin mengelompokkan intranet mereka dan menggunakan firewall untuk mengontrol lalu lintas antara berbagai segmen / domain. Jadi, membuat repo SCM yang dapat diterima sebagai "seluruh perusahaan" mungkin sebenarnya membutuhkan banyak pekerjaan ekstra untuk sysadmin, dan risiko keamanan ekstra. Walaupun biasanya tidak membawa manfaat secara umum, karena pengusaha yang bekerja di benua yang berbeda pada hal-hal yang sama sekali berbeda bahkan mungkin tidak tahu tentang proyek kami di sini, apalagi berkontribusi secara positif.

Jadi, jika itu masuk akal di dalam departemen Anda , dan / atau untuk orang-orang yang terkait dengan proyek dengan cara tertentu, mengapa tidak. Tetapi secara umum, hanya demi "keterbukaan", saya tidak yakin itu sepadan.

Satu catatan terakhir: bahkan ketika orang-orang pendukung cerdas dan ingin berkontribusi patch, saya akan mengatakan kontribusi mereka harus selalu ditinjau oleh pengembang sebelum diintegrasikan ke dalam sistem.

Di sebagian besar organisasi tempat saya bekerja, repositori kode terbuka untuk semua pengembang.

Dalam beberapa itu juga digunakan untuk menyimpan dokumen (seperti spesifikasi dan persyaratan) untuk versi mereka bersama perangkat lunak. Dalam hal itu sebagian besar karyawan lain juga memiliki akses. Di mana repo hanya digunakan untuk kode, non-dev biasanya tidak memiliki akses - tapi saya tidak pernah mendengar ada yang mengeluh, jadi itu mungkin bukan masalah besar.

Saya akan merekomendasikan keterbukaan sebanyak mungkin - jadi jika orang ingin akses, berikan kepada mereka kecuali ada masalah yang jelas. Tapi itu benar-benar pertanyaan tentang budaya organisasi ...

Saya berbagi pandangan umum / pragmatis tentang ini dan mungkin juga tergantung pada sifat pekerjaan / organisasi juga. Tapi saya percaya bahwa basis kode harus terbuka untuk semua (juga akan menunjukkan keterbukaan dan kepercayaan dalam organisasi juga).

Saya juga bekerja dalam pengaturan yang sama seperti yang Anda sebutkan di mana kami memiliki tim suppor / helpdesk yang menangani permintaan pelanggan. Namun area kompleks tertentu dari sistem mereka memerlukan bantuan tambahan. Dalam kasus saya, basis kode terbuka untuk semua yang kami tidak mengalami masalah.

• Saya pikir dengan membuka basis kode anggota tim pendukung lain yang tertarik juga dapat memeriksa basis kode dan mengenal aturan bisnis / bidang yang mereka minati atau perlu menemukan jawaban (dan mungkin meningkatkan pemahaman teknis mereka dan melihat sesuatu berbeda dari rutin monoton jika waktu mengizinkan;)). Ini mungkin juga terbukti berguna ketika anggota tim pendukung mendapatkan masalah dan log pelanggan dan akan dapat menunjuk / membantu pada area yang mungkin dari kode di mana hal ini terjadi dengan melihat stacktrace misalnya (jelas akan tergantung pada masalah dll). Ini juga akan menghemat waktu dengan pengembang tetapi tergantung pada masalah tentunya.

Juga memiliki dokumentasi / wiki terkini dari produk yang berisi semua aturan / keputusan bisnis juga akan membantu. Tetapi tentu saja Anda perlu memastikan bahwa wiki terus diperbarui untuk memperbaiki perbaikan baru dan / atau perbaikan bug (di mana perubahan perilaku). Pikiran jujur ​​saya

Secara umum, dari sudut pandang organisasi - orang datang dan pergi; proyek (atau produk) perlu terus berkembang. Oleh karena itu, di sebagian besar organisasi, biasanya ada Buka untuk semua repositori untuk mempertahankan kode.

Biasanya ada hak akses dll. Untuk mencegah akses tanpa izin tanpa disadari (untuk mencegah pencurian kode, dll.) Tetapi kebanyakan petinggi tidak benar-benar dilarang dalam hal ini. Dalam suatu organisasi, seseorang harus memercayai orang (cukup) sehingga Anda dapat mempercayai mereka dengan kode. Menyembunyikan kode dari karyawan (atau kolega) adalah faktor pendorong motivasi yang hebat.

Dalam organisasi kami, bahkan ketika orang tidak benar-benar berkontribusi pada kode - mereka memiliki akses langsung ke kode yang membantu karena mereka berusaha untuk melawan / memperbaiki masalah di lapangan (dengan kepemilikan) daripada membuang barang-barang kembali ke pengembang dan tidur!