Adakah kegunaan SLOC yang dikenal untuk mengukur produktivitas?


54

Saya melakukan percakapan singkat dan tidak biasa dengan arsitek senior tentang bahasa yang dinamis dan statis. Dia mengatakan bahwa data perusahaan menunjukkan bahwa ada bukti untuk produktivitas yang lebih tinggi ketika bahasa statis digunakan. Catatan, ini adalah perusahaan besar dengan sejarah panjang. Yang mengejutkan saya (dan lainnya), metrik yang ia gunakan adalah baris kode yang ditambahkan.

Dia dengan cepat menolak keberatan tentang metrik yang mengatakan bahwa di dalam perusahaan yang sama, dengan budaya yang sama, lini bisnis dan dengan data yang cukup, perbedaan (seperti situasi unik dan kemampuan individu) berbaur cukup sehingga metrik SLOC berguna untuk membandingkan produktivitas alat dan bahasa.

Sementara saya tidak berpikir bahwa klaim ini didukung oleh analisis statistik yang ketat, adakah bukti dalam industri yang akan mendukung pemikiran ini?


25
Produktivitas adalah istilah yang salah. Istilah itu didefinisikan sebagai jumlah pekerjaan yang diselesaikan dalam periode waktu, yang tidak terkait dengan kode yang dihasilkan.
Frank Hileman

25
Orang bijak mengatakan kita harus mempertimbangkan baris kode bukan sebagai "dibangun" tetapi sebagai "dihabiskan"; dalam rekayasa fisik ketika kita mempertimbangkan jumlah bagian dan panjang BOM, lebih kecil lebih baik.
pjc50

23
Membandingkan bahasa yang berbeda (tidak peduli apakah statis atau dinamis) mengalahkan asumsi "dalam perusahaan yang sama, dengan budaya yang sama, lini bisnis": perbedaan dalam bahasa membuat perbandingan SLOC menjadi tidak berarti.
merampok

4
Metode ini secara tragis cacat. Bahkan dua pengembang berbeda di perusahaan yang sama menggunakan lingkungan pengembangan yang sama akan sering menghasilkan SLOC yang sangat berbeda untuk mengimplementasikan set fitur yang sama.
17 dari 26

8
Menggunakan SLOC untuk mengukur produktivitas sama masuk akalnya dengan menggunakan polusi yang dipancarkan untuk mengukur jarak yang ditempuh ketika yang harus Anda perhatikan adalah efisiensi bahan bakar. Cara-cara ini benar masih salah. Gunakan ini .
candied_orange

Jawaban:


65

Argumen arsitek senior bisa berarti dua hal.

  1. Ini mungkin berarti bahwa pengembang rata - rata di perusahaan menghasilkan lebih banyak baris kode ketika menggunakan bahasa statis daripada ketika menggunakan yang dinamis. Misalnya, jika lima belas pengembang bekerja dengan Java selama enam bulan, mereka akan menulis 100 KLOC, dan jika lima belas pengembang yang sama bekerja dengan Python selama enam bulan, mereka hanya akan menulis 50 KLOC.

    Tidak ada korelasi antara LOC dan produktivitas di sini. Bagaimana jika dibutuhkan empat kali lebih banyak baris kode di Jawa untuk menghasilkan fitur yang sama daripada di Python? Jika itu benar, menggunakan Python akan menghasilkan produktivitas dua kali lipat, berdasarkan metrik KLOC di atas.

  2. Dia juga dapat berarti bahwa pengembang rata-rata di perusahaan menghasilkan lebih sedikit baris kode ketika menggunakan bahasa statis daripada ketika menggunakan yang dinamis: lima belas pengembang akan menulis dalam enam bulan 100 KLOC di Jawa, atau 200 KLOC dengan Python.

    Walaupun lebih sedikit baris kode biasanya lebih baik (lebih sedikit kode untuk ditulis, dibaca dan dipelihara), masih belum jelas berapa banyak fitur yang dihasilkan pengembang Java dibandingkan dengan yang Python. Mungkin mereka menulis setengah baris kode dibandingkan dengan pengembang Python, tetapi juga menghasilkan setengah jumlah fitur?

