Unlimited WordPress themes, graphics, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Ruby on Rails
Code

Ruby/Rails Code Smell Basics 01

by
Length:LongLanguages:
This post is part of a series called Ruby / Rails Code Smell Basics.
Ruby/Rails Code Smell Basics 02

Indonesian (Bahasa Indonesia) translation by Ilham Saputra (you can also view the original English article)

file

Topik

  • Heads up
  • Resistance
  • Kelas Besar / Kelas Dewa
  • Kelas Ekstrak
  • Long Method
  • Daftar Parameter Long

Heads Up

Kumpulan artikel singkat berikut ini ditujukan untuk pengembang Ruby yang sedikit berpengalaman dan pemula. Saya memiliki kesan bahwa kode bau dan refactorings mereka bisa sangat menakutkan dan mengintimidasi untuk pemula—terutama jika mereka tidak dalam posisi yang menguntungkan untuk memiliki mentor yang dapat mengubah konsep pemrograman mistik menjadi bola lampu bersinar.

Setelah jelas berjalan di sepatu ini sendiri, saya ingat bahwa itu tidak perlu berkabut untuk masuk ke kode bau dan refactorings.

Di satu sisi, penulis mengharapkan tingkat kemahiran tertentu dan karena itu mungkin tidak merasa terdorong untuk memberikan pembaca dengan konteks dalam jumlah yang sama seperti seorang pemula mungkin perlu dengan nyaman menyelam ke dunia ini lebih cepat.

Sebagai akibatnya, mungkin, para pemula di sisi lain membentuk kesan bahwa mereka harus menunggu sedikit lebih lama sampai mereka lebih maju untuk belajar tentang bau dan refactorings. Saya tidak setuju dengan pendekatan itu dan berpikir bahwa membuat topik ini lebih mudah didekati akan membantu mereka merancang perangkat lunak yang lebih baik di awal karir mereka. Setidaknya saya berharap itu membantu untuk memberikan peeps junior dengan awal kepala yang solid.

Jadi apa yang kita bicarakan tentang kapan tepatnya orang-orang menyebut kode berbau? Apakah selalu ada masalah dalam kode Anda? Belum tentu! Bisakah Anda menghindarinya sepenuhnya? Saya tidak berpikir demikian! Apakah maksud Anda kode bau menyebabkan kode rusak? Yah, kadang-kadang dan terkadang tidak. Haruskah prioritas saya untuk memperbaikinya segera? Jawaban yang sama, saya khawatir: kadang-kadang ya dan kadang-kadang Anda pasti harus menggoreng ikan yang lebih besar terlebih dahulu. Apakah anda tidak waras? Pertanyaan wajar pada poin ini!

Sebelum Anda melanjutkan terjun ke dalam bisnis yang penuh bau ini, ingatlah untuk mengambil satu hal dari semua ini: Jangan mencoba memperbaiki setiap bau yang Anda temui—ini pasti membuang-buang waktu Anda!

Sepertinya saya bau kode agak sulit untuk dibungkus dalam kotak yang diberi label dengan baik. Ada semua jenis bau dengan berbagai pilihan yang berbeda untuk mengatasinya. Juga, bahasa pemrograman yang berbeda dan kerangka kerja yang rentan terhadap berbagai jenis bau—tetapi ada pasti banyak common strain "genetik" di antara mereka. Saya mencoba untuk menggambarkan kode bau adalah dengan membandingkan mereka dengan gejala medis yang memberitahu Anda bahwa Anda mungkin memiliki masalah. Mereka dapat menunjukkan berbagai macam masalah laten dan memiliki berbagai macam solusi jika didiagnosis.

Untungnya, mereka secara keseluruhan tidak serumit berurusan dengan tubuh manusia—dan jiwa tentu saja. Ini adalah perbandingan yang adil, meskipun, karena beberapa gejala ini perlu ditangani segera, dan beberapa orang lain memberi Anda cukup waktu untuk datang dengan solusi yang terbaik untuk "pasien" keseluruhan kesejahteraan. Jika Anda memiliki kode bekerja dan Anda menjalankan menjadi sesuatu yang bau, Anda harus membuat keputusan sulit jika perlu waktu untuk menemukan fix dan jika itu refactoring meningkatkan stabilitas aplikasi Anda.

