Metrik kode sumber untuk mengukur stabilitas kode?

17

Mempertimbangkan bagaimana perangkat lunak dikembangkan selama siklus rilis (implementasi, pengujian, perbaikan bug, rilis) saya berpikir bahwa seseorang harus dapat melihat beberapa pola dalam garis kode yang diubah dalam basis kode; misalnya menjelang akhir proyek, jika kode menjadi lebih stabil, orang akan melihat bahwa lebih sedikit baris kode yang dimodifikasi per unit waktu.

Sebagai contoh, orang dapat melihat bahwa selama enam bulan pertama proyek, rata-rata adalah 200 baris kode per hari, sedangkan selama bulan terakhir itu adalah 50 baris kode per hari, dan selama minggu terakhir (tepat sebelum DVD produk dikirimkan), tidak ada baris kode yang berubah sama sekali (pembekuan kode). Ini hanya contoh, dan pola yang berbeda dapat muncul sesuai dengan proses pengembangan yang diadopsi oleh tim tertentu.

Lagi pula, apakah ada metrik kode (ada literatur tentang mereka?) Yang menggunakan jumlah baris kode yang dimodifikasi per unit waktu untuk mengukur stabilitas basis kode? Apakah mereka berguna untuk merasakan jika suatu proyek mencapai suatu tempat atau jika masih jauh dari siap untuk dirilis? Apakah ada alat yang dapat mengekstrak informasi ini dari sistem kontrol versi dan menghasilkan statistik?

code-metrics

— Giorgio
sumber

1

ndepend.com/Features.aspx#BuildComparison

— AakashM

4

"Kedua, mekanismenya abstrak, produksinya dimasukkan dalam desainnya. Dalam hal ini, sebuah program seperti puisi: Anda tidak dapat menulis puisi tanpa menulisnya. Namun orang-orang berbicara tentang pemrograman seolah-olah itu adalah proses produksi dan ukuran" produktivitas programmer "dalam hal" jumlah baris kode yang dihasilkan ". Dengan demikian mereka memesan nomor itu di sisi yang salah dari buku besar: kita harus selalu merujuk pada" jumlah baris kode yang dihabiskan "." - Buah dari kesalahpahaman , Edsger W. Dijkstra.

— yannis

3

@Yannis Rizos: Saya sama sekali tidak menyarankan untuk mengukur produktivitas atau kompleksitas kode oleh LOC karena saya tahu bahwa ini bukan ukuran yang baik. Di sisi lain, jika 300 baris kode diubah dua hari sebelum pengiriman, saya sebagai manajer akan memiliki lampu "RED ALERT" besar dalam pikiran saya (kecuali ini direncanakan dan merupakan hasil dari evaluasi risiko yang sangat hati-hati terhadap risiko). ). Secara umum, saya akan menganggap bahwa kode yang telah digunakan (dan diuji) tanpa diubah untuk waktu yang lama "lebih stabil" daripada kode di mana 100 baris diubah setiap hari.

— Giorgio

2

@Giorgio Argh, saya terganggu (tengah hari kerja di sini) ketika saya memposting komentar lain (tekan batas char di yang pertama). Tidak bermaksud menyiratkan Anda berbicara tentang produktivitas, kutipan Dijkstra baru saja terlintas di benak saya dan saya pikir itu akan menarik. Bagaimanapun, metrik kode churn mendekati apa yang Anda cari, dan ada banyak literatur tentangnya. Adapun alat, FishEye Atlassian sangat spektakuler.

— yannis

@Yannis Rizos: Ini memang bacaan yang sangat menarik. Sedangkan untuk FishEye, kami menggunakannya di tempat kerja kami (untuk ulasan), jadi saya akan segera melihat ke manual dan melihat statistik apa yang bisa kami hasilkan.

— Giorgio

17

Satu ukuran yang dijelaskan Michael Feather adalah, " Set Aktif Kelas ".

Dia mengukur jumlah kelas yang ditambahkan terhadap yang "ditutup". Penjelasan tentang penutupan kelas sebagai:

Kelas ditutup pada tanggal di mana tidak ada modifikasi lebih lanjut terjadi dari tanggal itu hingga saat ini.

Dia menggunakan langkah-langkah ini untuk membuat grafik seperti ini: Bagan kelas aktif

Semakin kecil jeda antara dua garis semakin baik.

