tugas 5 rpl

Koding dan Pengujian Unit

Tujuan dari koding atau pemrograman kegiatan adalah untuk menerapkan desain dengan cara sebaik mungkin. Aktivitas koding mengenai baik pengujian dan main-tenance secara mendalam. Seperti yang kita lihat sebelumnya, waktu yang dihabiskan di koding adalah sebagian kecil dari total biaya perangkat lunak, sementara pengujian dan pemeliharaan mengkonsumsi porsi besar. Dengan demikian, itu harus jelas bahwa tujuan selama koding tidak hanya untuk mengurangi biaya pelaksanaan, tetapi membantu mengurangi biaya tahap selanjutnya. Selama koding, diingat bahwa program tidak harus dibangun sehingga mereka mudah untuk menulis, tetapi dengan cara yang mereka mudah untuk membaca dan memahami.

Dalam percobaan, lima tim perbedaan diberikan masalah yang sama yang mereka harus mengembangkan program. Namun, masing-masing tim ditentukan tujuan untuk memenuhi. Tujuan perbedaan yang diberikan adalah: meminimalkan perbedaan diperlukan untuk menyelesaikan program, meminimalkan jumlah pernyataan, meminimalkan memori diperlukan, memaksimalkan kejelasan Program, dan memaksimalkan kejelasan output. Kebanyakan kasus masing-masing tim melakukan yang terbaik untuk tujuan yang ditentukan itu. Peringkat dari tim ditunjukkan pada Tabel 7.1.

	Dihasilkan Rank (1 = Terbaik)
	O1	O2	O3	O4	O5
Meminimalkan Upaya (O1)	1	4	4	5	3
Meminimlakan Jumlah Pernyataan (O2)	2–3	1	2	3	5
Meminimalkan memori diperlukan (O3)	5	2	1	4	4
Memaksimalkan kejelasan Program (O4)	4	3	3	2	2
Memaksimalkan kejelasan keluaran (O5)	2–3	5	5	1	1

Dalam bab ini kita akan membahas:

- Beberapa prinsip seperti pemrograman terstruktur, informasi bersembunyi, penggunaan standar koding, yang dapat membantu mengembangkan program lebih mudah dibaca.

- Beberapa proses programmer tingkat seperti pengembangan tambahan dan pengembangan uji-didorong, untuk effisien mengembangkan kode berkualitas tinggi.

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

- Bagaimana unit modul tes menggunakan kerangka pengujian unit.

- Sebuah proses pemeriksaan kode terstruktur yang dapat digunakan untuk meningkatkan kualitas kode.

7.1 Pemrograman Prinsip dan Pedoman

Tugas utama sebelum programmer untuk menulis kode yang dapat dibaca dengan beberapa bug di dalamnya. Sebuah gol tambahan adalah untuk menulis kode cepat. Menulis kode padat adalah keterampilan yang hanya dapat diperoleh dengan praktek. 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. Pada bagian ini, kita akan membahas beberapa konsep dan praktik yang dapat membantu programmer menulis kode berkualitas tinggi yang juga mudah untuk dipahami.

7.1.1 Pemrograman Terstruktur

Sebuah program memiliki struktur statis serta struktur yang dinamis. Struktur statis adalah struktur teks dari program, yang hanya orga-nization linear laporan program. Struktur dinamis dari program ini adalah urutan pernyataan dijalankan selama pelaksanaan program. Dengan kata lain, baik struktur statis dan perilaku dinamis adalah urutan laporan; sedangkan urutan mewakili struktur statis dari sebuah program adalah tetap, urutan laporan dijalankan dapat berubah dari eksekusi eksekusi.

Kita umumnya juga perlu menyatakan kondisi input di mana program tersebut akan dipanggil dan yang program ini diharapkan dapat menghasilkan hasil yang valid. Penegasan tentang keadaan akhir yang diharapkan dari sebuah program yang disebut post-kondisi yang pro-gram, dan pernyataan tentang kondisi masukan disebut pre-kondisi program. Seringkali, dalam verifikasi program menentukan pra-kondisi yang pasca-kondisi akan puas adalah tujuan bukti.

Untuk memverifikasi program, pernyataan dasar tentang segmen program ini dalam bentuk

         P {S}Q.

Penafsiran ini adalah bahwa jika pernyataan P benar sebelum mengeksekusi S, maka pernyataan Q akan menjadi kenyataan 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 dalam program sebelum dan setelah pelaksanaannya. Pernyataan umumnya tidak menentukan nilai nominal-TERTENTU untuk variabel, tetapi mereka menentukan sifat umum dari nilai-nilai dan hubungan di antara mereka.