Bahwa menjadi kata, jika Anda tersandung atas kode yang Anda dapat meningkatkan segera, itu saran yang bagus untuk meninggalkan kode di belakang sedikit lebih baik dari sebelumnya—bahkan sedikit lebih baik menambahkan sampai substansial dari waktu ke waktu.

Resistance

Kualitas kode menjadi dipertanyakan jika dimasukkannya kode baru menjadi lebih keras—seperti memutuskan mana harus menempatkan kode baru adalah rasa sakit atau datang dengan banyak efek riak seluruh basis kode Anda, misalnya. Ini disebut resistance.

Sebagai pedoman untuk kualitas kode, Anda dapat mengukurnya selalu dengan cara mudah untuk memperkenalkan perubahan. Jika yang semakin lebih keras dan lebih keras, itu pasti waktu untuk refactor dan mengambil bagian terakhir dari red-green-REFACTOR lebih serius di masa depan.

Kelas Besar / Kelas Dewa

Mari kita mulai dengan sesuatu mewah terdengar—"Kelas dewa"—karena saya pikir mereka sangat mudah untuk memahami untuk pemula. Kelas-kelas Tuhan adalah kasus khusus dari bau kode yang disebut Kelas Besar. Dalam bagian ini saya akan membahas keduanya. Jika Anda telah menghabiskan sedikit waktu di tanah Rails, Anda mungkin telah melihat mereka begitu sering bahwa mereka tampak normal untuk Anda.

Anda pasti ingat "model gemuk, skinny controller" mantra? Sebenarnya, skinny bagus untuk semua kelas ini, tetapi sebagai pedoman, itu adalah nasihat yang baik untuk pemula, saya kira.

Kelas-kelas Tuhan adalah objek yang menarik segala macam pengetahuan dan perilaku seperti lubang hitam. Yang paling sering Anda curigai adalah model Pengguna dan masalah apa pun (semoga!) Yang coba diselesaikan oleh aplikasi Anda—setidaknya dan paling penting. Aplikasi todo mungkin massal di model Todos, aplikasi belanja di Produk, aplikasi foto di Foto—Anda mendapatkan penyimpangan.

Orang menyebut mereka kelas dewa karena mereka tahu terlalu banyak. Mereka memiliki terlalu banyak koneksi dengan kelas-kelas lain—terutama karena seseorang itu modeling mereka malas. Ini adalah kerja keras, untuk menjaga kelas dewa tetap di cek. Mereka membuatnya sangat mudah untuk membuang lebih banyak tanggung jawab ke mereka, dan seperti banyak pahlawan Yunani akan membuktikan, dibutuhkan sedikit keterampilan untuk membagi dan menaklukkan "dewa".

Masalah dengan mereka adalah bahwa mereka menjadi keras dan sulit untuk mengerti, terutama untuk anggota tim baru, lebih sulit untuk berubah, dan penggunaan kembali mereka menjadi kurang dan kurang opsi gravitasi lain mereka telah mengumpulkan. Oh ya, kau benar, tes Anda lebih tidak perlu sulit untuk menulis juga. Singkatnya, tidak ada benar-benar terbalik untuk memiliki kelas besar, dan kelas-kelas Tuhan secara khusus.

Ada beberapa gejala/tanda-tanda umum bahwa kelas Anda membutuhkan beberapa kepahlawanan/bedah:

  • Anda perlu scroll!
  • Ton metode private?
  • Apakah kelas Anda memiliki tujuh atau lebih metode di atasnya?
  • Sulit untuk mengatakan apa yang kelas Anda benar-benar — ringkas!
  • Apakah kelas Anda memiliki banyak alasan untuk mengubah ketika kode Anda berkembang?

