Adakah kegunaan SLOC yang dikenal untuk mengukur produktivitas?

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?

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.

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:

• Perbandingan empiris sistem tipe statis dan dinamis pada penggunaan API di hadapan IDE: Java vs groovy with eclipse , 2014
• Mempertimbangkan Efek Produktivitas dari Deklarasi Tipe Eksplisit , 2014, tetapi tidak konklusif
• Sebuah studi empiris tentang pengaruh sistem tipe statis pada kegunaan perangkat lunak tidak berdokumen

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

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.

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.

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.

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.