Dalam kedua kasus, LOC bukan metrik yang berharga, karena fitur yang sama tidak akan menerjemahkan dalam jumlah baris kode yang sama dalam bahasa yang berbeda . Beberapa bahasa cenderung lebih bertele-tele; lainnya — lebih kompak. Sementara dalam beberapa kasus, kekompakan itu berharga, tidak ada aturan umum untuk itu. Contoh ekstrem adalah bahasa Brainfuck yang memiliki kekompakan ekstrim, tetapi yang tidak populer karena mudah dibaca. Membandingkan bahkan bahasa yang mirip bisa menjadi rumit: misalnya, ketika datang ke kurung kurawal, Jawa mengikuti gaya K&R, sementara di C #, kurawal kurawal ada pada garisnya sendiri dalam banyak kasus ketika mengikuti gaya resmi, yang mengarah ke buatan peningkatan LOCs untuk C #. Dan apa yang terjadi ketika seseorang membandingkan bahasa prosedural dengan bahasa berorientasi objek, atau dengan bahasa fungsional?

Alih-alih menggunakan metrik rawan kesalahan, arsitek senior dapat mengandalkan sekelompok metrik yang mengukur produktivitas saat digunakan bersama: jumlah fitur yang dikembangkan per bulan, jumlah bug yang diperkenalkan dalam basis kode dan waktu yang dihabiskan untuk menyelesaikan bug tersebut. , evolusi hutang teknis, dll. Perbandingan ini bisa rumit pada awalnya, karena kita harus memperhitungkan ketidakbiasaan tim dengan bahasa baru. Setelah tim menjadi cukup akrab dengan itu, pilihan harus didasarkan pada metrik yang stabil, serta sebagian besar pada preferensi anggota tim itu sendiri.

LOC memiliki nilai dalam beberapa situasi sempit. Misalnya, ini bisa memberi petunjuk tentang ukuran proyek dan bagian-bagian proyek (dan rata-rata berkorelasi dengan titik fungsi, sementara sering lebih mudah untuk diukur), atau itu bisa menunjukkan metode dan kelas yang mungkin perlu perhatian lebih lanjut karena ukuran besar mereka. Namun, LOC harus digunakan dengan hati-hati, karena terlalu sering disalahgunakan oleh orang-orang yang membayangkan korelasi antara hal-hal yang tidak terkait. Penggunaan LOC yang paling manusiawi adalah di masa lalu upaya untuk mengukur produktivitas pengembang individu berdasarkan LOC yang ditulis per bulan.


8
Ya. Satu-satunya metrik yang saya percayai adalah jumlah tiket (fitur, bug, riset, dll.) Yang diselesaikan per unit waktu. Ini bervariasi menurut tim (tim yang berbeda memecah tiket dengan granularitas yang berbeda) tetapi dalam tim atau kelompok tim yang sama suatu budaya akan muncul untuk membuat ukuran tiket cukup akurat (selama Anda tidak membandingkannya dari luar budaya itu)
slebetman

10
Hal yang saya sukai: "Jangan hanya mengandalkan satu metrik"
Chococroc

30
@slebetman Saya iri dengan presisi / konsistensi dari orang yang membuat tiket Anda, tetapi saya harus menyelesaikan masalah mulai dari "Perbaiki penulisan 2 kata" hingga "Tambahkan fitur X". Metrik tiket bahkan kurang berguna bagi saya daripada LOC. Mengurangi kode kelas hingga 20 LOC setidaknya memberi saya gambaran tentang pekerjaan yang dilakukan. Menyelesaikan 5 tiket bisa menjadi satu jam kerja, tetapi bisa juga seminggu.
R. Schmitz

3
@ R.Schmitz Ini sama di perusahaan saya, tetapi setiap tiket juga memiliki ukuran yang terkait, sehingga jumlah dari ukuran tiket akan bekerja.
Nico Burns

1
Bahkan mencoba menggunakan metrik tersebut memiliki masalah. Bagaimana jika fitur yang ditambahkan rumit dan sulit diimplementasikan? Atau bahkan mungkin situasi di mana fitur tertentu sangat mudah atau sulit diterapkan untuk suatu bahasa, tetapi secara umum bahasa lebih mudah / sulit untuk dikerjakan. Kurangnya produktivitas mungkin juga karena karyawan saat ini tidak terbiasa dengan bahasa pada awalnya. Orang seharusnya tidak mengandalkan metrik untuk menentukan bahasa apa yang digunakan.
John Smith

26

Tentang produktivitas dan SLOC

Masalah dengan SLOC