Juga, jika Anda juling di kelas Anda dan berpikir "Eh? EW!"Anda mungkin menemukan sesuatu yang terlalu. Jika semua yang terdengar akrab, kemungkinan baik bahwa Anda menemukan diri Anda spesimen baik-baik saja.

Orang jelek, ya? Dapatkah Anda melihat seberapa banyak nastiness dibundel di sini? Tentu saja aku menaruh sedikit cherry di atas, tetapi Anda akan lari ke kode seperti ini cepat atau lambat. Mari kita berpikir tentang tanggung jawab apa CastingInviter ini kelas harus menyulap.

  • Memberikan email
  • Memeriksa untuk berlaku pesan dan alamat email
  • Menyingkirkan ruang putih
  • Membagi alamat email pada koma dan titik koma

Harus semua ini dibuang pada kelas yang hanya ingin memberikan panggilan casting melalui deliver? Tentu saja tidak! Jika metode undangan Anda berubah, Anda mungkin akan mengalami operasi senapan. CastingInviter tidak perlu tahu sebagian besar rincian ini. Itulah lebih tanggung jawab class yang mengkhususkan diri dalam berurusan dengan hal-hal yang berhubungan dengan email. Di masa depan, Anda akan menemukan banyak alasan untuk mengubah kode di sini juga.

Kelas Ekstrak

Jadi bagaimana seharusnya kita menangani ini? Seringkali, mengekstraksi kelas adalah pola refactoring yang berguna yang akan menampilkan dirinya sebagai solusi yang masuk akal untuk masalah-masalah seperti kelas-kelas yang besar dan berbelit-belit—terutama ketika kelas yang bersangkutan berurusan dengan banyak tanggung jawab.

Metode swasta adalah sering kandidat yang baik untuk memulai dengan—dan tanda mudah juga. Terkadang Anda perlukan untuk mengekstrak bahkan lebih dari satu kelas dari seorang yang buruk—hanya tidak melakukan itu semua dalam satu langkah. Setelah Anda menemukan daging cukup koheren yang tampaknya termasuk dalam sebuah objek khusus sendiri bahwa Anda dapat mengekstrak bahwa fungsi ke kelas baru.

Anda membuat sebuah class baru dan secara bertahap bergerak fungsionalitas—satu per satu. Bergerak setiap metode secara terpisah, dan mengubah mereka jika Anda melihat alasan untuk. Kemudian referensi kelas baru yang asli dan mendelegasikan fungsi yang diperlukan. Hal yang baik Anda memiliki tes cakupan (mudah-mudahan!) yang memungkinkan Anda memeriksa jika sesuatu masih bekerja dengan baik setiap langkah dari jalan. Bertujuan mampu kembali kelas diekstrak Anda juga. Lebih mudah untuk melihat bagaimana hal ini dilakukan dalam tindakan, jadi mari kita membaca beberapa kode:

Dalam solusi ini, Anda tidak hanya akan melihat bagaimana keprihatinan pemisahan ini mempengaruhi kualitas kode Anda, juga membaca banyak lebih baik dan menjadi lebih mudah dicerna.

Di sini kita mendelegasikan metode untuk kelas baru yang mengkhususkan diri dalam berurusan dengan menyampaikan undangan melalui email. Anda memiliki satu tempat khusus yang memeriksa jika pesan dan undangan yang berlaku dan bagaimana mereka harus disampaikan. CastingInviter tidak perlu tahu apa-apa tentang rincian ini, jadi kami mendelegasikan tanggung-jawab ini untuk kelas baru CastingEmailHandler.

Pengetahuan tentang bagaimana untuk memberikan dan memeriksa validitas email undangan pengecoran ini sekarang adalah semua yang terkandung dalam kelas diekstrak kami baru. Apakah kita memiliki kode lagi sekarang? Anda bertaruh! Apakah itu layak untuk memisahkan masalah? Cukup yakin! Dapat kita pergi di luar itu dan refactor CastingEmailHandler lagi? Benar! Bunuh dirimu sendiri!

