TUGAS 5 RANGKUMAN BAB 7

NAMA : DWIKI ARDIANSYAH
NPM     : 43A87007150390
KELAS : S1/S1/3B(P)

BAB.7 Coding Dan Pengujan Unit

Tujuan dari coding atau pemrograman mengimplementasikan kegiatan desain untuk mencetak
Aktivitas coding mempengaruhi baik atau tidaknya tampilan pengujian dan maintenance mendalam. Seperti kami lihat sebelumnya, waktu yang dihabiskan mengcoding adalah kecil
persentase dari total biaya perangkat lunak mengurangi tidak hanya untuk biaya pelaksanaan

tetapi membantu mengurangi biaya selama coding. Sebuah program memiliki pembacaan jelas dan dimengerti sebagai tujuan. Tujuan diberikan untuk meminimalkan upaya yang diperlukan untuk menyelesaian program, meminimalkan jumlah pernyataan, meminimalkan memory yang diperlukan, memaksimalkan kejelasan program, dan memaksimalkan kejelasan output. Itu ditemukan disebagian besar CO. Masing-masing tim melakukan yang terbaik untuk tujuan itu. Programmer cenderung mencapai tujuan CO. Oleh karena itu, jika dibaca adalah tujuan coding aktifitas adalah kemungkinan program CO mengembangkan coding yang mudah dimengerti.

Hal ini juga menunjukkan jika fokusnya adalah pada CO meminimalkan upaya coding, membutuhkan kejelasan program yang besar. Untuk tujuan, kemudahan pemahaman dan modifikasi adalah tujuan dasar dari kegiatan pemrograman. Dalam bab ini kita akan membahas:

-         1. Beberapa Prinsip seperti pemrograman terstruktur, informasi bersembunyi, penggunaan Coding Standar, dapat membantu mengembangkan program yang lebih mudah dibaca.

-          2. Beberapa proses programmer tingkat tambahan pembangunan seperti pengembangan, berkualitas tinggi untuk mengembangkan kode efisien.

-          3. Bagaimana mengelola kode dengan menggunakan kontrol kode sumber yang tepat berkembang dan refactoring.

-          4. Bagaimana unit modul tes menggunakan kerangka pengujian unit

.

-          5. Sebuah proses inspeksi kode terstruktur digunakan secara efektif untuk meningkatkan kualitas kode.

7.1 Prinsip pemrograman dan Pedoman

Tugas utama adalah sebelum seorang programmer  menulis kode yang dapat dibaca. Menulis kode adalah keterampilan yang solid hanya dapat diperoleh dengan praktek CO. Berdasarkan pengalaman, beberapa aturan umum dan pedoman dapat diberikan untuk programmer. Pemrograman yang baik (memproduksi program yang benar dan sederhana) adalah independen praktek bahasa pemrograman sasaran, meskipun bahasa pemrograman yang terstruktur dengan baik membuat pekerjaan programmer sederhana.

 

7.1.1 Pemrograman Terstruktur

Seperti yang dinyatakan sebelumnya tujuan dasar dari kegiatan ini adalah untuk program coding yang mudah dimengerti. Praktek pemrograman membantu mengembangkan program yang mudah dimengerti. Sekarang konsep meliputi begitu banyak program yang berlaku umum dan bahkan terstruktur. Meskipun banyak penekanan pada struktur pemrograman, motivasi di balik konsep dan pemrograman terstruktur tidak dipahami dengan baik sering. Pemrograman terstruktur sering dianggap kurang. Meskipun penggunaan luas ini tentunya tidak diinginkan dari pengguna. Sebuah program memiliki struktur statis serta struktur yang dinamis. Struktur statis adalah struktur teks program, hanya organisasi linear laporan program. Struktur dinamis dari program ini adalah urutan pernyataan dieksekusi oleh pelaksanaan program. Dengan kata lain, kedua tampilan struktur statis dan perilaku dinamis adalah urutan laporan, sedangkan urutan mewakili struktur statis dari sebuah program adalah tetap.

Jelas ini lebih mudah untuk memahami perilaku dinamis dalam struktur dinamis. Jika perilaku menyerupai struktur statis. Semakin dekat korespondensi antara pelaksanaan dan struktur teks, program ini  mudah untuk dipahami. Tujuan dari pemrograman terstruktur adalah untuk memastikan struktur statis dan struktur dinamis adalah sama. Artinya, tujuan dari pemrograman terstruktur adalah untuk menulis program dalam urutan perbandingan laporan pelaksanaan program adalah sama dengan urutan pernyataan dalam teks program CO. Seperti pernyataan dalam program yang terorganisir. Motivasi nyata untuk pemrograman terstruktur adalah verifikasi formal program. Untuk menunjukkan sebuah program adalah CO benar, kita perlu untuk menunjukkan program yang benar. Sebagai program pada input data dan hasil hanya berlaku untuk beberapa berbagai masukan. Umumnya juga menyatakan perlunya program masukan pemesanan. Program ini diharapkan menghasilkan hasil yang valid. Penegasan tentang keadaan akhir dari sebuah program Pemerintah Indonesia pasca-kondisi program Co, dan pernyataan tentang kondisi masukan adalah pra-kondisi GOI program. untuk memverifikasi program, pernyataan dasar tentang segmen program ini dalam bentuk

