Haruskah saya merasa terganggu jika rasio LOC / hari saya terlalu tinggi? [Tutup]


9

Saat ini saya sedang mengerjakan proyek indie, jadi saya tidak benar-benar memiliki kemewahan di seluruh pengujian manusia atau review kode eksternal - namun, saya tidak melihat bug yang sulit dalam kode saya saat ini (saya memperbaikinya seperti yang saya lihat mereka) , dan sebagian besar waktu itu hanya nama bidang yang salah dan semacamnya, hal-hal yang Anda perbaiki dalam satu atau dua menit), dan saya mengujinya setelah menerapkan fitur apa pun sebelum mendorongnya. Akhir-akhir ini nomor LOC saya sekitar 400 sehari (sebagai catatan, ini C #), dan saya tidak hanya menerapkan sistem baru, tetapi juga menulis ulang hal-hal yang sudah saya tulis dan memperbaiki beberapa bug.

Haruskah saya merasa terganggu? Apakah itu pertanda bahwa saya harus berhenti dan meninjau semua kode yang telah saya tulis hingga tanggal ini dan memperbaikinya?


bagaimana Anda mengukur LOC? apakah itu mengecualikan kode yang dihasilkan visual studio atau tidak?
jk.

Dengan perintah bash ini di folder kode saya: (find ./ -name '* .cs' -print0 | xargs -0 cat) | wc -l
Max Yankov

benar sehingga kemungkinan akan menyertakan kode yang dihasilkan misalnya designer.cs - Saya tidak akan khawatir tentang jumlah baris yang Anda tulis
jk.

Secara umum, ya, tetapi dengan lingkungan khusus ini (mesin game Unity) bukan itu masalahnya.
Max Yankov

1
Saya mencoba untuk menghapus baris kode sebanyak yang saya bisa sebelum menambahkan lebih banyak. Bekerja dengan sistem minimal jauh lebih menyenangkan daripada alternatifnya.
Jon Purdy

Jawaban:


18

LOC mungkin adalah salah satu metrik yang paling banyak disalahgunakan, dan sebagai hasilnya mungkin merupakan salah satu ukuran kualitas kode yang tidak berguna, dan pengukuran upaya pemrograman yang bahkan lebih tidak berguna.

Ya, itu pernyataan yang berani saya buat, dan tidak, saya tidak bisa mengarahkan Anda untuk studi membuktikan poin saya. Namun, saya dapat menyatakan dengan pengalaman susah payah bahwa ketika Anda mulai khawatir tentang berapa banyak kode yang Anda tulis, Anda mungkin khawatir tentang masalah yang salah.

Pertama-tama Anda perlu bertanya pada diri sendiri apa yang Anda coba ukur atau buktikan, dan apakah bukti ini semata-mata tidak menarik, atau untuk mendukung peningkatan kualitas yang lebih luas dan di mana Anda perlu menggunakan informasi ini untuk mendapatkan dukungan dari tim Anda Saya manajemen untuk melakukan sesuatu.

Salah satu hal yang saya cenderung menggunakan LOC adalah sedikit pemeriksaan kewarasan. Jika saya menemukan diri saya menulis banyak kode, saya menjadi lebih tertarik pada LOC per metode, atau LOC per kelas, daripada LOC atas semua. Pengukuran ini mungkin merupakan indikator yang harus Anda lakukan untuk refactoring lebih lanjut jika Anda merasa sedikit OCD tentang seberapa baik faktor Anda. Kelas yang sangat besar mungkin perlu di refactored menjadi beberapa kelas yang lebih kecil, dan metode multi-line yang panjang mungkin perlu dipecah menjadi beberapa metode, kelas lain, atau bahkan mungkin menunjukkan beberapa pengulangan yang dapat dihapus. Perhatikan saya menggunakan kata "mungkin" beberapa kali di sana.

Kenyataannya adalah bahwa LOC hanya menyediakan indikator yang memungkinkan, dan tidak ada jaminan nyata bahwa kode Anda mungkin perlu diubah. Pertanyaan sebenarnya untuk ditanyakan adalah apakah kode berperilaku seperti yang disyaratkan dan seperti yang diharapkan. Jika demikian, maka pertanyaan Anda berikutnya adalah apakah Anda akan dapat mempertahankan kode dengan mudah atau tidak, dan apakah Anda akan punya waktu baik sekarang atau di masa depan untuk membuat perubahan pada kode kerja untuk mengurangi biaya pemeliharaan di masa mendatang.

Seringkali, banyak kode berarti Anda akan memiliki lebih banyak untuk dipelihara nanti, tetapi kadang-kadang bahkan kode yang diperhitungkan dengan baik dapat menjangkau ratusan baris kode, dan ya, Anda kadang-kadang menemukan diri Anda menulis ratusan baris kode dalam sehari. Namun pengalaman memberi tahu saya bahwa jika saya mempertahankan output dari ratusan baris kode baru setiap hari, sering kali ada risiko bahwa sebagian besar kode telah dipotong dan ditempelkan secara tidak tepat dari tempat lain, dan itu sendiri dapat mengindikasikan masalah dengan duplikasi dan pemeliharaan, tapi sekali lagi itu bukan jaminan, jadi saya cenderung mengandalkan apa yang dikatakan oleh pengalaman dan insting saya berdasarkan pada bagaimana tugas-tugas yang ada diselesaikan.

Cara terbaik untuk menghindari dilema yang ditimbulkan dalam IMHO pertanyaan Anda adalah dengan melupakan LOC, dan melakukan refactor SEMUA waktu. Tulis tes kode Anda terlebih dahulu, implementasikan untuk gagal, refactor untuk lulus, kemudian lihat apa yang mungkin di refactored di sana dan kemudian untuk memperbaiki kode. Anda akan meninggalkan tugas dengan mengetahui bahwa Anda telah memeriksa ulang pekerjaan Anda, dan Anda tidak akan terlalu khawatir tentang menebak-nebak diri sendiri di masa mendatang. Secara realistis, jika Anda menggunakan pendekatan uji-pertama seperti yang saya jelaskan, setiap pengukuran LOC / hari pada kode Anda yang lengkap akan benar-benar berarti Anda telah menulis 3-5 kali jumlah yang diukur, dengan upaya itu berhasil disembunyikan oleh refactoring Anda yang sedang berlangsung upaya.


1
+1 400 baris sehari bisa menjadi indikasi masalah, sayangnya saya pikir satu-satunya cara untuk mengetahuinya adalah review kode, yang sulit pada tim 1 orang
jk.

Terima kasih atas jawaban yang begitu terperinci :) Saya pikir ini sepenuhnya mencakup topik.
Max Yankov

