Subyektif: refactoring adalah "penyakit" muda. Menurut pengamatan pribadi, di suatu tempat setelah 26 tahun mulai melepaskan. Seperti dalam ungkapan lama itu: "Dia yang bukan revolusioner di masa mudanya - dia tidak punya hati, dia yang tidak menjadi konservatif dalam kedewasaan - dia tidak punya pikiran." Oleh karena itu, sampai akhirnya saya melepaskan, saya akan mencoba menggambarkan kasus pengguna refactoring dan kemungkinan sasaran yang dapat dicapai dengannya.
Inspirator
Saya mulai menulis setelah melihat berikutnya permintaan tarik untuk 150+ file, di mana fungsi baru dan refactoring dari yang sudah ada sangat terlibat. Refactoring bukan hanya kosmetik, tetapi juga logis, yang menyebabkan rasa sakit terbesar. Misalnya, di Ruby, amount == 0 diganti dengan berani oleh amount.zero? tanpa mempertimbangkan bahwa untuk kasus nil dalam amount konstruksi ini tidak setara. Semua ini dijelaskan kira-kira sebagai berikut: "tetapi sesuai dengan kode standar seharusnya!" Untuk pertanyaan logis "apa tujuan mengikuti kode ke standar dan secara umum, apa tujuan Anda sebagai pengembang?" lelaki itu mengunci diri dan mengulangi sedikit kesalahan "tetapi menurut standar kode, Anda harus menulis seperti ini ..." dan tampak seperti seorang pirang di toko pakaian yang tidak bisa mengatasi keinginannya refactor beli semuanya.
Definisi
Topiknya sensitif, jadi Anda perlu memberi perhatian khusus pada pertanyaan "siapa itu siapa?" Jadi, menurut wiki , refactoring adalah proses mengubah struktur internal suatu program yang tidak memengaruhi perilaku eksternalnya dan dimaksudkan untuk memudahkan pemahaman tentang pekerjaannya.
Untuk bagian saya, saya ingin mempersempit batas dan mendefinisikan refactoring (dalam arti terburuk dari kata) sebagai setiap perubahan yang tidak terkait langsung dengan masalah yang sedang dipecahkan dan tidak mengubah perilaku eksternal sistem, tetapi dilakukan sebagai bagian dari tugas asli.
Artinya, saya ingin berbicara bukan tentang perubahan yang direncanakan dalam basis kode, yang ruang lingkup pekerjaannya telah diuraikan dan tujuan spesifik telah ditetapkan, tetapi tentang modifikasi spontan yang terjadi selama pengembangan.
Nilai produk
Sekarang saya akan mulai dari jauh. Kode sumber bukan tujuan atau nilai. Tentu saja, secara estetika atau artistik, mungkin menarik, tetapi ini adalah pengecualian. Secara umum, kode adalah alat untuk membuat produk perangkat lunak yang digunakan siapa pun. Oleh karena itu, sebagai permulaan, akan baik untuk menentukan apa nilai-nilai dalam produk.
Nilai produk langsung
Semuanya sederhana di sini. Mereka menggunakan produk, jadi nilai langsung adalah apa yang dirasakan / dilihat / dirasakan pengguna. Yaitu:
- semua jenis fungsi produk;
- kegunaan (UI / UX, kinerja, toleransi kesalahan, dll.).
Poin kedua dapat menyebabkan beberapa diskusi. Lagi pula, banyak yang percaya bahwa ini bukan hal utama. Karena jika fungsionalitasnya baik, tidak masalah apa yang dibungkus. Contoh fungsionalitas yang bagus tanpa UI / UX waras: Redmine dan SAP . Namun, saya tidak setuju dengan pandangan ini dan pendapat yang lebih dekat kepada Kamerad Alan Cooper dan "Rumah Sakit Jiwa di tangan pasien."
Nilai Produk Tidak Langsung
Ini adalah nilai-nilai yang dalam dirinya sendiri tidak mempengaruhi pengguna. Tetapi mereka dapat "menembak" atau "menumpuk" dan memiliki dampak (dengan tingkat keparahan yang berbeda-beda) pada produk atau fungsinya.
- Bug. Kasus nilai batas. Mereka adalah nilai kedua karena nilai-nilai itu sendiri tidak dibawa, tetapi mengambilnya dari fitur tetangga.
- Kebersihan. Ini tentang keterbacaan, modularitas, minimalisasi komponen yang masuk, standardisasi dan penyatuan antarmuka, dll.
- Dokumentasi Ini tentang kode dan penjelasan untuk pengembang, bukan tentang deskripsi bisnis atau akun pengguna. Ini diilustrasikan dengan baik oleh ungkapan seorang petani yang ceria dari salah satu wawancara: "Logika dalam database ditulis seperti buku."
- Skalabilitas / keamanan / keamanan. Pengguna tidak melihatnya sampai sesuatu yang buruk terjadi.
Nilai Pengembang
Kategori yang sangat penting yang banyak diabaikan, tetapi yang selalu mempengaruhi hasilnya.
- Kode menurut standar.
- Lekukan pada feng shui.
- Transaksi lainnya dengan hati nurani. Lagi pula, kodenya ditulis, sehingga ada hasilnya untuk hari itu, dan karenanya ada manfaatnya.
- Kepatuhan terhadap kode dengan dunia batin.
Tapi mari kita jujur. Semua ini bukan tentang nilai-nilai yang terkait dengan produk dan pengguna akhir. Ini tentang psikologi dan kecoak pribadi.
Dilihat dari sisi bisnis
Demi kelengkapan, orang harus melihat semua ini dari sisi bisnis, dan bukan produk perangkat lunak. Dalam hal ini, pembagian menjadi nilai langsung dan tidak langsung menjadi cukup dangkal: langsung - jelas membawa uang dan Anda dapat memberikan penilaian kuantitatif yang tidak ambigu; tidak langsung - mereka tidak membawa uang dan / atau sangat sulit untuk diukur; nilai untuk pengembang tidak membawa uang dalam bentuk apa pun (bahkan mungkin mengambilnya).
Sebagai contoh.
- Fitur baru dengan OAuth screwing meningkatkan jumlah pendaftaran sebesar 10% dan kami mendapatkan $ 1k.
- Kami membagi modul penagihan menjadi beberapa bagian independen, berdasarkan pada pola tanggung jawab tunggal. Sepertinya itu menjadi lebih mudah untuk dipertahankan, tetapi itu tidak mungkin untuk diukur.
- Kami membawa basis kode sesuai dengan standar kode dan ... tidak menerima apa pun.
Perlu dicatat bahwa dari perkiraan di atas, kaki tumbuh pada percepatan bisnis tercinta, terburu-buru umum dan keengganan untuk mencurahkan waktu untuk apa pun selain fungsi dan, mungkin, perbaikan bug. Memang, nilai langsung dapat diperkirakan dan "dijual", dan nilai tidak langsung sangat sulit atau tidak mungkin. Dan ternyata nilai-nilai tidak langsung diwujudkan baik berdasarkan latar belakang teknik, atau dipahami pada tingkat intuitif, atau dibuang sebagai "tidak berharga."
Dalam keadilan, di sini kita perlu mengingat kembali konsep enabler, yang "membuka jalan" untuk implementasi fitur yang diinginkan, tetapi tidak menghasilkan keuntungan yang jelas bagi pengguna. Tapi itu cerita lain.
Dan bagaimana dengan refactoring?
Setidaknya terlepas dari kenyataan bahwa ia hanya dapat mempengaruhi nilai tidak langsung dari produk tersebut. Oleh karena itu, pengguna tidak akan merasa lebih baik dari refactoring apa pun.
Penting juga untuk diingat tentang entropi. Refactoring selalu meminimalkannya. Untuk mengurangi entropi, idealnya, Anda memerlukan tim arsitek yang meminimalkan entropi pada tahap desain. Mengutip tulisan dari Mythical Man-Month:
Pemrograman sistem adalah proses yang mengurangi entropi, dan karenanya metastabilitas melekat di dalamnya. Pemeliharaan program adalah proses yang meningkatkan entropi, dan bahkan pemeliharaannya yang paling terampil hanya menunda sistem agar tidak menjadi usang.
Oleh karena itu, jika kami menganggap refactoring sebagai bagian dari proses pemeliharaan program, maka semakin sedikit refactor, semakin lama kode akan hidup tanpa menulis ulang.
Apa tujuan yang bisa dimiliki refactoring?
Biarkan saya mengingatkan Anda bahwa saya sedang berbicara tentang perubahan spontan selama implementasi fitur, dan bukan tentang perubahan yang direncanakan. Dalam hal ini, definisi tujuan sepenuhnya terletak pada pengembang. Dia harus bertanya pada dirinya sendiri pertanyaan utama "mengapa?", Jawab itu dan setelah itu, bergerak ke arah tujuan yang dimaksud.
Untuk entropi!
Sulit melakukannya sendiri. Dan untuk menarik ulasan umumnya tidak realistis. Tujuannya tentu baik: membersihkan jembatan untuk pencapaian baru, serta untuk membersihkan racun dan racun yang terakumulasi selama dukungan produk. Tetapi menyekop beberapa modul dari awal tanpa kehilangan apa pun di sepanjang jalan bukanlah tugas yang mudah. Ini harus diselesaikan bersama dengan analis bisnis dan arsitek, jika ada. Jadi sedikit orang yang mengambil risiko melakukan ini atas dasar sukarela.
Untuk dokumentasi!
Sudah lebih mudah. Ubah nama variabel / fungsi pada prinsip "apa yang ada di kotak, lalu di dalam kotak", sederhanakan desain karena kemampuan bahasa dan perpustakaan, tambahkan komentar di tempat yang tidak jelas, dll. Ini dapat dilakukan sendiri dan, dengan pendekatan yang tepat, dapat dilakukan dengan baik untuk diri sendiri di masa depan, dan untuk rekan kerja di sekitarnya.
Untuk kecepatan!
Sejujurnya, pekerjaan seperti itu harus disorot sebagai tugas yang terpisah. Karena kemampuan sistem saat ini sudah cukup untuk Anda dan Anda tidak perlu melakukan apa pun, atau Anda tahu persis apa dan berapa banyak yang perlu Anda percepat.
Semuanya termasuk dalam kategori ini: mulai dari koreksi N + 1 yang tidak berbahaya hingga akselerasi serius karena perubahan dalam algoritma operasi. Seluruh masalah adalah "paritas" bug selalu berada pada kecepatan. Berikut ini contohnya: dalam satu data transaksi dalam database didorong dan dalam transaksi yang sama tugas diatur dalam Sidekiq; Antrian Sidekiq di Redis dan transaksi tidak berlaku untuk itu; ketika kecepatan antrian meningkat, tugas kadang-kadang diambil untuk dieksekusi sebelum data dilakukan; Anda dapat membayangkan konsekuensi dan proses debug sendiri.
Untuk refactoring!
Bayangkan Anda menggunakan layanan pembersihan apartemen. Mereka datang dan mulai membersihkan, tetapi, di sepanjang jalan, mereka memindahkan semua perabotan di apartemen dan menjabarkan tirai dari ruang tamu ke bak mandi dengan argumen "dalam kondisi seperti itu, pembersih lebih menyenangkan untuk melakukan pekerjaannya." Gambar dari "WTF?!" Anda bisa membayangkannya sendiri.
Saya harap Anda mengerti bahwa Anda tidak perlu memikirkan diri sendiri, tetapi untuk siapa Anda melakukannya.
Kerendahan hati dan penerimaan
Sebagai kesimpulan, perlu untuk memberikan "manual" tentang apa yang harus dilakukan sebelum refactoring. Benar, ini bukan daftar TODO, melainkan daftar fakta yang Anda perlukan untuk menerima dan menerima atau tidak mengambil tindakan.
- Saya meningkatkan jumlah bug di proyek dan bisa mendapatkan rebana untuk itu.
- Saya menjadi pemilik kode refactored dan semua pertanyaan tentangnya, pertama-tama, akan dikirimkan kepada saya.
- Dengan tindakan saya, saya tidak menghasilkan sesuatu yang bernilai bagi pengguna akhir.
Sedikit penjelasan.
- Setiap perubahan pada kode tersebut memiliki peluang yang tidak nol untuk menghasilkan bug. Dan karena tindakan ini tidak terhubung dengan fungsi pamungkas, maka Anda hanya menghasilkan bug tanpa menghasilkan nilai inti. Adalah baik untuk menyadari hal ini dan tidak berpura-pura menjadi selang ketika mereka mendatangi Anda dengan pertanyaan.
- Alasan seperti "anotate before" dan sejenisnya sangat menyedihkan, karena dalam github / gitlab yang sama tidak ada fitur seperti itu. Plus, penulis sebelumnya mengonfirmasi bahwa semuanya berfungsi dalam konfigurasinya, dan ia tidak bertanggung jawab atas perubahan Anda dan kehilangan sebagian gambar yang sedang terjadi. Lebih tepatnya, Anda mengambilnya darinya bersama dengan tanggung jawab.
- Pengguna benar-benar tidak peduli dengan refactoring, ia tertarik pada stabilitas dan fungsionalitas, dan refactoring bukan tentang itu.
Dan lagi: jika Anda tidak setuju dengan setidaknya satu poin - jangan mulai refactoring. Lebih baik membaca Habr, mengintai, minum teh atau, paling buruk, gash fitur berikutnya dari dashboard.
Akhirnya
Jangan menilai dengan ketat. Jika memungkinkan, kritiklah secara konstruktif. Dan selalu pikirkan tentang tujuan tindakan Anda. Terima kasih