Interpretasi pernyataan ini adalah co jika sebelum mengeksekusi S P adalah benar, maka Q pernyataan yang benar setelah melaksanakan S, jika eksekusi S berakhir. Sikap tegas P adalah pra-kondisi program dan Q adalah pasca-kondisi. pernyataan ini adalah tentang nilai-nilai yang diambil oleh variabel. Jika program ini adalah urutan pernyataan, maka semantik dari Quyet komposit menjadi program mudah.

Penjelasan notasi ini jika apa yang dinyatakan adalah co di pembilang dapat dibuktikan, penyebut dapat disimpulkan. Menggunakan aturan ini, jika terbukti P1 dan P2 {S1} {S2} Q1 R2, maka semantik S1 untuk S2, Semua Kita perlu menunjukkan adalah co Q1 ⇒ P2, dan kemudian kita bisa bekerja sama jika eksekusi sebelum P1 memegang pra-kondisi, kemudian setelah eksekusi S1, S2 pasca-kondisi Q2 dan seterusnya. Dengan kata lain, untuk membuktikan P {S1, S2} setelah S1 dan S2 dari perilaku, Kami hanya butuh satu langkah tambahan. Ini bukti dari program pembangunan yang lebih besar. Aturan catatan ini menangani urutan yang ketat dari pernyataan. Jadi, jika ingin menerapkan ini, kita perlu untuk membangun program sebagai urutan pernyataan. Dalam sebuah program jelas tidak ada program bisa bermakna sebagai urutan laporan sederhana tanpa percabangan atau Pengulangan. Dalam pemrograman terstruktur, pernyataan ini bukan pernyataan tugas sederhana, itu adalah pernyataan terstruktur. Properti kunci pernyataan terstruktur memiliki single-Co dan satu entri-keluar. Artinya, eksekusi pelaksanaan (terstruktur) pernyataan dimulai dari satu didefinisikan.

Dalam pemrograman terstruktur, pernyataan bukanlah pernyataan tugas sederhana melainkan pernyataan terstruktur. Properti kunci dari pernyataan terstruktur adalah bahwa ia memiliki satu-masukan dan satu-keluar. Artinya, selama dieksekusi, pernyataan dimulai dari satu titik didefinisikan dan  berakhir pada satu titik didefinisikan. Dengan pernyataan satu-masukan dan satu-keluar, kita dapat melihat program sebagai urutan laporan (terstruktur). pernyataan yang paling sering digunakan adalah

 

Bahasa modern memiliki konstruksi seperti lainnya yang membantu  aliran kontrol dari program, yang, secara umum, membuat lebih mudah untuk memahami program. Tujuan dasar, seperti yang kita telah mencoba untuk menekankan, adalah untuk membuat logika program sederhana untuk memahami. Sebuah catatan akhir tentang konstruksi terstruktur. Setiap bagian dari kode dengan single-entry dan single-exit tidak dapat dianggap sebagai konstruk terstruktur. Jika itu terjadi, orang selalu bisa mendefinisikan unit yang tepat dalam program apapun untuk membuatnya muncul sebagai urutan unit-unit ini (dalam kasus terburuk, seluruh program dapat didefinisikan sebagai unit).

     Tujuan dasar menggunakan konstruksi terstruktur adalah untuk linearize aliran kontrol sehingga perilaku eksekusi lebih mudah untuk dimengerti dan berdebat tentang. Secara keseluruhan, dapat dikatakan bahwa pemrograman terstruktur mengarah ke program yang lebih mudah dimengerti daripada program terstruktur, dan bahwa program tersebut lebih mudah untuk secara resmi membuktikan. Namun, harus diingat bahwa pemrograman terstruktur tidak tujuan

Namun, ada beberapa praktik pemrograman umum yang sekarang dipahami bahwa menggunakan konstruksi yang tidak terstruktur

7.1.2 Informasi Tersembunyi.

     Sebuah solusi perangkat lunak untuk masalah selalu berisi struktur data yang dimaksudkan untuk mewakili informasi dalam domain masalah. Artinya, ketika perangkat lunak dikembangkan untuk memecahkan masalah, perangkat lunak menggunakan beberapa struktur data untuk menangkap informasi dalam domain masalah.
     Ketika informasi tersebut direpresentasikan sebagai struktur data, prinsip yang sama harus diterapkan, dan hanya beberapa operasi yang didefinisikan harus dilakukan pada struktur data. Ini, pada dasarnya, adalah prinsip bersembunyi informasi. Informasi yang ditangkap dalam struktur data harus disembunyikan dari sisa dari sistem, dan hanya akses fungsi pada struktur data yang mewakili operasi yang dilakukan pada informasi yang harus terlihat. Dengan kata lain, ketika informasi tersebut ditangkap di struktur data dan kemudian pada struktur data yang mewakili beberapa informasi, untuk setiap operasi pada informasi fungsi akses harus disediakan. Dan sebagai sisa dari sistem dalam domain masalah hanya melakukan operasi ini didefinisikan pada informasi, sisa modul dalam perangkat lunak hanya menggunakan fungsi akses ini untuk mengakses dan memanipulasi struktur data.
     Informasi bersembunyi dapat mengurangi coupling antara modul dan membuat sistem lebih dipertahankan. Informasi bersembunyi juga merupakan alat efektif untuk mengelola kompleksitas mengembangkan software-dengan menggunakan informasi bersembunyi kita telah memisahkan perhatian dari mengelola data dari kepedulian menggunakan data untuk menghasilkan beberapa hasil yang diinginkan.

 

7.1.3 Beberapa Praktek Pemrograman

beberapa aturan yang telah ditemukan untuk membuat kode lebih mudah dibaca serta menghindari beberapa kesalahan.

