Apakah ada pola anti untuk perangkat lunak yang dikembangkan secara historis? [Tutup]

Apakah ada pola anti yang menggambarkan sistem perangkat lunak yang dikembangkan secara historis di mana banyak pengembang baru saja menambahkan fitur baru ke sistem, tetapi tidak ada yang benar-benar mengawasi arsitektur secara keseluruhan atau refactor yang pernah dilakukan?

Saya pikir ini terjadi ketika manajemen / pelanggan meminta fitur baru secara terus-menerus dan tidak ada yang pernah melakukan refactor apa pun selain hanya menambahkan apa yang telah dilakukan pengembang lain sebelumnya.

Alasannya bisa juga karena pengembang hanya kewalahan dengan sistem perangkat lunak dan tidak benar-benar mengerti cara kerjanya saat ini dan kemudian hanya menambahkan / menempelkan kode-nya di akhir (alih-alih refactoring kode dan mengubahnya.)

Jadi seiring berjalannya waktu semakin sulit untuk mempertahankan sistem.

(Saya ingin tahu apakah ada gambar untuk pola anti semacam ini untuk membuatnya lebih jelas bagi siapa pun yang tidak memprogram - seperti mobil yang dibangun dengan hanya menambah lebih banyak fitur tanpa memikirkan desain keseluruhan. Seperti seseorang memiliki kebutuhan untuk menarik trailer saat mengendarai mundur dan kemudian seorang insinyur hanya mengelas bar derek ke bagian depan mobil. Pekerjaan selesai. Tapi sekarang cowl tidak terbuka lagi.)

Anda mengacu pada hutang teknis .

Kita semua menghasilkan utang teknis dalam produk yang kita kembangkan seiring waktu; refactoring adalah salah satu cara yang sangat umum dan efektif untuk mengurangi utang teknis ini, meskipun banyak perusahaan tidak pernah membayar utang teknis mereka. Perusahaan-perusahaan ini cenderung menemukan perangkat lunak mereka sangat tidak stabil selama bertahun-tahun, dan hutang teknis menjadi begitu mengerikan sehingga Anda tidak dapat membayarnya secara bertahap, karena akan terlalu lama untuk membayarnya dengan cara itu.

Utang teknis memiliki istilah, karena mengikuti perilaku utang yang sama. Anda mendapatkan utang, dan selama Anda terus belanja (membuat fitur) dan tidak membayar utang itu, itu hanya akan tumbuh. Sama seperti utang, ketika terlalu besar, Anda sampai ke titik di mana Anda mungkin ingin menumpahkannya sepenuhnya dengan tugas-tugas berbahaya seperti penulisan ulang penuh. Juga seperti utang nyata, karena bertambah ke titik tertentu, itu menghambat kemampuan Anda untuk menghabiskan (membuat fitur) sama sekali.

Hanya untuk melemparkan istilah lain dalam campuran, kohesi mengacu pada seberapa baik suatu sistem, mikro ke tingkat garis, atau makro ke tingkat sistem, cocok bersama. Sistem yang sangat kohesif akan menyatukan semua bagiannya dengan sangat baik dan terlihat seperti seorang insinyur yang menulis semuanya. Referensi Anda di atas kepada seseorang yang hanya menempelkan kode mereka sampai akhir akan melanggar kohesi sistem itu.

Mengelola Hutang Teknis

Ada banyak cara untuk mengelola utang teknis, meskipun seperti utang nyata, pendekatan terbaik adalah membayarnya sesering mungkin. Sayangnya seperti utang nyata, kadang-kadang lebih baik untuk menambah lebih banyak untuk periode singkat, di mana misalnya waktu untuk memasarkan fitur dapat menggandakan atau melipatgandakan pendapatan Anda. Bagian yang sulit adalah menimbang prioritas yang bersaing ini serta mengidentifikasi kapan ROI utang tidak layak untuk fitur yang diberikan vs ketika itu.

Jadi kadang-kadang layak untuk menambah hutang untuk periode yang singkat, tapi itu jarang terjadi, dan seperti semua hutang, semakin pendek periode semakin baik. Jadi pada akhirnya (lebih disukai cepat ) setelah Anda mendapatkan utang teknis, Anda harus membayarnya, ini adalah pendekatan umum:

• Refactoring
  • Ini memungkinkan Anda untuk mengambil bit kode yang hanya disadari salah diletakkan sebagian atau setelah implementasi selesai, dan menempatkannya di tempat yang benar (atau yang lebih benar lagi).
• Menulis kembali
  • Ini seperti kebangkrutan. Ini menghapus bersih papan tulis, tetapi Anda mulai dengan apa-apa dan memiliki setiap kesempatan untuk membuat kesalahan yang sama, atau yang lebih besar. Risiko tinggi, pendekatan hadiah tinggi untuk utang teknis, tetapi terkadang itu satu - satunya pilihan Anda. Meskipun itu lebih jarang terjadi daripada banyak yang akan memberitahu Anda.
• Tinjauan Arsitektur
  • Ini lebih merupakan pendekatan pembayaran utang teknis yang aktif. Hal ini dilakukan dengan meminta seseorang yang memiliki wewenang atas perincian teknis untuk menghentikan implementasi terlepas dari rencana dan jadwal proyek untuk memastikannya mengurangi hutang teknis.
• Pembekuan kode
  • Membekukan kode perubahan dapat memungkinkan Anda bernapas di mana utang Anda tidak naik atau turun. Ini memberi Anda waktu untuk merencanakan pendekatan Anda untuk mengurangi utang teknis dengan harapan memiliki ROI tertinggi pada pendekatan Anda.
