Flamboyan


Bliki

Saat ini, tim sedang berupaya memperbarui komponen penetapan harga untuk menambahkan dukungan untuk risiko dari badai. Mereka tahu bahwa dalam waktu enam bulan, mereka juga perlu mendukung penetapan harga untuk risiko pembajakan. Karena mereka saat ini bekerja pada mesin penetapan harga, mereka mempertimbangkan untuk membangun fitur dugaan untuk harga pembajakan sekarang, karena dengan cara itu layanan penetapan harga akan lengkap sebelum mereka mulai bekerja pada perangkat lunak penjualan. Saya mengatasinya dengan menunjukkan betapa sulit dan mahalnya itu. untuk mengetahui kebutuhan Anda di muka, tetapi bahkan jika Anda bisa, Anda masih bisa membabi buta ketika Angkatan Laut Gondor menyapu bersih para perompak, sehingga merusak seluruh model bisnis. Guru persyaratan yang digerakkan oleh rencana mungkin berpendapat bahwa ini adalah karena kami tidak melakukan pekerjaan yang cukup baik dari analisis persyaratan kami, kami harusnya meluangkan lebih banyak waktu dan upaya untuk melakukannya. Argumen pertama untuk yagni adalah bahwa sementara kita sekarang mungkin berpikir kita membutuhkan fitur dugaan ini, kemungkinan kita akan salah. Jika kita malah menggunakan energi kita untuk membangun perangkat lunak penjualan untuk risiko cuaca, kita bisa saja membuat badai besar fitur risiko dalam produksi dan menghasilkan pendapatan dua bulan sebelumnya. Tapi mari kita pertimbangkan bahwa kita sepenuhnya benar dengan pemahaman kita tentang kebutuhan kita, dan Angkatan Laut Gondor tidak membasmi para perompak.Salah satu pendekatan yang saya gunakan ketika membimbing pengembang dalam situasi ini adalah meminta mereka untuk membayangkan refactoring yang harus mereka lakukan nanti untuk memperkenalkan kemampuan ketika dibutuhkan. Hasil lain dari imajinasi seperti itu adalah menambahkan sesuatu yang mudah dilakukan sekarang, menambah kompleksitas minimal, namun secara signifikan mengurangi biaya nantinya. Menggunakan tabel pencarian untuk pesan kesalahan daripada literal inline adalah contoh yang sederhana namun membuat terjemahan lebih mudah didukung. Seringkali eksperimen pemikiran itu cukup untuk meyakinkan mereka bahwa tidak akan jauh lebih mahal untuk menambahkannya nanti. Jika kita tidak pernah membutuhkan perangkat lunak harga pembajakan, kita akan mengeluarkan biaya untuk setiap fitur yang dibangun sampai kita menghapus pembajakan -Fitur mahal, bersama dengan biaya menghapusnya. Kode untuk fitur dugaan menambahkan beberapa kompleksitas pada perangkat lunak, kompleksitas ini membuatnya lebih sulit untuk memodifikasi dan men-debug perangkat lunak itu, sehingga meningkatkan biaya fitur lainnya. Kompleksitas ekstra dari memiliki fitur harga pembajakan dalam perangkat lunak mungkin menambah beberapa minggu untuk berapa lama waktu yang dibutuhkan untuk membangun komponen penjualan asuransi badai. Dua minggu itu menyentuh dua cara: biaya tambahan untuk membangun fitur, ditambah biaya keterlambatan tambahan karena terlihat lebih lama untuk dimasukkan ke dalam produksi. Kami akan dikenakan biaya untuk setiap fitur yang dibangun antara sekarang dan saat perangkat lunak asuransi pembajakan mulai berguna. Biaya keterlambatan adalah salah satu biaya yang dibebankan oleh fitur dugaan yang sukses, tetapi yang lain adalah biaya membawa.
Dalam hal ini Anda telah mengakumulasi TechnicalDebt dan harus mempertimbangkan biaya perbaikan untuk fitur tersebut atau biaya yang sedang berjalan untuk mengatasi kesulitannya. Semua ini berarti Anda sering menyadari bahwa fitur yang dikodekan enam bulan lalu tidak dilakukan seperti yang Anda sadari sekarang. Secara alami sebenarnya ada spektrum di sana, dan dengan satu titik pada spektrum itu yang patut disorot: fitur yang tepat salah dibangun. Yagni mengatakan untuk tidak melakukan ini, karena Anda mungkin tidak memerlukan fungsi penetapan harga lainnya, atau jika Anda melakukan ide Anda tentang apa abstraksi yang Anda butuhkan tidak akan cocok dengan apa yang Anda pelajari ketika Anda benar-benar membutuhkannya. Ini tidak berarti melepaskan semua abstraksi, tetapi itu berarti abstraksi apa pun yang membuatnya lebih sulit untuk memahami kode untuk persyaratan saat ini dianggap bersalah. Saat membuat kalkulator risiko badai, Anda dapat mempertimbangkan abstraksi dan parameterisasi sekarang untuk mendukung pembajakan dan risiko lainnya nanti. Contoh asuransi saya berbicara tentang fungsionalitas yang relatif terlihat oleh pengguna, tetapi argumen yang sama berlaku untuk abstraksi untuk mendukung fleksibilitas di masa depan.Satu masalah yang saya lihat dengan ini adalah karena seluruh ekspresi reguler disorot, saya tidak dapat menangani kasus di mana saya memerlukan regex untuk mencocokkan bagian yang lebih besar daripada apa yang ingin saya sorot. Tapi saya belum perlu menggunakan regex yang cocok dengan lebih dari apa yang saya sorot, jadi saya belum memperpanjang kode sorotan saya untuk menangani kasus ini - dan tidak akan sampai saya benar-benar membutuhkannya. Saya berharap saya bisa menyelesaikannya dengan menggunakan grup di dalam regex dan membiarkan kode saya hanya menyoroti grup jika ada grup. Yagni terlihat paling jelas dengan fitur-fitur yang lebih besar, tetapi Anda melihatnya lebih sering dengan hal-hal kecil. Yagni hanya strategi yang layak jika kodenya mudah diubah, jadi upaya pengeluaran untuk refactoring bukan pelanggaran yagni karena refactoring membuat kode lebih mudah ditempa. Yagni hanya berlaku untuk kemampuan yang dibangun ke dalam perangkat lunak untuk mendukung fitur dugaan, itu tidak berlaku untuk upaya membuat perangkat lunak lebih mudah untuk dimodifikasi. Ini adalah praktik yang memungkinkan untuk desain evolusi, tanpa mereka, yagni berubah dari praktik yang menguntungkan menjadi kutukan. Setelah mengatakan semua ini, ada kalanya menerapkan yagni memang menyebabkan masalah, dan Anda dihadapkan dengan perubahan mahal ketika perubahan sebelumnya harus jauh lebih murah. Yang sulit di sini adalah bahwa kasus-kasus ini sulit dikenali sebelumnya, dan jauh lebih mudah diingat daripada kasus-kasus di mana upaya yagni menyelamatkan. Perasaan saya adalah bahwa kegagalan yagni relatif jarang terjadi dan biayanya dengan mudah melebihi ketika yagni berhasil. (source)