* Kontrol Constructs: Seperti telah dibahas sebelumnya, hal ini diinginkan bahwa sebanyak mungkin single-entry, konstruksi single-exit digunakan.

* Gotos: gotos harus digunakan dengan hemat dan secara disiplin. Jika goto harus digunakan, transfer ke depan (atau melompat ke pernyataan kemudian) lebih diterima daripada melompat ke belakang.
* Informasi Menyembunyikan: Hanya fungsi akses untuk struktur data harus dibuat terlihat saat bersembunyi struktur data di balik fungsi tersebut.
* Jenis Buatan Pengguna: bahasa modern memungkinkan pengguna untuk menentukan jenis seperti tipe enumerasi. Ketika fasilitas tersebut tersedia, mereka harus ex-ploited mana yang berlaku. Misalnya, ketika bekerja dengan tanggal, tipe dapat didefinisikan untuk hari dalam seminggu.

* Nesting: Jika bersarang jika-maka-lain konstruksi menjadi terlalu dalam, maka logika menjadi sulit untuk memahami. Dalam kasus sangat bersarang jika-maka-elses, seringkali sulit  untuk menentukan jika pernyataan yang klausul lain tertentu terkait. Bila memungkinkan, bersarang dalam harus dihindari, bahkan jika itu berarti sedikit ine FFI efisiensi. Sebagai contoh, perhatikan konstruk berikut bersarang jika-maka-elses:

* Modul Ukuran: Kami membahas masalah ini selama desain sistem. Seorang programmer harus hati-hati memeriksa setiap fungsi dengan terlalu banyak laporan (mengatakan lebih dari 100). modul besar sering tidak akan fungsional kohesif.
* Modul Interface: Sebuah modul dengan antarmuka yang kompleks harus diteliti dengan seksama. Sebagai aturan praktis, setiap modul yang antarmuka memiliki lebih dari lima parameter harus diteliti dengan seksama dan patah menjadi beberapa modul dengan antarmuka sederhana jika mungkin.
* Side E ff proyek-: Ketika sebuah modul dipanggil, kadang-kadang memiliki sisi e proyek-ff memodifikasi program negara di luar modifikasi parameter yang tercantum dalam definisi antarmuka modul, misalnya, memodifikasi variabel global. sisi e ff ects tersebut harus dihindari jika mungkin, dan jika modul memiliki sisi e proyek-ff, mereka harus didokumentasikan dengan benar.
* Kekokohan: Sebuah program adalah kuat jika melakukan sesuatu yang direncanakan bahkan untuk kondisi yang luar biasa. Sebuah program mungkin mengalami seperti masukan yang salah, nilai yang salah dari beberapa variabel, dan melimpah. Jika situasi seperti itu timbul, program seharusnya tidak hanya "kecelakaan" atau "inti sampah"; itu harus menghasilkan beberapa pesan yang bermakna dan keluar dengan anggun.

* Beralih Kasus dengan Default: Jika tidak ada kasus default di "switch" pernyataan, perilaku dapat diprediksi jika kasus yang muncul di beberapa titik waktu yang tidak dapat diprediksi pada tahap pembangunan. praktek tersebut dapat mengakibatkan bug seperti NULL dereference, kebocoran memori, serta jenis lain dari bug serius. Ini adalah praktik yang baik untuk selalu menyertakan kasus default.
* Kosong Menangkap Block: Pengecualian tertangkap, tetapi jika tidak ada tindakan, itu mungkin merupakan skenario di mana beberapa operasi yang akan dilakukan tidak dilakukan. Setiap kali pengecualian tertangkap, itu adalah praktik yang baik untuk mengambil beberapa tindakan default, bahkan jika itu hanya mencetak pesan kesalahan.
* Kosong jika, sementara Pernyataan: Sebuah kondisi diperiksa tapi tidak ada yang dilakukan berdasarkan cek. Hal ini sering terjadi karena beberapa kesalahan dan harus ditangkap. kesalahan serupa lainnya termasuk akhirnya, mencoba, disinkronkan, metode statis kosong kosong, dll 

Seringkali nilai kembali dari membaca tidak diperiksa, dengan asumsi bahwa membaca mengembalikan nilai yang diinginkan. Kadang-kadang hasil dari membaca bisa menjadi di ff berbeda dengan apa yang diharapkan, dan ini dapat menyebabkan kegagalan kemudian.

Dalam contoh ini, nilai yang dikembalikan baik dalam pengecualian dan nonexception SCE-narios. Oleh karena itu, di lokasi penelepon, pengguna tidak akan bisa membedakan antara keduanya.

Sumber Data: Counter pemeriksaan harus dilakukan sebelum mengakses data input, terutama jika data input yang disediakan oleh pengguna atau sedang diperoleh melalui jaringan. Misalnya, saat melakukan operasi copy string, kita harus memeriksa bahwa string sumber nol diakhiri, atau yang ukurannya seperti yang kita harapkan.

Kebanyakan programmer cenderung memberikan sedikit perhatian pada kasus luar biasa mungkin dan cenderung bekerja dengan arus utama acara, kontrol, dan data.

Untuk membuat sistem software yang lebih handal, programmer harus mempertimbangkan semua kemungkinan dan menulis penangan pengecualian cocok untuk mencegah kegagalan atau kehilangan ketika situasi tersebut terjadi.

7.1.4 Standar Coding

Programmer menghabiskan jauh lebih banyak waktu membaca kode daripada menulis kode.