Tujuan dasar menggunakan konstruksi terstruktur adalah untuk linearize aliran kontrol sehingga perilaku eksekusi lebih mudah untuk di bawah-berdiri dan berdebat tentang. Dalam aliran kontrol linier, jika kita memahami perilaku masing-masing konstruksi dasar benar, perilaku program dapat dianggap sebagai komposisi perilaku dari laporan. Untuk pendekatan ini untuk bekerja, itu tersirat bahwa kita dapat dengan jelas memahami dan menentukan perilaku setiap konstruk. Ini mengharuskan kita dapat ringkas menangkap atau menggambarkan perilaku setiap konstruk.

7.1.2 Menyembunyikan Informasi

Secara umum, hanya operasi tertentu dilakukan pada beberapa informasi. Artinya, sepotong informasi dalam masalah domain hanya digunakan dalam sejumlah cara dalam domain masalah. Sebagai contoh, sebuah buku besar di akuntan memiliki beberapa kegunaan yang sangat jelas: debit, kredit, memeriksa saldo, dll.

Ketika informasi tersebut direpresentasikan sebagai struktur data, prinsip yang sama harus diterapkan, dan hanya beberapa operasi yang didefinisikan harus dilakukan pada struktur data. 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.

                                                                                                                                           

7.1.3 Beberapa Praktek Pemrograman

Ada banyak praktek pemrograman yang dapat membantu ke arah tujuan itu. Kita bahas beberapa aturan yang telah ditemukan untuk membuat kode lebih mudah dibaca serta menghindari beberapa kesalahan.

Kontrol Constructs: Sebanyak mungkin single-entry, konstruksi single-exit digunakan. Hal ini juga diinginkan untuk menggunakan beberapa konstruksi kontrol standar daripada.

Gotos: Digunakan dengan hemat dan disiplin. Ketika alternative menggunakan gotos lebih kompleks harus gotos digunakan. Dalam kasus apapun, alternatif harus memikirkan sebelum akhirnya menggunakan gotos. Jika gotos harus digunakan, transfer ke depan (atau melompat ke pernyataan kemudian) lebih diterima daripada melompat ke belakang.

Menyembunyikan Informasi: Informasi bersembunyi harus didukung. Hanya fungsi akses untuk struktur data harus dibuat terlihat saat bersembunyi struktur data di balik fungsi tersebut.

Buatan Jenis Pengguna: bahasa modern memungkinkan pengguna untuk menentukan jenis seperti tipe enumerasi. Ketika fasilitas tersebut tersedia, mereka harus ex-ploited mana yang berlaku. Menggunakan jenis seperti membuat program yang lebih jelas daripada mendefinisikan kode untuk setiap hari dan kemudian bekerja dengan kode.

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

jika C1 kemudian S1

lain jika C2 kemudian S2

lain jika C3 kemudian S3

lain jika C4 kemudian S4;

Jika kondisi-nya saling terpisah (karena mereka sering), struktur ini dapat dikonversi ke dalam struktur berikut:

jika C1 kemudian S1;

jika C2 kemudian S2;

jika C3 kemudian S3;

jika C4 kemudian S4;

Modul Ukuran: membahas masalah system desain. Seorang programmer harus hati-hati memeriksa setiap fungsi dengan terlalu banyak laporan (mengatakan lebih dari 100). modul besar sering tidak akan fungsional kohesif. Tidak ada aturan keras-dan-cepat tentang ukuran modul; prinsip harus kohesi dan kopling.

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 proyek: Ketika sebuah modul dipanggil, kadang-kadang memiliki sisi proyek memodifikasi program negara di luar modifikasi parameter yang tercantum dalam definisi antarmuka modul, misalnya, memodifikasi variabel global. sisi effects tersebut harus dihindari jika mungkin, dan jika modul memiliki sisi proyek, mereka harus didokumentasikan dengan benar.

Kekokohan: Sebuah program yang kuat jika melakukan sesuatu yang direncanakan bahkan untuk kondisi yang luar biasa.

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.

