it-swarm-id.com

Apa metrik yang berguna untuk kode sumber?

Apa metrik yang berguna untuk ditangkap untuk kode sumber?

Bagaimana metrik, seperti misalnya (Dapat Dilakukan?) Baris Kode atau Kompleksitas Siklon membantu dengan jaminan kualitas atau bagaimana mereka bermanfaat secara umum untuk proses pengembangan perangkat lunak?

33
cschol

"Mengukur produktivitas perangkat lunak berdasarkan baris kode seperti mengukur kemajuan di pesawat terbang dengan beratnya." - Bill Gates

30
chrisaycock

Lihatlah posting Jeff tentang masalah ini:

Kunjungan dari Pembantu Metrik

Rekayasa Perangkat Lunak: Mati?

Ada yang lama, tapi bagus, posting dari Joel juga, terkait erat dengan metrik perangkat lunak, dan saya sangat merekomendasikan bacaannya: Metode Manajemen Econ 101

Poin kunci, bagi saya, adalah ini, mengutip Jeff: "Penggunaan metrik yang bertanggung jawab sama pentingnya dengan mengumpulkannya sejak awal."

12
Machado

Yang membingungkan saya tentang metrik kode adalah tidak dilakukan lagi. Sebagian besar perusahaan melaporkan efisiensi karyawan, pemasok, dan sistem mereka, tetapi tampaknya tidak ada yang mau melaporkan kode. Saya pasti akan setuju dengan jawaban yang menyatakan bahwa lebih banyak baris kode merupakan liabilitas tetapi apa yang kode Anda lakukan lebih penting.

Lines Of Code: Seperti yang telah saya sebutkan ini adalah pengukuran vital dan harus dilakukan dengan sangat serius, tetapi pada setiap level. Fungsi, kelas, file, dan antarmuka dapat menunjukkan kode do-everything yang sulit dipertahankan dan mahal dalam jangka panjang. Sangat sulit untuk membandingkan total baris kode versus apa yang dilakukan sistem. Bisa jadi sesuatu yang melakukan banyak hal dan dalam hal itu akan ada banyak baris kode!

Kompleksitas: Pengukuran ini baik dilakukan pada basis kode yang belum Anda kerjakan, dan dapat memberi Anda indikasi yang baik tentang letak masalah. Sebagai anekdot yang bermanfaat, saya mengukur kompleksitas pada salah satu basis kode saya sendiri, dan area kompleksitas tertinggi adalah area yang paling banyak saya habiskan ketika saya perlu mengubahnya. Bekerja ke arah mengurangi kompleksitas menghasilkan pengurangan besar dalam waktu pemeliharaan. Jika manajemen memiliki pengukuran ini di tangan, mereka dapat merencanakan iterasi refactoring atau mendesain ulang area spesifik suatu sistem.

Duplikasi kode: Ini adalah pengukuran yang sangat penting sejauh yang saya ketahui. Duplikasi kode adalah pertanda yang sangat buruk dan bisa mengarah ke masalah yang mendalam di tingkat rendah dari desain sistem atau pengembang yang menyalin paste, menyebabkan masalah besar dalam jangka panjang dan sistem yang tidak dapat dipelihara.

Grafik Ketergantungan Menemukan dependensi buruk dan dependensi melingkar adalah pengukuran penting dalam kode. Ini hampir selalu menunjuk ke desain tingkat tinggi yang salah yang perlu direvisi. Terkadang satu ketergantungan dapat menyedot banyak yang tidak perlu, karena seseorang menggunakan addNumber di dalam perpustakaan e-mail untuk melakukan perhitungan keuangan mereka. Semua orang terkejut ketika perpustakaan email diubah dan keuangan rusak. Jika semuanya tergantung pada satu hal, itu juga bisa menunjukkan untuk melakukan semua perpustakaan yang sulit untuk dipelihara dan dirancang dengan buruk.

Pengukuran yang baik akan selalu memberi tahu Anda bahwa setiap fitur sistem memiliki jejak kecil. Lebih sedikit ketergantungan, lebih sedikit kompleksitas, lebih sedikit duplikasi. Ini menunjukkan kopling longgar dan kohesi tinggi.

11
Tjaart

Bukankah ini omong kosong "metrik kode sumber" PERNAH mati?

Baris kode sumber mentah (SLOC) adalah metrik tertua, termudah, paling mendasar.