Selama perkembangan kode, penulis saat mengkoding cukup membacanya selama tahap debugging dan peningkatan. Singkatnya, perkembangan kode itu adalah sangat penting untuk menulis kode dengan cara yang mudah dibaca dan dimengerti. Coding standar memberikan aturan dan pedoman untuk beberapa aspek pemrograman untuk membuat kode lebih mudah dibaca. Sebagian besar organisasi yang mengembangkan perangkat lunak secara teratur mengembangkan standar mereka sendiri.

Secara umum, standar coding memberikan pedoman bagi programmer mengenai penamaan, organisasi berkas, pernyataan dan deklarasi, dan tata letak.

File konvensi adalah tentang bagaimana file harus dinamai, dan apa saja file yg harus di isi, sehingga pembaca bisa mendapatkan beberapa ide tentang apa file contains. Beberapa contoh konvensi ini adalah:

-          1. File source Java harus memiliki ekstensi .java ini diberlakukan oleh sebagian besar kompiler.

-          2. Setiap file harus berisi satu kelas luar dan nama kelas harus sama dengan nama file.

-          3. Panjang garis harus dibatasi kurang dari 80 kolom dan khusus charac-ters harus dihindari. 

      4. Jika garis lebih panjang, hal itu harus dilanjutkan dan kelanjutan harus dibuat sangat jelas.

Laporan Tata Cara ini adalah untuk deklarasi dan dieksekusi dalam kode source.

Namun, perlu diketahui bahwa tidak semua orang akan setuju pada cara ini. Itulah sebabnya organisasi umumnya mengembangkan pedoman mereka sendiri yang dapat diikuti tanpa membatasi fleksibilitas programmer untuk jenis pekerjaan organisasi.

Komentar dan Layout Komentar adalah pernyataan tekstual yang dimaksudkan untuk program pembaca untuk membantu pemahaman kode. Secara umum, komentar harus menjelaskan kegunaan kode atau mengapa kode yang ada, sehingga kode dapat menjadi hampir standalone (berdiri sendiri)  untuk memahami sistem. Komentar umumnya harus disediakan untuk blok kode.

Menyediakan komentar untuk modul yang paling berguna, sebagai modul membentuk unit pengujian, kompilasi, verifikasi, dan modifikasi.

Perlu dicatat bahwa prolog berguna jika mereka tetap konsisten. Jika modul tersebut dimodifikasi, maka prolog juga harus diubah.

Java menyediakan komentar dokumentasi yang dibatasi oleh "/ ** ... * /", dan yang bisa diambil ke file HTML. Komentar ini sebagian besar digunakan sebagai prolog metode-metode dan bidang.

Selain prolog untuk modul, standar pengkodean dapat menentukan bagaimana dan di mana komentar harus berada. Beberapa pedoman tersebut adalah:

-         1. Satu baris komentar untuk blok kode harus sejajar dengan kode mereka dimaksudkan untuk.

-         2. Harus ada komentar untuk semua variabel utama menjelaskan apa yang mereka refensi

-        3. Sebuah blok komentar harus didahului oleh kosong baris komentar hanya dengan "/ *" dan diakhiri dengan baris yang berisi hanya "* /".

-       4. Trailing komentar setelah laporan harus singkat, pada baris yang sama, dan bergeser cukup jauh untuk memisahkan mereka dari laporan.

Pedoman tata letak fokus pada bagaimana program harus menjorok, bagaimana harus menggunakan baris kosong, ruang putih, dll, untuk membuatnya lebih mudah dibaca. pedoman lekukan kadang-kadang disediakan untuk setiap jenis pemrograman membangun. Namun, kebanyakan programmer belajar ini dengan melihat kode dari orang lain dan fragmen kode dalam buku-buku dan dokumen, dan banyak dari ini telah menjadi cukup standar selama bertahun-tahun. Kita tidak akan membahas mereka lebih jauh kecuali untuk mengatakan bahwa seorang programmer harus menggunakan beberapa konvensi, dan menggunakannya secara konsisten.

Bertahap Mengembangkan Kode

        Aktivitas coding dimulai ketika beberapa bentuk desain yang telah dilakukan dan spesifikasi dari modul untuk dikembangkan tersedia. Dengan desain, modul ditugaskan untuk pengembang untuk coding. Ketika modul ditugaskan untuk pengembang, mereka menggunakan beberapa proses untuk mengembangkan kode. Jelas, berbagai proses yang mungkin untuk mencapai tujuan ini. Di sini kita membahas beberapa proses yang efektif  menggunakan pengembang untuk secara bertahap mengembangkan kode.

7.3 Managing Evolving Code

Selama proses coding, kode yang ditulis oleh programmer (atau sepasang) berkembang mulai dari nol untuk akhirnya memiliki modul diuji dengan baik. Selama proses ini kode mengalami perubahan. Selain perubahan karena proses pembangunan, perubahan kode juga dibutuhkan karena perubahan spesifikasi modul, yang mungkin terjadi karena perubahan persyaratan.

7.3.1 Source Code Control and Build

Sebuah sistem kontrol sumber kode yang modern berisi repositori, yang pada dasarnya adalah struktur direktori dikontrol, yang membuat sejarah revisi penuh dari semua file yang dihasilkan oleh programmer yang berbeda dalam tim proyek. Untuk efisiensi, sejarah berkas umumnya disimpan sebagai delta atau increment dari file base. Hal ini memungkinkan setiap versi lama dari file yang akan diciptakan, sehingga memberikan fleksibilitas untuk dengan mudah membuang perubahan, harus perlu timbul. repositori adalah juga "resmi" sumber untuk semua file.