switch (i) {

Kasus 0: {s = malloc (size)}
s [0] = y; / * NULL d e r e f e r e n c e jika bawaan terjadi * /

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.

try {

F i l e I n p u t S t r e a m fis = baru

F i l e I n p u t S t r e m a ( "I n pu TF il e");

} catch (I O E x c e p t i o n IOE) {} // bukan praktik yang baik

Kosong, sementara pernyataan jika: 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 cek berguna seperti itu harus dihindari.

if (x == 0) {} / * ada yang dilakukan setelah memeriksa x * / else {

: }

Baca Kembali lalu Diperiksa: Seringkali nilai kembali dari membaca tidak diperiksa, dengan asumsi bahwa membaca mengembalikan nilai yang diinginkan. Kadang-kadang hasil dari membaca bisa menjadi berbeda dengan apa yang diharapkan, dan ini dapat menyebabkan kegagalan kemudian. Mungkin ada beberapa kasus di mana mengabaikan kondisi ini dapat mengakibatkan beberapa kesalahan serius. Misalnya, jika membaca dari scanf () adalah lebih dari yang diharapkan, maka dapat menyebabkan overflow buffer. Oleh karena itu, nilai membaca harus diperiksa sebelum mengakses membaca data. (Ini adalah alasan mengapa sebagian besar bahasa memberikan nilai kembali untuk operasi read.)

Kembali dari Block Akhirnya: Kita tidak harus kembali dari blok akhirnya, karena dapat membuat keyakinan palsu. Sebagai contoh, perhatikan kode

String public foo () {

try {

membuang E xc ep ti baru di ( "An Ex ce pt io n");

}

catch (E xc ep ti di e) {

membuang e;

}

akhirnya {

kembali "Beberapa nilai";}

}

Parameter berkorelasi: Seringkali ada korelasi implisit antara parameter. Misalnya, di segmen kode yang diberikan di bawah ini, "panjang" membenci ukuran BUFFER. Jika korelasi tidak tahan, kita bisa lari ke masalah serius seperti buffer overflow (digambarkan dalam kode fragmen bawah). Oleh karena itu, itu adalah praktik yang baik untuk memvalidasi korelasi ini bukan asumsi yang dimilikinya. Secara umum, hal ini diinginkan untuk melakukan beberapa pemeriksaan counter pada asumsi implisit tentang parameter.

void  ( char  * src ,	int  length ,  char	destn [])	{
strcpy  ( destn ,	src );  /*  dapat menyebabkan bufferr		Overflow
	if  length	>  MAX_SIZE  */
}

Dipercaya Sumber Data: Counter pemeriksaan harus dilakukan sebelum mengakses data input, terutama jika data input yang disediakan oleh pengguna atau sedang diperoleh melalui jaringan.

Berikan Pentingnya ke Pengecualian: Untuk membuat sistem software yang lebih handal, programmer harus mempertimbangkan semua kemungkinan dan menulis penangan pengecualian cocok untuk mencegah kegagalan atau kehilangan saat seperti situasi terjadi.

7.1.4 Standar Koding

Programmer menghabiskan jauh lebih banyak waktu membaca kode daripada menulis kode. Selama kehidupan kode, penulis menghabiskan waktu yang cukup membacanya selama debugging dan peningkatan. Koding 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.

Konvensi Beberapa Penamaan konvensi standar yang sering melengah adalah:

- Nama paket harus dalam huruf kecil (misalnya, mypackage, edu.iitk.maths).

- Nama Type harus kata benda dan harus dimulai dengan huruf besar (misalnya, Day, DateOfBirth, EventHandler).

- Nama-nama variabel harus kata benda dimulai dengan huruf kecil (misalnya, nama, jumlah).

- Nama Konstan harus semua huruf besar (misalnya, PI, MAX iterasi).

- Nama Metode harus verba dimulai dengan huruf kecil (misalnya, getValue ()).

- Variabel kelas swasta harus memiliki su FFI x (misalnya, "pribadi nilai int"). (Beberapa standar akan membutuhkan ini menjadi awalan.)

- Variabel dengan lingkup yang besar harus memiliki nama yang panjang; variabel dengan lingkup kecil dapat memiliki nama pendek; iterator lingkaran harus dinamai i, j, k, dll

- Prefix tersebut harus digunakan untuk variabel Boolean dan metode untuk menghindari kebingungan (misalnya, isStatus harus digunakan bukan status); nama variabel boolean negatif (misalnya, isNotCorrect) harus dihindari.

- The menghitung jangka dapat digunakan untuk metode di mana sesuatu sedang com-puted; istilah find dapat digunakan di mana sesuatu yang sedang melihat ke atas (misalnya, computeMean (), findMin ()).

- Kelas Exception harus su FFI xed dengan Pengecualian (mis, OutOfBoundEx-konsepsi).

File Ada konvensi tentang bagaimana file harus dinamai, dan apa file harus berisi, sehingga pembaca bisa mendapatkan beberapa ide tentang apa file con-tains. Beberapa contoh konvensi ini adalah:

- File sumber Java harus memiliki ekstensi .java-ini diberlakukan oleh sebagian besar kompiler dan alat.

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

- Panjang garis harus dibatasi kurang dari 80 kolom dan khusus charac-ters harus dihindari. Jika garis lebih panjang, hal itu harus dilanjutkan dan kelanjutan harus dibuat sangat jelas

- Variabel harus diinisialisasi di mana dinyatakan, dan mereka harus dinyatakan dalam lingkup terkecil yang mungkin.

- Menyatakan variabel yang terkait bersama-sama dalam sebuah pernyataan umum. Tidak terkait vari-ables tidak harus dinyatakan dalam laporan yang sama.

- Variabel Kelas tidak harus dinyatakan publik.

- Gunakan hanya pernyataan kontrol loop dalam untuk loop.

- Variabel loop harus diinisialisasi segera sebelum loop.

- Hindari penggunaan istirahat dan terus dalam satu lingkaran.

- Hindari penggunaan do ... sementara membangun.

- Hindari kondisional kompleks ekspresi memperkenalkan sementara boolean variabel-variabel-bukan.

- Hindari pernyataan dieksekusi dalam conditional.

  Java menyediakan komentar dokumentasi yang dibatasi oleh "/ ** ... * /", dan yang bisa diambil ke file HTML. Komentar ini sebagian besar digunakan sebagai prolog untuk kelas dan metode-metode dan bidang, dan dimaksudkan untuk menyediakan dokumentasi untuk pengguna kelas yang mungkin tidak memiliki akses ke kode sumber. Selain prolog untuk modul, standar pengkodean dapat menentukan bagaimana dan di mana komentar harus berada. Beberapa pedoman tersebut adalah:

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

- Harus ada komentar untuk semua variabel utama menjelaskan apa yang mereka rep-membenci.

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

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

7.2 Tahap Mengembangkan Kode

Aktivitas coding dimulai ketika beberapa bentuk desain yang telah dilakukan dan spesifikasi dari modul untuk dikembangkan. 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.

7.2.1 Proses Incremental Koding

Proses diikuti oleh banyak pengembang untuk menulis kode untuk modul yang saat ini ditetapkan, dan ketika dilakukan, melakukan unit testing dan memperbaiki bug yang ditemukan. Maka kode tersebut akan diperiksa dalam repositori proyek untuk membuatnya tersedia untuk orang lain dalam proyek tersebut. (Kami akan menjelaskan proses memeriksa kemudian.)

Sebuah proses baik untuk coding, yang sering diikuti oleh berpengalaman pengembang, adalah untuk mengembangkan kode secara bertahap. Artinya, menulis kode untuk im-plementing hanya bagian dari fungsi modul. Kode ini disusun dan diuji dengan beberapa tes cepat untuk memeriksa kode yang telah ditulis sejauh ini. Ketika kode melewati tes ini, pengembang hasil untuk menambah fungsionalitas lebih lanjut untuk kode, yang kemudian diuji lagi.

Keuntungan dasar mengembangkan kode secara bertahap dengan pengujian yang dilakukan setelah setiap putaran coding adalah untuk memfasilitasi debugging-kesalahan yang ditemukan dalam beberapa pengujian dapat dengan aman dikaitkan dengan kode yang ditambahkan sejak pengujian terakhir yang berhasil.

                                                                                                                            

7.2.2 Uji-Driven Development

Test-Driven Development (TDD) adalah proses koding yang berbalik pendekatan umum. Alih-alih menulis kode dan kemudian mengembangkan kasus uji untuk memeriksa kode, di TDD itu sebaliknya-programmer menulis skrip tes, dan kemudian menulis kode untuk lulus tes. Seluruh proses dilakukan secara bertahap, dengan tes yang ditulis berdasarkan spesifikasi dan kode yang ditulis untuk lulus tes.

Beberapa poin yang perlu diperhatikan tentang TDD. Pertama, pendekatan mengatakan bahwa Anda menulis kode hanya cukup untuk lulus tes. Dengan mengikuti ini, kode ini selalu sinkron dengan tes. Hal ini tidak selalu terjadi dengan pendekatan kode-pertama, tapi kemudian hanya menulis beberapa tes yang hanya mencakup beberapa bagian kode.

7.2.3 Pair Programming

Pair programming juga merupakan proses coding yang telah diusulkan sebagai metodologi kunci teknik dalam pemrograman ekstrim (XP). Dalam pemrograman pasangan, kode tidak ditulis oleh programmer individu tetapi oleh sepasang programmer. Artinya, pekerjaan coding ditugaskan untuk tidak individu tetapi untuk sepasang individu. Pasangan ini bersama-sama menulis kode.

Proses dipertimbangkan adalah bahwa satu orang akan ketik program sementara yang lain akan secara aktif berpartisipasi dan terus-menerus meninjau apa yang sedang diketik. Ketika kesalahan perhatikan, mereka menunjukkan dan diperbaiki. Jika diperlukan, pasangan membahas algoritma, struktur data, atau strategi yang akan digunakan dalam kode yang akan ditulis. Peran yang diputar sering membuat kedua pasangan sama dan memiliki peran yang sama. Motivasi dasar pemrograman pasangan adalah bahwa sebagai kode membaca dan kode ulasan.

7.3 Mengelola Kode Berkembang

Selama proses coding, kode yang ditulis oleh programmer (atau sepasang) berevolusi-mulai dari nol untuk akhirnya memiliki modul teruji. 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. Sedemikian skenario dinamis, mengelola kode berkembang adalah sebuah tantangan. Di sini kita membahas dua aspek ini-bagaimana mengelola versi erent di ff yang bisa dibuat, dan bagaimana mempertahankan kualitas kode di bawah perubahan.

7.3.1 Sumber Pengaturan dan Mengembangkan Kode

Dalam banyak proyek, beberapa orang mengembangkan sumber kode. Setiap programmer membuat file sumber, yang akhirnya digabungkan bersama-sama untuk menciptakan executable. Programmer terus berubah file sumber mereka sebagai kode berevolusi. Dalam rangka menjaga kontrol atas sumber dan evolusi mereka, kontrol sumber kode hampir selalu digunakan dalam proyek-proyek menggunakan alat seperti CVS pada UNIX (www.cvshome.org) atau sumber visual aman (VSS) pada Windows (msdn.microsoft.com / VStudio / sebelumnya / safe).

Untuk proyek, repositori harus diatur dengan izin untuk perbedaan orang dalam proyek. File-file repositori akan berisi juga specified- 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 local.

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 <f ile>). Operasi ini juga disebut sebagai check-in.

