it-swarm-id.com

Berapa banyak baris kode yang dapat dihasilkan oleh pengembang C # per bulan?

Seorang eksekutif di tempat kerja saya bertanya kepada saya dan kelompok pengembang pertanyaan:

Berapa banyak baris kode yang dapat dihasilkan oleh pengembang C # per bulan?

Sistem lama akan di-porting ke C # dan dia ingin ukuran ini sebagai bagian dari perencanaan proyek.

Dari beberapa sumber (tampaknya dapat dikreditkan) dia memiliki jawaban "10 SLOC/bulan" tapi dia tidak senang dengan itu.

Kelompok itu sepakat bahwa ini hampir mustahil untuk ditentukan karena akan tergantung pada daftar panjang keadaan. Tetapi kita dapat mengatakan bahwa lelaki itu tidak akan pergi (atau sangat kecewa pada kita) jika kita tidak menemukan jawaban yang cocok untuknya. Jadi dia pergi dengan jawaban berkali-kali lebih baik dari "10 SLOC/hari"

Dapatkah pertanyaan ini dijawab? (begitu saja atau bahkan dengan beberapa analisis)

21
lox

Tanyakan kepada eksekutif Anda berapa halaman kontrak yang bisa ditulis pengacaranya per bulan. Kemudian (semoga) ia akan menyadari bahwa ada perbedaan besar antara menulis kontrak satu halaman dan menulis kontrak 300 halaman tanpa celah dan kontradiksi. Atau antara menulis kontrak baru dan mengubah yang sudah ada. Atau antara menulis kontrak baru dan menerjemahkannya ke bahasa yang berbeda. Atau ke sistem hukum yang berbeda. Mungkin dia bahkan akan setuju bahwa "halaman kontrak per unit waktu" bukanlah ukuran yang sangat baik untuk produktivitas pengacara.

Tetapi untuk memberi Anda beberapa jawaban untuk pertanyaan Anda yang sebenarnya: Dalam pengalaman saya, untuk proyek baru beberapa ratus SLOC per hari dan pengembang tidak biasa. Tetapi segera setelah bug pertama muncul, jumlah ini akan turun tajam.

84
nikie

Berapa banyak baris kode yang dapat dihasilkan oleh pengembang C # per bulan?

Jika bagus, kurang dari nol.

33
quentin-starin

Jalankan ke arah lain ... Sekarang.

LoC adalah salah satu metrik terburuk yang dapat Anda gunakan.

Pengembang yang buruk berpotensi menulis lebih banyak LoC sehari daripada pengembang yang baik, tetapi menghasilkan kode sampah.

Bergantung pada kerumitan kode, porting dapat dilakukan dengan proses otomatisasi yang akan menghasilkan ribuan + perubahan LoC sehari, sedangkan bagian yang lebih sulit di mana bahasa yang dikonstruksi adalah kode yang sangat berbeda untuk porting di 100LoC sehari.

Kirim dia untuk membaca halaman Wikipedia di SLOC . Jika memberikan beberapa contoh yang bagus dan sederhana tentang mengapa itu adalah metrik yang buruk.

21
Dan McGrath

Jawaban yang Tepat: Tidak ...

Eksekutif ini harus dididik, bahwa SLOC bukan metrik yang valid untuk kemajuan analisis

The Sloppy Answer: Nomor apa pun yang bisa Anda buat.