Untuk proyek, repositori harus diatur dengan izin untuk orang yang berbeda dalam proyek. File-file repositori akan berisi juga ditentukan ini adalah file yang evolusi repositori mempertahankan. Programmer menggunakan repositori untuk membuat mereka perubahan file sumber yang tersedia, serta mendapatkan berkas sumber lain. Beberapa jenis perintah yang umumnya dilakukan oleh seorang programmer adalah:

-          Dapatkan salinan lokal. Seorang programmer di sebuah proyek bekerja pada salinan lokal file. Perintah disediakan untuk membuat salinan lokal dari repositori. Membuat salinan lokal umumnya disebut checkout. Contoh perintah cvs checkout <module>, yang salinan satu set file yang dimiliki oleh <module> pada mesin lokal. Seorang pengguna akan mendapatkan salinan terbaru dari file. Namun, jika pengguna ingin, setiap versi lama dari file yang bisa diperoleh dari repositori, sebagai sejarah lengkap dipertahankan. Banyak pengguna dapat memeriksa file.

-          Membuat perubahan ke file (s). Perubahan yang dibuat ke file lokal dengan programmer tetap lokal sampai perubahan berkomitmen kembali pada repositori. Dengan melakukan (misalnya, oleh cvs commit <file>) perubahan yang dibuat ke file lokal yang dibuat untuk repositori, dan oleh karenanya tersedia untuk orang lain. Operasi ini juga disebut sebagai check-in.

-          Memperbarui salinan lokal. Perubahan yang dilakukan oleh anggota proyek untuk repositori tidak tercermin dalam salinan lokal yang dibuat sebelum perubahan itu dilakukan. Untuk mendapatkan perubahan, salinan lokal dari file harus diperbarui (misalnya, oleh cvs perintah update). Dengan update, semua perubahan yang dibuat untuk file-file tersebut tercermin dalam salinan lokal.

-          Mendapatkan laporan. alat kontrol sumber menyediakan sejumlah perintah untuk memberikan laporan yang berbeda pada evolusi file. Ini termasuk laporan seperti perbedaan antara file lokal dan versi terbaru dari file, semua perubahan yang dibuat ke file bersama dengan tanggal dan alasan untuk perubahan (yang biasanya disediakan saat melakukan perubahan).

Dengan sistem kontrol kode sumber, programmer tidak perlu mempertahankan semua versi kapan saja jika beberapa perubahan perlu dibatalkan, versi yang lebih tua dapat dengan mudah ditemukan. Repositori selalu didukung, sehingga mereka juga memberikan perlindungan terhadap kerugian disengaja. Selain itu, catatan perubahan dipertahankan yang membuat perubahan dan kapan, mengapa perubahan dibuat, apa yang menjadi perubahan yang sebenarnya, dll Yang paling penting, repositori menyediakan tempat sentral untuk file-file terbaru dan berwibawa proyek. Ini sangat berharga untuk produk yang memiliki umur panjang dan yang berevolusi selama bertahun-tahun.

Selain menggunakan repositori untuk menjaga versi yang berbeda, juga digunakan untuk membangun sistem perangkat lunak dari sumber kegiatan sering disebut membangun. membangun mendapatkan versi terbaru (atau versi yang diinginkan) dari sumber-sumber dari repositori, dan menciptakan executable dari sumber.

 

7.3.2 Refactoring

Refactoring adalah teknik untuk meningkatkan kode yang ada dan mencegah kerusakan desain ini dengan waktu. Refactoring adalah bagian dari coding di bahwa itu dilakukan selama masa coding, tetapi tidak coding biasa. Refactoring telah dipraktekkan di masa lalu oleh programmer, tetapi baru-baru ini telah mengambil bentuk yang lebih konkrit.  Refactoring juga memainkan peran penting dalam test-driven development-kode perbaikan langkah dalam proses TDD benar-benar melakukan refactoring.

Tujuan dasar dari refactoring adalah untuk memperbaiki desain. Namun, perlu diketahui bahwa ini bukan tentang meningkatkan desain selama tahap desain untuk menciptakan desain yang akan kemudian dilaksanakan (yang merupakan fokus dari metodologi desain), tetapi tentang meningkatkan desain kode yang sudah ada. Dengan kata lain, refactoring, meskipun dilakukan pada kode sumber, memiliki tujuan untuk meningkatkan desain yang kode mengimplementasikan. Oleh karena itu, prinsip-prinsip dasar desain memandu proses refactoring. Akibatnya, refactoring umumnya menghasilkan satu atau lebih hal berikut:

1. Mengurangi kopling

2. kohesi Peningkatan

3. kepatuhan yang lebih baik untuk membuka-menutup prinsip

Risiko utama dari refactoring adalah bahwa ada kode kerja mungkin "istirahat" karena perubahan yang dibuat. Ini adalah alasan utama mengapa sering refactoring tidak dilakukan.Alasan lain adalah bahwa hal itu dapat dilihat sebagai biaya tambahan dan tidak perlu) Untuk mengurangi risiko ini, dua aturan emas adalah:

1. Refactor dalam langkah-langkah kecil

2. Memiliki tes skrip yang tersedia untuk menguji fungsi yang ada