Anda mungkin dapat menerapkan ukuran serupa ke basis kode Anda. Sangat mungkin bahwa jumlah kelas berkorelasi dengan jumlah baris kode. Bahkan dimungkinkan untuk memperluas ini dengan memasukkan baris-kode-per ukuran kelas, yang dapat mengubah bentuk grafik jika Anda memiliki beberapa kelas monolitik besar.

— Dave Hillier
sumber

4

Selama ada pemetaan fitur yang relatif konsisten ke kelas, atau dalam hal ini, sistem file Anda dapat mengaitkan sesuatu seperti gource ke dalam sistem kontrol versi Anda dan dengan cepat memahami di mana sebagian besar pengembangan difokuskan (dan dengan demikian bagian mana dari kode yang paling tidak stabil).

Ini mengasumsikan Anda memiliki basis kode yang relatif rapi. Jika basis kode adalah bola lumpur, Anda pada dasarnya akan melihat setiap bagian kecil yang dikerjakan karena saling ketergantungan. Yang mengatakan, mungkin itu sendiri (pengelompokan saat bekerja pada fitur) adalah indikasi yang baik dari kualitas basis kode.

Ini juga mengasumsikan bahwa bisnis Anda dan tim pengembang secara keseluruhan memiliki beberapa cara untuk memisahkan fitur dalam pengembangan (baik itu cabang dalam kontrol versi, satu fitur pada suatu waktu, apa pun). Jika, misalnya, Anda sedang mengerjakan 3 fitur utama pada cabang yang sama, maka metode ini menghasilkan hasil yang tidak berarti, karena Anda memiliki masalah yang lebih besar daripada stabilitas kode di tangan Anda.

Sayangnya, saya tidak punya literatur untuk membuktikan maksud saya. Ini semata-mata didasarkan pada pengalaman saya menggunakan gource pada basis kode yang baik (dan tidak begitu baik).

Jika Anda menggunakan git atau svn dan versi gource Anda adalah> = 0,39, ini sesederhana menjalankan gource di folder proyek.

— Carl
sumber

gource juga tampaknya menjadi alat yang hebat! (+1)

— Giorgio

1

Saya menemukan jawaban ini, lalu menghabiskan enam jam berikutnya bermain dengan Gource. Saya tidak yakin apakah itu layak diberi +1 atau -1, tapi sial, itu salah satu alat keren.

— RonU

@RonU: Anda dapat menggunakan gource untuk memvisualisasikan keadaan repositori dalam rentang waktu khusus. Intinya adalah memvisualisasikan aktivitas pada basis kode Anda dari waktu ke waktu. Seberapa mudah informasi itu diartikan tergantung pada banyak faktor, seperti yang telah saya jelaskan dalam jawaban saya di atas. Ya, ini adalah alat yang luar biasa jika Anda menginginkan "gambaran besar", jadi saya pikir itu layak diberi +1;)

— Carl

Ya, ketika saya mengatakan "enam jam," saya tidak bermaksud saya menjalankan satu sim Gource untuk waktu itu ... hanya saja saya bermain-main dengan banyak pilihan, menyalurkannya ke ffmpeg, mungkin menambahkan soundtrack epik, dll. cukup lubang kelinci. :)

— RonU

Coba tebak. Soundtrack-nya adalah Harlem Shuffle;)

— Carl

0

Penggunaan frekuensi garis yang dimodifikasi sebagai indikator untuk stabilitas kode setidaknya dipertanyakan.

Pada awalnya, distribusi dari waktu ke waktu garis yang dimodifikasi, sangat tergantung pada model manajemen perangkat lunak proyek. Ada perbedaan besar dalam model manajemen yang berbeda.

Pada kedua, korban dalam asumsi ini tidak jelas - adalah jumlah yang lebih rendah dari garis yang dimodifikasi yang disebabkan oleh stabilitas perangkat lunak, atau hanya karena tenggat waktu berakhir dan pengembang memutuskan untuk tidak membuat beberapa perubahan sekarang, tetapi untuk membuatnya setelah melepaskan?

Pada ketiga, sebagian besar garis dimodifikasi ketika fitur baru diperkenalkan. Tetapi fitur baru tidak membuat kode tidak stabil. Itu tergantung pada keahlian pengembang dan pada kualitas desain. Di sisi lain, bahkan bug serius dapat diperbaiki dengan sedikit perubahan garis - dalam hal ini, stabilitas perangkat lunak meningkat secara signifikan, tetapi jumlah baris yang diubah tidak terlalu besar.

— Johnfound
sumber

