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:
- 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).
- Metode
Long. Jika metode besar, sering menggambarkan situasi di mana ia mencoba
untuk melakukan terlalu banyak hal dan karena itu tidak kohesif.
- Panjang
Class. Demikian pula, kelas besar dapat menunjukkan bahwa itu
encapsulating beberapa konsep, membuat kelas tidak kohesif.
- 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.
- 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.
- 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.
- 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.
- 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.
- n1 adalah jumlah operator yang
berbeda
- n2 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:
.jpeg)
.jpeg)
.jpeg)
.jpeg)
.jpeg)