Berikan saja beberapa nomor, Anda dan tim Anda dapat dengan mudah menambah nomor itu. (Dengan meletakkan kecuali baris, baris kosong, komentar dll dll, hanya untuk memungkinkan orang ini untuk terus hidup di dunia fantasinya, dan menghantui tim lain dan melanjutkan siklus yang diperkuat kesengsaraan yang membuat cerita ke thwailywtf.

Tidak baik, tetapi bisa dilakukan.

18
Zekta Chan

Dari pandangan pertama pertanyaan ini terlihat benar-benar bodoh, dan semua orang di sini menjawab hanya bagian C # LoC yang bodoh itu. Tapi ada satu nuansa penting - ini adalah pertanyaan tentang kinerja porting. Cara yang tepat untuk mengajukan pertanyaan ini adalah dengan bertanya, berapa banyak baris kode dari proyek sumber (yang sedang diangkut) yang dapat ditangani oleh pengembang dalam satuan waktu tertentu. Ini pertanyaan yang dibenarkan sempurna, karena jumlah baris kode diketahui, dan jumlah pekerjaan yang harus dilakukan. Dan cara yang tepat untuk menjawab pertanyaan ini adalah dengan mengumpulkan sedikit data historis - bekerja selama, katakanlah, seminggu, dan mengukur kinerja masing-masing pengembang.

10
SK-logic

Saya hanya punya satu hal untuk dikatakan:

"Mengukur kemajuan pemrograman berdasarkan baris kode seperti mengukur kemajuan pembangunan pesawat berdasarkan beratnya."

-- Bill Gates

Setelah itu, Anda mungkin berpendapat bahwa Bill Gates tidak tahu bagaimana membuat perangkat lunak yang sukses;)

Catatan: SLOC adalah ukuran kompleksitas basis kode yang sangat baik!

7
Matthieu M.
I 
can
write
large
numbers
of
lines
of
code
per
month.

Sebanding dengan jumlah kata, sebenarnya.

Anda mengerti maksud saya?

5
JBRWilkinson

Biasanya adalah ide yang buruk untuk menyebut bos Anda idiot, jadi saran saya mulai dengan memahami dan mendiskusikan metrik, daripada menolaknya.

Beberapa orang yang sebenarnya tidak dianggap idiot telah menggunakan metrik yang didasarkan pada baris kode. Fred Brooks, Barry Boehm, Capers Jones, Watts Humphries, Michael Fagan, dan Steve McConnell semuanya menggunakan mereka. Anda mungkin telah menggunakannya bahkan jika hanya untuk mengatakan kepada seorang rekan, modul Tuhan ini 4000 baris, perlu dipecah menjadi kelas yang lebih kecil.

Ada data spesifik terkait dengan pertanyaan ini dari sumber yang banyak dari kita hormati.

http://www.codinghorror.com/blog/2006/07/diseconomies-of-scale-and-lines-of-code.html

http://www.codinghorror.com/blog/2005/08/are-all-programming-languages-the-same.html

http://discuss.joelonsoftware.com/default.asp?joel.3.286106.22

Saya menduga bahwa penggunaan terbaik dari baris kode per jam programmer adalah untuk menunjukkan bahwa selama umur proyek, nilai ini akan mulai cukup tinggi, tetapi karena cacat ditemukan dan diperbaiki, baris kode baru akan ditambahkan untuk menyelesaikan masalah yang bukan bagian dari perkiraan semula, dan baris kode yang dihapus untuk menghilangkan duplikasi dan meningkatkan efisiensi akan menunjukkan bahwa LOC/jam menunjukkan hal-hal selain produktivitas.

  • Ketika kode ditulis dengan cepat, ceroboh, kembung, dan tanpa upaya refactoring, efisiensi nyata akan berada pada titik tertinggi. Moral di sini adalah bahwa Anda harus berhati-hati terhadap apa yang Anda ukur.
  • Untuk pengembang tertentu, jika mereka menambah atau menyentuh kode dalam jumlah besar minggu ini, minggu depan mungkin ada hutang teknis untuk membayar dalam hal tinjauan kode, pengujian, debug, dan pengerjaan ulang.
  • Beberapa pengembang akan bekerja pada tingkat output yang lebih konsisten daripada yang lain. Dapat ditemukan bahwa mereka paling banyak menghabiskan waktu untuk mendapatkan cerita pengguna yang bagus, berbalik dengan sangat cepat dan membuat tes unit yang sesuai, dan kemudian berbalik dan dengan cepat membuat kode yang berfokus hanya pada cerita pengguna. Yang perlu diperhatikan di sini adalah bahwa pengembang metodis mungkin akan cepat berbalik, akan menulis kode ringkas, dan memiliki pengerjaan ulang yang rendah karena mereka memahami masalah dan solusinya dengan sangat baik sebelum mereka mulai membuat kode. Tampaknya masuk akal bahwa mereka akan kode kurang karena mereka kode hanya setelah mereka memikirkannya, daripada sebelum dan sesudah.
  • Ketika kode dievaluasi kerapatan cacatnya, ia akan ditemukan kurang dari seragam. Beberapa kode akan menyebabkan sebagian besar masalah dan cacat. Itu akan menjadi kandidat untuk menulis ulang. Ketika itu terjadi, itu akan menjadi kode yang paling mahal karena berdasarkan itu pengerjaan ulang tingkat tinggi. Ini akan memiliki baris tertinggi jumlah kode (ditambahkan, dihapus, dimodifikasi, seperti yang dapat dilaporkan dari alat seperti CVS atau SVN), tetapi baris kode net terendah per jam diinvestasikan. Ini mungkin akhirnya menjadi kombinasi kode baik menerapkan masalah yang paling kompleks atau solusi yang paling rumit.