Memperbarui salinan local: 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 upaya pada evolusi file. Ini termasuk laporan seperti selisih antara file lokal dan versi terbaru dari file, semua perubahan yang dibuat ke file bersama dengan tanggal dan alasan untuk perubahan (yang typ-ically tersedia saat melakukan perubahan).

Ini harus jelas bahwa jika dua orang memeriksa beberapa berkas dan kemudian membuat perubahan, ada kemungkinan konflik perubahan dibuat untuk bagian yang sama dari file. Semua alat akan mendeteksi konflik ketika orang kedua mencoba untuk melakukan perubahan, dan akan menginformasikan pengguna. pengguna harus secara manual mengatasi conflit itu, yaitu, membuat file sehingga perubahan tidak bertentangan dengan perubahan yang ada, dan kemudian melakukan file. Konflik biasanya jarang karena mereka terjadi hanya jika perubahan dibuat untuk baris yang sama dalam file.

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.

7.3.2 Refactoring

Kita telah melihat bahwa coding sering melibatkan membuat perubahan ke beberapa kode. Kode juga berubah ketika persyaratan mengubah atau ketika fungsi baru ditambahkan. Karena perubahan yang dilakukan oleh modul, bahkan jika kita mulai dengan desain yang baik. Dan sekali desain yang terkandung dalam kode menjadi kompleks, maka meningkatkan kode untuk mengakomodasi perubahan yang diperlukan menjadi lebih kompleks, memakan waktu, dan rawan kesalahan. Dengan kata lain, produktivitas dan kualitas mulai menurun.