Masalah dengan metrik SLOC adalah ia mengukur perkiraan jumlah kode yang ditulis, tanpa memperhitungkan:

  • kualitas kode (yaitu bagaimana jika untuk setiap 100 SLOC Anda harus menambahkan 90 SLOC lain karena bug, tetapi Anda tidak tahu saat kode Anda dikirimkan?)
  • tujuan tercapai dengan kode (yaitu apakah 10K SLOC menangani semua kasus penggunaan yang diharapkan atau cerita pengguna? atau hanya sebagian kecil?)
  • pemeliharaan kode (yaitu apakah Anda harus menambahkan 1% atau 50% lebih banyak kode untuk menyesuaikan kode dengan persyaratan yang berkembang yang diharapkan?).

Jika tidak dinyatakan, produksi kode spaghetti rawan kesalahan yang tidak dapat dipelihara dengan banyak bagian yang disalin akan dianggap lebih produktif daripada kode yang dapat digunakan kembali yang direkayasa dengan cermat.

Jadi SLOC secara definitif bukan cara terbaik untuk mengukur produktivitas.

Produktivitas apa yang kita pertimbangkan?

Produktivitas diukur untuk suatu proses. Jadi SLOC bisa menjadi indikator yang valid sempurna untuk proses pengkodean saja.

Jika misalnya, Anda salah paham persyaratan yang buruk, menghabiskan waktu lima bulan untuk memproduksi perangkat lunak, menunjukkannya kepada pengguna, menemukan bahwa itu salah, dan menghabiskan 5 bulan lagi untuk menulis ulang untuk selamanya dari awal, Anda akan memiliki produktivitas yang sama di SLOC / bulan, bahwa tim menulis kode tepat pada saat pertama, misalnya karena mereka menggunakan proses gesit yang mengurangi kesalahpahaman melalui umpan balik yang sering. Produktivitas yang sama ini menyembunyikan masalah besar.

Jadi, mengukur produktivitas pengembangan perangkat lunak perlu memperhitungkan seluruh proses, termasuk menganalisis persyaratan, merancang apa yang harus dikodekan, pengkodean, pengujian, debugging, dan memverifikasi bahwa harapan pengguna terpenuhi. Karena semua kegiatan ini sangat berbeda, hal terbaik adalah mengukur satu-satunya pemikiran yang penting: perangkat lunak yang berfungsi, yaitu apa yang dihasilkan perangkat lunak bagi pengguna .

Bagaimana mengukur kiriman perangkat lunak?

Ada beberapa pendekatan:

  • Pendekatan khas dalam rekayasa perangkat lunak klasik adalah Function Points (FP). Titik fungsi diukur berdasarkan persyaratan yang harus dipenuhi (misalnya jumlah formulir, jumlah bidang dalam setiap formulir, dll ...). Produktivitas kemudian diukur dalam FP per unit waktu dan per orang. Beberapa perusahaan bahkan memiliki data yang menunjukkan berapa banyak poin fungsi yang dapat dihasilkan oleh seorang pengembang per unit waktu dalam bahasa tertentu untuk domain tertentu. Masalah dengan FP adalah membutuhkan persyaratan yang sangat rinci di muka dan itu memakan waktu.
  • Pendekatan yang lebih modern dan pragmatis adalah story point (SP). Ini digunakan untuk mengevaluasi kompleksitas kode yang akan dihasilkan, dan secara rutin digunakan untuk mengevaluasi kecepatan tim pengembangan. Namun, SP adalah ukuran estimasi untuk pekerjaan yang dilakukan sebelum semua detail diketahui. Itu bukan ukuran akhir dari apa yang sebenarnya terjadi. Jadi harus berhati-hati ketika menggunakannya sebagai ukuran produktivitas karena bisa menjadi bumerang pada proses estimasi .

Tentang produktivitas pengetikan statis vs dinamis

Saya harus mengakui bahwa saya pribadi penggemar bahasa yang diketik secara statis, karena di dalam diri saya, saya tahu itu lebih dapat diandalkan (bertahun-tahun pengkodean membuktikannya kepada saya).

Jadi satu hal yang saya ambil pasti adalah bahwa bahasa yang diketik secara statis dapat mencegah lebih banyak kesalahan / bug pada waktu kompilasi (mis. Kesalahan ketik, ketidakcocokan dalam jenis yang diharapkan, dll ...) daripada bahasa yang diketik secara tidak statis. Tetapi dalam semua obyektivitas, saya tidak akan berani menyamaratakan ini sebagai produktivitas yang lebih tinggi.

Apakah arsitek Anda benar?

Mungkin tidak.

Tetapi argumennya tampaknya tidak valid: perolehan produktivitas dari bahasa yang diketik secara statis berasal dari sejumlah besar kesalahan yang ditangkap dimuka oleh kompiler.

