Apakah ada keuntungan bagi lingkungan pengembangan yang heterogen?

Saya bekerja dengan tim pengembang yang diberi pilihan untuk hardware dan software apa yang mereka jalankan. Perasaan kami adalah bahwa skenario ini memungkinkan kami melihat berbagai sistem target sebelum melakukan tes. Pengalaman kami adalah bahwa kami menemukan sejumlah masalah aneh di berbagai browser dan sistem operasi segera setelah pengenalan masalah. Tapi itu hanya pengalaman satu kelompok.

Variasi sistem ini sulit bagi tim infrastruktur dan keamanan kami, sehingga sering muncul sebagai titik penghambat.

Apakah lebih menguntungkan untuk memiliki lingkungan pengembangan yang homogen atau heterogen pada tim pengembang?

development-process

— Ben
sumber

Sebagian besar masalah pengembangan perangkat lunak seperti ini tidak diteliti secara otoritatif. Jika Anda mencari cara untuk meyakinkan atasan atau rekan kerja Anda, Anda perlu mencari cara lain untuk melakukannya. Yang mengatakan, lihat di sini: netlib.org/utk/papers/practical-hetro/node2.html

— Robert Harvey

Saya pikir ini layak untuk pengujian kelompok Anda sendiri. Dengan cara ini Anda dapat melihat apakah Anda mempertahankan manfaat bagi pengembang ketika diminta untuk menggunakan lingkungan yang homogen bersama dengan menentukan apakah Anda mendapatkan manfaat keamanan dan infrastruktur yang diklaim oleh tim-tim itu akan mereka dapatkan. Bukannya hal-hal ini sederhana, tetapi menemukan programmer yang baik sulit dan mahal jadi saya tidak yakin apakah tim lain yang ingin memperbaiki area mereka benar-benar hanya ekor yang mengibas-ngibaskan anjing.

— JeffO

Pertanyaan luar biasa yang pada akhirnya harus dijawab oleh persyaratan produk / layanan dan manajemen yang mengetahui manfaat dan biaya heterogenitas yang Anda jelaskan. Dalam pengalaman saya, keragaman yang tidak perlu cenderung meningkatkan biaya terutama ketika itu merupakan gangguan yang menarik dari persyaratan yang sebaliknya membosankan. Dan ada biaya untuk mempertahankan keragaman teknologi begitu pembuatnya pergi untuk tantangan lain. Saya juga tertarik dengan studi kasus terkait. +1

— bvj

Banyak toko yang sukses menyerahkan keamanan dan infrastruktur pembangunan kepada pengembang. Anda mengirimkan kode yang ditinjau oleh rekan ke repositori dan itu tidak penting jika laptop Anda diretas karena kami tahu sumber Anda bersih. Kami dapat melakukan ini karena kami tidak mempercayai Anda lebih dari siapa pun yang meretas laptop Anda. Tetapi karena kami bekerja dengan cara ini, Anda dapat memiliki root. Saya sudah bekerja dua arah. Saya lebih suka memiliki root. Jadi keuntungan dari perkembangan heterogen adalah bahwa itu adalah titik sakit bagi orang-orang yang mencoba untuk mengambil akar saya.

— candied_orange

Saya menyarankan fakta bahwa tim Anda tampaknya lebih memilih untuk dapat memilih lingkungan mereka sendiri adalah keuntungan sampai batas tertentu

Satu keuntungan adalah bahwa Anda menemukan, dan harus menyelesaikan, kompatibilitas lintas-platform dan masalah divergensi di awal proses pengembangan. Semua orang terbiasa berurusan dengan kunci pas dan rintangan monyet.

Anda juga melihat sisi negatif dari divergensi tersebut: Lingkungan lebih sulit untuk diatur, dipelihara, diamankan, dan dikembangkan karena divergensi tersebut. Setiap orang harus mengerjakan masalah divergensi sejak dini dan sering. Mengatur Chaos Monkey longgar pada awalnya bisa menjadi gangguan yang cukup besar dari membuat kemajuan.

Dalam pengalaman saya, kerepotan divergensi tidak sepadan dengan usaha kecuali Anda sangat khusus bekerja pada produk yang harus lintas platform. Tapi, itu adalah panggilan penilaian tim yang berbeda harus membuat untuk diri mereka sendiri. Saya lebih suka setidaknya memiliki sedikit kesamaan dalam tim-tim proyek saya — tetapi kenyataannya adalah keinginan daripada sesuatu yang dapat saya terapkan. Beberapa orang memiliki & menggunakan Windows, yang lain macOS, yang lain beberapa rasa Linux. Kalikan itu kali semua alat pengembang mungkin ingin menggunakan.

Anda dapat meletakkan beberapa standar proyek inti seperti Python 3.5, PostgreSQL 9.5+, pipa aset berbasis gulp, git, Github, cabang rebased, ... yang harus dipatuhi setiap orang. Ini membantu memotong divergensi, sehingga waktu / upaya yang diperlukan untuk mengakomodasi dan mengatasi itu. Semakin korporat dan mengunci langkah organisasi Anda, semakin banyak standardisasi dan kesamaan yang dapat Anda tekankan. Namun, pengembang cenderung menjadi kucing metaforis yang tidak bisa diajak bicara. Jadi menjaga divergensi "menjadi suara yang membosankan" sering kali merupakan yang terbaik yang dapat Anda lakukan secara praktis.

— Jonathan Eunice
sumber

Saya tidak berpikir itu adalah jawaban yang baik karena OP telah secara eksplisit bertanya tentang beberapa penelitian dan makalah, dan bukan pendapat pribadi.

— KjMag

@ KjMag Terima kasih atas pendapat Anda. Ini adalah pertanyaan yang sering saya tanyakan dalam kapasitas profesional selama bertahun-tahun, termasuk oleh perusahaan dan tim pemerintah yang membayar dengan baik untuk mendengar jawaban. Situs-situs Stack Exchange secara mendasar dibentuk untuk mengumpulkan dan berbagi pengalaman yang berasal dari orang banyak. Ini adalah milikku. Jika Anda ingin melakukan pencarian laporan penelitian lengkap dan memposting bibliografi Anda, miliki di.

— Jonathan Eunice

@ KjMag meminta penelitian dan makalah di luar topik di sini dan saya mengeditnya di luar pertanyaan. Jawaban ini akan mendapat manfaat dari beberapa tautan luar, tetapi mandiri dan "berguna."