Refactoring adalah teknik untuk meningkatkan kode yang ada dan mencegah kerusakan desain.

7.3 Mengelola Pengembangan

Refactoring juga memainkan peran penting dalam test-driven development-kode, perbaikan langkah dalam proses TDD benar-benar melakukan refactoring. Di sini kita membahas beberapa konsep kunci dan beberapa metode untuk melakukan refactoring.

Refactoring didefinisikan sebagai perubahan yang dibuat dengan struktur internal perangkat lunak untuk membuatnya lebih mudah memahami dan lebih murah untuk memodifikasi tanpa mengubah perilaku yang dapat diamati Tujuan dari refactoring adalah untuk memperbaiki desain, tetapi tentang meningkatkan desain kode yang sudah ada. Dengan kata lain, refactoring, meskipun dilakukan pada kode sumber, memiliki tujuan untuk meningkatkan implementasi desain kode. 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 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

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

2. Metode Besar

3. Panjang Class

4. Daftar Panjang Parameter.

5. Beralih Laporan

6. Generality spekulatif.

7. Terlalu Banyak Komunikasi Antara Objek

8. Pesan Chaining. 

 Ini bau buruk secara umum adalah indikasi dari desain miskin. Jelas ada kemungkinan tak terbatas dari bagaimana kode dapat refactored untuk meningkatkan desain.

7.4 Pengujian Satuan