Akibatnya, tidak mungkin untuk mengetahui kenaikan produktivitas "lebih tinggi" ini dengan hanya melihat SLOC tanpa melihat pengerjaan ulang yang diperlukan untuk bahasa yang diketik secara dinamis. Jadi perbandingannya tidak adil.

Argumen keadaan yang sebanding juga tidak berlaku. Beberapa bahasa yang diketik secara dinamis memungkinkan beberapa konstruksi tingkat yang lebih tinggi yang memerlukan lebih sedikit kode daripada melakukan hal yang sama di salah satu bahasa klasik yang diketik secara statis. Jadi Anda mungkin memerlukan lebih sedikit waktu, menulis lebih sedikit kode, tetapi menambahkan analisis, pengujian, dan overhead verifikasi yang sama. Jadi, mengukur produktivitas oleh SLOC akan mencairkan potensi peningkatan produktivitas, sehingga menciptakan bias terhadap bahasa yang diketik secara dinamis.

Adakah studi untuk mendukung klaim itu?

Beberapa studi akademik baru-baru ini ada tentang topik ini. Meskipun beberapa dari mereka melihat keuntungan dari pengetikan statis, secara umum terbatas pada tujuan tertentu (dokumentasi, penggunaan kembali kode atau API yang tidak didokumentasikan dengan buruk, dll.). Kata-kata bijak juga digunakan karena IDE modern telah secara signifikan mengurangi risiko terkait pengetikan dinamis:


3
Poin kritik Anda telah dibahas dalam pertanyaan: "di dalam perusahaan yang sama, dengan budaya yang sama, lini bisnis dan dengan data yang cukup, perbedaan (seperti situasi unik dan kemampuan individu) berbaur cukup sehingga metrik SLOC berguna ". Yaitu argumennya adalah bahwa pada skala ini, semua basis kode akan memiliki kualitas yang sebanding. Meskipun secara pribadi, saya sangat meragukan itu benar.
amon

Kami menggunakan gitprime ( gitprime.com ) untuk pengukuran konkret, dan salah satu hal yang dilakukannya adalah melacak berapa kali pengembang menulis ulang baris kode yang sama. Jadi, jika Anda menulis beberapa kode, mendapatkan laporan bug, dan menulis ulang kode, itu sebenarnya mengukur efisiensi Anda dan melaporkan produktivitas bersih Anda. Singkatnya, saya tidak berpikir komentar Anda adalah masalah yang melekat dalam menggunakan SLoC sebagai ukuran produktivitas. Sebaliknya, saya pikir keluhan Anda adalah dengan sistem yang tidak mengukur SLoC "dengan benar".
Conor Mancone

8
@ConorMancone Tidak ada yang dibayar untuk menulis kode. Mereka dibayar untuk menciptakan solusi. Sebuah analogi akan mengukur seorang tukang kayu dengan berapa banyak kuku dan papan yang dia gunakan. Seorang badut yang memotong papan menjadi pendek dan membengkokkan lebih banyak paku yang ia bawa pulang akan lebih produktif daripada tukang kayu utama dengan metrik ini.
JimmyJames

1
@ Christophe Saya telah bereksperimen dengan mengukur kiriman ke produksi sebagai metrik produktivitas utama. Satu-satunya bagian yang sulit adalah bahwa beberapa hal mungkin lebih berfungsi daripada yang lain, tetapi dari apa yang dapat saya katakan, seiring waktu, tren hal-hal menuju throughput konsisten (statistik) cantik berdasarkan ukuran dan komposisi tim. Tentu saja, banyak yang masuk sehingga atribusi bisa menjadi tantangan tapi itu jangkar untuk pengukuran produktivitas pengembangan lainnya.
JimmyJames

2
Bertahun-tahun yang lalu, di setidaknya satu toko pemrograman beberapa orang menulis diagram logika dan orang lain mengubah diagram logika tersebut menjadi kode yang dapat dikompilasi. Pada dasarnya kompiler toko itu memiliki preprocessor manusia. Adalah adil untuk menggunakan SLoC / bulan untuk mengukur produktivitas salah satu dari preprosesor manusia tersebut; itu analog dengan berapa banyak sekrup yang bisa dipasang oleh pekerja jalur perakitan di lubang tempat para insinyur mengatakan mereka harus pergi. Insinyur yang menentukan 100 sekrup saat 15 adalah apa yang dibutuhkan oleh pekerjaan menurunkan produktivitas perusahaan. (Demikian juga jika mereka menentukan 5 sekrup!)
David K

7