• Modularisasi
  • Ini seperti pendekatan tingkat-2 yang hanya tersedia ketika Anda menggunakan Arsitektur Ikhtisar untuk memiliki sistem modular, atau Refactoring untuk bergerak ke arah itu. Ketika Anda memiliki sistem modular, Anda kemudian dapat membayar utang dalam seluruh bagian sistem secara terpisah. Hal ini memungkinkan Anda untuk melakukan penulisan ulang sebagian , refactoring parsial , serta meminimalkan tingkat utang teknis yang timbul karena isolasi membuat utang hanya di area di mana fitur masuk, sebagai lawan menyebar di sekitar sistem.
• Tes Otomatis
  • Pengujian otomatis dapat membantu dalam mengelola utang teknis Anda, karena mereka dapat membantu Anda mengidentifikasi titik-titik masalah dalam sistem, semoga sebelum utang di daerah-daerah tersebut tumbuh sangat besar, tetapi bahkan setelah itu mereka masih dapat membuat para insinyur menyadari area berbahaya tersebut. mungkin belum menyadari. Selain itu, setelah Anda mendapatkan tes otomatis, Anda dapat lebih bebas melakukan refactor tanpa khawatir melanggar terlalu banyak. Bukan karena pengembang tidak akan memecahkan masalah, tetapi karena mereka akan mencari tahu kapan mereka memecahkan masalah , mengandalkan penguji manual dalam sistem yang sangat berhutang cenderung memiliki rekam jejak yang buruk untuk menemukan masalah.

Deskripsi Anda cocok dengan Foote dan Yoder's Big Ball of Mud :

Selama beberapa tahun terakhir, sejumlah penulis ... telah mempresentasikan pola-pola yang menjadi ciri arsitektur perangkat lunak tingkat tinggi ... Dalam dunia yang ideal, setiap sistem akan menjadi contoh dari satu atau lebih pola-pola tingkat tinggi tersebut. Namun, ini tidak benar. Arsitektur yang sebenarnya mendominasi dalam praktiknya belum dibahas: BALL BIG MUD .

SEBUAH BUD LUMPUR BESAR terstruktur secara serampangan, luas, ceroboh, selotip dan kawat pengikat, hutan kode spageti. Kita semua pernah melihatnya. Sistem-sistem ini menunjukkan tanda-tanda pertumbuhan tidak diatur yang tidak salah, dan perbaikan yang berulang dan bijaksana. Informasi dibagikan secara acak di antara elemen-elemen yang jauh dari sistem, seringkali ke titik di mana hampir semua informasi penting menjadi global atau digandakan. Struktur keseluruhan sistem mungkin tidak pernah didefinisikan dengan baik. Jika ya, itu mungkin telah terkikis tanpa bisa dikenali. Programmer dengan sedikit kepekaan arsitektur menghindari quagmir ini. Hanya mereka yang tidak peduli tentang arsitektur, dan, mungkin, merasa nyaman dengan kelambanan tugas sehari-hari menambal lubang di dalam tanggul yang gagal ini, yang puas bekerja pada sistem seperti itu ...

Mengapa sistem menjadi BALL OF MUD BIG? Terkadang, sistem besar dan jelek muncul dari THROWAWAY CODE . KODE THROWAWAY adalah kode cepat dan kotor yang dimaksudkan untuk digunakan hanya sekali dan kemudian dibuang. Namun, kode seperti itu sering mengambil kehidupan sendiri, meskipun struktur kasual dan dokumentasi yang buruk atau tidak ada. Berhasil, jadi mengapa memperbaikinya? Ketika masalah terkait muncul, cara tercepat untuk mengatasinya mungkin dengan memodifikasi kode kerja ini, daripada merancang program umum yang tepat dari awal. Seiring berjalannya waktu, program pembuangan yang sederhana menghasilkan BUD LUMPUR BESAR.

Bahkan sistem dengan arsitektur yang didefinisikan dengan baik rentan terhadap erosi struktural. Serangan tanpa henti untuk mengubah persyaratan yang menarik sistem yang berhasil dapat secara bertahap merusak strukturnya. Sistem yang dulunya rapi menjadi ditumbuhi seiring PERTUMBUHAN PIECEMEAL secara bertahap memungkinkan elemen sistem terkapar secara tak terkendali.

Jika penyebaran seperti itu terus berlanjut, struktur sistem dapat menjadi sangat dikompromikan sehingga harus ditinggalkan. Seperti halnya lingkungan yang membusuk, spiral ke bawah pun terjadi. Karena sistem menjadi semakin sulit untuk dipahami, pemeliharaan menjadi lebih mahal, dan semakin sulit. Pemrogram yang baik menolak untuk bekerja di sana. Investor menarik modal mereka. Namun, seperti halnya lingkungan, ada cara untuk menghindari, dan bahkan membalikkan, penurunan semacam ini. Seperti halnya hal lain di alam semesta, menangkal kekuatan entropis membutuhkan investasi energi. Gentrifikasi perangkat lunak tidak terkecuali. Cara untuk menangkap entropi dalam perangkat lunak adalah dengan mengubahnya. Komitmen berkelanjutan untuk refactoring dapat menjaga sistem dari mereda menjadi BALL BESAR DARI ...

• ... Salah satu musuh lumpur paling efektif adalah sinar matahari. Menundukkan kode berbelit-belit ke panah pengawasan dapat mengatur panggung untuk refactoring, perbaikan, dan rehabilitasi. Ulasan kode adalah salah satu mekanisme yang dapat digunakan untuk mengekspos kode ke siang hari.