Setelah programmer menulis kode untuk modul, itu harus diverifikasi sebelum digunakan oleh orang lain. Pengujian tetap metode yang paling umum dari verifikasi ini. Pada tingkat programmer pengujian dilakukan untuk memeriksa kode programmer telah mengembangkan (dibandingkan dengan memeriksa seluruh sistem software) disebut unit testing.

Unit pengujian seperti pengujian rutin di mana program dijalankan dengan beberapa kasus uji kecuali bahwa fokusnya adalah pada pengujian program yang lebih kecil atau modul yang biasanya ditugaskan ke salah satu programmer (atau sepasang) untuk coding. Dalam proses pemrograman kita bahas sebelumnya, pengujian pada dasarnya unit testing. Sebuah unit mungkin fungsi atau kumpulan kecil dari fungsi untuk bahasa proce-dural, atau kelas atau kumpulan kecil dari kelas untuk bahasa berorientasi objek.

7.4.1 Pengujian Unit Prosedural

Dalam unit testing, satu, atau koleksi kecil, modul ini adalah untuk diuji dengan serangkaian uji kasus. Sebagai perilaku modul tergantung pada nilai parameter serta negara secara keseluruhan sistem yang merupakan bagian (misalnya, negara variabel global), kasus uji untuk modul f () akan melibatkan pengaturan baik keadaan sistem yang perilaku f () tergantung serta nilai parameter. Nilai yang sebenarnya dan keadaan sistem untuk kasus uji tergantung pada tujuan merancang uji kasus ini.

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.

Setelah kasus uji dirancang, ini urutan langkah 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 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.

7.4.2 Pengujian Unit 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 #. Di sini kita secara singkat menjelaskan bagaimana Junit dapat digunakan untuk menguji kelas dan memberikan contoh.

Untuk pengujian dari CUT kelas (kelas yang diuji) dengan Junit, tester harus menciptakan kelas lain yang mewarisi dari Junit (misalnya, kelas cuttest meluas Junit). Kerangka Junit harus diimpor oleh kelas ini. kelas ini adalah driver untuk pengujian CUT. Ini harus memiliki konstruktor di mana benda-benda yang diperlukan untuk kasus uji diciptakan; metode setup () yang biasanya digunakan untuk membuat benda dan mendirikan nilai-nilai sebelum mengeksekusi kasus uji; suite (), dan utama () yang mengeksekusi suite () menggunakan TestRunner disediakan oleh Junit. Selain metode ini, semua metode lain sebenarnya uji kasus. Sebagian besar dari metode ini sering disebut testxxxx ().

7.5 Inspeksi Kode

Inspeksi kode 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. Inspeksi kode, seperti pengujian, diterapkan hampir seluruhnya di tingkat unit, yaitu, hanya unit program menjadi sasaran pemeriksaan. Oleh karena itu, kami menganggap itu sebagai bentuk lain dari unit testing. Namun, dalam praktiknya, sering keduanya digunakan, terutama untuk modul kritis.

Ini harus menunjukkan bahwa pemeriksaan adalah pendekatan verifikasi umum yang dapat diterapkan untuk mendeteksi cacat pada dokumen. Namun, pertama kali digunakan untuk mendeteksi cacat dalam kode, dan inspeksi kode tetap bahkan hari ini industri praktek terbaik yang secara luas digunakan.

Inspeksi kode adalah review kode oleh sekelompok rekan-rekan mengikuti proses didefinisikan dengan jelas. Tujuan dasar dari inspeksi adalah untuk meningkatkan kualitas kode dengan menemukan cacat. Beberapa karakteristik kunci dari inspeksi adalah:

- Inspeksi Kode dilakukan oleh programmer.

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

- Fokusnya adalah pada identifikasi cacat, tidak memperbaiki mereka.

- Inspeksi data yang dicatat dan digunakan untuk memantau efektifitas e ff 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 diikuti.

7.5.1 Perencanaan

Tujuan dari tahap perencanaan adalah untuk mempersiapkan untuk pemeriksaan. Sebuah tim inspeksi terbentuk, yang harus mencakup kode programmer untuk ditinjau. Tim harus terdiri dari setidaknya tiga orang, meskipun kadang-kadang tim empat atau lima anggota juga terbentuk. Sebuah moderator ditunjuk.

Penulis kode memastikan bahwa kode siap untuk diperiksa dan puas dalam kriteria entri. Umumnya kriteria masuk yang digunakan adalah bahwa kode mengkompilasi dengan benar dan alat analisis statis yang tersedia telah diterapkan. moderator memeriksa bahwa kriteria masuk puas dengan kode. Sebuah paket disiapkan yang akan didistribusikan kepada tim inspeksi. Paket biasanya terdiri dari kode yang akan diperiksa, spesifikasi yang kode dikembangkan, dan checklist yang harus digunakan untuk pemeriksaan.