Berikut adalah contoh tandingan untuk arsitek senior Anda: Misalkan saya ingin menulis hierarki tiga kelas, dua di antaranya berasal dari yang ketiga, menerapkan beberapa fungsi virtual yang didefinisikan oleh kelas dasar.

Jika saya menulis tiga kelas ini dalam C ++, itu cukup mudah. Saya mendeklarasikan kelas, menggunakan virtual di tempat yang benar, dan selesai.

Jika saya menulis tiga kelas ini dalam C, saya harus menambahkan sedikit kode: Saya perlu mendefinisikan structs untuk v-tables, saya perlu menambahkan pointer v-table ke kelas dasar, saya perlu menambahkan kode ke konstruktor untuk benar-benar mengatur pointer v-table, saya perlu menambahkan kode konstruktor untuk benar-benar memanggil konstruktor kelas dasar, saya perlu menambahkan kode untuk melakukan alokasi memori secara eksplisit sebelum memanggil konstruktor (yang C ++ newlakukan dalam satu langkah ), juga, saya perlu memisahkan kehancuran dari free()panggilan berikutnya , dan seterusnya, dan sebagainya.

Intinya adalah, semua hal tambahan ini cukup tidak ada artinya. Saya bisa melakukannya dengan sangat cepat. Jadi, saya tidak akan membutuhkan waktu lebih lama untuk menulis versi C daripada saya harus menulis versi C ++. Namun demikian, saya telah menghasilkan lebih banyak baris kode C daripada kode C ++. Sedemikian rupa sehingga saya tampaknya lebih produktif dalam C dalam hal SLOC.

Bahasa apa pun yang memerlukan sejumlah kode boilerplate akan tampak lebih produktif dalam hal SLOC daripada bahasa yang tidak memerlukan jumlah kode boilerplate yang sama.

Anda tahu, argumen SLOC sangat cacat secara fundamental, sehingga saya benar-benar melihatnya sebaliknya: Saya akan mengambil pernyataan "programmer cenderung menghasilkan lebih banyak SLOC dalam bahasa statis" artinya: "bahasa statis tampaknya memerlukan lebih banyak kode boilerplate, dan dengan demikian mengurangi produktivitas ".


1
Saya suka kalimat terakhir Anda.
Peter - Reinstate Monica

1
"bahasa statis tampaknya memerlukan lebih banyak kode boilerplate, dan dengan demikian mengurangi produktivitas": Ini lagi menunjukkan betapa cacatnya metrik SLOC. Jumlah baris terakhir tidak mempertimbangkan (1) berapa kali seseorang perlu menulis ulang kode sebelum mendapatkan solusi akhir (2) berapa banyak baris kode tambahan dalam bentuk unit test yang diperlukan (bahasa yang diketik secara dinamis memerlukan rata-rata lebih banyak lagi) unit test memiliki kepercayaan yang sebanding dalam kebenaran kode produksi). Metrik SLOC jelas cacat.
Giorgio

6

Saya akan menjadi pelawan.

Kami melacak SLoC di pekerjaan kami (meskipun kami tidak menggunakannya secara langsung dalam pengambilan keputusan kepegawaian), dan saya telah membuat orang berdebat tentang apa yang dikatakan kebanyakan orang dalam jawaban mereka. Akibatnya, "LoC tidak masalah karena teknologi X memungkinkan kita berbuat lebih banyak dengan lebih sedikit kode" atau "Pengembang yang lebih baik menulis lebih baik, kode lebih pendek, dan karenanya mereka tidak menulis lebih banyak daripada orang lain". Dalam pengalaman saya (walaupun saya tidak memiliki angka yang sulit untuk mendukung hal ini), keberatan ini sama sekali tidak benar. Dalam waktu saya sendiri, saya telah melihat korelasi yang jelas dalam tingkat dan kualitas produksi kode untuk pengembang kami, bila dibandingkan dengan semua pengukuran bermakna lainnya dari "kompetensi" keseluruhan mereka sebagai seorang insinyur. Untuk memberikan beberapa contoh tandingan terhadap berbagai argumen yang dibuat di atas:

  1. Ya, beberapa bahasa dapat berbuat lebih banyak dengan lebih sedikit kode. Bahkan, kami memiliki seluruh kerangka kerja yang telah kami bangun yang "mengotomatisasi" sebagian besar pengembangan untuk masalah bisnis khusus kami (hanya back-end). Hasil dari semua ini bukanlah bahwa orang menulis lebih sedikit kode, tetapi hanya karena kita memiliki lebih banyak waktu untuk menulis kode. Akibatnya, di perusahaan kami, tingkat penulisan kode secara keseluruhan cukup konstan di seluruh teknologi dan terutama tergantung pada tingkat kompetensi insinyur.
  2. Gagasan bahwa pengembang yang lebih baik akan menghasilkan lebih sedikit kode karena mereka menulis lebih pintar jelas tidak benar. Ya, program yang dirancang lebih baik mungkin menggunakan lebih sedikit baris kode. Namun, saya pribadi menemukan bahwa pengembang "yang lebih baik" yang menulis kode yang lebih efisien tidak perlu waktu lebih lama untuk merencanakannya daripada pengembang yang lebih junior menulis hal-hal yang jauh. Akibatnya, pengembang yang lebih senior akan lebih cepat menyelesaikan tugas pengkodean, dan beralih ke menulis kode yang berbeda dengan kecepatan tinggi yang sama.

