Apakah ada korelasi antara kompleksitas kode dan produktivitas pengembang?

10

Apakah waktu yang dihabiskan untuk refactoring basis kode layak dalam jangka panjang, dalam hal produktivitas pengembang?

Tampaknya cukup jelas bagi saya bahwa memodifikasi sistem yang bersih dan dirancang dengan baik jauh lebih sederhana dan lebih cepat daripada bekerja pada yang dirancang dengan buruk, tetapi saya mencari beberapa bukti kuat. Apakah ada studi seputar topik ini?

productivity complexity

— Benny Hallett
sumber

Lihat RECONSTRUCTION

— hakre

1

Mulailah menjaga diri Anda berantakan dan jadilah hakim.

— Tulains Córdova

16

Secara empiris, perangkat lunak dengan metrik kompleksitas yang lebih tinggi, seperti kompleksitas siklomatik, lebih sulit dipertahankan. Ada penelitian yang mendukung hal ini sejak tahun 1970-an ("Kompleksitas Program dan Produktivitas Programmer", ET Chen) . Ada juga pekerjaan yang menunjukkan bahwa kepadatan kompleksitas, yang merupakan kompleksitas siklus atas ukuran sistem juga berhubungan dengan waktu pemeliharaan ("Kerapatan kompleksitas siklomatik dan produktivitas pemeliharaan perangkat lunak", GK Gill, CF Kemerer) , yang juga tersedia secara gratis di sini . Sayangnya, langganan IEEE diperlukan untuk makalah Chen, tetapi Anda dapat mencoba mencarinya di sumber lain jika Anda tertarik.

Dari perspektif kualitas, sering kali layak untuk meluangkan waktu refactoring, dengan asumsi Anda memiliki kerangka kerja pengujian untuk mencegah pengenalan cacat baru. Ini akan memungkinkan Anda untuk lebih mudah mengimplementasikan fitur-fitur baru ke sistem Anda, menambahkan tes tambahan, dan melatih pengembang baru untuk bekerja.

Namun, pada akhirnya, ada tekanan untuk memberikan fungsionalitas baru dan nilai tambah. Anda harus menyeimbangkan refactoring dengan penerapan fungsi baru dan perbaikan cacat.

— Thomas Owens
sumber

2

poin lain untuk ditambahkan adalah bahwa ketika Anda refactor, Anda juga kemungkinan mengimplementasikan fitur dengan cara yang lebih baik / lebih efisien / bersih. Ada pepatah yang saya dengar berkali-kali dengan efek "dalam 5 tahun Anda akan merasa ngeri bahwa Anda menganggap kode Anda 'baik'"

— warren

1

@ hakre Saya memeriksa ketika saya memposting ini dan lagi sekarang, menggunakan pencarian Web Google dan Google Cendekia. Pada awalnya saya menulis posting ini, tidak ada kertas yang tersedia tanpa pembelian. Namun, sejak itu, satu makalah telah diposting di domain University of Pittsburgh yang tampaknya milik salah satu penulis dan saya menambahkan tautan ke sana. Kertas lain tidak tersedia secara gratis. Saya memang menambahkan judul ke badan pos untuk memudahkan pencarian mereka. Jika Anda tidak ingin membaca makalah, Anda harus menerima analisis saya, ditambah dengan pengetahuan dan pengalaman saya.

— Thomas Owens

0

Saya mencari beberapa bukti kuat

Kemudian berhentilah membuang waktu Anda di sini.

Temukan beberapa kode yang mahal untuk dipelihara. Mudah. Lihatlah tiket masalah organisasi Anda.
Temukan beberapa kode yang murah untuk dipelihara. Temukan kode yang sering dijalankan, tetapi memiliki sedikit atau tidak ada tiket bermasalah.
Ukur kompleksitas dengan salah satu alat kompleksitas yang tersedia secara luas.
Berjemur di bukti.

Anda sekarang telah memberikan nomor untuk mengkonfirmasi yang sudah jelas.

— S.Lott
sumber

5

Tidak juga. kompleksitas tugas yang dilakukan oleh perangkat lunak harus dibedakan dari kompleksitas tambahan yang disebabkan oleh implementasi yang dipilih.

— reinierpost

4

-1 bukan jawaban

— Dave Hillier