Dalam kasus Anda bertanya-tanya tentang valid? metode CastingEmailHandler dan CastingInviter, yang satu ini untuk RSpec untuk membuat matcher kustom. Hal ini memungkinkan saya menulis sesuatu seperti:

Cukup berguna, saya pikir.

Ada lebih banyak teknik untuk berurusan dengan kelas besar / objek dewa, dan selama rangkaian ini Anda akan belajar beberapa cara untuk refactor objek tersebut.

Ada tidak ada resep yang tetap untuk menangani kasus ini—itu selalu tergantung, dan itu adalah kasus-oleh-kasus penilaian panggilan jika Anda perlu membawa senjata besar atau jika lebih kecil, teknik refactoring inkremental mewajibkan terbaik. Aku tahu, sedikit frustrasi di kali. Mengikuti Single Responsibility Principle (SRP) akan pergi jauh, meskipun, dan adalah hidung yang bagus untuk mengikuti.

Long Method

Memiliki metode yang mendapat sedikit besar adalah salah satu hal yang paling umum yang Anda temui sebagai pengembang. Secara umum, Anda ingin tahu sekilas apa yang seharusnya sebuah metode lakukan. Itu juga harus memiliki hanya satu tingkat bersarang atau satu tingkat abstraksi. Singkatnya, menghindari menulis metode yang rumit.

Aku tahu ini terdengar keras, dan sering adalah. Solusi yang muncul sering adalah penggalian bagian metode ke satu atau lebih fungsi baru. Teknik ini refactoring disebut metode ekstrak—ini adalah salah satu yang paling sederhana tetapi tetap sangat efektif. Sebagai efek samping yang baik, kode menjadi lebih mudah dibaca jika Anda nama metode Anda dengan tepat.

Mari lihat spesifikasi fitur di mana Anda akan memerlukan teknik ini banyak. Aku ingat mendapatkan diperkenalkan ke metode ekstrak saat menulis spesifikasi fitur tersebut dan bagaimana menakjubkan rasanya ketika lampu pergi. Karena fitur spesifikasi seperti ini mudah untuk memahami, mereka adalah calon yang baik untuk demonstrasi. Plus Anda akan mengalami skenario yang sama berulang-ulang bila Anda menulis spesifikasi Anda.

spec/features/some_feature_spec.rb

Seperti Anda dapat dengan mudah melihat, ada banyak hal yang terjadi dalam skenario ini. Anda pergi ke halaman indeks, masuk dan membuat sebuah misi untuk setup, dan kemudian berlatih melalui menandai misi selesai, dan akhirnya Anda memverifikasi perilaku. Tidak roket sains, tetapi juga tidak bersih dan jelas tidak terdiri untuk usabilitas. Kita bisa melakukan lebih dari itu:

spec/features/some_feature_spec.rb

Di sini kami ekstrak empat metode yang dapat dengan mudah kembali dalam tes lain sekarang. Saya berharap hal ini jelas bahwa kita memukul tiga burung dengan satu batu. Fitur ini jauh lebih ringkas, bunyinya lebih baik, dan itu terdiri dari komponen diekstrak tanpa duplikasi.

Mari kita bayangkan Anda telah menulis semua jenis skenario yang sama tanpa mengeluarkan metode ini dan Anda ingin mengubah beberapa implementasi. Sekarang Anda berharap Anda telah meluangkan waktu untuk refactor tes Anda dan memiliki satu tempat sentral untuk menerapkan perubahan.

Tentu saja, ada cara yang lebih baik untuk berurusan dengan fitur spesifikasi seperti ini—Halaman objek, misalnya—tapi itu tidak lingkup kami untuk hari ini. Saya rasa itu adalah semua yang Anda perlu tahu tentang metode ekstraksi. Anda dapat menerapkan pola refactoring ini di mana pun dalam kode Anda—tidak hanya dalam spesifikasi, tentu saja. Dalam hal frekuensi penggunaan, saya duga adalah bahwa hal itu akan teknik Anda nomor satu untuk meningkatkan kualitas kode Anda. Selamat bersenang-senang!