Paket untuk ditinjau diberikan kepada pengulas. moderator dapat ar-range pertemuan pembukaan, jika diperlukan, di mana penulis dapat memberikan gambaran singkat dari produk dan setiap daerah khusus yang perlu memandang perawatan sepenuhnya.

7.5.2 Ulasan Diri

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

Nama proyek dan kode:    Bekerja nama produk dan ID:

No.	Location	Description	Criticality/Seriousness
hline

7.6 Metrik

Secara tradisional, bekerja pada metrik telah difokuskan pada produk akhir, yaitu, kode. Dalam arti, semua metrik untuk produk antara persyaratan dan desain pada dasarnya digunakan untuk memastikan bahwa produk akhir memiliki kualitas tinggi dan produktivitas proyek tetap tinggi. Artinya, tujuan dasar dari metrik untuk produk adalah untuk memprediksi atau mendapatkan beberapa ide tentang metrik dari produk akhir. Untuk kode, metrik yang paling umum digunakan adalah ukuran dan kompleksitas. Di sini kita membahas beberapa langkah ukuran dan kompleksitas.

7.6.1 Tindakan Ukuran

Ukuran produk adalah ukuran sederhana, yang dapat mudah untuk menghitung. Ukuran sendiri adalah sedikit menggunakan 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). Untuk alasan ini, ukuran adalah salah satu metrik yang paling penting dan sering digunakan.

Ukuran yang paling umum dari ukuran disampaikan baris kode sumber, atau jumlah baris kode (LOC) akhirnya disampaikan. Masalahnya dengan LOC adalah bahwa jumlah baris kode untuk sebuah proyek sangat tergantung pada bahasa yang digunakan. Misalnya, program yang ditulis dalam bahasa assembly akan besar dibandingkan dengan program yang sama yang ditulis dalam bahasa tingkat tinggi, jika 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

Dalam program kita mendefinisikan jumlah terukur berikut:

- N1 adalah jumlah operator yang berbeda

- N2 adalah jumlah operan yang berbeda

- F1, j adalah jumlah kejadian dari j Operator yang paling sering

- F2, j adalah jumlah kemunculan j paling operan sering Kemudian kosakata n dari sebuah program didefinisikan sebagai

n = n1 + n2.

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

X X

N1 = f1, j, N2 = f2, j.

N1 adalah total kejadian dari operator perbedaan dalam program dan N2 adalah total kejadian operant. Panjang dari program ini didefinisikan sebagai

N = N1 + N2.

 Dari panjang dan kosa kata, volume V dari program didefinisikan sebagai V = Nlog2 (n).

Definisi volume program mewakili jumlah minimum bit diperlukan untuk mewakili program. log2 (n) adalah jumlah bit yang diperlukan untuk mewakili setiap elemen dalam program unik, dan N adalah total terjadi-rences elemen. Volume digunakan sebagai ukuran metrik untuk suatu program. Percobaan telah menunjukkan bahwa volume sebuah program sangat berkorelasi dengan ukuran di LOC.

7.6.2 Kompleksitas Metrik

Kompleksitas memiliki dampak yang besar pada biaya pemeliharaan program. Untuk mengukur kompleksitas gagasan luar dari kemudahan, program dapat dibangun atau dipahami, beberapa metrik untuk mengukur kompleksitas program yang dibutuhkan.

Sejumlah metrik telah diusulkan untuk mengukur kompleksitas program, dan penelitian telah dilakukan untuk mengkorelasikan kompleksitas dengan pemeliharaan. Di sini kita membahas beberapa langkah kompleksitas yang telah diusulkan.

Cyclomatic Kompleksitas Berdasarkan kemampuan pikiran manusia dan pengalaman orang, umumnya diakui bahwa kondisi dan pernyataan kontrol menambahkan kompleksitas program. Mengingat dua program dengan ukuran yang sama, program dengan jumlah yang lebih besar dari pernyataan keputusan cenderung lebih kompleks. Ukuran paling sederhana kompleksitas, kemudian, adalah jumlah konstruksi yang mewakili cabang di aliran kontrol dari program, seperti jika kemudian lain, sementara lakukan, ulangi sampai, dan pernyataan goto.

Sebuah ukuran yang lebih halus adalah ukuran kompleksitas cyclomatic diusulkan oleh McCabe, yang merupakan konsep graph-teori berbasis. Untuk graf G dengan n simpul, e tepi, dan komponen terhubung p, jumlah cyclomatic V (G) didefinisikan sebagai

V (G) = e - n + p.

