![Clean Code Terjemahan PDF [PDF]](https://pdfs.asia/img/200x200/clean-code-terjemahan-pdf.jpg)
16 0 2 MB
3/12/2020
www.it-ebooks.info
Halaman 1
www.it-ebooks.info
Halaman 2
Kode Bersih
https://translate.googleusercontent.com/translate_f
1/365
3/12/2020
www.it-ebooks.info
www.it-ebooks.info
Halaman 3
Robert C. Martin Series Misi dari seri ini adalah untuk meningkatkan seni pengerjaan perangkat lunak. Buku-buku dalam seri ini bersifat teknis, pragmatis, dan substansial. Penulis adalah pengrajin dan profesional yang sangat berpengalaman yang berdedikasi untuk menulis tentang apa sebenarnya bekerja dalam praktik, sebagai lawan dari apa yang mungkin berhasil dalam teori. Kamu akan membaca tentang apa yang telah dilakukan penulis, bukan apa yang menurutnya harus Anda lakukan. Jika buku itu tentang pemrograman, akan ada banyak kode. Jika buku itu tentang mengelola, di sana akan banyak studi kasus dari proyek nyata. Ini adalah buku-buku yang akan dimiliki semua praktisi serius di rak buku mereka. Ini adalah buku-buku yang akan diingat untuk membuat perbedaan dan untuk membimbing profesional untuk menjadi pengrajin sejati. Mengelola Proyek Agile Sanjiv Augustine Estimasi dan Perencanaan Agile Mike Cohn Bekerja Efektif dengan Kode Legacy Michael C. Feathers Agile Java ™: Membuat Kode dengan Pengembangan Berbasis Tes Jeff Langr Prinsip, Pola, dan Praktek Agile dalam C # Robert C. Martin dan Micah Martin Pengembangan Perangkat Lunak Agile: Prinsip, Pola, dan Praktek Robert C. Martin Kode Bersih: Buku Pegangan Pengerjaan Perangkat Lunak Agile Robert C. Martin Programmer UML Untuk Java ™ Robert C. Martin Cocok untuk Mengembangkan Perangkat Lunak: Kerangka untuk Tes Terpadu Rick Mugridge dan Ward Cunningham Pengembangan Perangkat Lunak Agile dengan SCRUM Ken Schwaber dan Mike Beedle Rekayasa Perangkat Lunak Ekstrim: Pendekatan Langsung Daniel H. Steinberg dan Daniel W. Palmer Untuk informasi lebih lanjut, kunjungi informit.com/martinseries
www.it-ebooks.info
https://translate.googleusercontent.com/translate_f
2/365
3/12/2020
www.it-ebooks.info
Halaman 4
Kode Bersih Buku Pegangan Agile Pengerjaan Perangkat Lunak
Obyek Mentor: Robert C. Martin Michael C. Feathers Timothy R. Ottinger Jeffrey J. Langr Brett L. Schuchert James W. Grenning Kevin Dean Wampler Object Mentor Inc.
Menulis kode bersih adalah hal yang harus Anda lakukan untuk menyebut diri Anda seorang profesional. Tidak ada alasan yang masuk akal untuk melakukan sesuatu yang kurang dari yang terbaik.
Upper Saddle River, NJ • Boston • Indianapolis • San Francisco New York • Toronto • Montreal • London • Munich • Paris • Madrid Capetown • Sydney • Tokyo • Singapura • Kota Meksiko
www.it-ebooks.info
Halaman 5
Banyak sebutan yang digunakan oleh produsen dan penjual untuk membedakan produk mereka diklaim sebagai merek dagang. Di mana sebutan itu muncul dalam buku ini, dan penerbit mengetahui adanya klaim merek dagang, sebutan telah dicetak dengan huruf kapital awal atau di semua ibukota. Penulis dan penerbit telah berhati-hati dalam persiapan buku ini, tetapi tidak menyatakan atau garansi tersirat dalam bentuk apa pun dan tidak bertanggung jawab atas kesalahan atau kelalaian. Tidak ada tanggung jawab yang ditanggung untuk kerusakan insidental atau konsekuensial sehubungan dengan atau timbul dari penggunaan informasi atau program yang terkandung di sini. Penerbit menawarkan diskon yang sangat baik untuk buku ini ketika dipesan dalam jumlah banyak untuk pembelian dalam jumlah besar atau
https://translate.googleusercontent.com/translate_f
3/365
3/12/2020
www.it-ebooks.info penjualan khusus, yang mungkin termasuk versi elektronik dan / atau sampul khusus dan konten khusus untuk Anda bisnis, tujuan pelatihan, fokus pemasaran, dan minat merek. Untuk informasi lebih lanjut silahkan hubungi: Penjualan Korporat dan Pemerintah AS (800) 382-3419 [email protected] Untuk penjualan di luar Amerika Serikat, silakan hubungi: Penjualan internasional [email protected]
Termasuk referensi dan indeks bibliografi. ISBN 0-13-235088-2 (pbk.: Kertas alk) 1. Pengembangan perangkat lunak tangkas. 2. Perangkat lunak komputer — Keandalan. I. Judul. QA76.76.D47M3652 2008 005.1 — dc22 2008024750 Hak Cipta © 2009 Pearson Education, Inc. Seluruh hak cipta. Dicetak di Amerika Serikat. Publikasi ini dilindungi oleh hak cipta, dan izin harus diperoleh dari penerbit sebelum reproduksi dilarang, disimpan di a sistem pengambilan, atau transmisi dalam bentuk apa pun atau dengan cara apa pun, elektronik, mekanik, fotokopi, merekam, atau juga. Untuk informasi mengenai izin, tulis ke: Pearson Education, Inc Departemen Hak dan Kontrak 501 Boylston Street, Suite 900 Boston, MA 02116 Faks: (617) 671-3447 ISBN-13: 978-0-13-235088-4 ISBN-10: 0-13-235088-2 Teks dicetak di Amerika Serikat pada kertas daur ulang di Courier di Stoughton, Massachusetts. Pencetakan pertama Juli 2008
www.it-ebooks.info
Halaman 6
Untuk Ann Marie: Cinta abadi dalam hidupku.
https://translate.googleusercontent.com/translate_f
4/365
3/12/2020
www.it-ebooks.info
www.it-ebooks.info
Halaman 7
halaman ini sengaja dibiarkan kosong
https://translate.googleusercontent.com/translate_f
5/365
3/12/2020
www.it-ebooks.info
www.it-ebooks.info
Halaman 8
Isi Kata Pengantar ..................................................... ............................................... xix Pengantar ................................................. ......................................... xxv Di Sampul ................................................... ........................................ xxix Bab 1: Kode Bersih ............................................. ........................... 1 Akan Ada Kode .................................................. ................................. 2 Kode yang salah ................................................ ................................................ 3 Total Biaya Memiliki Mess ........................................... ............. 4 Grand Redesign in the Sky ............................................ .............. 5 Sikap................................................. .............................................. 5 The Primal Conundrum ............................................... ....................... 6 Seni Kode Bersih? ............................................ .......................... 6 Apa itu Kode Bersih? ............................................. ............................. 7 Sekolah Pemikiran ................................................... ............................... 12 Kami Adalah Penulis ............................................... ..................................... 13 Aturan Pramuka .................................................. ............................... 14 Prekuel dan Prinsip ............................................... ......................... 15 Kesimpulan ................................................. ........................................... 15 Daftar Pustaka ................................................. ........................................ 15
Bab 2: Nama Yang Berarti ................................................. .......... 17 Pengantar ................................................. ........................................ 17 Gunakan Nama yang Mengungkap Tujuan ................................................. ............ 18 Hindari Disinformasi ................................................ .......................... 19 Buat Perbedaan Yang Berarti ............................................... ............ 20 Gunakan Nama yang Dapat Diucapkan ............................................... ................... 21 Gunakan Nama yang Dapat Dicari ............................................... ......................... 22
vii www.it-ebooks.info
https://translate.googleusercontent.com/translate_f
6/365
3/12/2020
www.it-ebooks.info
Halaman 9
viii
Isi
Hindari Penyandian ................................................ ...................................... 23 Notasi Hongaria ................................................ .......................... 23 Awalan Anggota .................................................... ............................... 24 Antarmuka dan Implementasi ............................................... ........ 24 Hindari Pemetaan Mental ............................................... ........................ 25 Nama Kelas .................................................... ......................................... 25 Nama Metode .................................................... ..................................... 25 Don't Be Cute ................................................. ......................................... 26 Pilih Satu Kata per Konsep ............................................. .................. 26 Jangan Pun .................................................. ............................................... 26 Gunakan Nama Domain Solusi .............................................. ................ 27 Gunakan Masalah Nama Domain .................................................. ................ 27 Tambahkan Konteks yang Berarti ............................................... ..................... 27 Jangan Tambahkan Konteks Sombong ............................................ ............... 29 Kata-kata Akhir .................................................... .......................................... 30
Bab 3: Fungsi .............................................. ........................... 31 Kecil! .................................................. .................................................. 34 Blok dan Indentasi ............................................... ......................... 35 Lakukan Satu Hal ............................................... ........................................ 35 Bagian dalam Fungsi ............................................... ................. 36 Satu Tingkat Abstraksi per Fungsi ............................................ .36 Membaca Kode dari Atas ke Bawah: Aturan Stepdown .................. 37 Beralih Pernyataan ................................................ ............................... 37 Gunakan Nama Deskriptif ............................................... ......................... 39 Argumen Fungsi ................................................ ............................ 40 Bentuk Monadik Umum ............................................... .................. 41 Tandai Argumen ................................................ ................................ 41 Fungsi Dyadic ................................................ .............................. 42 Triad ................................................. ............................................... 42 Objek Argumen ................................................ ............................. 43 Daftar Argumen ................................................ ................................. 43 Kata Kerja dan Kata Kunci ............................................... .......................... 43 Tidak Memiliki Efek Samping .................................................. ............................. 44 Argumen Keluaran .................................................... ............................ 45 Pemisahan Query Perintah ............................................... .............. 45
www.it-ebooks.info
Halaman 10
ix
Isi
Memilih Pengecualian untuk Mengembalikan Kode Kesalahan ................................... 46 Ekstrak Blok Coba / Tangkap ............................................. .................... 46 Penanganan Kesalahan Adalah Satu Hal ............................................. ............... 47 Magnet Ketergantungan Error.java ............................................ .47 Jangan Ulangi Diri Anda ............................................. ............................ 48 Pemrograman Terstruktur ................................................ ................... 48 Bagaimana Anda Menulis Fungsinya Seperti Ini? .......................................... 49 https://translate.googleusercontent.com/translate_f
7/365
3/12/2020
www.it-ebooks.info
Kesimpulan ................................................. ........................................... 49 SetupTeardownIncluder ................................................. .................... 50 Daftar Pustaka ................................................. ........................................ 52
Bab 4: Komentar .................................................. ......................... 53 Komentar Jangan Menebus Kode Buruk ....................................... 55 Jelaskan Dirimu dalam Kode .............................................. ...................... 55 Komentar Baik ................................................ ...................................... 55 Komentar Hukum ................................................ ............................... 55 Komentar Informatif ................................................ ..................... 56 Penjelasan Tujuan ............................................... ......................... 56 Klarifikasi................................................. ..................................... 57 Peringatan Konsekuensi ............................................... ................. 58 Komentar TODO ................................................ ............................. 58 Amplifikasi ................................................. ................................... 59 Javadocs dalam API Publik .............................................. ...................... 59 Komentar buruk ................................................ .................................... 59 Bergumam ................................................. ........................................ 59 Komentar Redundan ................................................ ...................... 60 Komentar yang Menyesatkan ................................................ ...................... 63 Komentar yang Dimandatkan ................................................ ........................ 63 Komentar Jurnal ................................................ ............................ 63 Komentar Kebisingan ................................................ .............................. 64 Suara Menakutkan ................................................ .......................................... 66 Jangan Gunakan Komentar Saat Anda Dapat Menggunakan a Fungsi atau Variabel .................................................. ......................... 67 Penanda Posisi ................................................ ............................... 67 Komentar Penutupan Brace ............................................... .................. 67 Atribusi dan Bylines ............................................... .................... 68
www.it-ebooks.info
Halaman 11
x
Isi
Kode yang Diomentari .................................................. ........................ 68 Komentar HTML ................................................ ............................ 69 Informasi Nonlokal ................................................ ....................... 69 Terlalu banyak informasi ............................................... ...................... 70 Koneksi Tak Terlihat ................................................ ....................... 70 Tajuk Fungsi ................................................ .............................. 70 Javadocs dalam Kode Nonpublik .............................................. .............. 71 Contoh................................................. ........................................... 71 Daftar Pustaka ................................................. ........................................ 74
Bab 5: Memformat .............................................. ........................ 75 Tujuan Memformat .................................................. .................. 76 Pemformatan Vertikal ................................................ ............................. 76 Metafora Koran ............................................... ................. 77 Keterbukaan Vertikal Antar Konsep .............................................. 78 Kepadatan Vertikal ................................................ ................................ 79 Jarak Vertikal ................................................ .............................. 80 Pemesanan Vertikal ................................................ .............................. 84 Pemformatan Horizontal ................................................ ........................ 85 Keterbukaan dan Kepadatan Horizontal .............................................. ...... 86 Alignment Horizontal ................................................ ....................... 87 Lekukan................................................. ....................................... 88 https://translate.googleusercontent.com/translate_f
8/365
3/12/2020
www.it-ebooks.info
Lingkup Dummy ................................................ ................................. 90 Aturan Tim ................................................ ........................................... 90 Aturan Pemformatan Paman Bob .............................................. .............. 90
Bab 6: Objek dan Struktur Data .................................... 93 Abstraksi Data ................................................ .................................. 93 Data / Objek Anti-Simetri ............................................ .................. 95 Hukum Demeter .................................................. .............................. 97 Kecelakaan Kereta ................................................ .................................... 98 Hibrida ................................................. ............................................ 99 Menyembunyikan Struktur ................................................ ............................... 99 Objek Transfer Data ................................................... ........................ 100 Rekaman Aktif ................................................ ................................. 101 Kesimpulan ................................................. ......................................... 101 Daftar Pustaka ................................................. .......................................... 101
www.it-ebooks.info
Halaman 12
xi
Isi
Bab 7: Penanganan Kesalahan ............................................. .............. 103 Gunakan Pengecualian Daripada Mengembalikan Kode ................................... 104 Tulis Pernyataan Coba-Tangkap-Akhirnya Anda Pertama ....................... 105 Gunakan Pengecualian yang Tidak Dicentang ............................................... ................ 106 Berikan Konteks dengan Pengecualian .............................................. ....... 107 Tentukan Kelas Pengecualian dalam Persyaratan Kebutuhan Penelepon .................. 107 Tentukan Aliran Normal .............................................. ...................... 109 Jangan Mengembalikan Null ............................................. ................................. 110 Jangan Lewati Null ............................................. ..................................... 111 Kesimpulan ................................................. ......................................... 112 Daftar Pustaka ................................................. .......................................... 112
Bab 8: Batas .............................................. ...................... 113 Menggunakan Kode Pihak Ketiga ............................................. ....................... 114 Menjelajahi dan Mempelajari Batas .................................................. .116 Belajar log4j ................................................ ................................. 116 Tes Belajar Lebih Baik Daripada Bebas ............................................ ... 118 Menggunakan Kode yang Belum Ada ........................................... ..... 118 Batas Bersih ................................................ .............................. 120 Daftar Pustaka ................................................. .......................................... 120
Bab 9: Tes Unit ............................................. .......................... 121 Tiga Hukum TDD ............................................. ...................... 122 Menjaga Tes Bersih ............................................... ........................... 123 Pengujian Mengaktifkan -ilities ............................................. ...................... 124 Tes Bersih .................................................... ......................................... 124 Bahasa Pengujian Domain-Khusus ............................................. ... 127 Standar Ganda ................................................... .............................. 127 Satu Penegasan per Tes .................................................. ............................. 130 Konsep tunggal per Tes .................................................. .................... 131 PERTAMA ..................................................... ............................................ 132 Kesimpulan ................................................. ......................................... 133 Daftar Pustaka ................................................. .......................................... 133
Bab 10: Kelas .............................................. ............................ 135 Organisasi Kelas ................................................ ............................ 136 https://translate.googleusercontent.com/translate_f
9/365
3/12/2020
www.it-ebooks.info
Enkapsulasi ................................................. ................................ 136
www.it-ebooks.info
Halaman 13
xii
Isi
Kelas Harus Kecil! .................................................. ................ 136 Prinsip Tanggung Jawab Tunggal .............................................. .138 Kohesi................................................. ........................................ 140 Mempertahankan Hasil Kohesi di Banyak Kelas Kecil .................. 141 Pengorganisasian untuk Perubahan ................................................... ...................... 147 Mengisolasi dari Perubahan ............................................... ..................... 149 Daftar Pustaka ................................................. ...................................... 151
Bab 11: Sistem .................................................. .......................... 153 Bagaimana Anda Akan Membangun Kota? .................................................. ........ 154 Pisahkan Membangun Sistem dari Penggunaannya .............................. 154 Pemisahan Utama ............................................... .......................... 155 Pabrik ................................................. ........................................ 155 Injeksi Ketergantungan ................................................ ..................... 157 Meningkatkan Scaling Up ................................................ .......................................... 157 Kekhawatiran Lintas Sektor .................................................. ................... 160 Proxy Java ................................................ ........................................ 161 Kerangka Kerja AOP Pure Java .............................................. ............... 163 Aspek Aspek J ................................................ ................................. 166 Test Drive Arsitektur Sistem ............................................. ..... 166 Optimalkan Pengambilan Keputusan ............................................... ................ 167 Gunakan Standar dengan Bijak, Ketika Mereka Menambahkan Nilai yang Dapat Dilihat ......... 168 Sistem Membutuhkan Bahasa-Bahasa yang Tertentu Domain ..................................... 168 Kesimpulan ................................................. ......................................... 169 Daftar Pustaka ................................................. .......................................... 169
Bab 12: Munculnya .............................................. .................... 171 Bersihkan melalui Desain Muncul ............................................. ... 171 Aturan Desain Sederhana 1: Menjalankan Semua Pengujian ........................................ 172 Aturan Desain Sederhana 2–4: Refactoring .......................................... ..172 Tidak Ada Duplikasi ................................................ ................................... 173 Ekspresif ................................................. .............................................. 175 Kelas dan Metode Minimal .............................................. ........... 176 Kesimpulan ................................................. ......................................... 176 Daftar Pustaka ................................................. .......................................... 176
Bab 13: Konkurensi .............................................. ................ 177 Mengapa konkurensi? .................................................. ......................... 178 Mitos dan Kesalahpahaman ............................................... .............. 179
www.it-ebooks.info
Halaman 14
https://translate.googleusercontent.com/translate_f
10/365
3/12/2020
www.it-ebooks.info
xiii
Isi
Tantangan ................................................. ......................................... 180 Prinsip Pertahanan Konkurensi ............................................... ....... 180 Prinsip Tanggung Jawab Tunggal ............................................... ....... 181 Konsekuensi: Batasi Cakupan Data ........................................... ..... 181 Konsekuensi: Gunakan Salinan Data ............................................ ........... 181 Konsekuensi: Utas Sebisa Mungkin Independen ............ 182 Ketahui Perpustakaan Anda ............................................... ............................ 182 Koleksi Thread-Safe .................................................. ................... 182 Ketahui Model Eksekusi Anda .............................................. ............ 183 Konsumen-Konsumen ............................................... ......................... 184 Pembaca-Penulis ............................................... ............................... 184 Filsuf Bersantap ................................................ ....................... 184 Waspadai Ketergantungan Antara Metode yang Disinkronkan ................ 185 Jaga agar Bagian yang Disinkronkan Kecil .............................................. .... 185 Menulis Kode Shut-Down Benar Sulit ..................................... 186 Menguji Kode Berurutan ............................................... ...................... 186 Perlakukan Kegagalan Palsu sebagai Masalah Calon Threading ................. 187 Dapatkan Kode Nonthreaded Anda Bekerja Dahulu .................................... 187 Buat Kode Berurutan Anda Dapat Dibatasi ............................................ 187 Jadikan Kode Berurutan Anda Dapat Diubah ............................................. ... 187 Jalankan dengan Lebih Banyak Thread Daripada Prosesor ....................................... 188 Jalankan pada Berbagai Platform .................................................. .............. 188 Instrumentasi Kode Anda untuk Mencoba dan Memaksa Kegagalan ............................ 188 Kode Tangan ................................................... .................................... 189 Otomatis ................................................. ..................................... 189 Kesimpulan ................................................. ......................................... 190 Daftar Pustaka ................................................. .......................................... 191
Bab 14: Penyempurnaan Berturut-turut ............................................ 193 Implementasi Args ................................................ ........................ 194 Bagaimana Saya Melakukan Ini? .................................................. ..................... 200 Args: The Rough Draft ............................................. ........................ 201 Jadi saya berhenti ............................................... .................................... 212 Tentang Inkrementalisme ................................................ ......................... 212 Argumen String ................................................ .............................. 214 Kesimpulan ................................................. ........................................ 250
www.it-ebooks.info
Halaman 15
xiv
Isi
Bab 15: JUnit Internal ............................................. ............. 251 Kerangka Kerja JUnit ............................................... ........................ 252 Kesimpulan ................................................. ......................................... 265
Bab 16: Tanggal Refactoring Serial ......................................... 267 Pertama, Jadikan Bekerja ............................................. .............................. 268 Kemudian Lakukan dengan Benar .................................................. ............................. 270 Kesimpulan ................................................. ......................................... 284 Daftar Pustaka ................................................. .......................................... 284
https://translate.googleusercontent.com/translate_f
11/365
3/12/2020
www.it-ebooks.info
Bab 17: Bau................................................. dan Heuristik ............................................ .285 Komentar ......................................... 286 C1: Informasi Tidak Pantas .............................................. ......... 286 C2: Komentar Usang .................................................. ..................... 286 C3: Komentar Redundan .................................................. ................. 286 C4: Komentar yang ditulis dengan buruk ............................................. ............. 287 C5: Kode Keluar-Komentar ............................................ ................. 287 Lingkungan ................................................. ..................................... 287 E1: Build Membutuhkan Lebih Dari Satu Langkah ........................................ 287 E2: Tes Membutuhkan Lebih Dari Satu Langkah .......................................... 287 Fungsi ..................................................... ........................................... 288 F1: Terlalu Banyak Argumen ............................................. ................... 288 F2: Argumen Keluaran .................................................. ...................... 288 F3: Tandai Argumen .............................................. .......................... 288 F4: Fungsi Mati .............................................. ........................... 288 Umum ................................................. .............................................. 288 G1: Beberapa Bahasa dalam Satu File Sumber ...................................... 288 G2: Perilaku Jelas Tidak Diimplementasikan .......................................... 288 G3: Perilaku yang Tidak Benar di Batas ..................................... 289 G4: Override Safeties .................................................. ................... 289 G5: Duplikasi ............................................... ............................... 289 G6: Kode di Level Abstraksi Salah ........................................ 290 G7: Kelas Dasar Tergantung pada Derivatifnya ....................... 291 G8: Terlalu Banyak Informasi ............................................. ................ 291 G9: Kode Mati .............................................. ................................. 292 G10: Pemisahan Vertikal .............................................. .................. 292 G11: Inkonsistensi ............................................... .......................... 292 G12: Kekacauan ............................................... ..................................... 293
www.it-ebooks.info
Halaman 16
xv
Isi
G13: Kopling Buatan .............................................. ................... 293 G14: Kecemburuan Fitur .............................................. ............................ 293 G15: Argumen Pemilih .............................................. .................. 294 G16: Maksud Tersembunyi .................................................. ....................... 295 G17: Tanggung Jawab yang salah tempat .............................................. ......... 295 G18: Statis Tidak Pantas .................................................. ................. 296 G19: Gunakan Variabel Penjelasan ............................................. ....... 296 G20: Nama Fungsi Harus Mengatakan Apa Yang Mereka Lakukan .......................... 297 G21: Memahami Algoritma ............................................. ........ 297 G22: Jadikan Ketergantungan Logis Fisik ................................... 298 G23: Memilih Polimorfisme untuk If / Else atau Switch / Case .................... 299 G24: Ikuti Konvensi Standar ............................................. ... 299 G25: Ganti Angka Ajaib dengan Konstanta Bernama .................. 300 G26: Jadilah Precise .............................................. ................................ 301 G27: Struktur atas Konvensi ............................................. ........ 301 G28: Meringkas Kondisional .................................................. ....... 301 G29: Hindari Persyaratan Negatif ................................................. .... 302 G30: Fungsi Seharusnya Melakukan Satu Hal ........................................... 302 G31: Kopling Temporal Tersembunyi ............................................. ..... 302 G32: Jangan Sewenang-wenang ........................................... ...................... 303 G33: Meringkas Ketentuan Batas ........................................ 304 G34: Fungsi Hanya Harus Turun Satu Tingkat Abstraksi .............................................. .................. 304 G35: Simpan Data yang Dapat Dikonfigurasi di Level Tinggi ................................ 306 G36: Hindari Navigasi Transitif ............................................. ...... 306 https://translate.googleusercontent.com/translate_f
12/365
3/12/2020
www.it-ebooks.info
Jawa ..307 J1:................................................. Hindari Daftar Impor Panjang.................................................. dengan Menggunakan Wildcard ............................ 307 J2: Jangan Mewarisi Konstanta ........................................... ................. 307 J3: Konstanta versus Enums ............................................. .............. 308 Nama ................................................. ................................................ 309 N1: Pilih Nama Deskriptif ............................................. ......... 309 N2: Pilih Nama di Tingkat Abstraksi yang Tepat .......... 311 N3: Gunakan Nomenklatur Standar Bila Mungkin ........................... 311 N4: Nama Tidak Jelas .................................................. ................. 312 N5: Gunakan Nama Panjang untuk Lingkup Panjang .......................................... 0,312 N6: Hindari Penyandian .............................................. ........................ 312 N7: Nama Harus Menjelaskan Efek Samping. ..................................... 313
www.it-ebooks.info
Halaman 17
xvi
Isi
Tes ..................................................... .................................................. 0,313 T1: Tes Tidak Cukup .................................................. ......................... 313 T2: Gunakan Alat Cakupan! .................................................. ............. 313 T3: Jangan Lewati Tes Sepele .......................................... .................. 313 T4: Tes yang Diabaikan Adalah Pertanyaan tentang Ambiguitas .................. 313 T5: Uji Kondisi Batas ............................................. ........... 314 T6: Menguji Bug Hampir Seluruhnya ............................................ ........ 314 T7: Pola Kegagalan Mengungkap ........................................... 0,314 T8: Pola Cakupan Tes Dapat Diungkap ............................... 314 T9: Tes Harus Cepat ............................................ ..................... 314 Kesimpulan ................................................. ......................................... 314 Daftar Pustaka ................................................. .......................................... 315
Lampiran A: Concurrency II ............................................. ............ 317 Contoh Klien / Server .................................................. ........................ 317 Server ................................................ ...................................... 317 Menambahkan Threading ................................................ ........................... 319 Pengamatan Server .................................................... ....................... 319 Kesimpulan................................................. ..................................... 321 Jalur Eksekusi yang Mungkin .................................................. ................ 321 Jumlah Jalur ................................................... .............................. 322 Menggali lebih dalam ................................................ .............................. 323 Kesimpulan................................................. ..................................... 326 Mengenal Perpustakaan Anda ............................................... ....................... 326 Kerangka Pelaksana ................................................ ...................... 326 Solusi Nonblocking ................................................ ................... 327 Kelas Tidak-Aman-Aman .................................................. .................... 328 Ketergantungan Antara Metode Dapat Melanggar Kode Serentak .................................................. ............. 329 Toleransi Kegagalan ............................................... .......................... 330 Penguncian Berbasis Klien .................................................. ....................... 330 Penguncian Berbasis Server .................................................. ...................... 332 Meningkatkan Throughput ................................................ ..................... 333 Perhitungan Single-Thread untuk Throughput .......................................... 334 Perhitungan Multithread untuk Throughput .............................................. 335 Jalan buntu ................................................. ............................................ 335 Pengecualian Saling ................................................ ........................... 336 Kunci & Tunggu ................................................... .................................... 337
https://translate.googleusercontent.com/translate_f
13/365
3/12/2020
www.it-ebooks.info www.it-ebooks.info
Halaman 18
xvii
Isi
Tidak Ada Preemption ................................................ ................................ 337 Edaran Tunggu ................................................ .................................. 337 Melanggar Pengecualian Saling ............................................... ............. 337 Breaking Lock & Tunggu .............................................. ...................... 338 Melanggar Preemption ................................................ ...................... 338 Breaking Circular Wait ............................................... .................... 338 Menguji Kode Multithreaded ............................................... .............. 339 Alat Bantu untuk Menguji Kode Berbasis Thread ................................ 342 Kesimpulan ................................................. ......................................... 342 Tutorial: Contoh Kode Lengkap ............................................. ............. 343 Klien / Server Tidak Dibaca .................................................. ............... 343 Klien / Server Menggunakan Threads ............................................. ............. 346
Lampiran B: org.jfree.date.SerialDate .......................................... 349 Lampiran C: Referensi Silang Heuristik ........................... 409 Epilog ..................................................... ............................................... 411 Indeks ................................................. .................................................. ... 413
www.it-ebooks.info
Halaman 19
https://translate.googleusercontent.com/translate_f
14/365
3/12/2020
www.it-ebooks.info
halaman ini sengaja dibiarkan kosong
www.it-ebooks.info
Halaman 20
Kata pengantar Salah satu permen favorit kami di Denmark adalah Ga-Jol, yang memiliki uap licorice yang kuat adalah a pelengkap sempurna untuk cuaca lembab dan sering dingin kami. Bagian dari pesona Ga-Jol untuk as. Danes adalah ucapan bijak atau jenaka yang dicetak pada tutup setiap kotak atas. Saya membeli dua pak kelezatan pagi ini dan menemukan bahwa itu membosankan melihat Denmark tua ini: Terlebih dahulu aku tersenyum dan tidak tahu apa-apa . "Kejujuran dalam hal-hal kecil bukanlah hal yang kecil." Itu pertanda baik yang konsisten dengan apa yang saya
https://translate.googleusercontent.com/translate_f
15/365
3/12/2020
www.it-ebooks.info sudah ingin katakan di sini. Hal-hal kecil penting. Ini adalah buku tentang keprihatinan sederhana yang nilainya jauh dari kecil. Tuhan ada dalam perinciannya , kata arsitek Ludwig mies van der Rohe. Kutipan ini mengingatkan argumen kontemporer tentang peran arsitektur dalam pengembangan perangkat lunak, dan parkhususnya di dunia Agile. Bob dan saya kadang-kadang menemukan diri kami bergairah dialog ini. Dan ya, mies van der Rohe memperhatikan utilitas dan bentuk abadi bangunan yang mendasari arsitektur hebat. Di sisi lain, ia juga secara pribadi memilih setiap gagang pintu untuk setiap rumah yang dirancangnya. Mengapa? Karena hal-hal kecil penting. Dalam "debat" berkelanjutan kami tentang TDD, Bob dan saya telah menemukan bahwa kami sepakat bahwa arsitektur ware memiliki tempat penting dalam pengembangan, meskipun kami mungkin memiliki perbedaan visi tentang apa artinya itu. Pertengkaran semacam itu relatif tidak penting, namun, karena kita dapat menerima begitu saja bahwa profesional yang bertanggung jawab memberikan beberapa waktu untuk berpikiring dan perencanaan pada permulaan proyek. Gagasan akhir 1990-an desain hanya didorong oleh tes dan kodenya sudah lama hilang. Namun perhatian terhadap detail bahkan lebih kritis fondasi profesionalisme daripada visi besar mana pun. Pertama, melalui latihan di Internet kecil sehingga profesional memperoleh kemahiran dan kepercayaan untuk praktik dalam skala besar. Kedua, itu Sedikit konstruksi ceroboh, dari pintu yang tidak tertutup rapat atau sedikit ubin bengkok di lantai, atau bahkan meja yang berantakan, benar-benar menghilangkan pesona keseluruhan lebih besar. Itulah kode bersihnya. Namun, arsitektur hanyalah satu metafora untuk pengembangan perangkat lunak, dan khususnya untuk bagian dari perangkat lunak yang memberikan produk awal dalam arti yang sama dengan arsitek memberikan bangunan yang masih asli. Pada hari-hari Scrum dan Agile ini, fokusnya cepat membawa produk ke pasar. Kami ingin pabrik berjalan dengan kecepatan tinggi untuk menghasilkan perangkat lunak. Ini adalah pabrik manusia: pemikir, pencerap perasaan yang bekerja dari suatu produk log atau cerita pengguna untuk membuat produk . Metafora manufaktur tampak sangat kuat berpikir. Aspek produksi manufaktur mobil Jepang, dari jalur perakitan dunia, banyak menginspirasi Scrum. xix www.it-ebooks.info
Halaman 21
xx
Kata pengantar
Namun, bahkan dalam industri otomotif, sebagian besar pekerjaannya tidak terletak di bidang manufaktur tetapi di pemeliharaan — atau penghindarannya. Dalam perangkat lunak, 80% atau lebih dari apa yang kita lakukan disebut aneh "Pemeliharaan": tindakan perbaikan. Daripada merangkul fokus khas Barat pada pro Karena perangkat lunak yang baik, kita harus berpikir lebih seperti tukang rumah di gedung industri, atau mekanik otomatis di bidang otomotif. Apa yang dimiliki manajemen Jepang katakan tentang itu ? Pada sekitar tahun 1951, pendekatan kualitas yang disebut Total Productive Maintenance (TPM) datang di kancah Jepang. Fokusnya adalah pada pemeliharaan dan bukan pada produksi. Salah satunya pilar utama TPM adalah serangkaian prinsip 5S. 5S adalah seperangkat disiplin — dan di sini saya menggunakan istilah "disiplin" secara instruktif. Prinsip-prinsip 5S ini sebenarnya ada di Tions of Lean — kata kunci lain di kancah Barat, dan semakin menonjol kata kunci di lingkaran perangkat lunak. Prinsip-prinsip ini bukan pilihan. Sebagaimana Paman Bob menceritakan Hal terpentingnya, praktik perangkat lunak yang baik membutuhkan disiplin seperti itu: fokus, kehadiran pikiran, dan berpikir. Tidak selalu hanya tentang melakukan, tentang mendorong peralatan pabrik untuk meningkatkan kurangi pada kecepatan optimal. Filosofi 5S terdiri dari konsep-konsep ini:
• Seiri , atau organisasi (pikirkan "sort" dalam bahasa Inggris). Mengetahui di mana segala sesuatu — menggunakan pendekatan seperti penamaan yang cocok — sangat penting. Anda pikir pengidentifikasi nama tidak penting? Baca terus di bab-bab berikut.
• Seiton , atau kerapian (pikirkan "sistematis" dalam bahasa Inggris). Ada pepatah Amerika kuno: Tempat untuk semuanya, dan segala sesuatu di tempatnya . Sepotong kode harus ada di mana Anda berharap menemukannya — dan, jika tidak, Anda harus mempertimbangkan kembali untuk mendapatkannya di sana.
• Seiso , atau membersihkan (pikirkan "bersinar" dalam bahasa Inggris): Jaga tempat kerja bebas dari gantung kabel, minyak, sisa, dan limbah. Apa yang penulis katakan di sini tentang sampah Anda kode dengan komentar dan baris kode berkomentar yang menangkap sejarah atau keinginan masa depan? Singkirkan mereka.
• Seiketsu , atau standardisasi: Grup setuju tentang cara menjaga kebersihan tempat kerja. Apakah menurut Anda buku ini mengatakan sesuatu tentang memiliki gaya dan rangkaian pengkodean yang konsisten praktik dalam kelompok? Dari mana standar itu berasal? Baca terus.
• Shutsuke , atau disiplin (disiplin diri ). Ini berarti memiliki disiplin untuk mengikuti praktik dan untuk sering merefleksikan pekerjaan seseorang dan bersedia berubah. Jika Anda menerima tantangan — ya, tantangan — membaca dan menerapkan buku ini, Anda akan memahami dan menghargai poin terakhir. Di sini, kami akhirnya berkendara ke
https://translate.googleusercontent.com/translate_f
16/365
3/12/2020
www.it-ebooks.info akar profesionalisme yang bertanggung jawab dalam profesi yang harus peduli dengan kehidupan siklus suatu produk. Karena kami memelihara mobil dan mesin lain di bawah TPM, pemeliharaan bawah — menunggu bug muncul — adalah pengecualian. Sebaliknya, kita naik a level: periksa mesin setiap hari dan perbaiki bagian aus sebelum pecah, atau lakukan setara dengan pergantian 10.000 mil pepatah minyak untuk mencegah keausan. Dalam kode, refactor tanpa ampun. Anda dapat meningkatkan satu tingkat lebih jauh lagi, karena gerakan TPM meningkatkan lebih dari 50 tahun yang lalu: membangun mesin yang lebih mudah dirawat. MakMembaca kode Anda sama pentingnya dengan membuatnya dapat dieksekusi. Praktek utama, diperkenalkan di kalangan TPM sekitar tahun 1960, adalah untuk fokus pada memperkenalkan seluruh mesin baru atau
www.it-ebooks.info
Halaman 22
xxi
Kata pengantar
mengganti yang lama. Ketika Fred Brooks memperingatkan kita, kita mungkin harus kembali melakukan soft-soft ware potongan dari awal setiap tujuh tahun atau lebih untuk menyapu merayap cruft. Mungkin kita harus memperbarui konstanta waktu Brooks ke urutan minggu, hari atau jam, bukan tahun. Di situlah letak detailnya. Ada kekuatan besar dalam detail, namun ada sesuatu yang rendah hati dan mendalam tentang ini pendekatan terhadap kehidupan, seperti yang mungkin kita harapkan secara stereotip dari pendekatan apa pun yang mengklaim Japaakar nese. Tapi ini bukan hanya pandangan Timur tentang kehidupan; Orang Inggris dan Amerika dom penuh dengan peringatan seperti itu. Kutipan Seiton dari atas mengalir dari pena seorang menteri Ohio yang secara harfiah memandang kerapian "sebagai obat untuk setiap tingkat kejahatan." Bagaimana dengan Seiso? Kebersihan di sebelah kesalehan . Secantik rumah itu, berantakan meja merampas kemegahannya. Bagaimana dengan Shutsuke dalam masalah kecil ini? Dia yang setia dalam sedikit itu banyak yang setia . Bagaimana kalau ingin kembali faktor pada waktu yang bertanggung jawab, memperkuat posisi seseorang untuk keputusan "besar" berikutnya, daripada menundanya? SEBUAH menjahit tepat waktu menghemat sembilan . Burung awal menangkap cacing. Jangan menunda sampai besok apa yang bisa kamu lakukan hari ini. (Begitulah arti asli dari frasa “yang bertanggung jawab terakhir moment ”di Lean hingga jatuh ke tangan konsultan perangkat lunak . ) Bagaimana dengan kalibrating tempat usaha kecil, individu dalam keseluruhan besar? Oak perkasa dari biji kecil tumbuh. Atau bagaimana mengintegrasikan pekerjaan pencegahan sederhana ke dalam kehidupan sehari-hari? Satu ons pencegahan bernilai satu pon penyembuhan. Satu apel sehari dapat menghindarkan dari penyakit. Kode bersih menghormati akar kebijaksanaan yang mendalam di bawah budaya kita yang lebih luas, atau budaya kita seperti dulu, atau harus, dan bisa dengan perhatian terhadap detail. Bahkan dalam literatur arsitektur besar kita menemukan gergaji yang mengingatkan kembali pada dukungan ini. rincian yang diajukan. Pikirkan gagang pintu mies van der Rohe. Itu seiri . Itu penuh perhatian ke setiap nama variabel. Anda harus memberi nama variabel menggunakan perawatan yang sama dengan yang Anda nama anak pertama. Seperti yang diketahui oleh setiap pemilik rumah, perawatan dan perbaikan yang terus menerus tidak pernah berakhir. Arsitek Christopher Alexander - bapak pola dan bahasa pola - pandangan setiap tindakan desain itu sendiri sebagai tindakan perbaikan kecil dan lokal. Dan dia memandang pengerjaan struktur halus untuk menjadi ruang lingkup arsitek; bentuk-bentuk yang lebih besar dapat diserahkan pada pola dan aplikasi mereka oleh penduduk. Desain terus berlangsung tidak hanya karena kami menambahkan yang baru ruangan untuk rumah, tetapi karena kami memperhatikan pengecatan ulang, mengganti karpet usang, atau peningkatandi wastafel dapur. Kebanyakan seni menggemakan sentimen analog. Dalam pencarian kami untuk orang lain yang menganggap rumah Allah sebagai bagian dari perincian, kita mendapati diri kita berada dalam perusahaan yang baik dari Penulis Perancis abad ke-19 Gustav Flaubert. Penyair Prancis Paul Valery menasihati kita bahwa a puisi tidak pernah dilakukan dan terus dikerjakan ulang, dan berhenti mengerjakannya adalah pengabaian. Keasyikan dengan detail seperti itu biasa terjadi pada semua upaya keunggulan. Jadi mungkin disana sedikit baru di sini, tetapi dalam membaca buku ini Anda akan ditantang untuk mengambil pelajaran yang baik Pline bahwa Anda lama menyerah pada apatis atau keinginan untuk spontanitas dan adil "Merespons perubahan." Sayangnya, kami biasanya tidak melihat keprihatinan seperti itu sebagai landasan utama seni pemrograman. Kami meninggalkan kode kami lebih awal, bukan karena itu dilakukan, tetapi karena nilai kami sistem lebih berfokus pada penampilan luar daripada pada substansi dari apa yang kami berikan.
www.it-ebooks.info
https://translate.googleusercontent.com/translate_f
17/365
3/12/2020
www.it-ebooks.info
Halaman 23
xxii
Kata pengantar
Ketidakpedulian ini pada akhirnya membuat kita rugi: Satu sen yang buruk selalu muncul . Penelitian, baik dalam industri maupun dalam dunia akademis, merendahkan diri ke stasiun rendah menjaga kode bersih. Kembali di hari-hari saya bekerja di organisasi Bell Labs Software Produksi Penelitian ( Production , memang!) kami memiliki beberapa temuan back-of-the-envelope yang menyarankan agar konsisten gaya indentasi adalah salah satu indikator yang paling signifikan secara statistik dari kepadatan bug yang rendah. Kami ingin itu arsitektur atau bahasa pemrograman atau gagasan tinggi lainnya harus menjadi penyebab kualitas; sebagai orang yang seharusnya profesionalisme berutang kepada penguasaan alat dan metode desain yang tinggi, kami merasa terhina oleh nilai bahwa pabrikmesin lantai, coders, menambahkan melalui aplikasi lekukan sederhana yang konsisten gaya. Mengutip buku saya sendiri 17 tahun yang lalu, gaya seperti itu membedakan keunggulan dari kompetensi belaka. Pandangan dunia Jepang memahami nilai penting dari kehidupan sehari-hari pekerja dan, lebih dari itu, sistem pembangunan yang berhutang kepada yang sederhana, setiap hari tindakan para pekerja itu. Kualitas adalah hasil dari jutaan tindakan perawatan tanpa pamrih — bukan hanya dari metode hebat apa pun yang turun dari surga. Bahwa tindakan ini sederhana tidak berarti bahwa mereka sederhana, dan itu tidak berarti bahwa mereka mudah. Meskipun demikian mereka adalah jalinan kebesaran dan, lebih lagi, keindahan, dalam setiap usaha manusia. Mengabaikan mereka tidak belum sepenuhnya manusia. Tentu saja, saya masih seorang penganjur pemikiran pada ruang lingkup yang lebih luas, dan khususnya dari nilai pendekatan arsitektur yang berakar pada pengetahuan domain yang mendalam dan kegunaan perangkat lunak. Buku ini bukan tentang itu — atau, paling tidak, tidak jelas tentang itu. Buku ini lebih subtil pesan yang kedalamannya tidak boleh dihargai terlalu rendah. Cocok dengan gergaji saat ini dari orang-orang yang benar-benar berbasis kode seperti Peter Sommerlad, Kevlin Henney dan Giovanni Asproni. "Kode adalah desain" dan "Kode sederhana" adalah mantra mereka. Padahal kita harus ingatlah bahwa antarmuka adalah program, dan strukturnya memiliki banyak untuk mengatakan tentang struktur program kami, sangat penting untuk terus mengadopsi sikap rendah hati bahwa desain hidup dalam kode. Dan sementara pengerjaan ulang dalam metafora manufaktur mengarah ke biaya, pengerjaan ulang desain mengarah pada nilai. Kita harus melihat kode kita sebagai artikulasi yang indah upaya mulia desain — desain sebagai proses, bukan titik akhir statis. Ada dalam kode itu metrik arsitektur kopling dan kohesi dimainkan. Jika Anda mendengarkan Larry ConstanUntuk mendeskripsikan kopling dan kohesi, ia berbicara dalam hal kode — bukan konsep abstrak yang tinggi kecuali yang mungkin ditemukan di UML. Richard Gabriel menasihati kami dalam esainya, “Abstraksi Descant ”bahwa abstraksi itu jahat. Kode adalah anti-kejahatan, dan kode yang bersih mungkin ilahi. Kembali ke kotak kecil saya Ga-Jol, saya pikir penting untuk dicatat bahwa Denmark kebijaksanaan menasihati kita tidak hanya untuk memperhatikan hal-hal kecil, tetapi juga jujur dalam hal kecil sesuatu. Ini berarti bersikap jujur pada kode, jujur kepada rekan kerja tentang keadaan kita kode dan, yang terpenting, jujur dengan diri kita sendiri tentang kode kita. Apakah kita melakukan yang terbaik untuk itu? "Meninggalkan perkemahan lebih bersih daripada yang kita temukan"? Apakah kita mem-re-faktor kode kita sebelum checkmasuk? Ini bukan kekhawatiran pinggiran tetapi kekhawatiran yang terletak tepat di tengah Nilai lincah. Merupakan praktik yang direkomendasikan dalam Scrum bahwa re-factoring menjadi bagian dari kecuali "Done." Baik arsitektur maupun kode bersih tidak menuntut kesempurnaan, hanya kejujuran dan melakukan yang terbaik yang kami bisa. Berbuat salah adalah manusia; untuk memaafkan, ilahi. Di Scrum, kami membuat hal yang terlihat. Kami mengangkut cucian kotor kami. Kami jujur tentang keadaan kode kami karena
www.it-ebooks.info
Halaman 24
Kata pengantar
xxiii
kode tidak pernah sempurna. Kita menjadi lebih manusiawi, lebih layak bagi yang ilahi, dan lebih dekat untuk kebesaran itu dalam detail. Dalam profesi kita, kita sangat membutuhkan semua bantuan yang bisa kita dapatkan. Jika lantai toko bersih
https://translate.googleusercontent.com/translate_f
18/365
3/12/2020
www.it-ebooks.info mengurangi kecelakaan, toko yang terorganisir meningkatkan produktivitas, maka saya siap mereka. Adapun buku ini,dan ituperalatan adalah aplikasi pragmatis terbaik dari prinsip Lean untuk perangkat lunak I untuk itu pernah lihat di media cetak. Saya berharap tidak kurang dari kelompok kecil yang praktis ini, indi- vidu video yang telah berjuang bersama selama bertahun-tahun tidak hanya untuk menjadi lebih baik, tetapi juga untuk hadiah pengetahuan mereka untuk industri dalam pekerjaan seperti sekarang Anda temukan di tangan Anda. Itu meninggalkan dunia sedikit lebih baik daripada yang saya temukan sebelum Paman Bob mengirimi saya naskah itu. Setelah menyelesaikan latihan ini dengan wawasan yang tinggi, saya pergi untuk membersihkan meja saya. James O. Coplien Mørdrup, Denmark
www.it-ebooks.info
Halaman 25
halaman ini sengaja dibiarkan kosong
https://translate.googleusercontent.com/translate_f
19/365
3/12/2020
www.it-ebooks.info
www.it-ebooks.info
Halaman 26
pengantar
ocus Shift
(c) 2008 F Direproduksi dengan izin dari Thom Holwerda. http://www.osnews.com/story/19266/WTFs_m
https://translate.googleusercontent.com/translate_f
20/365
3/12/2020
www.it-ebooks.info Pintu mana yang mewakili kode Anda? Pintu mana yang mewakili tim Anda atau perusahaan Anda? Kenapa kita ada di ruangan itu? Apakah ini hanya tinjauan kode normal atau kami telah menemukan aliran masalah mengerikan tak lama setelah ditayangkan? Apakah kita sedang debugging dalam panik, meneliti kode yang menurut kami berhasil? Apakah pelanggan pergi berbondong-bondong dan manajer bernafas
xxv www.it-ebooks.info
Halaman 27
xxvi
pengantar
leher kita? Bagaimana kita bisa memastikan bahwa kita berakhir di belakang pintu kanan ketika keadaan berjalan sulit? Jawabannya adalah: keahlian . Ada dua bagian untuk mempelajari keahlian: pengetahuan dan pekerjaan. Anda harus mendapatkan pengetahuan tentang prinsip, pola, praktik, dan heuristik yang diketahui oleh pengrajin, dan Anda juga harus menggiling pengetahuan itu ke jari, mata, dan usus Anda dengan bekerja keras dan berlatih. Saya bisa mengajari Anda fisika mengendarai sepeda. Memang, matematika klasik adalah relatif mudah. Gravitasi, gesekan, momentum sudut, pusat massa, dan sebagainya sebagainya, dapat ditunjukkan dengan kurang dari satu halaman penuh dengan persamaan. Mengingat rumus-rumus itu I bisa membuktikan kepada Anda bahwa mengendarai sepeda itu praktis dan memberi Anda semua pengetahuan Anda diperlukan untuk membuatnya bekerja. Dan Anda masih akan jatuh saat pertama kali naik sepeda itu. Pengkodean tidak berbeda. Kita bisa menuliskan semua prinsip bersih “enak” kode dan kemudian percaya Anda untuk melakukan pekerjaan (dengan kata lain, biarkan Anda jatuh ketika Anda melanjutkan sepeda), tetapi kemudian guru seperti apa yang membuat kita, dan siswa seperti apa apakah itu akan membuatmu? Tidak. Itu bukan cara buku ini akan bekerja. Belajar menulis kode yang bersih adalah kerja keras . Ini membutuhkan lebih dari sekedar pengetahuan prinsip dan pola. Anda harus berkeringat karenanya. Anda harus berlatih sendiri, dan menonton dirimu gagal. Anda harus melihat orang lain berlatih dan gagal. Anda harus melihat mereka tersandung dan menelusuri kembali langkah mereka. Anda harus melihat mereka menderita atas keputusan dan melihat harga yang mereka bayar membuat keputusan itu dengan cara yang salah. Bersiaplah untuk bekerja keras saat membaca buku ini. Ini bukan buku "merasa baik" itu Anda dapat membaca di pesawat terbang dan selesai sebelum mendarat. Buku ini akan membuat Anda bekerja, dan bekerja keras . Pekerjaan apa yang akan Anda lakukan? Anda akan membaca kode — banyak kode. Dan Anda akan ditantang untuk berpikir tentang apa yang benar tentang kode itu dan apa yang salah dengan itu. Anda akan diminta untuk mengikuti saat kami memisahkan modul dan mengembalikannya bersama lagi. Ini akan membutuhkan waktu dan usaha; tapi kami pikir itu akan sia-sia. Kami telah membagi buku ini menjadi tiga bagian. Beberapa bab pertama menjelaskan prinsip-prinsip tersebut. ciples, pola, dan praktik penulisan kode bersih. Ada sedikit kode di dalamnya bab, dan mereka akan sulit dibaca. Mereka akan mempersiapkan Anda untuk bagian kedua datang. Jika Anda meletakkan buku setelah membaca bagian pertama, semoga sukses untuk Anda! Bagian kedua dari buku ini adalah kerja keras. Ini terdiri dari beberapa studi kasus kompleksitas yang semakin meningkat. Setiap studi kasus adalah latihan membersihkan beberapa kode — dari mengubah kode yang memiliki beberapa masalah menjadi kode yang memiliki lebih sedikit masalah. Detail dalam bagian ini sangat intens . Anda harus bolak-balik antara narasi dan daftar kode. Anda harus menganalisis dan memahami kode yang sedang kami kerjakan dan berjalan melalui alasan kami untuk membuat setiap perubahan yang kami buat. Sisihkan waktu karena ini akan memakan waktu berhari-hari . Bagian ketiga dari buku ini adalah imbalannya. Ini adalah satu bab berisi daftar ristik dan aroma berkumpul saat membuat studi kasus. Saat kami berjalan melewati dan membersihkan kode dalam studi kasus, kami mendokumentasikan setiap alasan untuk tindakan kami sebagai a
www.it-ebooks.info
https://translate.googleusercontent.com/translate_f
21/365
3/12/2020
www.it-ebooks.info
Halaman 28
xxvii
pengantar
heuristik atau bau. Kami mencoba memahami reaksi kami sendiri terhadap kode yang kami baca dan berubah, dan bekerja keras untuk menangkap mengapa kami merasakan apa yang kami rasakan dan melakukan apa yang kami lakukan. Hasilnya adalah basis pengetahuan yang menggambarkan cara kita berpikir ketika kita menulis, membaca, dan kode bersih. Basis pengetahuan ini memiliki nilai terbatas jika Anda tidak melakukan pekerjaan membaca dengan cermat melalui studi kasus di bagian kedua buku ini. Dalam studi kasus tersebut kami memiliki sepenuhnya mencatat setiap perubahan yang kami buat dengan referensi ke depan ke heuristik. Ini untukreferensi lingkungan muncul dalam tanda kurung seperti ini: [H22]. Ini memungkinkan Anda melihat konteks di dimana heuristik itu diterapkan dan ditulis! Bukan heuristik itu sendiri sangat berharga, itu adalah hubungan antara heuristik dan keputusan-keputusan terpisah kita dibuat sambil membersihkan kode dalam studi kasus . Untuk lebih membantu Anda dengan hubungan-hubungan itu, kami telah menempatkan referensi silang di bagian akhir buku yang menunjukkan nomor halaman untuk setiap referensi maju. Anda dapat menggunakannya untuk melihat di setiap tempat di mana heuristik tertentu diterapkan. Jika Anda membaca bagian pertama dan ketiga dan melewatkan studi kasus, maka Anda akan melakukannya telah membaca buku "merasa baik" yang lain tentang menulis perangkat lunak yang baik. Tetapi jika Anda mengambil waktu untuk mengerjakan studi kasus, mengikuti setiap langkah kecil, setiap keputusan menit — jika Anda menempatkan diri Anda di tempat kami, dan memaksakan diri Anda untuk berpikir di jalan yang sama yang kita berpikir, maka Anda akan memperoleh pemahaman yang lebih kaya tentang prinsip, pola, praktik tices, dan heuristik. Mereka tidak akan menjadi "merasa baik" lagi. Mereka akan melakukannya tanah ke usus, jari, dan hati Anda. Mereka akan menjadi bagian dari Anda dengan cara yang sama bahwa sepeda menjadi perpanjangan dari keinginan Anda ketika Anda sudah menguasai cara mengendarainya.
Ucapan Terima Kasih Karya seni Terima kasih untuk dua artis saya, Jeniffer Kohnke dan Angela Brooks. Jennifer bertanggung jawab untuk gambar yang menakjubkan dan kreatif di awal setiap bab dan juga untuk potret dari Kent Beck, Ward Cunningham, Bjarne Stroustrup, Ron Jeffries, Grady Booch, Dave Thomas, Michael Feathers, dan saya sendiri. Angela bertanggung jawab atas gambar-gambar cerdas yang menghiasi jeroan setiap bab. Dia telah membuat beberapa foto untuk saya selama bertahun-tahun, termasuk banyak foto dalam. tures dalam Pengembangan Perangkat Lunak Agile: Prinsip, Pola, dan Praktik . Dia juga milikku anak sulung yang aku senang.
www.it-ebooks.info
Halaman 29
halaman ini sengaja dibiarkan kosong https://translate.googleusercontent.com/translate_f
22/365
3/12/2020
www.it-ebooks.info
www.it-ebooks.info
Halaman 30
Di Sampul Gambar di sampul M104: Galaksi Sombrero. M104 terletak di Virgo dan hanya di bawah 30 juta tahun cahaya dari kita. Pada intinya adalah lubang hitam supermasif berbobot masuk sekitar satu miliar massa matahari. Apakah gambar mengingatkan Anda tentang ledakan bulan kekuatan Klingon Praxis ? saya ingat dengan jelas adegan di Star Trek VI yang menunjukkan cincin puing-puing ekuatorial terbang jauh dari ledakan itu. Sejak adegan itu, cincin khatulistiwa telah menjadi artefak umum dalam ledakan film sci-fi. Itu bahkan ditambahkan ke ledakan Alderaan di edisi selanjutnya dari film Star Wars pertama. Apa yang menyebabkan cincin ini terbentuk di sekitar M104? Mengapa ia memiliki pusat yang sangat besar tonjolan dan nukleus yang terang dan sekecil itu? Bagiku itu tampak seperti lubang hitam tengah kehilangan kesejukannya dan meniup lubang 30.000 tahun cahaya di tengah galaksi. Celakalah menimpa siapa pun peradaban yang mungkin berada di jalur gangguan kosmik itu. Lubang hitam supermasif menelan seluruh bintang untuk makan siang, mengubah ukuran yang cukup besar. tion massa mereka menjadi energi. E = MC 2 cukup leverage, tetapi ketika M adalah massa bintang:
https://translate.googleusercontent.com/translate_f
23/365
3/12/2020
www.it-ebooks.info Mencari! Berapa banyak yang jatuh dengan cepat ke rahang itu sebelum monster itu kenyang? Mungkinkah ukuran pusatbintang batal menjadi petunjuk? Gambar M104 pada sampul adalah a kombinasi foto cahaya tampak yang terkenal tograph dari Hubble (kanan), dan yang terbaru gambar inframerah dari Spitzer yang mengorbit observatorium (di bawah, kanan). Itu infra merah gambar yang jelas menunjukkan kepada kita sifat cincin galaksi. Dalam cahaya tampak kita hanya melihat tepi depan cincin dalam siluet. Pusat tral tonjolan mengaburkan sisa cincin. Tetapi dalam inframerah, partikel panas masuk cincin bersinar melalui tonjolan pusat. Itu dua gambar digabungkan memberi kita pandangan kita sudah tidak terlihat sebelumnya dan menyiratkan bahwa sudah lama itu adalah aktivitas yang mengamuk.
Gambar sampul: © Spitzer Space Telescope
xxix www.it-ebooks.info
Halaman 31
halaman ini sengaja dibiarkan kosong
https://translate.googleusercontent.com/translate_f
24/365
3/12/2020
www.it-ebooks.info
www.it-ebooks.info
Halaman 32
1 Kode Bersih
Anda membaca buku ini karena dua alasan. Pertama, Anda seorang programmer. Kedua, kamu mau untuk menjadi programmer yang lebih baik. Baik. Kami membutuhkan programmer yang lebih baik.
1 www.it-ebooks.info
Halaman 33
https://translate.googleusercontent.com/translate_f
25/365
3/12/2020
www.it-ebooks.info 2
Bab 1: Kode Bersih
Ini adalah buku tentang pemrograman yang bagus. Itu diisi dengan kode. Kita akan melihat kode dari setiap arah yang berbeda. Kami akan melihat ke bawah dari atas, ke atas dari atas bawah, dan melewatinya dari dalam ke luar. Pada saat kita selesai, kita akan tahu a banyak tentang kode. Terlebih lagi, kami akan dapat membedakan antara kode yang baik dan yang buruk kode. Kami akan tahu cara menulis kode yang baik. Dan kita akan tahu bagaimana mengubah kode buruk menjadi kode yang baik.
Akan Ada Kode Orang mungkin berpendapat bahwa sebuah buku tentang kode entah bagaimana ketinggalan zaman — kode itu tidak lagi masalah; bahwa kita harus memperhatikan model dan persyaratan saja. Memang ada yang menyarankan agar kita mendekati akhir kode. Itu akan segera semua kode dihasilkan alih-alih ditulis. Programmer itu tidak diperlukan karena bisnis Orang-orang akan membuat program dari spesifikasi. Omong kosong! Kami tidak akan pernah terbebas dari kode, karena kode mewakili detail dari Persyaratan. Pada tingkat tertentu rincian itu tidak dapat diabaikan atau diabstraksikan; mereka harus ditentukan. Dan menentukan persyaratan secara rinci sehingga mesin dapat mengeksekusi mereka adalah pemrograman . Spesifikasi seperti itu adalah kode . Saya berharap bahwa tingkat abstraksi bahasa kita akan terus meningkat. saya juga berharap bahwa jumlah bahasa khusus domain akan terus bertambah. Ini akan menjadi hal yang baik. Tetapi itu tidak akan menghilangkan kode. Memang semua spesifikasi tertulis di level yang lebih tinggi dan bahasa khusus domain ini akan menjadi kode! Masih perlu menjadi ketat, akurat, dan begitu formal dan terperinci sehingga mesin dapat mengerti dan jalankan itu. Orang-orang yang berpikir bahwa kode suatu hari akan menghilang seperti ahli matematika yang berharap suatu hari menemukan matematika yang tidak harus formal. Mereka berharap bahwa suatu hari kita akan menemukan cara untuk membuat mesin yang bisa melakukan apa yang kita inginkan dari apa yang kita katakan. Mesin-mesin ini harus dapat memahami kita dengan baik sehingga mereka dapat menerjemahkan kebutuhan yang secara samar-samar ditentukan ke dalam program yang menjalankan dengan sempurna yang secara tepat memenuhi kebutuhan itu. Ini tidak akan pernah terjadi. Bahkan manusia, dengan semua intuisi dan kreativitas mereka, telah mampu menciptakan sistem yang sukses dari perasaan samar pelanggan mereka. Memang, jika disiplin spesifikasi persyaratan telah mengajarkan kita sesuatu, itu adalah itu persyaratan yang ditentukan dengan baik adalah seformal kode dan dapat bertindak sebagai tes yang dapat dieksekusi untuk itu kode! Ingat kode itu benar-benar bahasa di mana kita pada akhirnya mengekspresikan KASIH. Kami dapat membuat bahasa yang lebih dekat dengan persyaratan. Kami dapat membuat alat yang membantu kami mengurai dan mengumpulkan persyaratan tersebut ke dalam struktur formal. Tapi kita akan melakukannya jangan pernah menghilangkan presisi yang diperlukan — jadi selalu ada kode.
www.it-ebooks.info
Halaman 34
Kode yang salah
3
Kode yang salah Saya baru-baru ini membaca kata pengantar untuk Kent Beck Pola Implementasi buku . 1 Dia berkata, “. . . ini Buku ini didasarkan pada premis yang agak rapuh: itu masalah kode yang baik. . . . " Sebuah rapuh premis? Saya menemukan setuju! Saya pikir premis adalah yang paling banyak kuat, didukung, dan kelebihan dari semua pramises di kerajinan kami (dan saya pikir Kent tahu itu). Kita tahu hal-hal kode yang baik karena kita harus melakukannya berurusan begitu lama dengan kekurangannya. Saya tahu satu perusahaan bahwa, di akhir 80-an,
https://translate.googleusercontent.com/translate_f
26/365
3/12/2020
www.it-ebooks.info menulis aplikasi pembunuh . Itu sangat populer, dan banyak profesional membeli dan menggunakannya. Tapi kemudian siklus rilis mulai meregang. Bug tidak diperbaiki dari satu rilis ke yang berikutnya. Memuat kali tumbuh dan crash meningkat. Saya ingat hari saya mematikan produk dengan frustrasi dan tidak pernah menggunakannya lagi. Perusahaan gulung tikar waktu yang singkat setelah itu. Dua dekade kemudian saya bertemu dengan salah satu karyawan awal perusahaan itu dan bertanya kepadanya Apa yang sudah terjadi. Jawabannya menegaskan ketakutan saya. Mereka telah bergegas produk ke pasar dan telah membuat kekacauan besar dalam kode. Ketika mereka menambahkan lebih banyak fitur, the kode semakin buruk sampai mereka tidak bisa mengelolanya lagi. Itu yang buruk kode yang menjatuhkan perusahaan. Pernahkah Anda secara signifikan terhambat oleh kode yang buruk? Jika Anda seorang programmer setiap pengalaman maka Anda sudah merasakan kesulitan ini berkali-kali. Memang, kami punya nama untuk Itu. Kami menyebutnya mengarungi . Kami mengarungi kode buruk. Kami bekerja keras melalui tumpukan kusut semak duri dan perangkap tersembunyi. Kami berjuang untuk menemukan jalan kami, berharap untuk beberapa petunjuk, beberapa petunjuk, tentang apa yang sedang terjadi; tetapi yang kita lihat adalah kode yang semakin tidak masuk akal. Tentu saja Anda terhambat oleh kode yang buruk. Jadi — mengapa Anda menulisnya? Apakah Anda mencoba untuk berpuasa? Apakah Anda terburu-buru? Mungkin begitu. Mungkin Anda merasakannya tidak punya waktu untuk melakukan pekerjaan dengan baik; bahwa bos Anda akan marah kepada Anda jika Anda mengambil waktu untuk membersihkan kode Anda. Mungkin Anda hanya lelah mengerjakan program ini dan ingin semuanya berakhir. Atau mungkin Anda melihat tumpukan barang-barang lain yang telah Anda promosikan ingin menyelesaikan dan menyadari bahwa Anda perlu membanting modul ini bersama sehingga Anda bisa beralih ke yang berikutnya. Kita semua sudah melakukannya. Kita semua telah melihat kekacauan yang baru saja kita buat dan kemudian memilih untuk membiarkannya hari yang lain. Kita semua merasa lega melihat program berantakan kami bekerja dan memutuskan bahwa a
1. [Beck07].
www.it-ebooks.info
Halaman 35
4
Bab 1: Kode Bersih
kekacauan kerja lebih baik daripada tidak sama sekali. Kita semua mengatakan kita akan kembali dan membersihkannya nanti. Dari Tentu saja, pada masa itu kita tidak tahu hukum LeBlanc: Nanti sama dengan tidak pernah .
Total Biaya Memiliki Mess Jika Anda telah menjadi programmer selama lebih dari dua atau tiga tahun, Anda mungkin sudah secara signifikan diperlambat oleh kode berantakan orang lain. Jika Anda seorang programmer selama lebih dari dua atau tiga tahun, Anda mungkin diperlambat oleh kode yang berantakan. Tingkat perlambatan bisa signifikan. Selama rentang satu atau dua tahun, tim itu bergerak sangat cepat pada awal proyek dapat menemukan diri mereka bergerak di siput kecepatan. Setiap perubahan yang mereka lakukan pada kode memecah dua atau tiga bagian lain dari kode. Tidak perubahan itu sepele. Setiap penambahan atau modifikasi pada sistem mensyaratkan bahwa kusut, tikungan, dan simpul menjadi "dimengerti" sehingga lebih banyak kusut, tikungan, dan simpul dapat ditambahkan. Seiring waktu kekacauan itu menjadi begitu besar dan begitu dalam dan begitu tinggi, mereka tidak dapat membersihkannya. Sana tidak mungkin sama sekali. Ketika kekacauan terjadi, produktivitas tim terus menurun, tanpa gejala mendekati nol. Ketika produktivitas menurun, manajemen melakukan satu-satunya hal yang mereka bisa; mereka menambah lebih banyak staf ke proyek dengan harapan meningkatkan produktivitas. Tetapi staf baru itu tidak berpengalaman dalam desain sistem. Mereka tidak tahu perbedaan antara perubahan yang cocok dengan maksud desain dan perubahan yang menggagalkan niat desain. Selanjutnya, mereka, dan semua orang di tim, berada di bawah tekanan mengerikan untuk meningkatkan produktivitas. Begitu mereka semua membuat semakin banyak kekacauan, mendorong produktivitas semakin jauh ke nol. (Lihat Gambar 1-1.)
https://translate.googleusercontent.com/translate_f
27/365
3/12/2020
www.it-ebooks.info
Gambar 1-1 Produktivitas vs waktu
www.it-ebooks.info
Halaman 36
Total Biaya Memiliki Mess
5
Grand Redesign in the Sky Akhirnya tim memberontak. Mereka memberi tahu manajemen bahwa mereka tidak dapat terus berkembang dalam basis kode najis ini. Mereka menuntut desain ulang. Manajemen tidak mau mengeluarkan sumber daya pada desain ulang proyek yang sama sekali baru, tetapi mereka tidak dapat menyangkal bahwa itu mengerikan. Akhirnya mereka tunduk pada tuntutan pengembang dan mengesahkan redesign besar di langit. Tim harimau baru dipilih. Semua orang ingin berada di tim ini karena ini adalah greenproyek lapangan. Mereka memulai dari awal dan menciptakan sesuatu yang benar-benar indah. Tapi hanya yang terbaik dan paling cerdas dipilih untuk tim harimau. Semua orang harus terus mempertahankan sistem saat ini. Sekarang kedua tim berlomba. Tim harimau harus membangun sistem baru yang berfungsi semua yang dilakukan sistem lama. Tidak hanya itu, mereka harus mengikuti perubahan yang terus menerus dibuat untuk sistem yang lama. Manajemen tidak akan menggantikan yang lama sistem hingga sistem baru dapat melakukan semua yang dilakukan sistem lama. Perlombaan ini bisa berlangsung sangat lama. Saya telah melihatnya memakan waktu 10 tahun. Dan pada saat itu Setelah selesai, anggota asli tim harimau sudah lama hilang, dan anggota saat ini sudah menuntut agar sistem baru dirancang ulang karena berantakan. Jika Anda pernah mengalami satu bagian kecil saja dari kisah yang baru saja saya ceritakan, maka Anda sudah melakukannya tahu bahwa menghabiskan waktu menjaga kode Anda tetap bersih bukan hanya hemat biaya; ini masalah kelangsungan hidup profesional.
Sikap Pernahkah Anda mengarungi kekacauan yang begitu parah sehingga butuh berminggu-minggu untuk melakukan apa yang seharusnya diambil jam? Pernahkah Anda melihat apa yang seharusnya menjadi perubahan satu baris, yang dibuat sebagai gantinya ratusan modul berbeda? Gejala-gejala ini terlalu umum. Mengapa ini terjadi pada kode? Mengapa kode yang baik membusuk dengan begitu cepat menjadi kode yang buruk? Kita punya banyak penjelasan untuk itu. Kami mengeluh bahwa persyaratannya berubah dengan cara itu menggagalkan desain aslinya. Kami meratapi jadwal yang terlalu ketat untuk melakukan hal yang benar. Kami ngobrol tentang manajer bodoh dan pelanggan tidak toleran serta tipe pemasaran yang tidak berguna dan pembersih telepon. Tapi kesalahannya, Dilbert sayang, bukan di bintang kita, tapi di diri kita sendiri. Kami tidak profesional. Ini mungkin pil pahit yang harus ditelan. Bagaimana kekacauan ini bisa menjadi kesalahan kita ? Bagaimana tentang Persyaratan? Bagaimana dengan jadwalnya? Bagaimana dengan manajer bodoh dan tidak berguna tipe pemasaran? Bukankah mereka yang harus disalahkan? Tidak Manajer dan pemasar melihat ke kami untuk informasi yang mereka perlu untuk membuat janji dan komitmen; dan bahkan ketika mereka tidak memandang kita, kita seharusnya tidak malu tentang memberi tahu mereka apa yang kita pikirkan. Pengguna mencari kami untuk memvalidasi cara persyaratan akan masuk ke dalam sistem. Manajer proyek mencari kami untuk membantu menyelesaikan jadwal. Kita
https://translate.googleusercontent.com/translate_f
28/365
3/12/2020
www.it-ebooks.info www.it-ebooks.info
Halaman 37
6
Bab 1: Kode Bersih
sangat terlibat dalam perencanaan proyek dan berbagi banyak tanggung jawab bility untuk setiap kegagalan; terutama jika kegagalan itu ada hubungannya dengan kode buruk! "Tapi tunggu!" kamu bilang. "Jika saya tidak melakukan apa yang dikatakan manajer saya, saya akan dipecat." Mungkin tidak. Kebanyakan manajer menginginkan kebenaran, bahkan ketika mereka tidak bertindak seperti itu. Kebanyakan manajer menginginkan yang baik kode, bahkan ketika mereka terobsesi dengan jadwal. Mereka dapat mempertahankan jadwal dan persyaratan dengan hasrat; tapi itu tugas mereka. Adalah tugas Anda untuk mempertahankan kode dengan setara gairah. Untuk mengantar titik ini pulang, bagaimana jika Anda seorang dokter dan memiliki seorang pasien yang menuntut bahwa Anda menghentikan semua cuci tangan konyol sebagai persiapan untuk operasi karena itu mengambil terlalu banyak waktu? 2 Jelas bahwa pasien adalah bos; namun dokter harus menolak sama sekali untuk memenuhi. Mengapa? Karena dokter tahu lebih banyak daripada pasien tentang risiko penyakit kemudahan dan infeksi. Akan tidak profesional (apalagi kriminal) bagi dokter patuhi pasien. Demikian juga tidak profesional bagi programmer untuk tunduk pada kehendak manajer yang tidak memahami risiko membuat kekacauan.
The Primal Conundrum Programmer menghadapi teka-teki nilai-nilai dasar. Semua pengembang dengan lebih dari beberapa tahun Pengalaman tahu bahwa kekacauan sebelumnya memperlambatnya. Namun semua pengembang merasakannya tekanan untuk membuat kekacauan agar memenuhi tenggat waktu. Singkatnya, mereka tidak meluangkan waktu untuk pergi cepat! Para profesional sejati tahu bahwa bagian kedua dari teka-teki itu salah. Kamu tidak akan membuat batas waktu dengan membuat kekacauan. Memang, kekacauan akan memperlambat Anda secara instan, dan akan memaksa Anda untuk melewatkan tenggat waktu. Satu- satunya cara untuk membuat tenggat waktu — satu-satunya cara untuk bertindak cepat — adalah menjaga kode sebersih mungkin setiap saat.
Seni Kode Bersih? Katakanlah Anda percaya bahwa kode berantakan adalah hambatan yang signifikan. Katakanlah Anda menerima bahwa satu-satunya cara untuk bertindak cepat adalah menjaga kode Anda tetap bersih. Maka Anda harus bertanya pada diri sendiri: "Bagaimana saya harus menulis kode bersih? " Tidak ada gunanya mencoba menulis kode bersih jika Anda tidak tahu apa itu berarti kode menjadi bersih! Berita buruknya adalah bahwa menulis kode bersih sangat mirip dengan melukis gambar. Kebanyakan dari kami tahu kapan gambar dilukis dengan baik atau buruk. Tapi bisa mengenali seni yang bagus dari buruk bukan berarti kita tahu cara melukis. Jadi terlalu bisa mengenali kode bersih dari kode kotor tidak berarti kita tahu cara menulis kode bersih!
2. Ketika mencuci tangan pertama kali direkomendasikan kepada dokter oleh Ignaz Semmelweis pada tahun 1847, itu ditolak atas dasar bahwa dokter terlalu sibuk dan tidak punya waktu untuk mencuci tangan di antara kunjungan pasien.
www.it-ebooks.info
Halaman 38
Total Biaya Memiliki Mess
https://translate.googleusercontent.com/translate_f
7
29/365
3/12/2020
www.it-ebooks.info Menulis kode yang bersih membutuhkan penggunaan berbagai teknik kecil secara disiplin melalui rasa “kebersihan” yang diperoleh dengan susah payah. "Kode-akal" ini adalah kuncinya. Beberapa dari kita dilahirkan dengan itu. Sebagian dari kita harus berjuang untuk mendapatkannya. Tidak hanya membiarkannya melihat apakah kode itu baik atau buruk, tetapi juga menunjukkan kepada kita strategi untuk menerapkan pline untuk mengubah kode buruk menjadi kode bersih. Seorang programmer tanpa "code-sense" dapat melihat modul yang berantakan dan mengenali berantakan tetapi tidak tahu harus berbuat apa tentang hal itu. Seorang programmer dengan "code-sense" akan terlihat pada modul yang berantakan dan lihat opsi dan variasi. "Kode-akal" akan membantu programmer memilih variasi terbaik dan membimbingnya untuk merencanakan urutan perilaku melestarikan transformasi untuk pergi dari sini ke sana. Singkatnya, seorang programmer yang menulis kode bersih adalah seorang seniman yang dapat mengambil layar kosong melalui serangkaian transformasi hingga menjadi sistem kode yang elegan.
Apa itu Kode Bersih? Mungkin ada definisi sebanyak yang ada programmer. Jadi saya bertanya beberapa pemrogram terkenal dan sangat berpengalaman apa yang mereka pikirkan. Bjarne Stroustrup, penemu C ++ dan penulis Pemrograman C ++ Bahasa Saya suka kode saya menjadi elegan dan efisien. Itu Logika harus mudah untuk membuatnya sulit untuk menyembunyikan bug, ketergantungan minimal perawatan mudah, penanganan kesalahan selesai sesuai dengan strategi yang diartikulasikan, dan kinerja dekat dengan optimal agar tidak menggoda orang membuat kode berantakan dengan unsincimohon optimasi. Kode bersih melakukan satu hal baik.
Bjarne menggunakan kata "elegan." Itu cukup kata! Kamus di MacBook ® saya memberikan definisi berikut: menyenangkan anggun dan bergaya dalam penampilan atau cara; cerdik dan sederhana. Perhatikan penekanan pada kata "menyenangkan." Rupanya Bjarne berpikir bahwa kode yang bersih adalah menyenangkan untuk Baca. Membacanya seharusnya membuat Anda tersenyum seperti kotak musik yang dirancang dengan baik atau dirancang dengan baik mobil akan. Bjarne juga menyebutkan efisiensi— dua kali . Mungkin ini seharusnya tidak mengejutkan kita datang dari penemu C ++; tapi saya pikir ada lebih dari keinginan belaka untuk kecepatan. Siklus yang terbuang tidak tepat, mereka tidak menyenangkan. Dan sekarang perhatikan kata yang digunakan Bjarne
www.it-ebooks.info
Halaman 39
8
Bab 1: Kode Bersih
untuk menggambarkan konsekuensi dari ketidakmampuan itu. Dia menggunakan kata "godaan." Ada yang dalam kebenaran di sini. Kode buruk menggoda kekacauan untuk tumbuh! Ketika orang lain mengubah kode buruk, mereka cenderung membuatnya lebih buruk. Pragmatis Dave Thomas dan Andy Hunt mengatakan ini dengan cara yang berbeda. Mereka menggunakan meta jendela rusak. 3 Bangunan dengan jendela pecah sepertinya tidak ada yang peduli Itu. Jadi orang lain berhenti peduli. Mereka memungkinkan lebih banyak jendela menjadi rusak. Akhirnya mereka secara aktif melanggarnya. Mereka merusak fasad dengan grafiti dan membiarkan sampah mengumpul. lect. Satu jendela yang rusak memulai proses menuju pembusukan. Bjarne juga menyebutkan bahwa penyerahan kesalahan harus lengkap. Ini pergi ke disk Pline memperhatikan detail. Penanganan kesalahan singkat adalah salah satu cara yang menyediakan grammers mengabaikan detail. Kebocoran memori adalah hal lain, kondisi balapan masih merupakan hal lain. Penamaan tidak konsisten lagi. Hasilnya adalah bahwa kode bersih menunjukkan perhatian detail. Bjarne menutup dengan pernyataan bahwa kode bersih melakukan satu hal dengan baik. Itu bukan kecelakaan bahwa ada begitu banyak prinsip desain perangkat lunak yang dapat dirubah menjadi sederhana ini peringatan. Penulis demi penulis telah mencoba mengomunikasikan pemikiran ini. Kode yang salah coba dilakukan
https://translate.googleusercontent.com/translate_f
30/365
3/12/2020
www.it-ebooks.info terlalu itu telahkelas, mengacaukan niat dan ambiguitas tujuan. Kodepikiran bersihyang terfokus fungsi, banyak, masing-masing setiap modul memperlihatkan sikap satu tetap. Setiap sepenuhnya tidak terganggu, dan tidak terpolusi, oleh detail di sekitarnya. Grady Booch, penulis Object Analisis dan Desain Berorientasi dengan Aplikasi Kode bersih itu sederhana dan langsung. Kode bersih berbunyi seperti prosa yang ditulis dengan baik. Kode bersih tidak pernah mengaburkan niat desainer melainkan penuh abstraksi renyah dan garis lurus kontrol.
Grady membuat beberapa poin yang sama dengan Bjarne, tapi dia mengambil perspektif keterbacaan . saya terutama suka pandangannya bahwa kode bersih seharusnya membaca seperti prosa yang ditulis dengan baik. Pikirkan kembali pada a buku yang sangat bagus yang pernah Anda baca. Ingat bagaimana kata-kata itu hilang untuk diganti oleh gambar! Itu seperti menonton film, bukan? Lebih baik! Anda melihat karakter, Anda mendengar suara, Anda mengalami kesedihan dan humor. Membaca kode yang bersih tidak akan pernah seperti membaca Lord of the Rings . Namun, liter Bukan metafora yang buruk. Seperti novel yang bagus, kode bersih harus dengan jelas memaparkan dalam masalah yang harus dipecahkan. Itu harus membangun ketegangan itu sampai klimaks dan kemudian memberi
3. http://www.pragmaticprogrammer.com/booksellers/2004-12.html
www.it-ebooks.info
Halaman 40
Total Biaya Memiliki Mess
9
pembaca bahwa "Aha! Tentu saja!" karena masalah dan ketegangan diselesaikan dalam wahyu solusi yang jelas. Saya menemukan penggunaan Grady dari frasa "abstraksi renyah" menjadi oxymoron yang menarik! Lagi pula kata "crisp" hampir merupakan sinonim untuk "concrete." Kamus MacBook saya memegang definisi berikut tentang "garing": cepat menentukan dan soal fakta, tanpa terburu-buru tasi atau detail yang tidak perlu. Meskipun ini tampak penjajaran makna, kata-kata membawa pesan yang kuat. Kode kita harus benar-benar bertentangan dengan spekulatif. Seharusnya hanya berisi apa yang diperlukan. Pembaca kita harus menganggap kita telah menentukan. "Besar" Dave Thomas, pendiri OTI, ayah baptis Strategi gerhana Kode bersih dapat dibaca, dan ditingkatkan dengan a pengembang selain penulis aslinya. Memiliki tes unit dan penerimaan. Ini memiliki makna nama. Ini memberikan satu cara daripada banyak cara untuk melakukan satu hal. Ini memiliki ketergantungan minimal yang didefinisikan secara eksplisit, dan memberikan API yang jelas dan minimal. Kode seharusnya melek karena tergantung pada bahasanya, tidak semua informasi yang diperlukan dapat diungkapkan dengan jelas dalam kode saja.
Big Dave berbagi keinginan Grady untuk keterbacaandengan sentuhan yang penting. Dave menegaskan itu kode bersih memudahkan orang lain untuk meningkatkannya. Ini mungkin tampak jelas, tetapi bisatidak terlalu ditekankan. Lagi pula, ada perbedaan antara kode yang mudah dibaca dan kode yang mudah diubah. Dave mengikat kebersihan dengan ujian! Sepuluh tahun yang lalu ini akan mengangkat banyak alis. Tetapi disiplin Pengembangan yang Didorong Uji Coba telah memberikan dampak mendalam pada kami industri dan telah menjadi salah satu disiplin ilmu kami yang paling mendasar. Dave benar. Kode, tanpa tes, tidak bersih. Tidak peduli seberapa elegan itu, tidak peduli seberapa mudah dibaca dan accessible, jika tidak ada ujian, itu najis.
https://translate.googleusercontent.com/translate_f
31/365
3/12/2020
www.it-ebooks.info Dave menggunakan kata minimal dua kali. Tampaknya dia menghargai kode yang kecil daripada kode yang besar. Memang, ini telah menjadi pengulangan yang umum di seluruh literatur perangkat lunak mulai sejak awal. Lebih kecil lebih baik. Dave juga mengatakan kode itu harus melek . Ini adalah referensi lembut untuk melek huruf Knuth pemrograman. 4 Hasilnya adalah bahwa kode harus dibuat sedemikian rupa untuk membuatnya itu bisa dibaca oleh manusia.
4. [Knuth92].
www.it-ebooks.info
Halaman 41
10
Bab 1: Kode Bersih
Michael Feathers, penulis buku Working Efektif dengan Kode Legacy Saya bisa mendaftar semua kualitas yang saya perhatikan kode bersih, tetapi ada satu kualitas menyeluruh yang mengarah pada mereka semua. Selalu bersihkan kode Sepertinya itu ditulis oleh seseorang yang peduli. Tidak ada yang jelas yang bisa Anda lakukan membuatnya lebih baik. Semua hal itu dipikirkan tentang oleh penulis kode, dan jika Anda mencoba bayangkan peningkatan, Anda dituntun kembali ke di mana Anda berada, duduk dalam apresiasi terhadap kode seseorang yang tersisa untuk Anda — kode ditinggalkan oleh seseorangorang yang sangat peduli tentang kerajinan itu.
Satu kata: peduli. Itu benar-benar topik buku ini. Mungkin subtitle yang sesuai akan menjadi Cara Merawat Kode . Michael memukul kepalanya. Kode bersih adalah kode yang telah diurus. Seseorang telah mengambil waktu untuk membuatnya sederhana dan teratur. Mereka telah memperhatikan detail dengan tepat. Mereka peduli. Ron Jeffries, penulis Extreme Programming Terpasang dan Pemrograman Ekstrim Petualangan di C # Ron memulai pemrograman kariernya di Fortran di Komando Udara Strategis dan memiliki kode tertulis di hampir setiap bahasa dan hampir setiap bahasa mesin. Membayar untuk mempertimbangkan kata-katanya dengan hati-hati. Dalam beberapa tahun terakhir saya mulai, dan hampir berakhir, dengan Beck aturan kode sederhana. Dalam urutan prioritas, kode sederhana: • Menjalankan semua tes; • Tidak mengandung duplikasi; • Mengungkapkan semua ide desain yang ada di sistem; • Meminimalkan jumlah entitas seperti kelas, metode, fungsi, dan sejenisnya. Dari jumlah tersebut, saya lebih fokus pada duplikasi. Ketika hal yang sama dilakukan berulang-ulang, itu pertanda bahwa ada ide di benak kita yang tidak terwakili dengan baik dalam kode. saya mencoba untuk mencari tahu apa itu. Kemudian saya mencoba untuk mengekspresikan ide itu dengan lebih jelas. Ekspresivitas kepada saya termasuk nama yang bermakna, dan saya cenderung mengubah nama-nama beberapa kali sebelum saya menetap. Dengan alat pengkodean modern seperti Eclipse, mengganti nama cukup murah, jadi tidak masalah bagiku untuk berubah. Ekspresivitas berjalan
www.it-ebooks.info
https://translate.googleusercontent.com/translate_f
32/365
3/12/2020
www.it-ebooks.info
Halaman 42
11
Total Biaya Memiliki Mess
di luar nama, namun. Saya juga melihat apakah suatu objek atau metode melakukan lebih dari satu benda. Jika itu adalah objek, mungkin perlu dipecah menjadi dua atau lebih objek. Jika a metode, saya akan selalu menggunakan refactoring Metode Ekstrak di atasnya, menghasilkan satu metode yang mengatakan lebih jelas apa yang dilakukannya, dan beberapa submethod mengatakan bagaimana hal itu dilakukan. Duplikasi dan ekspresif membawa saya sangat jauh ke apa yang saya anggap bersih kode, dan meningkatkan kode kotor hanya dengan dua hal ini dalam pikiran dapat membuat perbedaan besar ence. Namun, ada satu hal lain yang saya sadari lakukan, yang agak sulit untuk dilakukan menjelaskan. Setelah bertahun-tahun melakukan pekerjaan ini, tampaknya bagi saya bahwa semua program terdiri dari sangat elemen serupa. Salah satu contoh adalah "menemukan barang-barang dalam koleksi." Apakah kita memiliki databasis catatan karyawan, atau peta hash kunci dan nilai, atau serangkaian item baik, kita sering menemukan diri kita menginginkan barang tertentu dari koleksi itu. Ketika saya menemukan yang terjadi, saya akan sering membungkus implementasi tertentu dalam metode yang lebih abstrak atau kelas. Itu memberi saya beberapa keuntungan menarik. Saya dapat mengimplementasikan fungsi sekarang dengan sesuatu yang sederhana, katakanlah peta hash, tetapi karena sekarang semua referensi untuk pencarian itu ditutupi oleh abstraksi kecilku, aku bisa ubah implementasi kapan saja saya mau. Saya bisa maju dengan cepat sambil menjaga kemampuan untuk berubah nanti. Selain itu, koleksi abstraksi sering menarik perhatian saya pada apa yang “sebenarnya” terjadi, dan membuat saya tidak berjalan di jalur menerapkan pengumpulan sewenang-wenang perilaku ketika yang benar-benar saya butuhkan adalah beberapa cara yang cukup sederhana untuk menemukan apa yang saya inginkan. Mengurangi duplikasi, ekspresif tinggi, dan membangun awal abstraksi sederhana. Itulah yang membuat kode bersih untuk saya.
Di sini, dalam beberapa paragraf pendek, Ron telah meringkas isi buku ini. Tidak duplikasi, satu hal, ekspresif, abstraksi kecil. Semuanya ada di sana. Ward Cunningham, penemu Wiki, penemu Fit, coinventor dari eXtreme Pemrograman Kekuatan motif di belakang Pola desain. Smalltalk dan OO pemimpin pemikiran. Ayah baptis semua mereka yang peduli tentang kode. Anda tahu Anda sedang mengerjakan kode bersih ketika masing-masing rutin yang Anda baca ternyata cukup banyak apa kamu diharapkan. Anda bisa menyebutnya kode cantik saat kode tersebut juga membuatnya terlihat seperti bahasanya dibuat untuk masalah ini.
Pernyataan seperti ini adalah karakteristik Ward. Anda membacanya, menganggukkan kepala, dan kemudian pergi ke topik selanjutnya. Kedengarannya masuk akal, begitu jelas, sehingga nyaris tidak terdaftar sebagai sesuatu mendalam. Anda mungkin berpikir itu seperti yang Anda harapkan. Tapi mari kita lihat lebih dekat Lihat.
www.it-ebooks.info
Halaman 43
12
Bab 1: Kode Bersih
“. . . cukup banyak apa yang Anda harapkan. " Kapan terakhir kali Anda melihat modul itu cukup banyak apa yang Anda harapkan? Bukankah lebih mungkin bahwa modul yang Anda lihat akan membingungkan, rumit, kusut? Bukankah penyesatan aturan? Apakah Anda tidak terbiasa memukul-mukul tentang mencoba untuk meraih dan memegang benang pemikiran yang memuntahkan dari seluruh sistem-
https://translate.googleusercontent.com/translate_f
33/365
3/12/2020
www.it-ebooks.info tem dan menenun jalan mereka melalui modul yang Anda baca? Kapan terakhir kali Anda baca beberapa kode dan menganggukkan kepala Anda seperti Anda mungkin menganggukkan kepala pada pernyataan Ward? Ward berharap bahwa ketika Anda membaca kode bersih Anda tidak akan terkejut sama sekali. Memang kamu bahkan tidak akan mengeluarkan banyak usaha. Anda akan membacanya, dan itu akan menjadi apa yang Anda baca diharapkan. Itu akan jelas, sederhana, dan menarik. Setiap modul akan mengatur panggung untuk selanjutnya. Masing-masing memberi tahu Anda bagaimana selanjutnya akan ditulis. Program yang yang bersih begitu ditulis dengan sangat baik sehingga Anda bahkan tidak menyadarinya. Perancang membuatnya tampak ridicusangat sederhana seperti semua desain luar biasa. Dan bagaimana dengan gagasan kecantikan Ward? Kita semua mencerca kenyataan bahwa bahasa kita gauge tidak dirancang untuk masalah kita. Tetapi pernyataan Ward menempatkan tanggung jawab pada kita. Dia mengatakan bahwa kode yang indah membuat bahasa terlihat seperti itu dibuat untuk masalah ! Begitu adalah tanggung jawab kami untuk membuat bahasa terlihat sederhana! Bahasa fanatik di mana-mana, Waspadalah! Bukan bahasa yang membuat program tampak sederhana. Itu adalah programmer yang membuat bahasa tampak sederhana!
Sekolah Pemikiran Bagaimana dengan saya (Paman Bob)? Apa yang saya pikirkan? kode bersih itu? Buku ini akan memberitahu Anda, dalam persembunyian detail, apa yang saya dan rekan saya pikirkan kode bersih. Kami akan memberi tahu Anda apa yang menurut kami dibuat nama variabel bersih, fungsi bersih, bersih kelas, dll. Kami akan menyajikan opini ini sebagai berikut kecut, dan kami tidak akan meminta maaf atas langkah kami. Bagi kami, pada saat ini dalam karir kita, mereka adalah mutlakkecapi. Mereka adalah sekolah pemikiran kita tentang bersih kode. Seniman bela diri tidak semua setuju tentang yang terbaik seni bela diri, atau teknik terbaik dalam bela diri seni. Seringkali menguasai seniman bela diri akan membentuk mereka memiliki sekolah pemikiran dan mengumpulkan siswa untuk belajar dari mereka. Jadi kita melihat Gracie Jiu Jistu , didirikan dan diajarkan oleh keluarga Gracie di Brasil. Kita melihat Hakkoryu Jiu Jistu , didirikan dan diajarkan oleh Okuyama Ryuho di Tokyo. Kita melihat Jeet Kune Do , didirikan dan diajar oleh Bruce Lee di Amerika Serikat.
www.it-ebooks.info
Halaman 44
Kami Adalah Penulis
13
Siswa dari pendekatan ini membenamkan diri dalam ajaran pendiri. Mereka mendedikasikan diri mereka untuk mempelajari apa yang diajarkan oleh guru tertentu itu, sering kali kepada Sion dari ajaran master lainnya. Kemudian, ketika siswa tumbuh dalam seni mereka, mereka mungkin menjadi siswa dari master yang berbeda sehingga mereka dapat memperluas pengetahuan dan praktik mereka. Beberapa akhirnya melanjutkan untuk memperbaiki keterampilan mereka, menemukan teknik baru dan menemukan keterampilan mereka sekolah sendiri. Tak satu pun dari sekolah yang berbeda ini benar-benar benar . Namun di sekolah tertentu kita bertindak seolah-olah ajaran dan teknik yang tepat. Bagaimanapun, ada cara yang tepat untuk kutu Hakkoryu Jiu Jitsu, atau Jeet Kune Do. Tetapi kebenaran di dalam sekolah ini tidak invalidate pengajaran dari sekolah yang berbeda. Anggap buku ini sebagai deskripsi Object Mentor School of Clean Code . Itu teknik dan ajaran di dalam adalah cara kita mempraktikkan seni kita . Kami bersedia mengklaim bahwa jika Anda mengikuti ajaran ini, Anda akan menikmati manfaat yang telah kami nikmati, dan Anda akan belajar menulis kode yang bersih dan profesional. Tapi jangan membuat kesalahan berpikir bahwa kita entah bagaimana "benar" dalam arti absolut. Ada sekolah lain dan tuan-tuan lain yang sama-sama mengklaim profesionalisme sama seperti kita. Itu akan membawamu untuk belajar dari mereka juga. Memang, banyak rekomendasi dalam buku ini kontroversial. Anda akan bly tidak setuju dengan mereka semua. Anda mungkin sangat tidak setuju dengan beberapa dari mereka. Tidak apa-apa. Kami tidak dapat mengklaim otoritas final. Di sisi lain, rekomendasi dalam buku ini adalah hal-hal yang telah lama kita pikirkan dan pikirkan. Kami telah mempelajarinya selama beberapa dekade
https://translate.googleusercontent.com/translate_f
34/365
3/12/2020
www.it-ebooks.info pengalaman dan coba-coba berulang. Jadi apakah Anda setuju atau tidak, itu akan menjadi Sayang jika Anda tidak melihat, dan menghormati, sudut pandang kami.
Kami Adalah Penulis Bidang @author dari Javadoc memberi tahu kita siapa kita. Kami adalah penulis. Dan satu hal tentang penulis adalah bahwa mereka memiliki pembaca. Memang, penulis bertanggung jawab untuk berkomunikasi dengan baik dengan pembaca mereka. Lain kali Anda menulis sebaris kode, ingat Anda adalah seorang penulis, menulis untuk pembaca yang akan menilai upaya Anda. Anda mungkin bertanya: Berapa kode yang benar-benar dibaca? Tidak sebagian besar upaya dilakukan menulisnya? Apakah Anda pernah memutar ulang sesi edit? Di tahun 80-an dan 90-an kami memiliki editor seperti Emacs yang melacak setiap penekanan tombol. Anda bisa bekerja selama satu jam dan kemudian memainkan kembali keseluruhan Anda edit sesi seperti film kecepatan tinggi. Ketika saya melakukan ini, hasilnya sangat menarik. Mayoritas pemutaran sedang bergulir dan menavigasi ke modul lain! Bob memasuki modul. Dia menggulir ke bawah ke fungsi yang membutuhkan perubahan. Dia berhenti, mempertimbangkan pilihannya. Oh, dia menggulir ke atas modul untuk memeriksa inisialisasi variabel. Sekarang dia menggulir ke bawah dan mulai mengetik.
www.it-ebooks.info
Halaman 45
14
Bab 1: Kode Bersih
Ups, dia menghapus apa yang diketiknya! Dia mengetiknya lagi. Dia menghapusnya lagi! Dia mengetik setengah dari sesuatu yang lain tetapi kemudian menghapusnya! Dia menggulir ke bawah ke fungsi lain yang memanggil fungsi yang dia ubah untuk melihat bagaimana fungsinya dipanggil. Dia menggulung kembali dan mengetik kode yang baru saja dia hapus. Dia berhenti. Dia menghapus kode itu lagi! Dia muncul jendela lain dan melihat subclass. Apakah fungsi itu ditimpa?
... Anda mengerti maksudnya. Memang, rasio waktu yang dihabiskan membaca dan menulis lebih dari 10: 1. Kami terus membaca kode lama sebagai bagian dari upaya untuk menulis kode baru. Karena rasio ini sangat tinggi, kami ingin pembacaan kode menjadi mudah, bahkan jika itu membuatnya penulisan lebih sulit. Tentu saja tidak ada cara untuk menulis kode tanpa membacanya, jadi membuatnya mudah dibaca sebenarnya membuatnya lebih mudah untuk menulis . Tidak ada jalan keluar dari logika ini. Anda tidak dapat menulis kode jika Anda tidak dapat membaca kode pembulatan. Kode yang Anda coba tulis hari ini akan sulit atau mudah untuk ditulis tergantung pada seberapa sulit atau mudah kode sekitarnya dibaca. Jadi jika Anda ingin cepat, jika Anda ingin cepat selesai, jika Anda ingin kode Anda mudah ditulis, buatlah mudah Baca.
Aturan Pramuka Tidak cukup menulis kode dengan baik. Kode harus tetap bersih seiring waktu. Kita semua kode terlihat membusuk dan menurun seiring waktu. Jadi kita harus mengambil peran aktif dalam mencegah hal ini degradasi. The Boy Scouts of America memiliki aturan sederhana yang dapat kita terapkan pada profesi kita. Tinggalkan perkemahan lebih bersih daripada yang Anda temukan. 5
Jika kita semua memeriksa kode kita sedikit lebih bersih daripada ketika kita memeriksanya, kodenya tidak bisa membusuk. Pembersihan tidak harus menjadi sesuatu yang besar. Ubah satu variabel nama untuk yang lebih baik, hancurkan satu fungsi yang sedikit terlalu besar, hilangkan satu sedikit duplikasi, bersihkan satu komposit jika pernyataan. Bisakah Anda bayangkan bekerja pada proyek di mana kode menjadi lebih baik seiring waktu berlalu? Apakah Anda yakin ada pilihan lain yang profesional? Memang, tidak berkelanjutan peningkatan bagian intrinsik dari profesionalisme?
https://translate.googleusercontent.com/translate_f
35/365
3/12/2020
www.it-ebooks.info
5. Ini diadaptasi dari pesan perpisahan Robert Stephenson Smyth Baden-Powell kepada Scouts: “Cobalah dan tinggalkan dunia ini sedikit lebih baik daripada yang Anda temukan. . . "
www.it-ebooks.info
Halaman 46
15
Bibliografi
Prekuel dan Prinsip Dalam banyak hal, buku ini adalah "prekuel" dari sebuah buku yang saya tulis pada tahun 2002 berjudul Agile Software Pengembangan: Prinsip, Pola, dan Praktek (PPP). Buku PPP menyangkut dirinya sendiri dengan prinsip-prinsip desain berorientasi objek, dan banyak praktik yang digunakan oleh para profesional pengembang nasional. Jika Anda belum membaca PPP, maka Anda mungkin akan melanjutkannya diceritakan oleh buku ini. Jika Anda sudah membacanya, maka Anda akan menemukan banyak sentimen buku itu bergema dalam buku ini di tingkat kode. Dalam buku ini Anda akan menemukan referensi sporadis untuk berbagai prinsip desain. Ini termasuk Prinsip Tanggung Jawab Tunggal (SRP), Prinsip Tertutup Terbuka (OCP), dan antara lain Prinsip Ketergantungan Pembalikan (DIP). Prinsip-prinsip ini dijelaskan dalam mendalam dalam PPP.
Kesimpulan Buku-buku tentang seni tidak menjanjikan untuk menjadikan Anda seorang seniman. Yang bisa mereka lakukan adalah memberi Anda beberapa alat, teknik, dan proses berpikir yang digunakan seniman lain. Begitu juga buku ini bisatidak berjanji untuk menjadikan Anda seorang programmer yang baik. Tidak bisa menjanjikan untuk memberi Anda "kode-akal." Yang bisa dilakukan hanyalah menunjukkan kepada Anda proses pemikiran programmer dan trik yang baik, teknologi niques, dan alat yang mereka gunakan. Sama seperti buku tentang seni, buku ini akan penuh dengan detail. Akan ada banyak kode. Anda akan melihat kode yang baik dan Anda akan melihat kode yang buruk. Anda akan melihat kode yang buruk diubah menjadi baik kode. Anda akan melihat daftar heuristik, disiplin, dan teknik. Anda akan melihat contoh setelahnya contoh. Setelah itu, terserah Anda. Ingat lelucon lama tentang pemain biola konser yang tersesat dalam perjalanannya ke sebuah pertunjukan mance Dia menghentikan seorang lelaki tua di sudut dan bertanya kepadanya bagaimana cara mencapai Carnegie Hall. Pria tua itu memandangi pemain biola dan biola itu terselip di bawah lengannya, dan berkata: Tice, Nak. Praktek!"
Bibliografi [Beck07]: Pola Implementasi , Kent Beck, Addison-Wesley, 2007. [Knuth92]: Pemrograman Literate , Donald E. Knuth, Pusat Studi Bahasa dan Informasi, Universitas Junior Leland Stanford, 1992.
www.it-ebooks.info
Halaman 47 https://translate.googleusercontent.com/translate_f
36/365
3/12/2020
www.it-ebooks.info
halaman ini sengaja dibiarkan kosong
www.it-ebooks.info
Halaman 48
2 https://translate.googleusercontent.com/translate_f
37/365
3/12/2020
www.it-ebooks.info
Nama Yang Berarti oleh Tim Ottinger
pengantar Nama-nama ada di mana-mana dalam perangkat lunak. Kami menamai variabel kami, fungsi kami, argumen kami, kelas, dan paket. Kami memberi nama file sumber kami dan direktori yang mengandungnya. Kita beri nama file jar kami dan file perang dan file telinga. Kami nama dan nama dan nama. Karena kami melakukannya
17 www.it-ebooks.info
Halaman 49
18
Bab 2: Nama Yang Berarti
begitu banyak, lebih baik kita melakukannya dengan baik. Berikut ini adalah beberapa aturan sederhana untuk dibuat nama baik.
Gunakan Nama yang Mengungkap Tujuan Mudah untuk mengatakan bahwa nama harus mengungkapkan niat. Apa yang ingin kami beri kesan pada Anda adalah itu kami serius tentang ini. Memilih nama baik membutuhkan waktu tetapi menghemat lebih banyak daripada yang dibutuhkan. Jadi berhati-hatilah dengan nama Anda dan ubahlah ketika Anda menemukan yang lebih baik. Semua orang yang membaca kode Anda (termasuk Anda) akan lebih bahagia jika Anda melakukannya. Nama variabel, fungsi, atau kelas, harus menjawab semua pertanyaan besar. Itu harus memberi tahu Anda mengapa itu ada, apa fungsinya, dan bagaimana ia digunakan. Jika suatu nama membutuhkan ment, maka nama tidak mengungkapkan maksudnya. int d; // waktu berlalu dalam beberapa hari
Nama d tidak mengungkapkan apa pun. Itu tidak membangkitkan rasa waktu yang berlalu, atau hari. Kita harus memilih nama yang menentukan apa yang sedang diukur dan unit ukuran itument: int elapsedTimeInDays; int daysSinceCreation; int daysSinceModification; int fileAgeInDays;
Memilih nama yang mengungkapkan niat dapat membuatnya lebih mudah untuk dipahami dan diubah kode. Apa tujuan dari kode ini? Daftar publik getThem () { List list1 = new ArrayList ();
https://translate.googleusercontent.com/translate_f
38/365
3/12/2020
www.it-ebooks.info untuk theList) if (x(int [0][]==x:4) list1.add (x); daftar balik1; }
Mengapa sulit mengatakan apa yang dilakukan kode ini? Tidak ada ekspresi yang rumit. Jarak dan lekukan masuk akal. Hanya ada tiga variabel dan dua konstanta tersebut. Bahkan tidak ada kelas mewah atau metode polimorfik, hanya daftar array (atau begitulah tampaknya). Masalahnya bukan kesederhanaan kode tetapi implikasi kode (untuk koin a frase): sejauh mana konteksnya tidak eksplisit dalam kode itu sendiri. Kode tersebut berimplikasiitu mensyaratkan bahwa kita mengetahui jawaban atas pertanyaan seperti: 1. Hal-hal
apa saja yang ada di Daftar ?
2. Apa
pentingnya zeroth subscript dari suatu item dalam theList ?
3. Apa
pentingnya nilai 4 ?
4. Bagaimana
saya menggunakan daftar yang dikembalikan?
www.it-ebooks.info
Halaman 50
Hindari Disinformasi
19
Jawaban atas pertanyaan-pertanyaan ini tidak ada dalam sampel kode, tetapi mereka dapat melakukannya telah . Katakanlah kita sedang bekerja dalam permainan penyapu ranjau. Kami menemukan bahwa papan adalah daftar sel-sel yang disebut theList . Mari kita ganti namanya menjadi gameBoard . Setiap sel di papan direpresentasikan oleh array sederhana. Kami selanjutnya menemukan bahwa ke nol subskrip adalah lokasi nilai status dan bahwa nilai status 4 berarti "ditandai." Hanya dengan memberikan nama konsep ini kita dapat meningkatkan kode secara signifikan: Daftar publik getFlaggedCells () { List flaggedCells = ArrayList baru (); untuk sel (int []: gameBoard) if (sel [STATUS_VALUE] == FLAGGED) flaggedCells.add (sel); mengembalikan sel yang ditandai; }
Perhatikan bahwa kesederhanaan kode tidak berubah. Masih memiliki nomor yang persis sama operator dan konstanta, dengan jumlah yang sama persis tingkat sarangnya. Tapi kodenya telah menjadi jauh lebih eksplisit. Kita bisa melangkah lebih jauh dan menulis kelas sederhana untuk sel daripada menggunakan array int . Itu dapat mencakup fungsi pengungkapan niat (sebut saja isFlagged ) untuk menyembunyikan angka ajaib bers. Ini menghasilkan versi fungsi yang baru: Daftar publik getFlaggedCells () { Daftar flaggedCells = ArrayList baru (); untuk (Sel seluler: gameBoard) if (cell.isFlagged ()) flaggedCells.add (sel); mengembalikan sel yang ditandai; }
Dengan perubahan nama sederhana ini, tidak sulit untuk memahami apa yang terjadi. Ini adalah kekuatan memilih nama baik.
Hindari Disinformasi Pemrogram harus menghindari meninggalkan petunjuk palsu yang mengaburkan makna kode. Kita harus hindari kata-kata yang maknanya berbeda dari makna yang kami maksudkan. Sebagai contoh, hp , aix , dan sco akan menjadi nama variabel yang buruk karena mereka adalah nama-nama plat Unix bentuk atau varian. Bahkan jika Anda mengkodekan suatu sisi miring dan hp terlihat seperti singkatan yang bagus-
tion, itu bisa disinformatif. Tidak mengacu pada pengelompokan rekening sebagai accountList kecuali itu sebenarnya Daftar . Daftar kata berarti sesuatu yang spesifik untuk programmer. Jika wadah memegang akun sebenarnya bukan Daftar , itu dapat menyebabkan kesimpulan yang salah. 1 Jadi akunGroup atau banyak akun atau hanya akun biasa akan lebih baik.
https://translate.googleusercontent.com/translate_f
39/365
3/12/2020
www.it-ebooks.info 1. Seperti yang akan kita lihat nanti, bahkan jika wadahnya adalah Daftar, mungkin lebih baik untuk tidak menyandikan jenis wadah ke dalam namanya.
www.it-ebooks.info
Halaman 51
20
Bab 2: Nama Yang Berarti
Waspadalah dalam menggunakan nama yang bervariasi dalam hal-hal kecil. Berapa lama untuk menemukan perbedaan halus antara XYZControllerForEfficientHandlingOfStrings dalam satu modul dan, di suatu tempat yang sedikit lebih jauh, XYZControllerForEfficientStorageOfStrings ? Itu kata-kata memiliki bentuk yang sangat mirip. Konsep ejaan yang serupa juga adalah informasi . Menggunakan ejaan yang tidak konsisten tidak Informasi . Dengan lingkungan Java modern, kami menikmati penyelesaian kode otomatis. Kita tulis beberapa karakter nama dan tekan beberapa kombinasi hotkey (jika itu) dan dihargai dengan daftar kemungkinan penyelesaian untuk nama itu. Sangat membantu jika nama untuk hal yang sangat mirip mengurutkan secara alfabet dan jika perbedaannya sangat jelas, karena pengembang cenderung memilih objek dengan nama tanpa melihat Anda berlebihan komentar atau bahkan daftar metode yang disediakan oleh kelas itu. Contoh yang benar-benar mengerikan dari nama disinformasi adalah penggunaan huruf kecil L atau huruf besar O sebagai nama variabel, terutama dalam kombinasi. Masalahnya, tentu saja, adalah itu mereka terlihat hampir seluruhnya seperti konstanta satu dan nol. int a = l; jika (O == l) a = O1; lain l = 01;
Pembaca mungkin berpikir ini alat, tetapi kami telah memeriksa kode di mana seperti itu segalanya berlimpah. Dalam satu kasus, penulis kode menyarankan untuk menggunakan font yang berbeda sehingga perbedaannya lebih jelas, solusi yang harus diturunkan semua pengembang masa depan sebagai tradisi lisan atau dalam dokumen tertulis. Masalahnya ditaklukkan dengan finalitas dan tanpa menciptakan produk kerja baru dengan penggantian nama sederhana.
Jadikan Bermakna Perbedaan Programmer menciptakan masalah untuk merekadiri ketika mereka menulis kode hanya untuk satbukan kompiler atau juru bahasa. Sebagai contoh, karena Anda tidak dapat menggunakan nama yang sama untuk merujuk dua hal yang berbeda dalam cakupan yang sama, Anda mungkin tergoda untuk mengubah satu nama dengan cara yang sewenang-wenang. Kadang-kadang ini dilakukan dengan salah mengeja, mengarah ke yang mengejutkan situasi di mana mengoreksi kesalahan ejaan menyebabkan ketidakmampuan untuk dikompilasi. 2 Tidak cukup menambahkan nomor seri atau kata-kata derau, meskipun kompilernya adalah puas. Jika nama harus berbeda, maka mereka juga harus berarti sesuatu yang berbeda.
2. Pertimbangkan, misalnya, praktik yang benar-benar mengerikan untuk membuat variabel bernama klass hanya karena kelas nama digunakan untuk sesuatu yang lain.
www.it-ebooks.info
Halaman 52
https://translate.googleusercontent.com/translate_f
40/365
3/12/2020
www.it-ebooks.info 21
Gunakan Nama yang Dapat Diucapkan
Penamaan seri- angka (a1, a2, .. aN) adalah kebalikan dari penamaan yang disengaja. Seperti itu nama tidak disinformatif — mereka tidak informatif; mereka tidak memberikan petunjuk untuk niat penulis. Mempertimbangkan: public static void copyChars (char a1 [], char a2 []) { untuk (int i = 0; i