Halstead awalnya mengusulkan sejumlah metrik. Banyak orang bersenang-senang menulis program pengukuran sampai beberapa spoilsport melakukan penelitian yang jelas, dan menunjukkan bahwa masing-masing dan setiap metrik Halstead sangat berkorelasi langsung dengan SLOC.

Pada titik itu, metrik Halstead ditinggalkan, karena SLOC selalu lebih mudah untuk diukur.

8
John R. Strohm

Metrik kode sumber untuk jaminan kualitas bertujuan pada dua tujuan:

  • menulis kode dengan lebih sedikit bug di dalamnya
  • menulis kode untuk perawatan yang mudah

Keduanya mengarah pada penulisan kode sesederhana mungkin. Ini berarti:

  • unit kode pendek (fungsi, metode)
  • beberapa elemen di setiap unit (argumen, variabel lokal, pernyataan, jalur)
  • dan banyak kriteria lain yang kurang lebih kompleks (lihat Metrik perangkat lunak di Wikipedia).
8
mouviciel

Sepengetahuan saya, jumlah bug yang ditemukan berkorelasi langsung dengan baris kode (mungkin churn), bahasa modulo, programmer, dan domain.

Saya tidak tahu metrik langsung dan praktis lainnya yang berkorelasi baik dengan bug.

Satu hal yang ingin saya lakukan adalah mulai menjalankan angka untuk berbagai proyek yang sedang saya ikuti - Cakupan Tes :: kLOC, dan kemudian mendiskusikan "persepsi kualitas" untuk melihat apakah ada korelasi.

7
Paul Nathan

Metrik hanya berguna jika Anda tahu apa yang harus dilakukan dengan jawaban yang Anda dapatkan. Pada dasarnya, metrik perangkat lunak seperti termometer. Fakta bahwa Anda mengukur sesuatu pada 98,6 ° F tidak berarti apa-apa sampai Anda tahu apa suhu normal . Suhu di atas baik untuk suhu tubuh tetapi sangat buruk untuk es krim.

Metrik umum yang dapat bermanfaat adalah:

  • Bug ditemukan/minggu
  • Bug teratasi/minggu
  • # Persyaratan yang ditentukan/lepaskan
  • # Persyaratan diimplementasikan/dirilis

Dua tren ukuran pertama. Apakah Anda menemukan bug lebih cepat dari yang dapat Anda perbaiki? Dua hasil yang mungkin: mungkin kita perlu lebih banyak sumber daya memperbaiki bug, mungkin kita perlu berhenti menerapkan fitur baru sampai kita mengejar ketinggalan. Dua yang kedua memberikan gambaran seberapa dekat Anda akan dilakukan. Tim tangkas menyebutnya grafik "bakar".

Kompleksitas Siklomatik adalah metrik yang menarik. Pada konsep dasarnya, ini adalah jumlah jalur eksekusi unik dalam fungsi/metode. Dalam lingkungan unit-tes berat ini sesuai dengan jumlah tes yang diperlukan untuk memverifikasi setiap jalur eksekusi. Namun demikian, hanya karena Anda memiliki metode yang memiliki Kompleksitas Siklomatik 96 tidak berarti itu adalah kode kereta - atau bahwa Anda harus menulis 96 tes untuk memberikan kepercayaan yang wajar. Ini tidak biasa untuk kode yang dihasilkan (melalui WPF atau parser generator) untuk membuat sesuatu yang kompleks ini. Ini dapat memberikan gambaran kasar tentang tingkat upaya yang diperlukan untuk men-debug suatu metode.

Garis Bawah

Setiap pengukuran yang Anda lakukan harus memiliki definisi berikut atau tidak berguna:

  • Pemahaman tentang apa yang "normal" itu. Ini dapat disesuaikan sepanjang umur proyek.
  • Ambang batas di luar "normal" di mana Anda perlu mengambil tindakan.
  • Rencana untuk berurusan dengan kode ketika ambang melebihi.

Metrik yang Anda ambil mungkin sangat bervariasi dari proyek ke proyek. Anda mungkin memiliki beberapa metrik yang Anda gunakan di berbagai proyek, tetapi definisi "normal" akan berbeda. Misalnya, jika satu proyek menemukan rata-rata 5 bug/minggu dan proyek baru menemukan 10 bug/minggu itu tidak berarti ada sesuatu yang salah. Mungkin saja tim pengujian kali ini lebih teliti. Juga, definisi "normal" dapat berubah sepanjang umur proyek.

Metrik hanya termometer, apa yang Anda lakukan dengan itu terserah Anda.

