Line of Code (LOC) Matric

Pengukuran adalah langkah penting untuk mencapai manajemen yang efektif. Orang sadar akan hal itu dan mereka menggunakan set metrik untuk mengukur proyek. Dibandingkan dengan unsur-unsur yang sulit untuk mengukur seperti kualitatif informasi, mereka cenderung berfokus pada kuantitatif informasi seperti jumlah angka yang dapat diukur dengan mudah. Namun, unsur-unsur mudah diukur mungkin tidak akan sama penting atau lebih penting daripada lebih sulit dalam kontribusinya untuk evaluasi proyek.

Ini adalah sama dengan pengembangan perangkat lunak. Ketika kita dan mengukur sebuah proyek software, kita perlu pertama menemukan metrik diukur. Jawaban yang paling intuitif adalah dengan menggunakan kode baris demi baris. Pada kenyataannya, Line of Code (LOC) secara luas digunakan untuk mengukur ukuran dari perangkat lunak dan kadang-kadang untuk mengevaluasi produktivitas pengembang. Namun, sebelum kita menggunakannya, kita mungkin perlu waktu sebentar untuk berpikir hati-hati apakah ini adalah metrik yang baik.

Jika kita menggunakan LOC untuk mengukur proyek perangkat lunak kami, pertama kita perlu menghitung berapa banyak baris kode yang ada. Tampaknya bahwa ini adalah hal yang cukup mudah, hanya dengan menghitung garis setiap file atau setiap modul. Di sini, pertanyaan adalah bagaimana kita dapat menghitung tepat? Dalam proyek skala besar perangkat lunak, kode dimodifikasi sebagai perubahan persyaratan atau bug yang ditemukan dan itu mungkin terjadi selama tahap pengembangan atau bahkan setelah proyek dirilis. Potongan kode yang ditulis dalam tahap pengembangan? Potongan-potongan yang ditambahkan atau dihapus ketika kita berurusan dengan bug? Orang mungkin menyarankan menggunakan perhitungan matematika sederhana untuk memecahkan masalah ini: untuk menghitung berapa banyak baris kode yang berubah, berapa banyak baris baru ditambahkan dan kemudian menambahkan mereka bersama-sama. Tapi untuk "kode berubah", kita harus memperhatikan bahwa hal itu terjadi karena pengembang menambahkan beberapa fungsi baru atau memodifikasi bug. Begitu sulit untuk menghitung persis berapa banyak baris kode yang ada terutama bagi mereka yang tidak cukup akrab dengan proyek.

Ada beberapa metode untuk menghitung berapa banyak baris kode yang ada, misalnya, menghitung eksekusi baris kode, data Deklarasi, garis yang tidak null, dll. Perusahaan-perusahaan yang berbeda atau bahkan berbeda tim mungkin tidak menggunakan aturan penghitungan yang sama. Hal ini berarti membandingkan ukuran proyek atau produktivitas pengembang dengan menggunakan LOC saat mereka dihitung pada standar yang berbeda.

Namun, dalam kehidupan nyata, pengembang mungkin bekerja di dua proyek dalam waktu yang sama; beberapa dari mereka mungkin bertanggung jawab untuk hanya setengah atau seperempat dari seluruh proyek. Untuk pengembang ini, produktivitas dihitung dengan menggunakan rumus diatas akan jauh lebih rendah daripada mereka yang bekerja penuh waktu pada satu proyek. Tapi kita tidak bisa hanya datang ke kesimpulan bahwa mereka memiliki produktivitas yang lebih rendah dibandingkan dengan orang lain.

Fakta lain yang perlu kita perhatikan adalah bahwa ada ribuan bahasa pemrograman. Ketika LOC pertama kali diperkenalkan sebagai metrik, bahasa yang paling umum digunakan adalah FORTRAN, COBOL dan bahasa Assembly. Untuk bahasa-bahasa ini, sangat mudah untuk menghitung garis. Kemudian, bahasa tingkat tinggi seperti Jawa, C++ muncul. Bahasa-bahasa tersebut, tunggal pernyataan yang secara umumnya menghasilkan banyak instruksi mesin. Itu berarti bahwa bahasa tingkat tinggi mungkin menggunakan lebih sedikit baris kode untuk melaksanakan fungsi. Dan hal ini juga tidak berarti untuk membandingkan jumlah baris kode yang dikembangkan menggunakan bahasa yang terstruktur versus berorientasi objek teknik [3]. Sebagai contoh, sistem yang dapat diterapkan dengan 6000 baris kode Assembly menjadi kode atau 3000 baris kode C++ Code. Misalkan seorang pengembang yang menggunakan bahasa assembly menulis 600 baris kode per bulan sedangkan C++ pengembang menulis 300 baris kode per bulan. Tampaknya bahwa pengembang mantan memiliki produktivitas yang tinggi yang kedua. Tapi ketika kedua pengembang sedang mengembangkan proyek yang disebutkan di atas, mereka mungkin menyelesaikan menggunakan jumlah waktu yang sama. Bahasa pemrograman canggih memiliki kekuatan ekspresif. Semakin kuat bahasa adalah, produktivitas rendah menunjukkan untuk para pengembangnya. Jadi kita tidak bisa hanya memutuskan pengembang yang memiliki produktivitas yang lebih tinggi hanya didasarkan pada angka-angka ini.