Ada satu prinsip menyeluruh yang mengatur kebutuhan untuk memperbaiki dan mengoptimalkan, baik dalam air terjun maupun Agile: YAGNI (You Ain't Gonna Need It). Prinsip kedua adalah konsekuensi wajar dari yang pertama: "Optimalisasi prematur adalah akar dari semua kejahatan", kode yang setara dengan pepatah umum "musuh keunggulan adalah kesempurnaan".
Mari kita ambil prinsip dan menerapkannya. Anda memiliki persyaratan untuk membangun algoritma ETL yang mengambil file jenis tertentu, mengekstrak informasinya, lalu memasukkan informasi itu ke dalam basis data. Tujuan Anda untuk minggu ini (untuk tujuan kami, tidak masalah apakah Anda berada di toko Agile atau SDLC) adalah untuk menyelesaikannya.
Anda orang yang cerdas, dan Anda telah melihat sekilas gambaran besar. Anda tahu bahwa ini bukan satu-satunya jenis file yang membutuhkan proyek ETL. Jadi, Anda mempertimbangkan untuk mengimplementasikan algoritma ETL ini untuk juga bekerja pada jenis file lain, yang hanya memiliki perbedaan kecil. Melakukan ini akan melanggar YAGNI. Tugas Anda bukanlah mengembangkan algoritma untuk file lain itu; itu adalah untuk mengembangkan algoritma untuk satu file yang dibutuhkan pada akhir minggu. Untuk memenuhi tujuan itu dan lulus tes penerimaan, Anda perlu mengembangkan algoritma itu dan membuatnya bekerja dengan benar. Anda "tidak perlu" kode tambahan untuk membuatnya bekerja dengan file lain. Anda mungkin berpikir itu akan menghemat waktu Anda untuk menggabungkannya sekarang, dan Anda mungkin benar, tetapi Anda mungkin juga sangat salah; algoritme untuk file lain mungkin perlu digunakan di area sistem kode Anda tidak dapat digunakan, atau persyaratan untuk file baru mungkin berbeda dari untuk Anda dengan cara Anda tidak tahu (di Agile, mereka persyaratan mungkin belum ada). Sementara itu, Anda telah membuang-buang waktu dan tidak perlu meningkatkan kompleksitas algoritma Anda.
Sekarang, ini minggu depan, dan sebagai hadiah yang meragukan untuk pekerjaan luar biasa Anda pada algoritma pertama, Anda telah diberi tugas untuk membuat algoritma untuk dua jenis file baru. Sekarang, Anda perlu kode tambahan untuk membuat algoritma Anda bekerja dengan lebih banyak file. Anda dapat memperluas algoritme yang ada dengan menggunakan pola metode templat yang akan menggunakan pola dasar dengan langkah-langkah individual khusus file, atau Anda dapat memperoleh antarmuka umum dari algoritme yang ada, mengembangkan dua yang baru yang mengikuti antarmuka, dan menyambungkannya ke sebuah objek yang dapat memilih algoritma mana yang akan digunakan.
Saat mengembangkan, Anda tahu Anda memiliki persyaratan agar sistem dapat memproses 10KB data mentah per detik. Anda melakukan uji beban dan menemukan draf algoritma awal Anda menangani 8KB / s. Yah, itu tidak akan melewati AAT. Anda melihat dan melihat bahwa ada beberapa struktur loop kompleksitas-O (my God) dalam algoritma Anda; Anda merampingkannya dan mendapatkan 12KB / dtk. "Cukup bagus", menurut Anda, "tetapi jika saya memiliki satu loop yang buruk dalam kode, apa lagi yang bisa saya hilangkan?". buzz Anda baru saja melanggar aturan "optimisasi prematur". Kode Anda berfungsi, dan melewati semua persyaratan. Anda "selesai", hingga persyaratan diperbarui agar memerlukan 15KB / dtk. Jika dan ketika itu terjadi, MAKA Anda menarik kode kembali dan mencari hal-hal untuk diperbaiki.
Ikuti proses sederhana ini sambil mengembangkan, apakah dalam Agile atau dalam SDLC tradisional: "Pada pass pertama, buat itu bekerja. Pada pass kedua, buatlah cantik. Pada pass ketiga, buat itu SOLID." Artinya, ketika Anda pertama kali membuat garis kode, buat kode itu melakukan tugasnya dengan benar dan bebas bug, tetapi jangan terlalu memperhatikan aturan desain dalam kode ini, karena untuk semua yang Anda tahu sekarang, Anda Saya tidak akan pernah menyentuh area ini lagi. Lain kali Anda mengunjungi baris kode itu, Anda hanya membuktikan diri Anda salah; ini bukan lagi bagian dari sistem. Refactor untuk keterbacaan, keringkasan kode, dan / atau prinsip KERING (Anda mungkin telah menyalin beberapa kode untuk melakukan sesuatu lima kali; refactor yang menjadi loop dan / atau pemanggilan metode). Ketiga kalinya Anda bekerja di dalam atau di sekitar baris kode itu,
O(my God)-complexity
jika tidak ada yang lain, buat saya tertawa!