Daftar Parameter Long

Mari kita menutup artikel ini dengan sebuah contoh bagaimana Anda dapat langsing parameter Anda. Itu akan membosankan cukup cepat ketika Anda harus memberi makan metode Anda lebih dari satu atau dua argumen. Bukankah lebih baik untuk penurunan objek sebaliknya? Itulah apa yang dapat Anda lakukan jika Anda memperkenalkan sebuah objek parameter.

Parameter ini tidak hanya sakit untuk menulis dan menjaga agar, tetapi juga dapat mengakibatkan kode duplikasi—dan kita pasti ingin menghindari yang sebisa mungkin. Apa yang saya sukai terutama tentang teknik refactoring ini adalah bagaimana ini mempengaruhi metode lain di dalam juga. Sering kita mampu menyingkirkan banyak parameter sampah ke dalam rantai makanan.

Mari kita telusuri contoh sederhana ini. M dapat menugaskan misi baru dan membutuhkan nama misi, agen, dan tujuan. M juga dapat beralih status double-0 agen—artinya lisensi mereka untuk membunuh.

Ketika Anda melihat ini dan bertanya apa yang terjadi ketika "parameter" misi tumbuh dalam kompleksitas, Anda sudah menjadi sesuatu. Itu adalah titik nyeri Anda hanya dapat memecahkan jika Anda lewat di satu objek yang memiliki semua informasi yang Anda butuhkan. Lebih sering daripada tidak, ini juga membantu Anda untuk menjauh dari mengubah metode jika objek parameter perubahan untuk beberapa alasan.

Jadi kami membuat objek baru, Mission, yang hanya berfokus pada penyediaan M dengan informasi yang dibutuhkan untuk menetapkan misi baru dan memberikan #assign_new_mission dengan objek parameter tunggal. Tidak perlu melewati parameter sial ini sendiri. Sebaliknya Anda memberitahu objek untuk mengungkapkan informasi yang Anda butuhkan di dalam metode itu sendiri. Selain itu, kami juga ekstrak beberapa perilaku—informasi cara mencetak—ke objek baru Mission.

Mengapa harus M perlu ketahui tentang bagaimana untuk mencetak misi tugas? #assign baru juga diuntungkan dari ekstraksi dengan kehilangan berat badan karena kita tidak perlu melewati parameter obyek—sehingga tidak perlu untuk menulis hal-hal seperti mission.mission_name, mission.agent_name dan seterusnya. Sekarang kita hanya menggunakan attr_reader(s) kami, yang jauh lebih bersih daripada tanpa ekstraksi. Anda menggali?

Yang juga berguna dalam hal ini adalah bahwa Mission mungkin mengumpulkan segala macam metode atau keadaan tambahan yang dikemas dengan baik di satu tempat dan siap untuk Anda akses.

Dengan teknik ini Anda akan berakhir dengan metode yang lebih singkat, cenderung membaca lebih baik, dan menghindari pengulangan grup parameter yang sama di semua tempat. Cukup bagus! Menyingkirkan identik Rombongan parameter juga merupakan strategi yang penting untuk kode kering.

Cobalah untuk melihat keluar untuk mengeluarkan lebih dari sekedar data Anda. Jika Anda dapat menempatkan perilaku dalam kelas baru juga, Anda akan memiliki benda-benda yang lebih berguna—jika tidak mereka akan segera mulai bau juga.

Tentu saja, sebagian besar waktu Anda akan lari ke versi lebih rumit yang—dan tes Anda akan jelas juga perlu disesuaikan secara bersamaan selama refactorings seperti—tapi jika Anda memiliki contoh sederhana di bawah ikat pinggang Anda, Anda akan siap beraksi.

Aku akan menonton Bond baru sekarang. Mendengar hal ini tidak yang baik, meskipun...

Update: Saw Spectre. Putusan saya: dibandingkan dengan Skyfall — yang adalah MEH imho — Spectre adalah wawawiwa!

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.