Apa metrik yang berguna untuk kode sumber? [Tutup]


33

Apa metrik yang berguna untuk ditangkap untuk kode sumber?

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


37
Satu-satunya ukuran yang valid adalah WTF / dtk. :)
terminus


Jawaban:


30

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


3
Harap jangan perbarui jawaban.
Eric Wilson

3
Meskipun anekdot yang lucu, jawaban ini tidak banyak berkontribusi pada jawaban pertanyaan ini.
Chris Knight

7
@ Chris Jawaban ini mendapat banyak suara (atau "pembaruan" sebagaimana FarmBoy ingin menyebutnya) karena banyak pengembang percaya bahwa metrik perangkat lunak tidak berguna. Jika Anda tidak setuju atau merasa bahwa Anda memiliki respons yang lebih baik terhadap pertanyaan itu, maka posting jawaban Anda sendiri. Mengomentari seperti yang Anda lakukan di sini tidak produktif; Anda sendiri tidak berkontribusi apa pun.
chrisaycock

7
Downvote dan komentar saya dimaksudkan untuk mencegah jawaban yang kurang mendalam dan tidak langsung menjawab pertanyaan OP. Ini bisa menjadi jawaban yang jauh lebih baik jika Anda masuk ke lebih detail tentang mengapa Anda percaya metrik perangkat lunak menjadi tidak berguna berkaitan dengan pengembangan perangkat lunak dan jaminan kualitas dan berfokus pada lebih dari sekedar LOC.
Chris Knight

Metrik perangkat lunak sebenarnya sangat berguna jika Anda menggunakannya dengan benar. Artinya, semakin banyak LoC -> semakin banyak bug -> semakin buruk kualitasnya. Saya belum pernah melihatnya gagal sebagai ukuran untuk kualitas. Dan pesawat terbang secara definitif lebih baik jika melakukan perjalanan yang sama pada kecepatan yang sama tetapi membutuhkan bobot yang jauh lebih sedikit. Jelas Bill Gates tidak tahu banyak tentang pesawat ketika dia mengatakan itu, juga tidak cukup tahu tentang perangkat lunak.
Pablo Ariel

12

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."


+1 untuk mengutip satu kalimat Jeff. Kearifan murni yang diperjuangkan dalam pertempuran di sana.
luis.espinal

11

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 tersebut. 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 dianggap paling 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 dengan 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 di mana letak masalah. Sebagai anekdot yang bermanfaat, saya mengukur kompleksitas pada salah satu basis kode saya sendiri, dan area kompleksitas tertinggi adalah yang paling banyak saya habiskan ketika saya perlu mengubahnya. Bekerja menuju pengurangan kompleksitas menghasilkan pengurangan besar dalam waktu perawatan. Jika manajemen memiliki pengukuran ini di tangan, mereka dapat merencanakan iterasi refactoring atau mendesain ulang area tertentu dari suatu sistem.

Duplikasi kode: Ini adalah pengukuran yang sangat penting sejauh yang saya ketahui. Duplikasi kode merupakan 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 lainnya, 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 dapat 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.


8

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

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

Awalnya Halstead mengusulkan sejumlah metrik. Banyak orang bersenang-senang menulis program pengukuran sampai beberapa spoilsport melakukan studi 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.


1
Adakah tautan ke studi ini?
Jon Hopkins

Google adalah TEMAN Anda, tetapi ini satu untuk Anda mulai. ecs.csun.edu/~rlingard/comp589/HoffmanArticle.pdf
John R. Strohm

6
Studi yang menarik, meskipun studi mereka hanya melihat program-program umumnya antara 50 dan 100 baris kode. Dengan masalah kecil yang terdefinisi dengan baik untuk dipecahkan, hasil akhirnya tidak begitu mengejutkan.
Chris Knight

Saya akan mengatakan bahwa di dunia nyata, semua studi ini berubah menjadi lumpur.
Warren P

Ini benar. Semakin banyak baris kode, semakin tinggi kualitasnya.
Pablo Ariel

8

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).

7

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

Saya tidak tahu adanya 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.


1
Jadi semakin banyak kode, semakin banyak bug yang ada di dalamnya?

3
@Thor: l yep yep. jijik, ya?
Paul Nathan