Bagian terakhir itu adalah ringkasan keseluruhan saya, BTW. Apa yang saya temukan adalah bahwa terlepas dari tumpukan teknologi atau jenis proyek, sebagian besar pengembang memiliki langkah mereka sendiri, yang merupakan kecepatan mereka beroperasi. Jika suatu bahasa memiliki banyak fitur yang membuat kode pengembang lebih efektif, maka itu merupakan keuntungan besar bagi bisnis, tetapi itu tidak berarti bahwa mereka akan menulis lebih sedikit kode sebagai hasilnya. Sebagai gantinya, mereka menyelesaikan fitur lebih cepat, dan dengan cepat beralih ke kode baru. Sekali lagi, hasil akhirnya adalah bahwa mereka menilai di mana mereka kode terutama tergantung pada keterampilan mereka, dan lebih sedikit pada tumpukan teknologi mereka. Bahkan, karena ini, saya biasanya berharap tumpukan teknologi membuat lebih banyak perbedaan pada tingkat di mana tiket dan fitur dikembangkan daripada tingkat di mana kode orang.

Oleh karena itu, baik tingkat penulisan kode maupun tingkat penutupan tiket bukan ukuran produktivitas yang sempurna, itulah sebabnya kami tidak secara langsung membuat keputusan kepegawaian berdasarkan SLoC. Sebaliknya itu adalah bagian dari proses, dan evaluasi karyawan dilakukan menggunakan poin data sebanyak mungkin. Saya akan mengatakan bahwa Arsitek Anda tentu tidak gila.

Satu pengecualian

Satu-satunya pengecualian yang saya setujui adalah kemungkinan kode boiler-plate. Jika ada banyak salin dan rekat yang terjadi dari satu kelas (atau apa pun) ke kelas lain untuk menjalankannya, maka itu jelas akan membuat metrik miring. Ini juga berlaku jika Anda memiliki alat yang dapat secara otomatis menghasilkan kode dalam jumlah besar untuk Anda. Namun, saya berpikir bahwa ini akan menjadi pengecualian daripada aturan. Jika pengembang Anda menghabiskan sejumlah waktu menyalin kode pelat ketel untuk memulai, maka Anda menggunakan perangkat teknologi yang salah. Jika mereka benar-benar menulis kode, bahkan jika itu cukup berulang, maka saya berharap ini akan memangkas setiap pengukuran hanya dalam jumlah kecil: ketika menulis kode, sebagian besar waktu kita dibatasi oleh seberapa cepat kita dapat memikirkan masalah daripada dari seberapa cepat kita bisa mengetik. Bahkan ketika menulis kode yang relatif berulang,

Jelas, semua hal di atas didasarkan pada pengalaman pribadi saya. Jarak tempuh Anda mungkin beragam, dan jelas saya termasuk minoritas. Jangan ragu untuk tidak setuju. Singkatnya:

Saya menemukan bahwa tingkat pengkodean lebih tergantung pada seberapa cepat Anda dapat memikirkan masalah Anda daripada hal lain. Sebagai hasilnya, saya telah menemukan bahwa laju pengkodean adalah ukuran produktivitas yang layak, bahkan di seluruh rangkaian teknologi, dengan hanya beberapa kemungkinan pengecualian.


4
Ada juga satu pengecualian lain: perburuan bug. Berburu bug untuk bug terutama yang jahat bisa memakan waktu lama, tetapi biasanya menghasilkan satu baris perubahan kode.
Nathan Merrill