Ternyata kompleksitas cyclomatic dari modul (atau cyclomatic num-ber grafik) adalah sama dengan jumlah maksimum sirkuit bebas linear dalam grafik. Satu set rangkaian linear jika ada sirkuit yang benar-benar terkandung dalam sirkuit lain atau merupakan kombinasi dari sirkuit lainnya. Jadi, untuk menghitung jumlah cyclomatic dari modul, kita dapat menarik grafik, membuatnya terhubung dengan menggambar busur dari node keluar ke node masuk, dan kemudian menghitung jumlah sirkuit atau menghitung dengan menghitung jumlah tepi dan node.

Bahwa kompleksitas cyclomatic dari modul adalah sejumlah keputusan dalam modul ditambah satu, di mana keputusan adalah effectively pernyataan Condi-nasional dalam modul. Oleh karena itu, kami juga bisa menghitung kompleksitas cyclomatic hanya dengan menghitung jumlah keputusan dalam modul. Untuk contoh ini, seperti yang kita lihat, kita mendapatkan kompleksitas cyclomatic sama untuk modul jika kita menambahkan 1 ke sejumlah keputusan dalam modul. (Modul ini memiliki tiga keputusan: di dua sementara pernyataan dan satu dalam laporan.)

7.7 Ringkasan

- Seperti membaca program adalah kegiatan jauh lebih umum daripada menulis program, tujuan dari kegiatan koding adalah untuk menghasilkan program, selain bebas dari cacat, mudah untuk memahami dan memodifikasi.

- Gunakan pemrograman terstruktur di mana program ini adalah urutan yang sesuai single-entry konstruksi single-exit membuat program yang mudah untuk memahami dan memverifikasi. praktek-praktek lainnya seperti menggunakan menyembunyikan informasi, cocok coding stan-dards, dan praktek pemrograman yang baik juga membantu meningkatkan pembacaan kode dan kualitas.

- Untuk pengembang, hal ini sangat efektif untuk mengembangkan kode secara bertahap. Hal ini dapat dilakukan dengan menulis kode sedikit demi sedikit, dan pengujian dan debugging setiap kenaikan sebelum menulis kode lebih. Atau, pengembangan uji-driven dapat diikuti di mana uji kasus yang ditulis pertama dan kemudian kode ditulis untuk lulus uji kasus ini. Meskipun coding dari modul umumnya dilakukan oleh programmer individu, alternatif adalah pasangan pemrograman, di mana coding dilakukan oleh sepasang programmer-baik strategi bersama-sama berkembang, struktur data, algoritma dll

- Kode Berkembang perlu dikelola dengan baik. Hal ini dapat dilakukan melalui kontrol alat kode sumber yang tepat yang memungkinkan manajemen mudah dari versi berbeda yang bisa dibuat, serta mudah kehancuran perubahan yang perlu digulung kembali.

- Sebagai kode berubah dengan waktu, untuk memastikan bahwa kualitas kode tidak terus menurunkan karena evolusi, refactoring dapat dilakukan. Selama refactoring ada fungsi baru ditambahkan-satunya perbaikan dilakukan agar desain kode membaik dengan penurunan kopling, peningkatan kohesi, dan lebih baik menggunakan hirarki.

- Unit testing adalah sangat populer dan paling sering digunakan praktek oleh programmer untuk memverifikasi kode yang mereka tulis. Dalam unit testing, programmer menguji / nya kode nya dalam isolasi. Untuk bahasa prosedural ini sering satu set kecil prosedur atau fungsi, dan untuk bahasa berorientasi objek ini umumnya kelas atau satu set kecil kelas. pengujian unit membutuhkan driver dan stub, dan dapat difasilitasi oleh penggunaan kerangka yang memungkinkan tes otomatis eksekusi script. kerangka yang baik seperti Cunit dan Junit ada untuk kedua bahasa prosedural dan bahasa berorientasi objek.

- Sejumlah metrik ada untuk kuantitasnya di kualitas perbedaan kode. Yang paling umum digunakan adalah metrik ukuran, karena mereka digunakan untuk menilai produktivitas orang dan sering digunakan dalam estimasi biaya. Ukuran paling umum adalah baris kode (LOC), yang juga digunakan di sebagian besar model biaya. Tujuan dari metrik kompleksitas adalah untuk mengukur kompleksitas perangkat lunak, sebagai kompleksitas merupakan faktor penting sebuah produktivitas proyek dan merupakan faktor dalam estimasi biaya. Sejumlah metrik perbedaan, yang paling umum adalah kompleksitas cyclomatic, yang didasarkan pada logika internal program dan mendefinisikan kompleksitas sebagai jumlah siklus independen dalam grafik aliran program.