@jk. Saya yakin saya menanggapi komentar Anda dalam konteks jawaban saya. Saat solo, cara terbaik untuk melindungi kualitas kode Anda adalah dengan fokus pada cara Anda menulis dan menguji kode Anda. Serangkaian tes yang baik ditambah dengan mentalitas refactoring yang berkelanjutan dapat sebagus ulasan kode dalam banyak hal. Perhatikan bahwa saya tidak mengatakan untuk melakukan tanpa ulasan sama sekali, tetapi mereka harus menjadi yang kedua untuk memastikan produk Anda memenuhi persyaratan dan memiliki cakupan pengujian yang baik, yang memungkinkan perubahan di masa depan dibuat dengan percaya diri. Pertanyaan pertama saya selama tinjauan kode selalu "Di mana tes untuk ini?" :-)
S.Robins

+1 Meskipun Anda tidak dapat menunjuk ke studi yang menunjukkan bahwa LOC adalah metrik yang buruk, mudah untuk menemukan studi yang mengalami masalah karena mereka menggunakan LOC sebagai metrik.
daramarak

Sepenuhnya setuju bahwa LOC adalah metrik yang tidak berguna. Beberapa hari saya menulis ratusan baris kode dan tidak masalah. Beberapa hari saya bersih nol. Beberapa hari yang saya lakukan hanyalah menghapus kode. :-)
Brian Knoblauch