7
Berin Loritsch

Kode sumber adalah kewajiban, bukan aset. Dengan mengingat hal itu, mengukur garis kode analog dengan melacak dolar yang dihabiskan saat membangun rumah. Ini perlu dilakukan jika Anda ingin tetap di bawah anggaran, tetapi Anda tidak akan berpikir bahwa menghabiskan $ 1000 sehari lebih baik daripada menghabiskan $ 50 sehari; Anda ingin tahu berapa banyak rumah yang dibangun untuk uang itu. Itu sama dengan baris kode dalam proyek perangkat lunak.

Singkatnya, tidak ada metrik yang berguna untuk kode sumber karena mengukur kode sumber dengan sendirinya tidak berguna.

6
Larry Coleman

Karena kode sumber hanyalah kombinasi dari urutan, pemilihan, dan pengulangan. Jika saya mendeskripsikan bagian paling optimal dari perangkat lunak yang dapat kita harapkan untuk memproduksinya adalah sebagai berikut. Perangkat lunak dengan cakupan kode pengujian hampir 100% menggunakan jumlah baris kode paling sedikit yang diperlukan untuk melakukan pekerjaan dan cukup fleksibel untuk menahan perubahan.

4
Xenohacker

Sebuah anekdot untuk menunjukkan mengapa penghitungan KLOC tidak berguna (dan bahkan berbahaya) untuk mengukur kinerja.

Bertahun-tahun yang lalu saya bekerja pada sebuah proyek besar (70+ orang di perusahaan kami, 30+ lainnya di pelanggan kami) yang menggunakan jumlah KLOC sebagai satu-satunya ukuran kinerja tim dan individu.

Untuk upaya Y2K kami (memberitahu Anda berapa lama itu :)) kami melakukan pembersihan besar-besaran pada bagian kode yang menjadi tanggung jawab tim saya. Kami akhirnya menulis untuk menulis sekitar 30.000 baris kode, bukan pekerjaan buruk 3 bulan untuk 5 orang. Kami juga akhirnya menghapus 70.000 baris kode lagi, pekerjaan yang sangat baik selama 3 bulan bekerja, terutama dikombinasikan dengan kode baru.

Hasil akhir untuk kuartal: -40.000 baris kode. Selama tinjauan kinerja setelah kuartal kami mendapat teguran resmi dari perusahaan karena gagal memenuhi persyaratan produktivitas kami dari 20.000 baris kode yang diproduksi per kuartal (setelah semua, alat telah menunjukkan kami telah memproduksi -40.000 baris kode), yang akan mengakibatkan kita semua terdaftar sebagai berkinerja buruk dan dilewati untuk promosi, pelatihan, kenaikan gaji, dll. seandainya manajer proyek dan tim QA tidak campur tangan dan mendapat teguran dibatalkan dan digantikan oleh pujian.

Beberapa bulan kemudian (hal-hal seperti itu membutuhkan waktu) kami diberitahu bahwa perusahaan sedang meninjau standar produktivitas mereka dan telah mempekerjakan tim ahli untuk membuat sistem baru berdasarkan analisis titik fungsi.

4
jwenting

Saya terkejut belum ada yang menyebutkan Pernyataan/Cakupan Tes unit (persentase kode yang dilakukan oleh unit test).

Cakupan kode berguna karena Anda tahu berapa persen dari aplikasi yang tidak gagal secara bencana; dengan sisa kegunaannya tergantung pada kualitas unit tes.

2
StuperUser

Ini tidak terlalu berguna absolut metrik dalam hal kemajuan, tetapi dapat digunakan untuk memberikan gambaran umum tentang status kode.

Khususnya Siklus Kompleksitas saya temukan berguna dalam hal memvisualisasikan bagaimana termodulasi basis kode yang diberikan. Anda biasanya menginginkan kompleksitas yang rendah karena ini berarti jumlah sumber per modul rendah dan ada banyak modul.

1
user1249

Semakin kecil komit, semakin baik. Ini tentang alat SCM, bukan kode per-se, tapi ini metrik yang sangat terukur. Semakin kecil komit, semakin mudah untuk melihat setiap perubahan sebagai unit atom; semakin mudah untuk mengembalikan perubahan tertentu dan titik-titik ketika hal-hal pecah.

Selama tidak ada komit yang merusak build ...

1
Assaf Lavie

Ada banyak situasi di tempat kerja saya di mana saya menggunakan metrik kode:

Saat menulis kode

Penggunaan terbesar dan mungkin paling penting dalam pekerjaan sehari-hari saya adalah di Checkstyle , alat untuk Java pengembang yang terus-menerus memeriksa metrik (antara lain) dari kode saya terhadap seperangkat aturan yang telah kami tetapkan dan menandai tempat-tempat di mana kode saya tidak mematuhi aturan-aturan itu. Ketika saya mengembangkan kode, ia memberi tahu saya secara real time jika metode saya menjadi panjang, rumit atau digabungkan memungkinkan saya untuk mundur dan Pikirkan tentang refactoring ke sesuatu yang lebih baik.

Pengembang sepenuhnya bebas untuk melanggar semua aturan karena mereka tidak akan pernah berlaku untuk semua situasi. "Aturan" yang ada untuk merangsang pemikiran dan berkata, "Hei, apakah ini cara terbaik untuk melakukan ini?"

Selama QA/Ulasan Kode

Hal pertama yang biasanya saya lakukan ketika saya melakukan tinjauan kode adalah untuk memeriksa cakupan kode dari kode yang saya ulas bersama dengan alat cakupan kode yang menyoroti baris kode mana yang telah dibahas. Ini memberi saya gambaran umum tentang seberapa teliti kode tes. Saya tidak terlalu peduli jika cakupannya 20% atau 100% selama kode penting diuji dengan baik. Jadi persen yang dicakup agak tidak berarti, tetapi 0% benar-benar menonjol seperti sesuatu yang ingin saya perhatikan dengan seksama.

Saya juga memeriksa metrik mana yang disetujui oleh tim telah 'rusak', jika ada, untuk melihat apakah saya setuju dengan pengembang bahwa itu OK atau jika saya dapat menyarankan cara untuk memperbaikinya. Memiliki metrik pengembangan yang disetujui dalam tim kami untuk menulis kode baru telah membuat kemajuan besar dalam meningkatkan kode kami. Kami menulis metode monolitik jauh lebih sedikit dan jauh lebih baik di prinsip tanggung jawab tunggal sekarang.

Tren peningkatan kode legacy Kami memiliki banyak kode legacy yang ingin kami tingkatkan. Metrik pada titik waktu mana pun cukup tidak berguna, tetapi yang penting bagi kami adalah bahwa cakupan kode waktu meningkat dan hal-hal seperti kompleksitas dan kopling turun. Karenanya, metrik kami terhubung ke server Integrasi Berkelanjutan kami yang memungkinkan kami melihat dari waktu ke waktu untuk memastikan kami berada di jalur yang benar.

Memahami basis kode baru Tentang satu-satunya waktu saya menggunakan baris metrik kode sumber adalah ketika melihat basis kode, saya tidak terbiasa dengan. Ini memungkinkan saya untuk dengan cepat mengukur ukuran kasar proyek dibandingkan dengan orang lain yang pernah bekerja dengan saya. Dengan menggunakan metrik lain saya juga bisa mendapatkan gambaran kasar lebih lanjut tentang kualitas proyek.

Kuncinya adalah menggunakan metrik sebagai titik awal untuk tren, diskusi atau cara maju dan tidak mengelolanya secara religius untuk angka yang tepat. Tetapi saya sangat percaya bahwa mereka dapat membantu Anda meningkatkan kode yang Anda gunakan saat digunakan dengan benar.

1
Chris Knight

Saya sering bekerja pada paket C++ raksasa, dan ketika mencari kode bermasalah layak refactoring Kompleksitas Siklon atau mengerikan FanIn/FanOut biasanya bendera merah yang cukup bagus untuk dicari. Memperbaiki masalah biasanya akan mengarah pada perbaikan di seluruh basis kode.

Tentu saja angka-angka ini hanya bisa berfungsi sebagai petunjuk tentang apa yang layak dilihat. Membuat ini ambang yang sulit setelah gagal membangun atau menolak komit akan konyol.

1
Benjamin Bannier

T: Apa metrik yang berguna untuk diambil untuk kode sumber?

ntuk bisnis:

A: Jumlah jam kerja

ntuk supervisor coder:

A: Tidak masalah. Mari kita lakukan semuanya hari ini

ntuk harga diri coder:

A: Jumlah SLOC (Sumber Baris kode)

ntuk ibu coder:

A: Makan lebih banyak dari gulungan Prancis lembut ini dan minum teh

melanjutkan komentar di bawah ini ...

0
Genius