"Itu tergantung pada keterampilan pengembang dan kualitas desain.": Tapi Anda perlu setidaknya beberapa waktu untuk menguji perubahan sehingga Anda memiliki cukup kepercayaan diri bahwa Anda belum memperkenalkan bug apa pun. Bahkan pengembang yang paling terampil pun dapat melakukan kesalahan pengetikan, misalnya jika mereka berada di bawah tekanan, terlalu banyak bekerja lembur, atau kurang tidur. Juga, jika Anda menerapkan prinsip buka / tutup, setelah beberapa saat jumlah perubahan (perbaikan bug) akan berkurang. Bagaimanapun, saya telah secara eksplisit menyatakan dalam pertanyaan saya bahwa hasil pengukuran seperti itu dapat berubah sesuai dengan proses pengembangan.

— Giorgio

BTW, kode bisa tidak stabil bukan karena pengembang buruk, tetapi karena persyaratannya tidak jelas dan proyek masih dalam tahap prototyping.

— Giorgio

@Iorgio: Tentu saja Anda benar. Tapi inilah yang saya tulis: Hitungan garis yang dimodifikasi sangat tergantung pada terlalu banyak faktor. Beberapa dari mereka terkait dengan stabilitas kode, beberapa tidak. Ini seperti mencoba menghitung berapa banyak orang yang berhubungan seks, mengukur daya listrik, dengan asumsi - lebih sedikit daya - lebih sedikit lampu - lebih banyak seks. Meskipun terbukti bahwa angka kelahiran meningkat setelah pemadaman besar. ;)

— johnfound

-1

Robustness adalah istilah yang berkaitan dengan fungsi yang benar dari set instruksi, bukan kuantitas, verbositas, kesederhanaan, kebenaran tata bahasa dari teks yang digunakan untuk mengekspresikan instruksi tersebut.

Memang sintaks itu penting dan harus benar tetapi apa pun di luar itu, karena berkaitan dengan fungsi yang diinginkan dari instruksi dengan melihat 'metrik' dari instruksi ini mirip dengan merencanakan masa depan Anda dengan membaca pola daun teh di bagian bawah Anda secangkir teh.

Ketegaran diukur dengan cara tes. Tes unit, tes asap, tes regresi otomatis; tes, tes, tes!

Jawaban saya atas pertanyaan Anda adalah bahwa Anda menggunakan pendekatan yang salah dalam mencari jawaban atas salah satu kekokohan. Ini adalah herring merah bahwa baris kode berarti lebih dari kode yang ditempati baris. Anda hanya dapat mengetahui apakah kode melakukan apa yang Anda inginkan jika Anda menguji apakah itu melakukan apa yang Anda perlukan.

Silakan kunjungi kembali harness pengujian yang tepat dan hindari mistisisme metrik kode.

Semoga sukses.

— Sassafras_wot
sumber

3

Saya telah secara eksplisit menyatakan bahwa saya tidak menyarankan LoC sebagai ukuran kompleksitas kode. Saya menyarankan perubahan kode sebagai ukuran stabilitas kode: apakah sepotong kode memiliki persyaratan fungsional yang stabil dan implementasi yang stabil dan teruji memenuhi persyaratan tersebut?

— Giorgio

Saya tidak ingin berdebat dengan Anda tetapi dengan hormat memandu Anda menjauh dari kebodohan metrik yang tidak berarti. Saya membaca ulang pertanyaan Anda dan semua contoh Anda menunjukkan keinginan untuk menyimpulkan hubungan antara baris kode yang berubah dan ketahanan yang dihasilkannya. Saya mengerti bahwa semakin banyak kata yang Anda ketikkan, semakin besar kemungkinan Anda membuat kesalahan ketik. Tetapi saya sangat menentang prinsipnya dalam apa yang Anda minta sehingga saya harus keluar dengan kuat agar Anda meninggalkan pencarian Anda dengan cara ini. Praktik pengujian yang baik = kemungkinan ketahanan yang bagus.

— Sassafras_wot

"Praktik pengujian yang baik = kemungkinan bagus untuk ketahanan.": Saya sepenuhnya setuju. Itu sebabnya saya menyarankan bahwa sepotong kode yang telah diubah baru-baru ini perlu diuji lagi sebelum kita dapat yakin bahwa itu benar.

— Giorgio

Ada beberapa definisi stabilitas dan salah satunya adalah apa yang Anda perdebatkan. Ini interpretasi semantik yang berbeda dari yang saya buat. Saya mengambil stabil berarti, bahwa itu "tidak tunduk pada perubahan ekstrem" daripada "tahan terhadap perubahan"

— Dave Hillier