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

Seorang eksekutif di tempat kerja saya bertanya kepada saya dan sekelompok 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 " tetapi dia tidak senang dengan itu.

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

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

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.

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

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

Jika bagus, kurang dari nol.

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 bagus dan sederhana mengapa metrik ini begitu buruk.

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.

Beri dia nomor, Anda dan tim Anda bisa dengan mudah membuat 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.

Dari pandangan pertama pertanyaan ini terlihat benar-benar bodoh, dan semua orang di sini hanya menjawab 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 untuk, katakanlah, seminggu, dan mengukur kinerja masing-masing pengembang.

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 yang sangat baik untuk kompleksitas basis kode!

I 
can
write
large
numbers
of
lines
of
code
per
month.

Sebanding dengan jumlah kata, sebenarnya.

Anda mengerti maksud saya?

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 berdasarkan pada jumlah SLOC dalam proyek serupa dan sekarang dapat menghasilkan rata-rata pengembang. 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 sama sekali bahwa perkiraan ini hanya dimaksudkan untuk perencanaan proyek dasar dan sebenarnya tidak 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.

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 kolega, modul Tuhan ini 4000 baris, perlu dipecah menjadi kelas yang lebih kecil.

Ada data spesifik terkait 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 cepat, ceroboh, membengkak, dan tanpa upaya refactoring, efisiensi jelas akan berada di tertinggi. Moral di sini adalah bahwa Anda harus berhati-hati terhadap apa yang Anda ukur.
• Untuk pengembang tertentu, jika mereka menambah atau menyentuh jumlah kode yang tinggi 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, kode itu 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 paling mahal karena berdasarkan tingkat tinggi pengerjaan ulang. Ini akan memiliki garis-garis tertinggi bruto jumlah kode (ditambahkan, dihapus, dimodifikasi, seperti bisa dilaporkan dari alat seperti CVS atau SVN), tetapi garis-garis bersih terendah kode per jam diinvestasikan. Ini mungkin akhirnya menjadi kombinasi dari 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 manusia 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).

Beri dia metrik yang lebih baik untuk bekerja dengannya

Alih-alih LOC , menjelaskan hal ini adalah yang metrik terburuk untuk menggunakan. Lalu beri dia alternatif:

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

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 mengetahui 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 nomornya berdasarkan waktu dan Anda dapat memberikan jawaban yang akurat - berapa banyak LOC yang Anda tulis per hari. Bagi kami, yang 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 :)

Kedengarannya benar.

/programming/966800/mythical-man-month-10-lines-per-developer-day-how-close-on-large-projects

Jika Anda mempertimbangkan 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 debugged kode setelah tes unit Anda menunjukkan kesalahan. Setelah semua yang Anda lakukan Anda kembali ke 10.

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

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 rekayasa Anda dan / atau manajer proyek. Anda memiliki masalah yang jauh lebih besar dan lebih mendasar untuk dihadapi, bahkan jika belum terungkap. Dalam hal ini masalah seperti ini dapat berfungsi sebagai "tembakan peringatan" untuk masalah yang lebih besar yang akan datang.

Jawaban lain benar, itu adalah pertanyaan bodoh dan jawabannya tidak berarti apa-apa. Itu semua benar, tapi 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 berusaha 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 bagian data yang tidak berarti dan tidak dapat digunakan dengan aman untuk ekstrapolasi dengan cara apa pun. Tetapi saya kebetulan mengetahui data ini sehingga saya memutuskan untuk berbagi.

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 seringkali 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 ide apakah itu akan mudah dilakukan dalam seminggu atau tahun lagi 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 porting code) juga dapat digunakan sebagai metrik dan sebenarnya membantu memastikan bahwa produk asli sedang diporting daripada sekelompok fungsi baru yang keren sedang ditambahkan sementara tidak menangani port yang sebenarnya.

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