Spaghetti Kode
Oleh
chmood
Spaghetti Kode
Bentuk umum
Spaghetti Kode muncul sebagai program atau sistem yang berisi struktur perangkat lunak sangat sedikit. Coding dan ekstensi progresif kompromi struktur perangkat lunak sedemikian rupa bahwa struktur tidak memiliki kejelasan, bahkan untuk pengembang asli, jika ia jauh dari perangkat lunak untuk waktu yang lama.
Jika dikembangkan menggunakan bahasa berorientasi objek, perangkat lunak mungkin termasuk sejumlah kecil benda yang mengandung metode dengan implementasi yang sangat besar yang memanggil, aliran proses multistage tunggal.
Selanjutnya, metode objek dipanggil dengan cara yang sangat diprediksi, dan ada tingkat diabaikan interaksi dinamis antara objek dalam sistem. Sistem ini sangat sulit untuk mempertahankan dan memperluas, dan tidak ada kesempatan untuk menggunakan kembali objek dan modul dalam sistem serupa lainnya.
Gejala Dan Konsekuensi
Setelah kode pertambangan, hanya bagian dari objek dan metode tampaknya cocok untuk digunakan kembali. Pertambangan Spaghetti Kode sering dapat kembali miskin atas investasi; ini harus diperhitungkan sebelum keputusan untuk tambang dibuat.
Metode yang sangat berorientasi proses; sering, pada kenyataannya, objek yang dinamakan sebagai proses.
Aliran eksekusi ditentukan oleh implementasi objek, bukan oleh klien dari objek.
Hubungan Minimal ada di antara benda-benda.
Banyak metode objek tidak memiliki parameter, dan memanfaatkan kelas atau variabel global untuk diproses.
Pola penggunaan benda sangat diprediksi.
Kode sulit untuk menggunakan kembali, dan ketika itu, sering melalui kloning. Dalam banyak kasus, bagaimanapun, kode tidak pernah dipertimbangkan untuk digunakan kembali.
Berorientasi bakat dari industri sulit untuk mempertahankan.
Manfaat orientasi objek hilang; warisan tidak digunakan untuk memperluas sistem; polimorfisme tidak digunakan.
Ikuti-on pemeliharaan upaya memberikan kontribusi untuk masalah ini.
Software cepat mencapai titik hasil yang menurun; usaha yang terlibat dalam mempertahankan basis kode yang ada lebih besar dari biaya pengembangan solusi baru dari bawah ke atas.
Penyebab khas
Pengalaman dengan teknologi desain berorientasi objek.
Tidak ada mentoring di tempat; ulasan kode tidak efektif.
Tidak ada desain sebelum implementasi.
Sering hasil dari pengembang yang bekerja dalam isolasi.
Dikenal Pengecualian
Spaghetti Kode antipattern cukup diterima ketika interface yang koheren dan hanya pelaksanaannya spaghetti. Ini agak seperti membungkus sepotong NONOBJECT berorientasi kode. Jika masa komponen pendek dan bersih terisolasi dari seluruh sistem, maka beberapa jumlah kode yang buruk dapat ditoleransi.
Realitas industri perangkat lunak adalah bahwa kekhawatiran software biasanya tunduk kepada badan usaha, dan, pada kesempatan, kesuksesan bisnis bergantung pada memberikan produk software secepat mungkin. Jika domain yang tidak akrab dengan arsitek dan pengembang perangkat lunak, mungkin lebih baik untuk mengembangkan produk untuk memperoleh pemahaman tentang domain dengan maksud merancang produk dengan meningkatkan arsitektur di kemudian hari
Solusi refactored
Software refactoring (atau kode pembersihan) merupakan bagian penting dari pengembangan perangkat lunak Tujuh puluh persen atau lebih dari biaya perangkat lunak adalah karena ekstensi, sehingga sangat penting untuk mempertahankan struktur software yang koheren yang mendukung ekstensi.
Ketika struktur menjadi terganggu dengan mendukung persyaratan yang tak terduga, kemampuan kode untuk mendukung ekstensi menjadi terbatas, dan akhirnya, tidak ada. Sayangnya, istilah "kode pembersihan" tidak menarik bagi manajer runcing berambut, sehingga mungkin terbaik untuk membahas masalah ini dengan istilah alternatif seperti "investasi perangkat lunak."
Setelah semua, dalam arti yang sangat nyata, kode pembersihan adalah pemeliharaan investasi perangkat lunak. Kode terstruktur dengan baik akan memiliki siklus hidup lebih lama dan lebih mampu mendukung perubahan dalam bisnis dan teknologi yang mendasari.
Idealnya, kode pembersihan harus menjadi bagian alami dari proses pembangunan. Karena setiap fitur (atau kelompok fitur) ditambahkan ke kode, kode pembersihan harus mengikuti apa yang mengembalikan atau memperbaiki struktur kode. Hal ini dapat terjadi pada setiap jam atau harian, tergantung pada frekuensi penambahan fitur baru.
Kode pembersihan juga mendukung peningkatan kinerja. Biasanya, optimasi kinerja mengikuti aturan 90/10, di mana hanya 10 persen dari kode perlu modifikasi dalam rangka mencapai 90 persen dari kinerja yang optimal. Untuk single-subsistem atau pemrograman aplikasi, optimasi kinerja sering melibatkan kompromi untuk struktur kode.
Tujuan pertama adalah untuk mencapai struktur yang memuaskan; yang kedua adalah untuk menentukan dengan pengukuran di mana kode kinerja kritis ada; yang ketiga adalah untuk hati-hati memperkenalkan kompromi struktur yang diperlukan untuk meningkatkan kinerja. Hal ini kadang-kadang diperlukan untuk membalikkan perubahan peningkatan kinerja dalam perangkat lunak untuk menyediakan ekstensi sistem penting. Daerah seperti pantas dokumentasi tambahan, dalam rangka melestarikan struktur perangkat lunak dalam rilis mendatang.
Membunuh Spaghetti Kode antipattern melalui pencegahan
Cara terbaik untuk menyelesaikan Spaghetti Kode antipattern adalah melalui pencegahan; yaitu, berpikir, kemudian mengembangkan rencana aksi sebelum menulis. Namun, jika basis kode telah merosot ke titik bahwa itu adalah unmaintainable, dan jika rekayasa ulang perangkat lunak bukanlah pilihan, masih ada langkah-langkah yang dapat diambil untuk menghindari menambah masalah.
Pertama, dalam proses pemeliharaan, setiap kali fitur baru ditambahkan ke basis kode Spaghetti Code, tidak memodifikasi Kode Spaghetti hanya dengan menambahkan kode dalam gaya yang serupa dengan minimal memenuhi persyaratan baru. Sebaliknya, selalu menghabiskan waktu refactoring perangkat lunak yang ada menjadi bentuk yang lebih dipertahankan. Refactoring perangkat lunak termasuk melakukan operasi berikut pada kode yang ada:
Mendapatkan akses abstrak untuk variabel anggota dari kelas menggunakan fungsi accessor. Menulis kode baru dan refactored untuk menggunakan fungsi accessor.
Mengkonversi segmen kode ke fungsi yang dapat digunakan kembali dalam pemeliharaan dan refactoring upaya masa depan. Sangat penting untuk menolak melaksanakan antipattern Cut-and-Paste. Sebaliknya, gunakan Cut-and-Paste solusi refactored untuk memperbaiki implementasi sebelumnya dari antipattern Cut-and-Paste.
Menyusun ulang argumen fungsi untuk mencapai konsistensi yang lebih besar di seluruh basis kode. Bahkan konsisten buruk Spaghetti Kode lebih mudah untuk mempertahankan dari konsisten Spaghetti Code.
Hapus bagian dari kode yang mungkin menjadi, atau sudah, tidak dapat diakses. Diulang kegagalan untuk mengidentifikasi dan menghapus bagian usang kode adalah salah satu kontributor utama terhadap Lava Flow antipattern.
Mengubah nama kelas, fungsi, atau tipe data agar sesuai dengan standar perusahaan atau industri dan / atau badan dipertahankan. Kebanyakan perangkat lunak menyediakan dukungan untuk mengubah nama global.
Singkatnya, berkomitmen untuk secara aktif refactoring dan meningkatkan Spaghetti Kode untuk separah yang dialami sebagai sumber memungkinkan setiap kali basis kode harus dimodifikasi. Ini sangat berguna untuk diterapkan unit dan pengujian sistem perangkat dan aplikasi untuk memastikan refactoring yang tidak segera memperkenalkan cacat baru ke dalam basis kode.
Bukti empiris menunjukkan bahwa manfaat dari refactoring perangkat lunak sangat besar daripada risiko bahwa modifikasi tambahan dapat menghasilkan cacat baru.
Metode pencegahan lainnya
Jika pencegahan Spaghetti Kode adalah pilihan, atau jika Anda memiliki kemewahan rekayasa sepenuhnya aplikasi Spaghetti Code, langkah-langkah pencegahan berikut dapat diambil:
Bersikeras pada proses analisis berorientasi objek yang tepat untuk menciptakan model domain, terlepas dari seberapa baik domain dipahami. Sangat penting bahwa setiap proyek-ukuran besar sedang-atau mengembangkan model domain sebagai dasar desain dan pengembangan. Jika domain sepenuhnya dipahami ke titik bahwa model domain tidak diperlukan, counter dengan "Jika itu benar, maka waktu untuk mengembangkan satu akan diabaikan." Jika itu benar-benar adalah, maka dengan sopan mengakui Anda keliru. Jika tidak, waktu yang dibutuhkan membenarkan betapa itu diperlukan.
Setelah mengembangkan model domain yang menjelaskan persyaratan sistem dan berbagai variabilitas yang harus ditangani, mengembangkan model desain terpisah. Meskipun berlaku untuk menggunakan model domain sebagai titik awal untuk desain, model domain harus dipertahankan seperti untuk mempertahankan informasi yang berguna yang lain akan hilang jika diizinkan untuk berkembang secara langsung menjadi model desain. Tujuan dari model desain adalah untuk mengekstrak kesamaan antara objek domain dan abstrak untuk memperjelas objek yang diperlukan dan hubungan dalam sistem. Benar dilakukan, menetapkan batas-batas untuk implementasi software. Implementasi harus dilakukan hanya dalam rangka untuk memenuhi persyaratan sistem, baik secara eksplisit ditunjukkan dengan model domain atau diantisipasi oleh arsitek sistem atau pengembang senior.
Dalam pengembangan model desain, penting untuk memastikan bahwa benda-benda yang membusuk ke tingkat di mana mereka sepenuhnya dipahami oleh pengembang. Ini adalah pengembang, bukan desainer, yang harus percaya modul software yang mudah diterapkan.
Setelah lulus pertama telah dilakukan pada kedua domain dan model desain, mulai pelaksanaan berdasarkan rencana yang ditetapkan oleh desain. Desain tidak harus lengkap; tujuannya adalah bahwa pelaksanaan komponen perangkat lunak harus selalu menurut beberapa rencana yang telah ditetapkan. Setelah pembangunan dimulai, lanjutkan untuk secara bertahap memeriksa bagian lain dari model domain dan desain bagian lain dari sistem. Seiring waktu, model domain dan model desain akan disempurnakan untuk mengakomodasi penemuan dalam persyaratan pengumpulan, keputusan desain, dan untuk mengatasi isu-isu implementasi. Sekali lagi, Spaghetti Kode jauh lebih mungkin terjadi jika ada proses perangkat lunak secara keseluruhan di mana persyaratan dan desain yang ditentukan sebelum pelaksanaan, bukan terjadi secara bersamaan.
Contoh
Ini adalah masalah yang sering ditunjukkan oleh orang-orang baru untuk object-oriented pengembangan, yang memetakan persyaratan sistem langsung ke fungsi, menggunakan benda sebagai tempat untuk fungsi kelompok terkait. Setiap fungsi berisi alur proses seluruh yang benar-benar mengimplementasikan tugas tertentu.
Sebagai contoh, segmen kode yang berikut berisi fungsi seperti initMenus (), getConnection (), dan executeQuery (), yang benar-benar melaksanakan operasi tertentu. Setiap metode objek berisi aliran proses tunggal yang melakukan semua langkah dalam urutan yang dibutuhkan untuk melakukan tugas tersebut.
Objek mempertahankan informasi sedikit atau tidak ada negara antara doa yang berurutan; bukan, variabel kelas yang lokasi penyimpanan sementara untuk menangani hasil antara dari aliran proses tunggal.
Solusi terkait
Analisis Kelumpuhan. Antipattern ini adalah hasil dari mengambil solusi untuk ekstrim logis. Daripada mengembangkan kode ad hoc tanpa desain untuk memandu keseluruhan struktur kode, Analisis Kelumpuhan menghasilkan desain rinci tanpa pernah mencapai titik di mana implementasi dapat dimulai.
Aliran lava. Antipattern ini sering berisi beberapa contoh Spaghetti Code yang mencegah refactoring dari basis kode yang ada. Dengan Lava Flow, basis kode memiliki tujuan logis di beberapa titik dalam siklus hidupnya, tetapi bagian-bagian menjadi usang, namun tetap sebagai bagian dari basis kode.
Antipattern Nama: Spaghetti Kode
Kebanyakan Skala Berlaku: Aplikasi
Refactored Solusi Nama: Software Refactoring, Kode Cleanup
Refactored Solusi Jenis: Software
Penyebab root: Ketidaktahuan, Sloth
Angkatan seimbang: Manajemen Kompleksitas, Perubahan
Anekdot Bukti: "Ugh Kacau!!" "Anda melakukan menyadari bahwa bahasa mendukung lebih dari satu fungsi, kan?" "Lebih mudah untuk menulis ulang kode ini daripada mencoba untuk memodifikasinya." "Insinyur perangkat lunak tidak menulis kode spaghetti." "Kualitas struktur perangkat lunak Anda merupakan investasi untuk modifikasi masa depan dan ekstensi."
Latar belakang
Spaghetti Kode Anti Pola adalah antipattern klasik dan paling terkenal; itu telah ada dalam satu bentuk atau lain sejak penemuan bahasa pemrograman. Bahasa non berorientasi objek tampak lebih rentan terhadap antipattern ini, tetapi cukup umum di antara para pengembang yang belum sepenuhnya menguasai konsep canggih yang mendasari orientasi objek.
Bentuk umum
Spaghetti Kode muncul sebagai program atau sistem yang berisi struktur perangkat lunak sangat sedikit. Coding dan ekstensi progresif kompromi struktur perangkat lunak sedemikian rupa bahwa struktur tidak memiliki kejelasan, bahkan untuk pengembang asli, jika ia jauh dari perangkat lunak untuk waktu yang lama.
Jika dikembangkan menggunakan bahasa berorientasi objek, perangkat lunak mungkin termasuk sejumlah kecil benda yang mengandung metode dengan implementasi yang sangat besar yang memanggil, aliran proses multistage tunggal.
Selanjutnya, metode objek dipanggil dengan cara yang sangat diprediksi, dan ada tingkat diabaikan interaksi dinamis antara objek dalam sistem. Sistem ini sangat sulit untuk mempertahankan dan memperluas, dan tidak ada kesempatan untuk menggunakan kembali objek dan modul dalam sistem serupa lainnya.
Gejala Dan Konsekuensi
Setelah kode pertambangan, hanya bagian dari objek dan metode tampaknya cocok untuk digunakan kembali. Pertambangan Spaghetti Kode sering dapat kembali miskin atas investasi; ini harus diperhitungkan sebelum keputusan untuk tambang dibuat.
Metode yang sangat berorientasi proses; sering, pada kenyataannya, objek yang dinamakan sebagai proses.
Aliran eksekusi ditentukan oleh implementasi objek, bukan oleh klien dari objek.
Hubungan Minimal ada di antara benda-benda.
Banyak metode objek tidak memiliki parameter, dan memanfaatkan kelas atau variabel global untuk diproses.
Pola penggunaan benda sangat diprediksi.
Kode sulit untuk menggunakan kembali, dan ketika itu, sering melalui kloning. Dalam banyak kasus, bagaimanapun, kode tidak pernah dipertimbangkan untuk digunakan kembali.
Berorientasi bakat dari industri sulit untuk mempertahankan.
Manfaat orientasi objek hilang; warisan tidak digunakan untuk memperluas sistem; polimorfisme tidak digunakan.
Ikuti-on pemeliharaan upaya memberikan kontribusi untuk masalah ini.
Software cepat mencapai titik hasil yang menurun; usaha yang terlibat dalam mempertahankan basis kode yang ada lebih besar dari biaya pengembangan solusi baru dari bawah ke atas.
Penyebab khas
Pengalaman dengan teknologi desain berorientasi objek.
Tidak ada mentoring di tempat; ulasan kode tidak efektif.
Tidak ada desain sebelum implementasi.
Sering hasil dari pengembang yang bekerja dalam isolasi.
Dikenal Pengecualian
Spaghetti Kode antipattern cukup diterima ketika interface yang koheren dan hanya pelaksanaannya spaghetti. Ini agak seperti membungkus sepotong NONOBJECT berorientasi kode. Jika masa komponen pendek dan bersih terisolasi dari seluruh sistem, maka beberapa jumlah kode yang buruk dapat ditoleransi.
Realitas industri perangkat lunak adalah bahwa kekhawatiran software biasanya tunduk kepada badan usaha, dan, pada kesempatan, kesuksesan bisnis bergantung pada memberikan produk software secepat mungkin. Jika domain yang tidak akrab dengan arsitek dan pengembang perangkat lunak, mungkin lebih baik untuk mengembangkan produk untuk memperoleh pemahaman tentang domain dengan maksud merancang produk dengan meningkatkan arsitektur di kemudian hari
Solusi refactored
Software refactoring (atau kode pembersihan) merupakan bagian penting dari pengembangan perangkat lunak Tujuh puluh persen atau lebih dari biaya perangkat lunak adalah karena ekstensi, sehingga sangat penting untuk mempertahankan struktur software yang koheren yang mendukung ekstensi.
Ketika struktur menjadi terganggu dengan mendukung persyaratan yang tak terduga, kemampuan kode untuk mendukung ekstensi menjadi terbatas, dan akhirnya, tidak ada. Sayangnya, istilah "kode pembersihan" tidak menarik bagi manajer runcing berambut, sehingga mungkin terbaik untuk membahas masalah ini dengan istilah alternatif seperti "investasi perangkat lunak."
Setelah semua, dalam arti yang sangat nyata, kode pembersihan adalah pemeliharaan investasi perangkat lunak. Kode terstruktur dengan baik akan memiliki siklus hidup lebih lama dan lebih mampu mendukung perubahan dalam bisnis dan teknologi yang mendasari.
Idealnya, kode pembersihan harus menjadi bagian alami dari proses pembangunan. Karena setiap fitur (atau kelompok fitur) ditambahkan ke kode, kode pembersihan harus mengikuti apa yang mengembalikan atau memperbaiki struktur kode. Hal ini dapat terjadi pada setiap jam atau harian, tergantung pada frekuensi penambahan fitur baru.
Kode pembersihan juga mendukung peningkatan kinerja. Biasanya, optimasi kinerja mengikuti aturan 90/10, di mana hanya 10 persen dari kode perlu modifikasi dalam rangka mencapai 90 persen dari kinerja yang optimal. Untuk single-subsistem atau pemrograman aplikasi, optimasi kinerja sering melibatkan kompromi untuk struktur kode.
Tujuan pertama adalah untuk mencapai struktur yang memuaskan; yang kedua adalah untuk menentukan dengan pengukuran di mana kode kinerja kritis ada; yang ketiga adalah untuk hati-hati memperkenalkan kompromi struktur yang diperlukan untuk meningkatkan kinerja. Hal ini kadang-kadang diperlukan untuk membalikkan perubahan peningkatan kinerja dalam perangkat lunak untuk menyediakan ekstensi sistem penting. Daerah seperti pantas dokumentasi tambahan, dalam rangka melestarikan struktur perangkat lunak dalam rilis mendatang.
Membunuh Spaghetti Kode antipattern melalui pencegahan
Cara terbaik untuk menyelesaikan Spaghetti Kode antipattern adalah melalui pencegahan; yaitu, berpikir, kemudian mengembangkan rencana aksi sebelum menulis. Namun, jika basis kode telah merosot ke titik bahwa itu adalah unmaintainable, dan jika rekayasa ulang perangkat lunak bukanlah pilihan, masih ada langkah-langkah yang dapat diambil untuk menghindari menambah masalah.
Pertama, dalam proses pemeliharaan, setiap kali fitur baru ditambahkan ke basis kode Spaghetti Code, tidak memodifikasi Kode Spaghetti hanya dengan menambahkan kode dalam gaya yang serupa dengan minimal memenuhi persyaratan baru. Sebaliknya, selalu menghabiskan waktu refactoring perangkat lunak yang ada menjadi bentuk yang lebih dipertahankan. Refactoring perangkat lunak termasuk melakukan operasi berikut pada kode yang ada:
Mendapatkan akses abstrak untuk variabel anggota dari kelas menggunakan fungsi accessor. Menulis kode baru dan refactored untuk menggunakan fungsi accessor.
Mengkonversi segmen kode ke fungsi yang dapat digunakan kembali dalam pemeliharaan dan refactoring upaya masa depan. Sangat penting untuk menolak melaksanakan antipattern Cut-and-Paste. Sebaliknya, gunakan Cut-and-Paste solusi refactored untuk memperbaiki implementasi sebelumnya dari antipattern Cut-and-Paste.
Menyusun ulang argumen fungsi untuk mencapai konsistensi yang lebih besar di seluruh basis kode. Bahkan konsisten buruk Spaghetti Kode lebih mudah untuk mempertahankan dari konsisten Spaghetti Code.
Hapus bagian dari kode yang mungkin menjadi, atau sudah, tidak dapat diakses. Diulang kegagalan untuk mengidentifikasi dan menghapus bagian usang kode adalah salah satu kontributor utama terhadap Lava Flow antipattern.
Mengubah nama kelas, fungsi, atau tipe data agar sesuai dengan standar perusahaan atau industri dan / atau badan dipertahankan. Kebanyakan perangkat lunak menyediakan dukungan untuk mengubah nama global.
Singkatnya, berkomitmen untuk secara aktif refactoring dan meningkatkan Spaghetti Kode untuk separah yang dialami sebagai sumber memungkinkan setiap kali basis kode harus dimodifikasi. Ini sangat berguna untuk diterapkan unit dan pengujian sistem perangkat dan aplikasi untuk memastikan refactoring yang tidak segera memperkenalkan cacat baru ke dalam basis kode.
Bukti empiris menunjukkan bahwa manfaat dari refactoring perangkat lunak sangat besar daripada risiko bahwa modifikasi tambahan dapat menghasilkan cacat baru.
Metode pencegahan lainnya
Jika pencegahan Spaghetti Kode adalah pilihan, atau jika Anda memiliki kemewahan rekayasa sepenuhnya aplikasi Spaghetti Code, langkah-langkah pencegahan berikut dapat diambil:
Bersikeras pada proses analisis berorientasi objek yang tepat untuk menciptakan model domain, terlepas dari seberapa baik domain dipahami. Sangat penting bahwa setiap proyek-ukuran besar sedang-atau mengembangkan model domain sebagai dasar desain dan pengembangan. Jika domain sepenuhnya dipahami ke titik bahwa model domain tidak diperlukan, counter dengan "Jika itu benar, maka waktu untuk mengembangkan satu akan diabaikan." Jika itu benar-benar adalah, maka dengan sopan mengakui Anda keliru. Jika tidak, waktu yang dibutuhkan membenarkan betapa itu diperlukan.
Setelah mengembangkan model domain yang menjelaskan persyaratan sistem dan berbagai variabilitas yang harus ditangani, mengembangkan model desain terpisah. Meskipun berlaku untuk menggunakan model domain sebagai titik awal untuk desain, model domain harus dipertahankan seperti untuk mempertahankan informasi yang berguna yang lain akan hilang jika diizinkan untuk berkembang secara langsung menjadi model desain. Tujuan dari model desain adalah untuk mengekstrak kesamaan antara objek domain dan abstrak untuk memperjelas objek yang diperlukan dan hubungan dalam sistem. Benar dilakukan, menetapkan batas-batas untuk implementasi software. Implementasi harus dilakukan hanya dalam rangka untuk memenuhi persyaratan sistem, baik secara eksplisit ditunjukkan dengan model domain atau diantisipasi oleh arsitek sistem atau pengembang senior.
Dalam pengembangan model desain, penting untuk memastikan bahwa benda-benda yang membusuk ke tingkat di mana mereka sepenuhnya dipahami oleh pengembang. Ini adalah pengembang, bukan desainer, yang harus percaya modul software yang mudah diterapkan.
Setelah lulus pertama telah dilakukan pada kedua domain dan model desain, mulai pelaksanaan berdasarkan rencana yang ditetapkan oleh desain. Desain tidak harus lengkap; tujuannya adalah bahwa pelaksanaan komponen perangkat lunak harus selalu menurut beberapa rencana yang telah ditetapkan. Setelah pembangunan dimulai, lanjutkan untuk secara bertahap memeriksa bagian lain dari model domain dan desain bagian lain dari sistem. Seiring waktu, model domain dan model desain akan disempurnakan untuk mengakomodasi penemuan dalam persyaratan pengumpulan, keputusan desain, dan untuk mengatasi isu-isu implementasi. Sekali lagi, Spaghetti Kode jauh lebih mungkin terjadi jika ada proses perangkat lunak secara keseluruhan di mana persyaratan dan desain yang ditentukan sebelum pelaksanaan, bukan terjadi secara bersamaan.
Contoh
Ini adalah masalah yang sering ditunjukkan oleh orang-orang baru untuk object-oriented pengembangan, yang memetakan persyaratan sistem langsung ke fungsi, menggunakan benda sebagai tempat untuk fungsi kelompok terkait. Setiap fungsi berisi alur proses seluruh yang benar-benar mengimplementasikan tugas tertentu.
Sebagai contoh, segmen kode yang berikut berisi fungsi seperti initMenus (), getConnection (), dan executeQuery (), yang benar-benar melaksanakan operasi tertentu. Setiap metode objek berisi aliran proses tunggal yang melakukan semua langkah dalam urutan yang dibutuhkan untuk melakukan tugas tersebut.
Objek mempertahankan informasi sedikit atau tidak ada negara antara doa yang berurutan; bukan, variabel kelas yang lokasi penyimpanan sementara untuk menangani hasil antara dari aliran proses tunggal.
Solusi terkait
Analisis Kelumpuhan. Antipattern ini adalah hasil dari mengambil solusi untuk ekstrim logis. Daripada mengembangkan kode ad hoc tanpa desain untuk memandu keseluruhan struktur kode, Analisis Kelumpuhan menghasilkan desain rinci tanpa pernah mencapai titik di mana implementasi dapat dimulai.
Aliran lava. Antipattern ini sering berisi beberapa contoh Spaghetti Code yang mencegah refactoring dari basis kode yang ada. Dengan Lava Flow, basis kode memiliki tujuan logis di beberapa titik dalam siklus hidupnya, tetapi bagian-bagian menjadi usang, namun tetap sebagai bagian dari basis kode.
Category
Komentar