Dengan refactoring, kualitas desain membaik, sehingga lebih mudah untuk melakukan perubahan kode serta menemukan bug. Jika perubahan baru yang diperlukan yang tidak terpikirkan sebelumnya, atau jika kekurangan yang ditemukan dalam desain, desain berubah melalui refactoring. Lebih sering daripada tidak, fleksibilitas tambahan dipertimbangkan dan dirancang tidak pernah diperlukan, sehingga sistem yang terlalu kompleks.

        Kapan refactoring diperlukan? Ada beberapa tanda-tanda yang mudah-spot dalam kode, yang kadang-kadang disebut "bau buruk"  yang sering menunjukkan bahwa beberapa sifat desain yang diinginkan dapat melanggar atau bahwa ada potensi untuk meningkatkan desain. Dengan kata lain, jika Anda "bau" salah satu dari ini "bau buruk," ini mungkin merupakan tanda bahwa refactoring diperlukan. Beberapa dari bau buruk dari yang diberikan di sini:

1. Kode Duplikat. Ini sangat umum. Salah satu alasan untuk ini adalah bahwa beberapa fungsi kecil sedang dijalankan di beberapa tempat (misalnya, usia dari tanggal lahir dapat dihitung di setiap tempat yang membutuhkan tanggal).
2. Metode Long. Jika metode besar, sering menggambarkan situasi di mana ia mencoba untuk melakukan terlalu banyak hal dan karena itu tidak kohesif.
3. Panjang Class. Demikian pula, kelas besar dapat menunjukkan bahwa itu encapsulating beberapa konsep, membuat kelas tidak kohesif.
4. Panjang Parameter Daftar. interface yang kompleks jelas tidak diinginkan-mereka membuat kode lebih sulit untuk mengerti. Seringkali, kompleksitas tidak intrinsik tetapi tanda desain yang tidak tepat.
5. Beralih Laporan. Dalam program berorientasi objek, jika polimorfisme yang tidak digunakan dengan benar, kemungkinan untuk menghasilkan pernyataan switch di mana-mana perilaku adalah untuk menjadi di ff erent tergantung pada properti. Kehadiran laporan beralih simi-lar di di ff tempat erent adalah tanda bahwa alih-alih menggunakan hirarki kelas, beralih pernyataan sedang digunakan. Kehadiran pernyataan switch membuat lebih sulit untuk memperpanjang kode-jika kategori baru yang akan ditambahkan, semua pernyataan switch akan harus diubah.
6. Generality spekulatif. Beberapa hierarki kelas mungkin ada karena benda-benda di subclass tampaknya di ff erent. Namun, jika perilaku objek subclass erent di ff adalah sama, dan tidak ada alasan mendesak untuk berpikir bahwa perilaku mungkin berubah, maka itu adalah kasus kompleksitas yang tidak perlu.
7. Terlalu Banyak Komunikasi Antara Objek. Jika metode dalam satu kelas membuat banyak panggilan ke metode objek lain untuk mencari tahu tentang keadaan, ini adalah tanda kopling kuat. Ada kemungkinan bahwa ini mungkin tidak diperlukan dan karenanya situasi tersebut harus diperiksa untuk refactoring.
8. Pesan Chaining. Salah satu metode panggilan metode lain, yang hanya melewati panggilan ini ke objek lain, dan sebagainya. rantai ini berpotensi menyebabkan kopling yang tidak perlu.

7.4 Unit Testing

 Driver memainkan peran "memanggil" modul dan sering bertanggung jawab untuk mendapatkan data tes, melaksanakan unit dengan data uji, dan kemudian melaporkan hasilnya. Bertopik dasarnya "bodoh" modul yang digunakan di tempat modul yang sebenarnya untuk memfasilitasi unit testing. Jadi, jika modul M menggunakan layanan dari modul N lain yang belum dikembangkan, maka untuk unit testing M, beberapa rintisan untuk N harus ditulis sehingga M dapat meminta layanan dalam beberapa cara pada N sehingga unit testing bisa memproses. Kebutuhan bertopik dapat dihindari, jika coding dan pengujian hasil dalam bottom-up dengan cara-modul pada tingkat yang lebih rendah dikodekan dan diuji pertama sehingga ketika modul pada tingkat yang lebih tinggi dari hirarki diuji, kode untuk modul-tingkat yang lebih rendah sudah tersedia. Jika coding tambahan dipraktekkan, seperti dibahas di atas, maka unit testing perlu dilakukan setiap kali programmer menambahkan beberapa kode. Jelas, itu akan jauh lebih e FFI efisien jika bukan melaksanakan unit dan memberikan masukan secara manual, pelaksanaan uji kasus otomatis. Kemudian uji kasus dapat dilaksanakan dengan mudah setiap kali pengujian perlu dilakukan. Beberapa alat yang tersedia untuk memfasilitasi ini. Di sini kita membahas beberapa pendekatan untuk unit testing menggunakan kerangka pengujian.

7.4.1 Testing Procedural Units

        Pengujian modul f () dengan kasus uji Maka akan melibatkan Langkah-Langkah berikut:

1.    Mengatur sistem negara yang diperlukan oleh uji kasus ini.

2.    Nilai Set parameter sesuai.

3.     Panggil prosedur f () dengan parameter.

4.    Bandingkan hasil f dengan hasil yang diharapkan