5

Tidak sama sekali - beberapa hari Anda memperbaiki bug yang sulit ditemukan dan hanya mengubah satu baris. Hari-hari lain Anda menambahkan kode baru dan menulis beberapa ribu baris.

LOC harian tidak memberi tahu Anda apa pun kecuali bahwa tugas untuk hari itu dapat diselesaikan dengan 400 baris kode.


2

Beberapa jawaban ini tidak ada gunanya, Anda tidak menggunakan LOC sebagai ukuran produktivitas (jika Anda maka Anda tidak akan khawatir tentang menjadi terlalu 'produktif'), apa yang sebenarnya Anda lakukan adalah mengkhawatirkan kualitas kode Anda karena kode adalah musuh ini adalah hal yang baik untuk dikhawatirkan.

Sayangnya satu-satunya cara untuk mengetahui tentang kualitas kode adalah tinjauan kode, karena Anda adalah tim satu orang, ini akan sulit, bahkan jika Anda berhenti untuk meninjau kode Anda (dan Anda tidak benar-benar ingin berhenti, bukan?) Meninjau Anda kode sendiri tidak akan mengungkapkan sebanyak rekan meninjau kode Anda. Saya sarankan mencoba membuat orang lain untuk meninjau setidaknya beberapa kode Anda sehingga Anda dapat mengetahui apakah 400 LOC / hari Anda mengaduk-aduk omong kosong atau tidak. Bahkan peninjauan independen terhadap kode satu hari akan membantu di sini


1

Anda tidak perlu repot dengan jumlah LOC yang Anda hasilkan per hari.

Tetapi Anda harus merasa terganggu:

  • jika kode Anda tidak diuji (jika misalnya, Anda tidak memiliki tes unit)
  • jika Anda mulai kesulitan menambahkan fitur baru atau mengubah fitur yang diimplementasikan (itu berarti refactoring Anda tidak tepat)
  • jika pengalaman Anda tidak besar, dan kode Anda tidak ditinjau (sepasang mata ekstra kemungkinan akan menemukan masalah)

0

LOC adalah ukuran produktivitas 'resmi', tetapi argumen yang menentang nilainya bisa panjang (ORM dapat menghasilkan 50.000 baris kode dalam 3 menit, namun, jika desain database salah, semua kode dapat masuk ke tempat sampah).

Saya sarankan Anda mengukur kemajuan Anda dengan melacak% tugas selesai vs waktu vs% tugas yang direncanakan akan selesai. Inilah yang terpenting. Pelanggan membayar kode kerja yang memberikan nilai bisnis bukan untuk LOC.

Beberapa referensi tentang LOC


tapi dia tidak menggunakan LOC sebagai ukuran produktivitas
jk.

Ya, tapi seperti yang saya katakan itu bukan ukuran yang akurat. Hal yang sama ketika Anda menggunakan "nilai rata-rata 1,2.100" Anda mendapatkan rata-rata tetapi bias dan tidak akurat. Dengan LOC, segalanya menjadi lebih buruk karena setiap lingkungan pengembangan dan seperangkat alat dapat mencerminkan angka produktivitas berbeda. Misalnya, LOC tidak dapat membandingkan kompleksitas kode, hanya panjangnya. Saya telah mengubah posting asli dengan 2 referensi yang mungkin ingin Anda lihat.
NoChance

0

Apakah Anda juga mengukur jumlah duplikat kode ?

Jika output tinggi adalah karena Anda memiliki banyak copy & paste dalam kode Anda maka Anda harus khawatir.

Alasan: jika ada kesalahan pada sumber copy & paste Anda sulit dan rentan kesalahan untuk memperbaiki semua penggunaan dari copy & paste


-1

Jika Anda percaya pada kode fungsional yang indah, maka itu harus menjadi satu-satunya ukuran Anda

"Apakah itu mengalir? Apakah itu terlihat indah?"


3
satu-satunya ukuran? bagaimana cara kerjanya? apakah cukup cepat?
jk.

itu sebabnya saya katakan fungsional :)
Darknight
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.