Berapa banyak upaya yang dilakukan untuk memelihara sistem pembangunan?

9

Dalam StackExchange Podcast # 09 disebutkan :

Studi lain baru-baru ini mengamati berapa banyak upaya yang dilakukan untuk memelihara sistem pembangunan: 5 hingga 30% dari semua upaya pengembangan dihabiskan untuk memelihara sistem pembangunan. Dengan variasi yang sangat besar bahkan ketika mengerjakan proyek serupa.

Apa nama penelitian yang dirujuk, dan di mana dapat ditemukan? Audio podcast tidak berisi detail lebih lanjut.

Selain itu, apakah ada yang punya tautan ke studi lain yang membahas topik yang sama.

commandline-build-tool

— Neil Mitchell
sumber

3

Wow. Tidak pernah terlintas dalam pikiran saya bahwa toko dapat menghabiskan banyak waktu untuk membangun sistem. Kami memiliki sistem build buatan tangan yang dibuat khusus, yang membangun setiap malam dari semua (20 beberapa) rilis dan (50 beberapa) cabang pengembangan (jika perubahan telah dilakukan), memulai pengujian unit dan berhenti dan memulai server pengujian (satu atau lebih banyak per rilis dan satu atau lebih untuk banyak cabang pengembangan), mengirimkan hasil, dll. Namun dalam 4 tahun saya bekerja di perusahaan ini, saya tidak berpikir kami telah menghabiskan lebih dari beberapa minggu untuk mengerjakannya dan bahwa termasuk memperluas fitur dari solusi kami yang dibuat khusus!

— Marjan Venema

Itulah yang terjadi ketika orang merujuk pada sesuatu / seseorang dan lupa untuk menambahkan referensi ...

— wleao

Tidak tahu studi ini, tetapi hasilnya mungkin berbeda tergantung pada apa yang Anda definisikan dengan "mempertahankan sistem build". "Apakah menambah atau mengubah file" bagian dari itu? Apakah pengaturan bagian penginstal dari "memelihara sistem bangun"?

— Doc Brown

1

Saya belum pernah mendengar podcast, tetapi penelitian ini mungkin sebuah makalah dari ICSE terbaru , yang disebut "Studi Empiris Upaya Bangun Pemeliharaan" oleh Shane McIntosh et al. Periksa tautan Langsung (atau halaman DOI resmi jika Anda menginginkan metadata).

Studi mereka sebagian besar berfokus pada seberapa sering perubahan kode sumber memengaruhi pembangunan dan berapa banyak pengembang dalam suatu tim biasanya peduli dengan mempertahankan pembangunan. Saya ingat bahwa ini adalah studi yang menarik, tetapi saya menemukan angka-angka agak sulit untuk ditafsirkan, seperti yang sering terjadi dengan studi empiris yang berusaha menemukan hubungan antara hal-hal :)

— Deckard
sumber

2

Saya tidak memiliki tautan untuk Anda, tetapi berbicara dari pengalaman pribadi, persentase itu bervariasi berdasarkan 2 poin utama: 1) desain dan kompleksitas sistem 2) dan organisasi pribadi

Sistem yang dirancang dengan baik akan membutuhkan upaya minimal untuk mempertahankannya meskipun cukup rumit. Tetapi jika staf Anda tidak terlatih dan terorganisir dengan baik dalam menangani kode, Anda mungkin akan menghabiskan waktu lama untuk memperbaiki bangunan yang salah atau melakukan salah dan hal-hal seperti ...

Namun, ketika Anda memiliki lingkungan pengembangan, T&J, RC, dan Produksi ... Ini semua berdampak pada proses perpindahan dari pengembangan ke produksi aktual.

Saya akan mengatakan persentase benar, membungkuk lebih dekat ke tanda 30% dari 5%. Jika semua yang Anda investasikan adalah 5%, Anda melakukan pekerjaan dengan baik. (Ini termasuk kesalahan yang ditemukan selama Tanya Jawab atau RC atau bahkan Produksi karena manajemen yang salah dari Sistem Bangun, yang dapat menyebabkan penundaan besar).

— AJC
sumber

Jika semua yang Anda investasikan adalah 5%, saya sarankan Anda tidak mengukur semuanya atau secara akurat.

— mattnz

tidak matt Anda menggunakan definisi yang berbeda. Sebagian besar perusahaan tempat saya bekerja tidak memiliki sistem build, seperti pada server build yang tidak otomatis, integrasi VCS (seringkali tidak ada VCS sama sekali kecuali proyek apa yang mungkin diatur sendiri, yang berakhir di bawah radar), dll. Dalam "penelitian" apa pun dari persentase sumber daya yang digunakan untuk memelihara "sistem bangun", mereka akhirnya terdaftar sebagai pengeluaran yang hampir tidak ada artinya, kecuali jika dirinci untuk memasukkan upaya yang dihabiskan untuk memelihara semua skrip ANT dan Maven, sesuatu jarang dilakukan.

— jwenting