@NathanMerrill Itu poin yang bagus untuk, meskipun kurang relevan dengan OP: debugging adalah debugging dalam semua bahasa dan (dari atas kepala saya), saya tidak melihat alasan mengapa itu akan jauh lebih mudah atau lebih sulit dari satu techstack ke yang lain. Yang sedang berkata, itulah alasan mengapa, secara keseluruhan, Anda tidak dapat menilai produktivitas secara eksklusif pada kode yang ditulis, lebih dari yang Anda dapat pada metrik lainnya.
Conor Mancone

Kami menggunakan gitprime ( gitprime.com ) di perusahaan kami, dan sebagai manajer sekaligus insinyur, saya pikir ini tentang hal terbaik di dunia. Sekali lagi, ini hanya bagian dari gambaran bagi kami, tetapi telah sangat membantu dalam mengidentifikasi potensi masalah dengan para insinyur jauh sebelum ada masalah yang sebenarnya. Transparansi luar biasa, dan semua yang mereka lakukan akhirnya bermuara pada SLoC. Mengingat jumlah nilai dan wawasan yang ditambahkan, saya selalu sangat meragukan tentang kecenderungan beberapa insinyur untuk mengabaikan SLoC. Siapa pun
boleh

Pertanyaannya adalah bertanya apakah LoC dapat digunakan untuk membandingkan alat dan bahasa, dalam konteks pengembang senior yang mengatakan itu menunjukkan produktivitas yang lebih tinggi dalam bahasa "statis". Anda tampaknya menjawab pertanyaan yang berbeda - LoC dapat digunakan untuk membandingkan pengembang, tetapi Anda masih setuju itu tidak dapat digunakan untuk membandingkan bahasa karena pengembang yang diberikan menulis jumlah LoC yang sama terlepas dari alat / bahasa? Anda mengatakan Anda menentang jawaban lain di sini, tetapi tampaknya Anda setuju?
TessellatingHeckler

Sebagai pengembang, saya bisa memikirkan berkali-kali saya mengambil banyak kode non-KERING dan menggantinya dengan satu set kecil fungsi yang dapat digunakan kembali. Saya kemudian menambahkan sejumlah besar fungsi baru. Mengurangi jumlah kode sambil menambahkan kelipatan nilai nyata adalah hal yang baik dalam buku saya. Dalam pengalaman saya, insinyur terbaik menulis baris kode paling sedikit dan paling buruk menulis.
JimmyJames

6

Meskipun saya melompat pada kereta musik. Saya pikir dampak pada perilaku programmer perlu disorot.

Menggunakan SLOC sebagai ukuran untuk produktif memiliki efek toksik pada moral programmer. Saat setiap insinyur di tim / perusahaan Anda menyadari bahwa mereka diukur pada SLOC beberapa hal terjadi:

  1. Mereka mulai menulis kode yang jauh lebih lama untuk melakukan fungsi yang sama
  2. mereka tidak akan terlalu peduli dengan kualitas kode mereka
  3. mereka akan berhenti melakukan hal-hal lain yang membantu tim Anda (merekrut, men-debug, membantu junior)
  4. mereka akan membenci pekerjaan mereka dan kemungkinan pergi

Saya tidak bisa cukup menekankan betapa korosifnya merekayasa semangat kerja seperti yang saya lihat terjadi dua kali di 2 perusahaan yang berbeda. Apa pun kasus penggunaan yang tampaknya valid yang Anda miliki untuk itu, saya berpendapat bahwa tidak mungkin sepadan dengan dampaknya pada tim / perusahaan Anda, bahkan jika hanya ada sedikit peluang bahwa penggunaannya akan ditemukan. Meskipun dalam beberapa kasus mungkin ada korelasi antara jumlah baris yang ditulis dan jumlah fitur yang berguna itu mendorong semua perilaku yang salah dalam programmer Anda dan mengirimkan pesan kualitasnya tidak penting.