Sejauh yang saya ingat angka-angka industri tipikal adalah sekitar 2-3 kesalahan per 1000 baris kode untuk proyek rata-rata, mendekati kira-kira 0,5 kesalahan per 1000 baris kode untuk perangkat lunak kendali pabrik nuklir atau proyek-proyek NASA di mana mereka meletakkan sejumlah usaha yang besar , mengendalikan, menguji, meninjau, dll karena kegagalan dapat memiliki konsekuensi yang sangat parah. Adakah yang memiliki referensi nomor yang mendukung ini?
hlovdal

2
@loloal: 2-3 kesalahan per KSLOC sudah merupakan angka yang sangat rendah. Angka terendah yang saya tahu dari domain kedirgantaraan dan keamanan adalah urutan 0,1 kesalahan per KSLOC. Angka tipikal tampaknya 20 hingga 50 kesalahan per KSLOC. Sebagai referensi, makalah Google untuk Andy Jerman berjudul "Analisis Kode Statis Perangkat Lunak - Pelajaran yang Didapat".
Schedler

1
Saya akan membantah angka-angka ini - sepenuhnya tergantung pada bahasa, kompiler, dan lingkungan yang dapat dieksekusi. Kesalahan ketik dalam kode JavaScript dapat memakan waktu bertahun - tahun untuk ditemukan, tetapi kesalahan ketik dalam bahasa yang dikompilasi akan ditemukan pada kompilasi pertama.
JBRWilkinson

7

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 Anda harus menulis 96 tes untuk memberikan kepercayaan yang wajar. Ini tidak biasa untuk kode yang dihasilkan (melalui WPF atau generator parser) untuk membuat sesuatu yang kompleks ini. Ini dapat memberikan gambaran kasar tentang tingkat upaya yang diperlukan untuk men-debug suatu metode.

Intinya

Setiap pengukuran yang Anda lakukan perlu 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 penguji kali ini lebih teliti. Juga, definisi "normal" dapat berubah sepanjang umur proyek.

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


Bug lain yang terkait yang dapat berguna dalam beberapa kasus adalah bug per baris kode. Secara umum, basis kode matang harus memiliki jumlah bug per baris kode yang cukup rendah dibandingkan dengan aplikasi yang masih dalam pengembangan.
rjzii

@Rob Z, dengan metrik apa pun, orang akan melakukan cukup hanya untuk mengoptimalkan metrik itu. Pada bug per baris kode, Anda mungkin meminta pengembang memperkenalkan variabel yang tidak digunakan yang mereka tambahkan hanya untuk meningkatkan jumlah LOC bebas bug (karena penghitung SLOC dapat mendeteksi beberapa titik koma). Tentu saja, itu juga secara artifisial meningkatkan jumlah kode yang harus dilalui.
Berin Loritsch

6

Kode sumber adalah liabilitas, 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.


4

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.


2
Cakupan 100% hanya 100% jika mencakup semua jalur, bukan hanya semua jalur. Dalam setiap bagian perangkat lunak yang realistis, cakupan jalur 100% adalah tujuan yang buruk untuk ditetapkan, karena akan sangat mahal untuk dijangkau, dan masih hanya akan memberi tahu Anda bahwa kode Anda berperilaku seperti yang dirancang, bukan karena desain itu sendiri yang baik. Anda bisa memiliki celah keamanan yang menganga, dan memiliki cakupan jalur 100%.
Joeri Sebrechts

+1 Lebih banyak kode sumber belum tentu lebih baik.
Larry Coleman

Hanya aplikasi yang sangat sederhana yang dapat menerima cakupan uji 100% (membuat cakupan menjadi berlebihan). Secara komputasi mahal (jika tidak layak) untuk mencapai cakupan uji 100% untuk perangkat lunak yang kompleks. Kita telah mengetahui fakta itu dengan alasan yang kuat selama 6 dekade sekarang. Kedua, pengujian hanya memberi tahu Anda bahwa Anda belum menemukan bug - itu tidak menjamin Anda bahwa tidak ada bug yang bukan tentang kualitas struktural, ukuran atau kompleksitas (sesuatu yang juga dikenal untuk waktu yang cukup lama.) Tidak mengetahui fakta-fakta ini ketika bekerja dalam perangkat lunak mirip dengan fisikawan yang tidak mengetahui hukum termodinamika, sungguh.
luis.espinal

@ luis.espinal Software sangat besar sehingga terlalu mahal untuk pengujian adalah perangkat lunak yang ditulis dengan buruk. Hampir tidak memiliki petunjuk tentang cara membuat perangkat lunak yang berfungsi.
Pablo Ariel