Terlepas dari bagaimana perdebatan mengenai produktivitas programmer dalam baris kode ternyata Anda akan menemukan bahwa Anda membutuhkan tenaga kerja lebih dari yang Anda mampu dan sistem tidak akan pernah selesai pada waktunya. Anda alat yang sebenarnya bukan metrik. Mereka menggunakan metodologi unggul, pengembang terbaik yang dapat Anda sewa atau latih, dan kontrol ruang lingkup dan risiko (mungkin dengan metode Agile).

4
DeveloperDon

Saya mungkin memiliki sikap yang sedikit berbeda dalam hal ini, tetapi saya pikir saya mungkin mengerti mengapa eksekutif mencari informasi ini jika mereka sedang melakukan perencanaan proyek. Karena sulit untuk memperkirakan berapa lama proyek akan berlangsung, salah satu metode yang digunakan (lihat: Estimasi Perangkat Lunak: Demistifying the Black Art ) adalah memperkirakan berapa lama proyek akan berlangsung. berdasarkan jumlah SLOCs dalam proyek serupa dan sekarang mungkin pengembang menghasilkan rata-rata. Dalam praktiknya ini dimaksudkan untuk dilakukan dengan menggunakan catatan sejarah yang dimiliki grup untuk proyek serupa dengan pengembang yang sama atau serupa.

Namun, tidak ada artinya bahwa perkiraan ini hanya dimaksudkan untuk perencanaan proyek dasar dan tidak benar-benar dimaksudkan untuk mengatur kecepatan pengembang pada proyek karena semuanya berubah dari hari ke hari. Dengan demikian, sebagian besar dari apa yang Anda baca tentang menggunakan SLOCs sebagai alat estimasi adalah bahwa mereka baik dalam jangka panjang jika Anda sudah memiliki pengetahuan yang baik, tetapi buruk untuk penggunaan sehari-hari.

4
rjzii

Saya dapat memberitahu Anda bahwa banyak kontraktor untuk proyek besar menulis 15.000 LOC (masing-masing) dalam setahun. Itu jawaban yang sangat kasar, tetapi itu berguna bagi kami karena kami memiliki 400.000 C++ LoC yang ada dan kami dapat menemukan bahwa mengonversi semuanya menjadi C # akan membutuhkan waktu sekitar 26 tahun untuk diselesaikan. Berikan atau ambil.

Jadi sekarang kita tahu urutan besarnya, kita dapat merencanakan lebih baik untuk itu - mendapatkan 20 devs dan memperkirakan pekerjaan satu tahun untuk mereka semua akan tepat. Sebelum menghitung, kami tidak memiliki petunjuk berapa lama untuk bermigrasi.

Jadi saran saya untuk Anda adalah untuk checkout semua kode yang Anda tulis dalam jumlah waktu tertentu (saya beruntung memiliki proyek baru untuk dikerjakan), kemudian jalankan salah satu dari banyak alat metrik kode di dalamnya. Bagilah angka berdasarkan waktu dan Anda dapat memberikan jawaban yang akurat - berapa banyak LOC Anda benar-benar menulis per hari. Bagi kami, itu keluar pada 90 LOC per hari! Saya kira kami memang memiliki banyak pertemuan dan dokumentasi tentang proyek itu, tetapi kemudian saya kira kami akan memiliki banyak pertemuan dan dokumentasi pada yang berikutnya juga :)

3
gbjbaanb

Beri dia metrik yang lebih baik untuk dikerjakan

Alih-alih LOC , jelaskan ini the metrik terburuk yang digunakan. Lalu beri dia alternatif:

No. Fungsi/Fitur Per Permintaan Fitur/Fungsi -> NOFF/RFF

Anda mungkin perlu menambahkan pembobotan/normalisasi di atas NOFF/RFF, untuk memenuhi jumlah permintaan per minggu.

:) jelas di atas dibuat, tetapi apa pun, lebih baik daripada SLOC ...

3
Darknight

Kedengarannya benar.

https://stackoverflow.com/questions/966800/mythical-man-month-10-lines-per-developer-day-how-close-on-large-projects

Jika Anda memperhitungkan debugging, dokumentasi, perencanaan dll. Rata-rata sekitar 10 baris kode per hari. Sebenarnya saya akan menilai 10 baris sehari di sisi atas (yaitu pengembang yang sangat produktif).

Meskipun Anda dapat menghasilkan beberapa ratus baris dalam satu hari (ini tidak berkelanjutan). Itu bukan kode kualitas sampai Anda kemudian menambahkan semua unit uji dokumentasi dan tentu saja debug kode setelah tes unit Anda menunjukkan kesalahan. Setelah semua yang Anda lakukan Anda kembali ke 10.

2
Martin York

Jawaban lain benar, itu adalah pertanyaan bodoh dan jawabannya tidak berarti apa-apa. Itu semua benar, tetapi saya kebetulan tahu berapa banyak baris kode yang saya hasilkan kira-kira satu bulan.

Ini sekitar 3000 baris kode C # tanpa XML-doc. Saya menerapkan fungsi baru dan berakhir dengan jumlah ini dalam sebulan atau sebulan dan satu minggu. Itu semua yang berakhir di kontrol sumber, banyak kode ditulis dan kemudian dire-refored atau dihapus.

Saya seorang pengembang C # dan saya mencoba untuk menjadi baik dalam hal itu, tetapi saya tidak bisa memberi tahu Anda seberapa baik saya secara objektif. Saya mencoba menulis kode yang baik dan berusaha keras untuk membuatnya mudah dipelihara. Saya hanya memberikan komentar satu atau dua kali dalam kode ini.

Saya tidak tahu apakah terlalu banyak atau terlalu sedikit baris kode dan saya harus mengatakan saya tidak terlalu peduli. Ini adalah data yang tidak berarti dan tidak dapat digunakan dengan aman untuk ekstrapolasi dengan cara apa pun. Tapi saya kebetulan tahu data ini jadi saya memutuskan untuk berbagi.

1
Dyppl

Biarkan manajer Anda menanganinya, atau mulai mencari pekerjaan.

Dalam semua keseriusan, Anda dapat menghabiskan waktu dengan apa yang mungkin berakhir dengan usaha tanpa harapan dalam menjelaskan kepada eksekutif metode yang tepat dan tidak tepat untuk mengukur kemajuan proyek menuju penyelesaian. Dalam semua kenyataan, untuk apa manajer proyek dan manajer proyek.

Di sisi lain, situasinya sedemikian rupa sehingga eksekutif-dalam-pertanyaan ADALAH insinyur dan/atau manajer proyek Anda. Anda memiliki masalah yang jauh lebih besar dan lebih mendasar untuk dihadapi, bahkan jika masalah itu belum terungkap. Dalam hal ini masalah seperti ini dapat berfungsi sebagai "tembakan peringatan" untuk masalah yang lebih besar yang akan datang.

1
mummey

Dugaan saya adalah, pengembang yang bekerja dengan bahasa seperti C # harus dapat menulis/menghasilkan sekitar 10K LoCs/hari. Saya kira, saya bisa melakukan itu. Aku tidak akan pernah melakukannya.

Apa yang Anda inginkan dari seorang pengembang adalah, untuk menyelesaikan pekerjaannya dalam 10 LoCs/hari. Lebih sedikit kode selalu lebih baik. Saya sering kali mulai memproduksi sejumlah besar kode dan kemudian memotong sampai saya mencapai kesederhanaan maksimum, jadi saya benar-benar memiliki hari dengan LoC negatif.

Dalam arti tertentu, pengkodean itu seperti puisi. Pertanyaannya bukan, berapa banyak baris yang bisa ditulis oleh penyair, tetapi berapa banyak yang bisa ia sampaikan dalam 14 baris soneta.

1
back2dos

Yah, aku agak terlambat ke pesta ini seperti biasa, tapi ini sebenarnya yang menarik. Awalnya saya memiliki pemikiran yang sama karena kebanyakan pertanyaan eksekutif itu bodoh. Namun, saya membaca jawaban SK-logika dan menyadari bahwa itu adalah pertanyaan yang masuk akal yang diajukan dengan cara yang tidak masuk akal. Atau, dengan kata lain, ada masalah yang valid di balik pertanyaan.

Manajer sering perlu mencoba menentukan kelayakan, pendanaan, kepegawaian, dll untuk suatu proyek. Ini adalah masalah yang masuk akal. Untuk port langsung, perkiraan berdasarkan garis kode pelabuhan dibagi dengan garis rata-rata kode per pengembang per hari menarik dalam kesederhanaan, tetapi pasti gagal karena semua alasan yang diberikan pada halaman ini.

Pendekatan yang lebih masuk akal adalah: -

  1. Untuk perkiraan di tempat, tanyakan pengembang dengan pengalaman paling banyak dengan kode untuk perkiraan perut berapa lama. Ini pasti salah karena banyak alasan bahwa saya tidak akan pergi ke sini, tetapi itu adalah yang terbaik yang dapat mereka lakukan sejak awal. Setidaknya mereka harus memiliki gagasan apakah itu akan mudah dilakukan dalam seminggu atau bertahun-tahun bahkan dengan sumber daya tambahan. Jika ada port berukuran serupa atau pekerjaan yang dilakukan, mereka bisa menggunakan ini sebagai panduan.
  2. Perkirakan port per komponen untuk mendapatkan ukuran total. Tugas-tugas yang tidak terkait langsung dengan pelabuhan perlu dimasukkan, seperti menyiapkan infrastruktur (mesin, membangun sistem, dll), menyelidiki dan membeli perangkat lunak, dll.
  3. Identifikasi komponen port paling berisiko dan mulailah dengan yang pertama. Ini kemungkinan besar akan meledakan perkiraan, jadi harus dilakukan di muka jika memungkinkan sehingga ada kejutan terbatas di pelabuhan.
  4. Melacak kemajuan terhadap ukuran yang dilakukan pada langkah 2 untuk terus menghitung durasi yang diharapkan dari port. Ketika proyek bergerak maju, ini harus menjadi lebih akurat. Tentu saja, jumlah baris kode yang telah porting (fitur dalam basis kode asli yang sekarang ada dalam kode porting) juga dapat digunakan sebagai metrik dan sebenarnya membantu memastikan bahwa produk asli sedang diporting daripada sekelompok fungsi baru yang keren sedang ditambahkan tanpa menangani port yang sebenarnya.

Ini akan menjadi langkah sederhana, tentu saja ada banyak kegiatan lain di sekitar ini yang membantu seperti menyelidiki alat-alat porting dan kerangka kerja pluggable, membuat prototipe, menentukan apa yang benar-benar perlu porting, menggunakan kembali alat uji dan infrastruktur, dll.

0
acarlon