5.    Menyatakan apakah kasus uji telah berhasil atau gagal

        Yang paling sederhana dan umum digunakan pendekatan untuk mengeksekusi urutan langkah adalah untuk menulis sebuah program utama () yang mengeksekusi tiga langkah pertama, dengan nilai-nilai yang diberikan sebagai masukan oleh tester atau membaca dari sebuah file atau hard dikodekan dalam program, dan kemudian mencetak nilai-nilai penting. programmer kemudian mengeksekusi dua langkah terakhir, yaitu, membandingkan hasil dengan yang diharapkan dan memutuskan apakah tes telah berhasil atau gagal. Karena kebutuhan intervensi programmer untuk mengevaluasi output, dan mungkin juga untuk memberikan masukan pendekatan ini tidak mudah untuk skala.
        Setelah kasus uji dirancang, ini urutan langkah tetap tetap dan karenanya sangat ideal untuk otomatisasi lengkap. Dalam kerangka pengujian, sering kasus uji akan dinyatakan sebagai fungsi di mana ini urutan langkah-langkah dijalankan untuk itu ujian, termasuk pengecekan hasil dan menyatakan hasil-ini yang dilakukan sering dengan bantuan laporan menegaskan tersedia oleh framework. Sebuah tes suite maka kumpulan fungsi-fungsi ini, dan pelaksanaan tes suite berarti masing-masing fungsi dijalankan. Test suite berhasil jika semua kasus uji sukses. Jika kasus uji gagal, maka kerangka tes akan memutuskan apakah akan melanjutkan mengeksekusi atau berhenti.
        Dengan kerangka kerja tes ini, setiap kasus uji didefinisikan sebagai fungsi. Fungsi berakhir dengan beberapa pernyataan (disediakan oleh framework) yang tes untuk beberapa kondisi untuk menyatakan apakah tes telah gagal atau berhasil. Setiap fungsi yang mewakili unit tes ditambahkan ke array atau struktur, yang merupakan test suite. Beberapa suite tes juga dapat dibuat. Seringkali ada satu fungsi pengemudi yang suite ini berlalu dan yang kemudian mengeksekusi semua kasus uji.

7.4.2 Pengujian Unit Kelas

Dalam program berorientasi objek, unit yang akan diuji biasanya objek kelas. Untuk menguji kelas, programmer perlu menciptakan sebuah objek dari kelas itu, mengambil objek untuk negara tertentu, memanggil metode di atasnya, dan kemudian memeriksa apakah keadaan objek tersebut seperti yang diharapkan. Urutan ini harus dijalankan berkali-kali untuk sebuah metode, dan harus dilakukan untuk semua metode. Semua ini difasilitasi jika kita menggunakan kerangka kerja seperti Junit (www.junit.org). Meskipun Junit sendiri untuk Java, kerangka serupa telah dikembangkan untuk bahasa lain seperti C ++ dan C #. Untuk memeriksa hasil, Junit menyediakan dua metode khusus Menegaskan-Benar (ekspresi boolean) dan Menegaskan-Salah (ekspresi boolean).

Atribut utama dari kelas dan metode utama digambarkan pada Gambar 7.3.

Untuk unit pengujian kelas Matrix, jelas kita perlu menguji operasi standar seperti penciptaan matriks, pengaturan nilai-nilai, dll. Dan perlu menguji apakah operasi seperti menambah, mengurangi, mengalikan, penentu kinerja seperti yang diharapkan. Misalnya, untuk pengujian pembuatan metode test Add ()

 

 

7.5 Kode Inspeksi

Kode inspeksi adalah teknik lain yang sering diterapkan pada tingkat unit. Hal ini dapat dilihat sebagai "pengujian statis" di mana cacat terdeteksi dalam kode tidak dengan mengeksekusi kode tetapi melalui proses manual. Kode inspeksi seperti pengujian, diterapkan hampir seluruhnya di tingkat unit, yaitu, hanya unit program yang menjadi sasaran pemeriksaan.

Pemeriksaan adalah pendekatan verifikasi umum yang dapat diterapkan untuk mendeteksi cacat pada dokumen. Kode inspeksi pertama kali diusulkan oleh Fagan. Tujuan dasar dari inspeksi adalah untuk meningkatkan kualitas kode.

Beberapa karakteristik kunci dari inspeksi adalah:

-          Kode Inspeksi dilakukan oleh programmer dan untuk programmer.

-          Ini adalah proses yang terstruktur dengan peran yang ditetapkan untuk peserta.

-          Fokusnya pada identifikasi cacat, tetapi tidak memperbaiki.

-          Inspeksi data yang dicatat digunakan untuk memantau efektifitas dari proses pemeriksaan.

Inspeksi dilakukan oleh tim ulasan (atau inspektur) termasuk penulis, dengan satu dari mereka menjadi moderator. Moderator memiliki tanggung jawab keseluruhan untuk memastikan bahwa review dilakukan dengan cara yang tepat dan semua langkah dalam proses peninjauan.

7.5.1 Perencanaan

Tujuan dari tahap perencanaan adalah untuk mempersiapkan pemeriksaan. Tim harus terdiri dari setidaknya tiga orang, meskipun kadang-kadang tim empat atau lima anggota dan seorang moderator.

Penulis kode memastikan bahwa kode siap untuk diperiksa. Tujuan kode inspeksi adalah untuk meningkatkan kualitas. Selain cacat coding, ada masalah kualitas lain, seperti effisiensi, kepatuhan terhadap standar coding, dll.

Pada fase ini, setiap resensi melakukan tinjauan diri dari kode. Selama peninjauan diri, resensi melewati seluruh kode dan log semua cacat potensial ia menemukan di log persiapan diri. Seringkali pengulas akan menandai cacat pada produk pekerjaan itu sendiri, dan dapat memberikan ringkasan dari tinjauan diri dalam log. Pengulas juga mencatat waktu yang mereka habiskan dalam tinjauan diri. Sebuah bentuk standar dapat digunakan untuk log persiapan diri; contoh formulir ditunjukkan pada gambar di bawah ini:

Idealnya, review diri harus dilakukan dalam satu rentang waktu kontinu. Waktu yang disarankan adalah kurang dari dua jam-yaitu, produk kerja cukup kecil sehingga dapat diperiksa secara penuh dalam waktu kurang dari dua jam. Fase ini dari proses peninjauan berakhir ketika semua pengulas telah benar dilakukan mereka diri review dan mengisi diri log peninjauan.

7.5.3 Group Meeting Ulasan

Tujuan dasar dari pertemuan kajian kelompok adalah untuk datang dengan daftar cacat akhir, berdasarkan daftar awal dari cacat yang dilaporkan oleh pengulas dan yang baru ditemukan selama pembahasan dalam pertemuan tersebut. Kriteria masuk untuk langkah ini adalah bahwa moderator puas bahwa semua pengulas siap untuk pertemuan. Keluaran utama dari tahap ini adalah log cacat dan ringkasan laporan cacat.

moderator pertama memeriksa untuk melihat apakah semua pengulas siap. Hal ini dilakukan dengan upaya pemeriksaan singkat dan cacat data dalam diri-review log mengkonfirmasi bahwa waktu yang cukup efisien dan dalam melakukan persiapan. Ketika persiapan tidak memadai, review kelompok ditangguhkan sampai semua peserta sepenuhnya siap dan langsung review pertemuan kelompok diadakan. moderator bertugas pertemuan dan harus memastikan bahwa pertemuan itu tetap fokus pada tujuan dasar identifikasi cacat dan tidak berubah menjadi sesi brainstorming umum atau serangan pribadi pada penulis.

Cacat log terakhir adalah catatan resmi dari cacat diidentifikasi dalam inspeksi dan juga dapat digunakan untuk melacak cacat penutupan. Untuk menganalisis efektivitas pemeriksaan, namun, informasi hanya ringkasan tingkat yang diperlukan, yang laporan ringkasan siap. Ringkasan laporan menjelaskan kode, total usaha yang dihabiskan dan perpisahan dalam kegiatan proses review yang berbeda, jumlah cacat yang ditemukan untuk setiap kategori, dan ukuran. Jika jenis cacat juga dicatat, maka jumlah cacat dalam setiap kategori dapat juga disimpan dalam ringkasan. Sebuah laporan Ringkasan terisi sebagian ditunjukkan pada diatas.

Ringkasan laporan ini cukup jelas. Total jumlah cacat kecil ditemukan adalah 8, dan jumlah cacat utama yang ditemukan adalah 3. Artinya, kepadatan cacat ditemukan adalah 8 / 0.250 = 32 cacat kecil per KLOC, dan 3 / 0,25 = 12 cacat utama per KLOC. Dari pengalaman, kedua angka ini berada dalam kisaran terlihat di masa lalu; maka dapat diasumsikan bahwa review ini dilakukan dengan benar. Tim peninjau memiliki 3 anggota, dan masing-masing telah menghabiskan sekitar 1,5 jam di review individu dan pertemuan kajian berlangsung 1 jam. Ini berarti bahwa tingkat persiapan sekitar 180 LOC per jam, dan kelompok ulasan rate 250 LOC per jam, yang keduanya, dari pengalaman masa lalu, juga tampak diterima.

Jika modifikasi yang diperlukan untuk memperbaiki cacat dan menyikapi yaitu-menggugat beberapa, maka status ulasan kelompok "diterima." Jika modifikasi yang diperlukan banyak, pertemuan tindak lanjut oleh moderator atau peninjauan ulang mungkin diperlukan untuk memverifikasi apakah perubahan telah dimasukkan dengan benar. moderator merekomendasikan apa yang harus dilakukan. Selain itu, rekomendasi mengenai ulasan pada tahap berikutnya juga dapat dilakukan (kode misalnya, dalam tinjauan rinci-desain itu dapat direkomendasikan yang modul harus menjalani inspeksi).

7.6.1 Tindakan Ukuran

Ukuran produk adalah ukuran sederhana, yang dapat mudah untuk menghitung. Ukuran sendiri adalah menggunakan sedikit; itu adalah hubungan ukuran dengan biaya dan kualitas yang membuat ukuran metrik penting. Hal ini juga digunakan untuk mengukur produktivitas selama proyek (misalnya, KLOC per orang-bulan). kualitas akhir yang disampaikan oleh sebuah proses juga sering dinormalisasi sehubungan dengan ukuran (jumlah cacat per KLOC).

LOC digunakan sebagai ukuran ukuran. Bahkan untuk bahasa yang sama, ukuran dapat bervariasi tergantung pada bagaimana garis dihitung. Meskipun kekurangan ini, LOC tetap menjadi ukuran berguna dan masuk akal yang digunakan secara luas. Saat ini, mungkin metode penghitungan yang paling banyak digunakan untuk menentukan ukuran adalah dengan menghitung noncomment, garis tidak kosong saja.

-       n₁ adalah jumlah operator yang berbeda

-       n₂ adalah jumlah operan yang berbeda

-       f1,j jumlah kejadian dari j operator yang paling sering

-       f2,j jumlah kejadian dari j operan yang paling sering

kosakata n dari sebuah program didefinisikan sebagai:

Dengan parameter terukur yang terdaftar sebelumnya, dua parameter baru didefinisikan: