Kembangkan kebiasaan pengkodean baru untuk mengurangi kesalahan dalam perangkat lunak yang disematkan
Ukuran dan kompleksitas aplikasi telah meningkat secara signifikan selama dekade terakhir. Ambil contoh sektor otomotif. Menurut The New York Times , 20 tahun yang lalu, rata-rata mobil memiliki satu juta baris kode, tetapi 10 tahun kemudian, General Motors 2010 Chevrolet Volt memiliki sekitar 10 juta baris kode—lebih banyak dari jet tempur F-35. Saat ini, rata-rata mobil memiliki lebih dari 100 juta baris kode.
Pergeseran ke prosesor 32-bit dan lebih tinggi dengan banyak memori dan daya telah memungkinkan perusahaan untuk membangun lebih banyak fitur dan kemampuan bernilai tambah ke dalam desain; itulah kelebihannya. Kelemahannya adalah jumlah kode dan kerumitannya sering mengakibatkan kegagalan yang berdampak pada keamanan dan keselamatan aplikasi.
Sudah waktunya untuk pendekatan yang lebih baik. Dua jenis kesalahan utama dapat ditemukan dalam perangkat lunak dan diatasi dengan menggunakan alat yang mencegah terjadinya kesalahan:
Kesalahan pengkodean:Contohnya adalah kode yang mencoba mengakses di luar batas array. Masalah seperti ini dapat dideteksi dengan melakukan analisis statis.
Kesalahan aplikasi:Ini hanya dapat dideteksi dengan mengetahui secara pasti apa yang seharusnya dilakukan aplikasi, yang berarti pengujian terhadap persyaratan.
Atasi kesalahan ini, dan insinyur desain akan menempuh jalan panjang menuju kode yang lebih aman dan terjamin.
Satu ons pencegahan melalui pemeriksaan kode
Kesalahan dalam kode terjadi semudah kesalahan dalam email dan pesan instan. Ini adalah kesalahan sederhana yang terjadi karena para insinyur sedang terburu-buru dan tidak mengoreksi. Tetapi dengan kompleksitas, muncul sejumlah kesalahan desain yang menciptakan tantangan besar. Kompleksitas melahirkan kebutuhan akan tingkat pemahaman yang sama sekali baru tentang bagaimana sistem bekerja, bagaimana data dilewatkan, dan bagaimana nilai didefinisikan. Apakah kesalahan disebabkan oleh kompleksitas atau semacam masalah manusia, mereka dapat mengakibatkan sepotong kode mencoba mengakses nilai di luar batas array. Dan, standar pengkodean menangkap hal itu.
Anda mungkin juga tertarik dengan artikel terkait berikut dari Tersemat:
Bangun sistem tertanam yang aman dan andal dengan MISRA C/C++
Menggunakan analisis statis untuk mendeteksi kesalahan pengkodean dalam aplikasi server yang kritis terhadap keamanan sumber terbuka
Bagaimana cara menghindari kesalahan seperti itu? Jangan menempatkan mereka di sana di tempat pertama. Meskipun ini terdengar jelas—dan hampir tidak mungkin—ini adalah nilai yang diberikan oleh standar pengkodean.
Di dunia C dan C++, 80% dari cacat perangkat lunak disebabkan oleh penggunaan yang salah atau keliru dari sekitar 20% bahasa. Standar pengkodean menciptakan batasan pada bagian bahasa yang diketahui bermasalah. Hasilnya:cacat dihindari, dan kualitas perangkat lunak meningkat pesat. Mari kita lihat beberapa contohnya.
Sebagian besar kesalahan pemrograman C dan C++ disebabkan oleh perilaku yang tidak ditentukan, ditentukan implementasi, dan tidak ditentukan yang melekat pada setiap bahasa, yang menyebabkan bug perangkat lunak dan masalah keamanan. Perilaku yang ditentukan implementasi ini menyebarkan bit orde tinggi ketika bilangan bulat yang ditandatangani digeser ke kanan. Bergantung pada yang digunakan insinyur kompiler, hasilnya bisa 0x40000000 atau 0xC0000000 karena C tidak menentukan urutan argumen ke fungsi yang dievaluasi.
Gambar 1. Perilaku beberapa konstruksi C dan C++ bergantung pada compiler yang digunakan. Sumber:LDRA
Pada Gambar 2 —di mana rollDice() function hanya membaca nilai berikutnya dari buffer melingkar yang memegang nilai "1,2,3 dan 4"—nilai yang dikembalikan yang diharapkan adalah 1234. Tapi tidak ada jaminan untuk itu. Setidaknya satu kompiler menghasilkan kode yang mengembalikan nilai 3412.
Gambar 2. Perilaku beberapa konstruksi C dan C++ tidak ditentukan oleh bahasa. Sumber:LDRA
Ada banyak jebakan lain dalam bahasa C/C++:penggunaan konstruksi seperti goto atau malloc; campuran nilai yang ditandatangani dan tidak ditandatangani; atau kode "pintar" yang mungkin sangat efisien dan ringkas tetapi sangat samar dan kompleks sehingga orang lain kesulitan untuk memahaminya. Salah satu dari masalah ini dapat menyebabkan kerusakan, kelebihan nilai yang tiba-tiba menjadi negatif, atau membuat kode tidak mungkin dipertahankan.
Standar pengkodean memberikan satu ons pencegahan untuk penyakit ini. Mereka dapat mencegah penggunaan konstruksi bermasalah ini dan mencegah pengembang membuat kode yang tidak terdokumentasi dan terlalu rumit serta memeriksa konsistensi gaya. Bahkan hal-hal seperti memverifikasi karakter tab tidak digunakan atau tanda kurung diposisikan pada posisi tertentu dapat dipantau. Meskipun hal ini tampak sepele, mengikuti gaya sangat membantu peninjauan kode manual dan mencegah campur aduk yang disebabkan oleh ukuran tab yang berbeda saat kode dilihat di editor lain—semua gangguan yang mencegah peninjau berkonsentrasi pada kode.
MISRA untuk menyelamatkan
Standar pemrograman yang paling terkenal adalah pedoman MISRA, pertama kali diterbitkan pada tahun 1998 untuk industri otomotif dan sekarang umumnya dianut oleh banyak kompiler tertanam yang menawarkan beberapa tingkat pemeriksaan MISRA. MISRA berfokus pada konstruksi dan praktik bermasalah dalam bahasa C dan C++, merekomendasikan penggunaan karakteristik gaya yang konsisten sambil berhenti menyarankan apapun.
Pedoman MISRA memberikan penjelasan yang berguna tentang mengapa setiap aturan ada, bersama dengan detail berbagai pengecualian untuk aturan itu, dan contoh perilaku yang tidak ditentukan, tidak ditentukan, dan ditentukan implementasi. Gambar 3 mengilustrasikan tingkat panduan.
Gambar 3. Referensi MISRA C ini berkaitan dengan perilaku yang tidak ditentukan, tidak ditentukan, dan ditentukan implementasi. Sumber:LDRA
Sebagian besar pedoman MISRA bersifat “Dapat ditentukan”, artinya alat ini dapat mengidentifikasi apakah ada pelanggaran; tetapi ada juga yang “Tidak dapat diputuskan”, yang menyiratkan bahwa alat tidak selalu dapat menyimpulkan apakah ada pelanggaran.
Variabel yang tidak diinisialisasi yang diteruskan ke fungsi sistem yang harus diinisialisasi mungkin tidak terdaftar sebagai kesalahan jika alat analisis statis tidak memiliki akses ke kode sumber untuk fungsi sistem. Ada potensi negatif palsu atau positif palsu.
Pada tahun 2016, 14 pedoman ditambahkan ke MISRA untuk memberikan pemeriksaan kode penting keamanan, bukan hanya keselamatan. Gambar 4 mengilustrasikan bagaimana salah satu pedoman baru—Petunjuk 4.14—memecahkan masalah ini dan membantu mencegah jebakan akibat perilaku yang tidak ditentukan.
Gambar 4. Petunjuk MISRA 4.14 membantu mencegah perangkap yang disebabkan oleh perilaku yang tidak ditentukan. Sumber:LDRA
Kekakuan standar pengkodean secara tradisional dikaitkan dengan perangkat lunak yang aman secara fungsional untuk aplikasi penting seperti mobil, pesawat terbang, dan perangkat medis. Namun, kompleksitas kode, kritisnya keamanan, dan kepentingan bisnis dalam menciptakan kode yang kuat dan berkualitas tinggi yang mudah dipelihara dan ditingkatkan membuat standar pengkodean menjadi penting dalam semua operasi pengembangan.
Dengan memastikan kesalahan tidak dimasukkan ke dalam kode sejak awal, tim pengembangan harus:
mengurangi kebutuhan untuk debug ekstensif,
mendapatkan kontrol jadwal yang lebih baik, dan
kontrol ROI dengan mengurangi biaya keseluruhan.
Pemeriksaan kode menawarkan kotak peralatan dengan potensi manfaat yang sangat besar.
Satu pon penyembuhan dengan alat uji
Sementara pemeriksaan kode memecahkan banyak masalah, bug aplikasi hanya dapat ditemukan dengan menguji bahwa produk melakukan apa yang seharusnya dilakukan, dan itu berarti memiliki persyaratan. Menghindari bug aplikasi membutuhkan desain produk yang tepat, dan desain produk yang tepat.
Merancang produk yang tepat berarti menetapkan persyaratan di awal dan memastikan ketertelusuran dua arah antara persyaratan dan kode sumber, sehingga setiap persyaratan diimplementasikan, dan setiap fungsi perangkat lunak menelusuri kembali ke persyaratan. Semua fungsi yang hilang atau tidak perlu—yang tidak memenuhi persyaratan—adalah bug aplikasi. Merancang produk dengan benar adalah proses konfirmasi bahwa kode sistem yang dikembangkan memenuhi persyaratan proyek. Anda mencapainya dengan melakukan pengujian berbasis persyaratan.
Gambar 5 menunjukkan contoh ketertelusuran dua arah. Fungsi tunggal yang dipilih menelusuri hulu dari fungsi ke persyaratan tingkat rendah, lalu ke persyaratan tingkat tinggi, dan terakhir ke persyaratan tingkat sistem.
Gambar 5. Ini adalah contoh ketertelusuran dua arah dengan satu fungsi yang dipilih. Sumber:LDRA
Gambar 6 menunjukkan bagaimana pemilihan persyaratan tingkat tinggi menampilkan ketertelusuran hulu ke persyaratan tingkat sistem dan hilir ke persyaratan tingkat rendah dan ke fungsi kode sumber.
Gambar 6. Ini adalah contoh ketertelusuran dua arah dengan persyaratan yang dipilih. Sumber:LDRA
Kemampuan untuk memvisualisasikan keterlacakan ini dapat mengarah pada deteksi bug aplikasi di awal siklus hidup.
Menguji fungsionalitas kode menuntut kesadaran tentang apa yang seharusnya dilakukan, dan itu berarti memiliki persyaratan tingkat rendah yang menyatakan apa yang dilakukan setiap fungsi. Gambar 7 menunjukkan contoh persyaratan tingkat rendah, yang, dalam hal ini, sepenuhnya menggambarkan satu fungsi.
Gambar 7. Ini adalah contoh kebutuhan tingkat rendah yang menjelaskan fungsi tunggal. Sumber:LDRA
Kasus uji diturunkan dari persyaratan tingkat rendah seperti yang diilustrasikan pada Gambar 8.
Gambar 8. Kasus uji diturunkan dari persyaratan tingkat rendah. Sumber:LDRA
Dengan menggunakan alat uji unit, kasus uji ini kemudian dapat dieksekusi pada host atau target untuk memastikan bahwa kode berperilaku seperti yang dikatakan persyaratan yang seharusnya. Gambar 9 menunjukkan bahwa semua kasus uji telah diregresi dan lulus.
Gambar 9. Ini adalah cara alat melakukan pengujian unit. Sumber:LDRA
Setelah kasus uji berjalan, cakupan struktural harus diukur untuk memastikan bahwa semua kode telah dilaksanakan. Jika cakupannya tidak 100 persen, mungkin diperlukan lebih banyak kasus uji atau kode yang berlebihan harus dihapus.
Kebiasaan baru dalam pengkodean
Tidak diragukan lagi, kompleksitas perangkat lunak—dan kesalahannya—telah menjamur dengan konektivitas, memori yang lebih cepat, platform perangkat keras yang kaya, dan permintaan pelanggan yang spesifik. Mengadopsi standar pengkodean tercanggih, mengukur metrik pada kode, melacak persyaratan, dan menerapkan pengujian berbasis persyaratan memberi tim pengembangan peluang untuk membuat kode berkualitas tinggi dan mengurangi kewajiban.
Sejauh mana sebuah tim mengadopsi kebiasaan baru ini ketika tidak ada standar yang mengharuskan kepatuhan bergantung pada pengakuan perusahaan atas perubahan permainan yang mereka bawa. Mengadopsi praktik-praktik ini, apakah suatu produk sangat penting bagi keselamatan atau keamanan, dapat membuat perbedaan siang dan malam dalam pemeliharaan dan ketahanan kode. Kode bersih menyederhanakan penambahan fitur baru, memudahkan perawatan produk, serta meminimalkan biaya dan jadwal—semua karakteristik yang meningkatkan ROI perusahaan Anda.
Terlepas dari apakah suatu produk kritis terhadap keselamatan atau tidak, ini pasti merupakan hasil yang hanya dapat bermanfaat bagi tim pengembangan.
>> Artikel ini awalnya diterbitkan pada situs saudara kami, EDN.