@PabloAriel - "Perangkat lunak sangat besar sehingga terlalu mahal untuk diuji" << Bukan itu yang saya katakan. Baca komentar (mungkin dua atau tiga kali) untuk memastikan Anda benar-benar membaca apa yang Anda pikir sedang Anda baca.
luis.espinal

4

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

Bertahun-tahun yang lalu saya bekerja pada 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 sekitar 30.000 baris kode, bukan pekerjaan 3 bulan yang buruk 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 ini: -40.000 baris kode. Selama tinjauan kinerja setelah kuartal kami mendapat teguran resmi dari perusahaan karena gagal memenuhi persyaratan produktivitas 20.000 baris kode yang dihasilkan per kuartal (setelah semua, alat telah menunjukkan bahwa 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 diganti dengan pujian.

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


Kenapa kau tidak menunjukkan diffnya saja ?!
reinierpost

Saya pikir itulah yang dilakukan. Tetapi jika suatu sistem sangat kaku bahkan tidak membunyikan lonceng alarm ketika datapoint palsu terang-terangan muncul itu tidak akan banyak gunanya.
jwenting

2
Jawaban Anda tidak menunjukkan bahwa KLOC tidak berguna, itu menunjukkan cara untuk tidak menggunakannya.
Neil N

2
itu menunjukkan bahwa mengandalkan mereka sebagai ukuran produktivitas adalah picik, mengandalkan mereka karena satu-satunya ukuran adalah idiot. Dalam proyek lain yang menggunakan KLOC sebagai ukuran produktivitas dan bahkan kualitas, kami dengan mudah menggembungkan angka-angka dengan menciptakan standar pengkodean yang menyebabkan banyak garis (praktik penyanggaan C ++, jalur ekstra kosong hanya dengan komentar singkat di mana-mana, membelah kondisi dalam pernyataan if over 3 baris, dll.).
jwenting

1
Menggunakan SLOC sebagai metrik produktivitas hanya bodoh dan mungkin tidak akan pernah memberikan hasil yang baik. Menggunakan SLOC sebagai metrik kualitas yang menunjukkan pemeliharaan dan jumlah cacat lebih waras, dengan semua peringatan sudah dibahas pada pertanyaan ini.
redcalx

2

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 aplikasi tidak gagal secara bencana; dengan sisa kegunaannya tergantung pada kualitas unit tes.


cakupan kode adalah metrik yang salah (meskipun dapat digunakan) juga. Itu mengundang menulis tes omong kosong hanya untuk mendapatkan cakupan yang lebih tinggi. Dan tentu saja ada hal-hal yang tidak akan pernah dibahas, dan orang-orang akan mulai menghindari menulis hal-hal itu. misalnya saya telah melihat alat cakupan kode yang menandai JavaDoc sebagai kode dan tentu saja itu tidak akan dibahas. alat lain menandai semua garis kosong karena tidak dicakup oleh pengujian. Anda akan setuju bahwa menghilangkan komentar dan spasi putih dalam kode Anda lebih buruk daripada melewatkan tes unit untuk beberapa setter saya harap?
jwenting

Tentu saja, tes unit yang buruk lebih menyakitkan daripada membantu dalam banyak hal. Misalnya, Anda bisa mendapatkan cakupan kode 100% untuk serangkaian tes yang tidak memiliki satu pernyataan.
StuperUser

1

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

Ini bukan metrik absolut yang sangat berguna 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

Saya sering bekerja pada paket C ++ raksasa, dan ketika mencari kode bermasalah layak refactoring Kompleksitas Cyclomatic atau FanIn / FanOut yang mengerikan biasanya tanda yang cukup bagus untuk dicari. Memperbaiki masalah di sana 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 beberapa ambang yang sulit setelah gagal membangun atau menolak komit akan konyol.


1

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 pengembang java yang terus-menerus memeriksa metrik (antara lain) dari kode saya terhadap seperangkat aturan yang telah kami tetapkan dan menandai 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 berpikir 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 / Tinjauan 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 yang 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 pada 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 penggandaan 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 garis metrik kode sumber adalah ketika melihat basis kode yang tidak saya kenal. Ini memungkinkan saya untuk dengan cepat mengukur ukuran kasar proyek dibandingkan dengan yang lain yang pernah saya kerjakan. 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.


0

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

Untuk bisnis:

A: Jumlah jam kerja

Untuk penyelia coder:

A: Tidak masalah. Mari kita lakukan semuanya hari ini

Untuk harga diri coder:

A: Jumlah SLOC (Sumber Baris kode)

Untuk ibu coder:

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

melanjutkan komentar di bawah ...


Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.