Memang ... metrik apa pun yang menghalangi seseorang untuk menghapus kode mubazir ("Anda memiliki metrik SLoC negatif minggu ini!" Salah, jelas salah!
Andrew

1

Biasanya tidak dianggap sebagai cara yang valid untuk mengukur produktivitas. Kode yang lebih kecil biasanya lebih baik daripada kode yang lebih besar, sehingga pengembang yang lebih produktif biasanya menghasilkan lebih sedikit kode. Produktivitas menjadi hit terbesar dalam debugging; pengembang yang efisien menghabiskan sedikit waktu untuk debugging.

Bahasa yang diketik secara statis lebih produktif (jika Anda mengontrol semua perbedaan lain di antara bahasa), karena ketika digunakan dengan bijak, mereka mengurangi waktu debug, menangkap kesalahan dalam fase kompilasi, di mana mereka lebih cepat untuk memperbaikinya.


1
Ini bisa menjadi poin yang valid jika kami membandingkan produktivitas masing-masing pengembang. Namun pertanyaannya adalah tentang perbandingan antar bahasa, sehingga konteksnya sangat berbeda. Ini juga berarti, misalnya, bahwa kode yang lebih kecil tidak lebih baik atau lebih buruk daripada kode yang lebih besar; bandingkan LOC kode yang ditulis dalam Brainfuck dengan kode yang ditulis dalam, katakanlah, Ruby.
Arseni Mourzenko

1
@ArseniMourzenko Selain dari lelucon seperti Brainfuck, bahasa yang dirancang dengan baik sebenarnya dibandingkan berdasarkan jumlah kode yang diperlukan untuk menyelesaikan suatu tugas. Biasanya perbandingan semacam itu disebut ekspresif. Memang benar, saya berbicara tentang LOC dalam satu bahasa, bukan lintas bahasa. Produktivitas secara umum didefinisikan sebagai berapa lama untuk melakukan suatu tugas; itu tidak spesifik untuk pemrograman.
Frank Hileman

0

Satu-satunya metrik yang dapat Anda gunakan untuk membandingkan produktivitas untuk pengembang antar bahasa adalah metrik yang tidak membandingkan kode antar bahasa. Beberapa bahasa terkenal verbose (COBOL untuk legacy win), dan yang lain memerlukan beberapa langkah untuk melakukan sesuatu yang dapat Anda lakukan dalam satu baris kode (perakitan vs hampir semua yang lain). Sekalipun Anda hanya membandingkan baris kode aktif (mis. Jangan menghitung deklarasi dan hanya menghitung kode yang melibatkan beberapa tindakan), Anda masih dapat mengubah hasil Anda.

Anda mungkin dapat membuat argumen untuk tingkat perubahan. Yakni baris kode ditambahkan, membandingkan kemiringan produktivitas selama periode waktu yang sama. Namun, itu tidak memperhitungkan perubahan negatif dalam baris kode. Misalnya, Anda mewarisi proyek yang memiliki kode salin dan tempel di mana-mana. Anda melakukan beberapa refactoring cepat dan mudah untuk mengurangi jumlah blok kode berulang - menurut definisi Anda memiliki kemiringan negatif.

Dalam semua keseriusan, membandingkan produktivitas tim / bahasa tidak ada artinya karena ada begitu banyak faktor tambahan yang memengaruhi produktivitas tim sehingga Anda tidak dapat menarik kesimpulan yang berarti darinya.

Saya mengerjakan sebuah proyek di mana infrastrukturnya sangat rapuh dan alat-alatnya sudah usang. Proyek ini dibangun di Jawa dengan Aplikasi Halaman Tunggal menamparnya, tetapi di-host dalam wadah portlet tanpa manfaat yang jelas. Waktu yang diperlukan untuk melakukan bahkan perubahan sederhana sangat panjang. Jika Anda mendasarkan semua kesimpulan Anda pada proyek tertentu itu, Anda mungkin menyimpulkan bahwa Java buruk, atau Aplikasi Halaman Tunggal buruk. Tidak ada yang benar. Sistem yang seharusnya diganti oleh proyek jelek itu dibangun di atas C # dan WebForms. Ketika kami membuat kasus bisnis untuk memperluas aplikasi yang ada untuk menangani kebutuhan pelanggan, produktivitas kami melonjak. Apakah itu berarti bahwa aplikasi WebForms yang digabungkan secara ketat lebih unggul? Anda hanya bisa membuat kesimpulan untuk kasus khusus inidan itu tidak meluas ke dunia pada umumnya. Dan itu hanya masuk akal karena ada aplikasi yang sudah ada dengan kematangan yang cukup untuk memperpanjang.

Bahkan membandingkan tingkat penyelesaian item dalam sistem pelacakan masalah adalah cacat dalam arti bahwa Anda membandingkan infrastruktur proyek lengkap satu sama lain. Perpustakaan dan kerangka kerja yang digunakan dapat mempercepat atau memperlambat kemajuan. Anda mungkin berada dalam fase start up dengan sedikit inersia untuk diatasi, di mana proyek Anda "lebih baik daripada" berada dalam fase pemeliharaan di mana jumlah tiket baru relatif rendah. Tidak pernah ada kasus membandingkan hal-hal seperti.

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.