Halo, Habr!
Tidak ada akhir untuk berbicara tentang
kode bersih , tetapi artikel selanjutnya oleh Dave Nicoletta sangat metaforis dan, mudah-mudahan, sangat layak diterjemahkan. Biarkan sedikit "membangun", karena penulis memperingatkan pembaca sebelumnya dalam artikel aslinya.
Selamat membaca.
Di rumah, selama bertahun-tahun, kebiasaan buruk telah terjadi. Menggunakan alat apa pun, kami terus lupa meletakkannya di tempatnya. Kali berikutnya seseorang membutuhkannya, mereka harus menghabiskan lebih banyak waktu mencari alat daripada menyelesaikan masalah. Hal yang paling menyedihkan adalah bahwa bahkan orang yang mengambil instrumen terakhir dan melemparkannya ke mana pun pasti akan mengalami pencarian yang sama persis. Seringkali ternyata lebih cepat untuk membeli peralatan baru daripada mencari alat yang kita miliki - kita tahu pasti! - suatu tempat berbaring.
Jadi, kami mendapat empat obeng Phillips ukuran sedang Philips, tiga dengan slot datar, setumpuk penjepit dan kunci pas tambahan, set adaptor. Belum lagi koleksi pena, gelendong pita, baterai, dan barang-barang bagus lainnya yang tersebar di mana-mana.
Setelah kami memutuskan: itu sudah cukup! Alokasikan tempat mereka untuk semua hal dan bereskan inventaris kami. Alat-alat tangan disumbangkan untuk amal. Kami melakukan segala upaya untuk menumbuhkan disiplin diri dan selalu menempatkan alat hanya di tempatnya setelah kami bekerja dengan mereka. Kualitas dan volume pekerjaan per unit waktu meningkat tajam. Stres, uang yang terbuang dan suasana hati yang manja menjadi jauh lebih sedikit.
Menempatkan pesanan di garasi perusahaan
Bagaimana jika mekanik otomatis yang bekerja di garasi perusahaan akan menjatuhkan alat di mana saja? Mereka akan menghabiskan lebih banyak waktu mencari alat daripada benar-benar bekerja. Detail akan diletakkan di tempat yang salah, hilang, berkarat, rusak, mereka hanya akan dicuri. Biaya pasokan akan meningkat sangat besar.
Dibutuhkan lebih banyak waktu untuk menyelesaikan tugas, tetapi kualitas pekerjaan akan menurun. Ketika seorang mekanik harus bekerja dengan alat yang berkarat, aus dan rusak, sulit baginya untuk memasang dan memasang komponen dengan benar. Selain itu, kebiasaan mengatur kekacauan di bengkel pasti akan mempengaruhi kualitas pekerjaan.
Pelanggan akan muak dengan transfer akhir pekerjaan tanpa akhir. Segera mereka akan pergi ke bengkel yang lebih andal. Entah bagaimana melakukannya tanpamu. Mungkin analogi dengan pengembangan dan dukungan perangkat lunak sudah jelas.
Melakukan pemesanan dalam pengembangan perangkat lunak
Mari kita lihat contoh spesifik: refactoring tambahan.
Ungkapan ini membingungkan banyak orang. Saya tidak tahu kata mana yang membingungkan mereka: "incremental" atau "refactoring".
Refactoring inkremental (bertahap) secara fundamental berbeda dari skala besar. Tampaknya bagi banyak orang bahwa setiap refactoring harus "berskala besar", bahwa itu harus "disahkan" oleh seseorang, dan karena itu, konon, pekerjaan itu harus diseret keluar. Bahkan, jika mengabaikan refactoring dalam perjalanan kerja, maka semuanya tertunda secara signifikan.
Kebanyakan pelatih teknis, termasuk saya, sulit menjelaskan perbedaan dalam kasus ini; bukan karena perbedaan ini rumit menurut definisi, tetapi karena sangat sulit untuk dirumuskan dengan kata-kata. Namun, saya pikir kebiasaan mempertimbangkan persediaan yang ada dan memonitor persediaan adalah analogi yang baik dalam kasus ini.
Refactoring bertahap
Melakukan refactoring bertahap adalah seperti menjaga ketertiban di meja kerja bahkan di puncak pekerjaan. Menggunakan obeng - letakkan di tempatnya. Sebelum setiap tugas baru, kami tidak akan membangun kembali bengkel untuk ini. Intinya, adalah kemampuan untuk menyelesaikan ... bagaimana menyelesaikan apa yang Anda mulai. Mengupas ujungnya.
Refactoring bertahap tidak membutuhkan banyak waktu ekstra dan tidak memerlukan izin seseorang dari atas. Untuk itu, Anda perlu meminta izin untuk tidak membersihkan kode, jika Anda perlu terburu-buru. Kemampuan untuk selalu menjaga kode tetap bersih sebenarnya harus dianggap sebagai keterampilan profesional dasar seorang programmer. Sangat memalukan bahwa hari ini, "kode bersih" perlu propaganda, dan beberapa programmer bahkan menentang kemurnian semacam itu. Refactoring bertahap sama sekali tidak ada artinya dengan refactoring arsitektur skala besar, yang benar-benar memerlukan perencanaan yang cermat, mengalokasikan waktu, uang, dan orang-orang untuk itu.
Aturan kepanduan
Dalam pemrograman, ada yang disebut "aturan scout": menjaga kode setidaknya sebersih yang diterima. Hal yang sama berlaku untuk penyimpanan alat kerja di rumah. Jika kita mencari tang, tetapi perhatikan bahwa obeng slotted secara tidak sengaja sampai ke salib dan obeng palang masuk ke slotted, kita, dalam prosesnya, meletakkannya di tempatnya. Kami tidak perlu persetujuan resmi untuk melakukan ini.
Inilah cara kerja refactoring bertahap. Sebelum kita adalah sepotong kode, dan kita perlu menambahkan syarat baru ke daftar konstruksi yang tersedia. Kami perhatikan bahwa daftar diimplementasikan sebagai blok if / else besar. Kami memutuskan bahwa itu perlu dirancang ulang sebagai switch atau operator seleksi, sambil menambahkan suatu kondisi. Orang bisa berargumen: apakah ini benar-benar jauh lebih baik daripada blok if / else? Ya, Anda benar: tidak banyak. Tapi sedikit lebih baik. Ketika seseorang selanjutnya membaca kode ini setelah Anda, ia akan dapat memperbaikinya lebih baik, karena Anda telah meningkatkan posisi awalnya. Jika Anda pernah melakukan hal seperti ini sebelumnya, maka Anda mungkin memperhatikan bahwa hanya dengan membaca semua kondisi dengan cermat, Anda kadang-kadang menemukan konstruksi duplikat, kemudian urutan ekspresi yang tidak optimal; mungkin Anda menemukan beberapa kondisi yang tidak pernah dapat dipenuhi, atau bahkan "lubang" logis yang melaluinya seluruh rangkaian kontrol akan jatuh melalui blok if / else, dan beberapa case tidak akan diproses sama sekali. Bersukacitalah bahwa Anda menemukannya sekarang, dan tidak sampai larut malam, ketika Anda menerima tiket yang sesuai dari layanan dukungan teknis. Pada saat mata saling menyatu, sama sekali tidak ada keinginan untuk memahami kode yang membingungkan.
Mungkin kita akan menambahkan beberapa fungsionalitas baru ke aplikasi dan memperhatikan bahwa fungsi / metode yang kita tulis sangat mirip dengan yang lain (lain) yang sudah kita miliki di basis kode. Setelah menghabiskan hanya beberapa detik, kami akan menyingkirkan duplikasi tersebut, bahkan tanpa alat tambahan yang ditawarkan di layanan kami dalam IDE yang apik. Anda dapat menolak tanpa ragu, karena kami telah membiasakan diri untuk mendisiplinkan diri dan menjamin bahwa tes mikro (unit test) yang mencakup kasus ini telah ditulis. Maka refactoring manual tidak mengerikan. Pada akhirnya, muncul dengan setidaknya satu alasan mengapa tidak?
"Jangka panjang" biasanya tidak sepanjang kelihatannya
Seringkali saya mendengar dari orang yang berbeda bahwa refactoring membawa manfaat "jangka panjang". Meskipun, secara teori, ini adalah, di sini, di Dunia Nyata, Anda harus terus-menerus menyerahkan pekerjaan secara ketat. Namun, jika kita berbicara tentang menjaga kemurnian kode melalui refactoring bertahap kecil, "jangka panjang" berlangsung tepat sampai saat ketika orang lain menyentuh basis kode. Tepat sampai waktu berikutnya.
Berita buruknya adalah bahwa yang terjadi adalah sebaliknya. Jika Anda tidak membersihkan kode saat bekerja, kode akan cepat rusak. Kami tidak memiliki "airbag" sepuluh tahun yang akan memungkinkan kami untuk mengakumulasi pernikahan dengan impunitas sampai masalah dimulai. Perubahan selanjutnya yang perlu dilakukan akan memakan waktu lama dari kita, risiko regresi kode akan meningkat, dan situasi tanpa perhatian yang tepat hanya akan memburuk.
Jika kita meretas hanya untuk memuaskan keinginan pelanggan (dan dia ingin produk jadi lebih cepat), bagaimana kita akan terus memenuhi permintaan ini setelah kami memastikan bahwa tidak ada perubahan cepat yang dilakukan lagi, karena kami membawa kode ke status kebingungan, dan tidak mungkin untuk mempertahankannya?
Apa yang cepat, apa yang lambat?
Pelanggan akan selalu ingin Anda bekerja lebih keras, tidak peduli seberapa cepat Anda mengaturnya. Cara paling efektif untuk mengurangi waktu rilis adalah dengan melakukan segalanya dengan benar; untuk melakukannya dengan baik; selalu bersihkan ujungnya, selalu, tanpa kecuali. Memotong sudut untuk "mempercepat", dalam praktiknya kita hanya memperlambat, dan tidak dalam "perspektif jangka panjang" yang sesaat, tetapi di sini dan sekarang.
Ketika pelanggan menuntut Anda untuk bekerja lebih cepat, ini tidak berarti dia membiarkan Anda bekerja dengan sembarangan. Secara alami, tampak jelas baginya bahwa ia tidak boleh, setelah setiap permintaan, mengingatkan kita bahwa ia tertarik pada kualitas tinggi. Kualitas tinggi tersirat sebagai salah satu komponen pekerjaan kami.
Sebagai insinyur, kami sendiri memilih apakah akan mempertimbangkan refactoring bertahap sebagai elemen dasar dari aktivitas profesional kami. Kami tidak bertanya apakah kami bisa bekerja sebagaimana mestinya, sama seperti ahli bedah tidak bertanya kepada akuntan apakah ia punya waktu untuk mencuci tangannya sebelum operasi. Waktu yang dihabiskan untuk operasi itu sama persis dengan waktu yang diperlukan agar operasi itu berhasil. Pasien harus dengan hati-hati melepas apendiks, dan setelah keluar, orang tersebut dapat kembali ke kehidupan normal - tanpa infeksi luka dan tanpa tampon di perut. Itu hanya akan menjadi lebih buruk jika seseorang diambil dari ruang operasi sepuluh menit lebih awal dari yang diperlukan, dan kemudian komplikasi dimulai.
Seringkali, dalam kasus ini, mereka menangkis bahwa jika "semuanya dilakukan sesuai dengan sains", maka ternyata "terlalu lama". Tidak, pada kenyataannya, “terlalu lama” adalah waktu yang diperlukan untuk memperbaiki konsekuensi jika pekerjaan dilakukan dengan tergesa-gesa dan tanpa profesionalisme yang tepat. Pemulihan dari infeksi adalah kejutan nyata bagi pasien dan keluarganya, ini pasti akan mempengaruhi pekerjaannya. Operasi kedua, di mana tampon yang dilupakan harus dikeluarkan dari perut, adalah intervensi yang jauh lebih serius, dan itu akan diperlukan hanya karena orang itu dioperasi terburu-buru untuk pertama kalinya.
Saat memprogram, jika Anda harus melakukan lima regresi kode karena fakta bahwa seseorang menulisnya dengan tergesa-gesa, Anda tidak dapat berbicara tentang "menghemat waktu". Sebaliknya, perubahan dilakukan lebih lama. Pekerjaan tidak “selesai” sampai selesai dengan benar. Jika tim harus menghabiskan waktu berjam-jam untuk memperbaiki kesalahan setelah “menyusun kesiapan”, maka ini adalah waktu yang hilang yang bisa dihabiskan untuk pekerjaan lain yang bermanfaat. Ini adalah keuntungan yang hilang.
Kesalahan seperti itu memberikan konsekuensi seperti gelombang dan menyebabkan kerugian waktu dan uang jangka panjang, dan kadang-kadang menyebabkan hilangnya pelanggan. Tekanan tambahan jatuh pada pundak para insinyur itu sendiri; moral rendah, pergantian staf tinggi. Oleh karena itu, persetan yang semakin sulit dan penurunan moral dan keterlibatan dalam pekerjaan.
Utang teknis sebagai metafora
Setiap kali Anda beralih ke topik refactoring bertahap, seseorang pasti akan mengingatkan Anda tentang utang teknis. Mereka akan mengatakan: "Kami punya tenggat waktu yang sangat penting sehingga hanya perlu mengambil jalan pintas." Mereka akan menambahkan bahwa dalam kasus ini, tim secara sadar mengakumulasi hutang teknis, dipandu oleh kebutuhan bisnis.
Mereka yang mengatakan demikian tidak memahami metafora ini, dan mungkin tidak ada metafora sama sekali.
Metafora ini tidak dimaksudkan untuk menjadi deskripsi yang lengkap dan komprehensif dari hal yang dikarakterisasi.
Metafora membantu secara umum menguraikan kesan dari aspek hal ini.
Orang-orang cenderung mengganti sesuatu dengan metaforanya, dan kemudian beroperasi dengan metafora seolah-olah dia dan dia
hal yang dijelaskan adalah satu dan hal yang sama. Tidak, ini bukan hal yang sama. Intinya.
Selain itu, adalah umum bagi orang untuk secara luas menafsirkan metafora di luar konteks aslinya. Dengan demikian, makna metafora menjadi kabur, dan itu menjadi kurang bermanfaat.
Ward Cunningham mengusulkan metafora untuk utang teknis, yang menggambarkan interaksi pelanggan dalam industri keuangan. Dia mencari metafora yang cocok untuk konteks khusus ini, untuk menekankan bagaimana realisasi peluang secara bertahap membantu menciptakan lingkaran umpan balik di mana program terus dioptimalkan. Dia tidak bermaksud "memotong sudut untuk menciptakan ilusi perkembangan cepat."
Konsep asli dari metafora utang teknis menyiratkan bahwa kode itu harus tetap bersih. Orang yang memahami masalah yang tertinggal dalam kode bergerak langkah demi langkah menuju solusinya, dan kode itu akan selalu cukup akurat sehingga perbaikan bertahap dapat dilakukan untuk itu. Ini bukan masalah fakta bahwa beberapa alasan teknis dapat membenarkan mengapa kode ini sampah dan membutuhkan koreksi terus-menerus.
Memotong sudut demi menyerahkan pekerjaan dengan cepat bukanlah akumulasi utang teknis. Ini adalah retasan umum.
Siapa yang bertanggung jawab
Untuk mencapai pengiriman cepat, Anda harus menyingkirkan masalah saat bekerja. Salah satu masalah ini adalah kode sampah. Anda dapat menyingkirkan rintangan ini langkah demi langkah dengan belajar untuk bekerja disiplin diri. Dalam hal ini, tidak masalah bagaimana Anda bekerja - sesuai dengan model "air terjun" atau menurut "aggail". Kami sendiri memilih cara bekerja setiap kali kami menyentuh keyboard.
Saya meringkas. Jika Anda bekerja dengan benar, termasuk membersihkan ujungnya, itu hanya akan menguntungkan klien, sponsor, manajer, mereka yang akan mendukung kode kita di masa depan dan, tentu saja, untuk diri kita sendiri.