Aturan praktis saya adalah bahwa ketika saya harus melakukan sesuatu untuk ketiga kalinya, saatnya untuk menulis naskah kecil untuk mengotomatiskannya, atau memikirkan kembali pendekatan saya.
Saya tidak membuat "alat" penuh pada saat ini, hanya sedikit skrip (biasanya bash atau python; perl akan bekerja juga, atau bahkan PHP) yang mengotomatiskan apa yang saya lakukan secara manual sebelumnya. Ini pada dasarnya merupakan penerapan prinsip KERING (atau prinsip Sumber Tunggal Kebenaran, yang pada dasarnya adalah hal yang sama) - jika Anda harus mengubah dua file sumber secara bersamaan, harus ada beberapa kebenaran umum yang mereka bagikan, dan bahwa kebenaran harus diperhitungkan dan disimpan di satu tempat utama. Sangat bagus jika Anda dapat menyelesaikan ini secara internal dengan refactoring, tetapi kadang-kadang, ini tidak layak, dan di situlah skrip kustom masuk.
Kemudian nanti, skrip mungkin berkembang atau tidak menjadi alat yang lengkap, tetapi saya biasanya memulai dengan skrip yang sangat spesifik dengan banyak hal yang dikodekan ke dalamnya.
Saya benci pekerjaan kasar dengan hasrat, tetapi saya juga sangat percaya bahwa itu adalah tanda desain yang buruk atau salah. Menjadi malas adalah kualitas penting dalam seorang programmer, dan lebih baik menjadi jenis di mana Anda berusaha keras untuk menghindari pekerjaan yang berulang.
Tentu, kadang-kadang saldo negatif - Anda menghabiskan tiga jam refactoring kode Anda atau menulis skrip untuk menghemat satu jam pekerjaan berulang; tetapi biasanya, keseimbangannya positif, apalagi jika Anda mempertimbangkan biaya yang tidak langsung terlihat: kegagalan manusia (manusia benar-benar buruk dalam pekerjaan yang berulang), basis kode yang lebih kecil, pemeliharaan yang lebih baik karena pengurangan yang berlebihan, dokumentasi mandiri yang lebih baik, masa depan yang lebih cepat pengembangan, kode bersih. Jadi, bahkan jika saldo tampak negatif sekarang, basis kode akan tumbuh lebih lanjut, dan alat yang Anda tulis untuk menghasilkan formulir web untuk tiga objek data akan tetap berfungsi saat Anda memiliki tiga puluh objek data. Dalam pengalaman saya, keseimbangan biasanya diestimasi mendukung pekerjaan kasar, mungkin karena tugas berulang lebih mudah untuk diperkirakan dan dengan demikian di bawah perkiraan, sementara refactoring, automating dan abstrak dianggap kurang dapat diprediksi dan lebih berbahaya, dan dengan demikian di atas perkiraan. Biasanya ternyata otomatisasi tidak terlalu sulit.
Dan kemudian ada risiko melakukannya terlambat: mudah untuk memperbaiki tiga kelas objek data baru menjadi bentuk dan menulis skrip yang menghasilkan formulir web untuk mereka, dan setelah Anda melakukannya, mudah untuk menambahkan 27 kelas lagi yang juga bekerja dengan skrip Anda. Tetapi hampir tidak mungkin untuk menulis skrip itu ketika Anda telah mencapai titik di mana ada 30 kelas objek data, masing-masing dengan formulir web tulisan tangan, dan tanpa konsistensi di antara mereka (alias "pertumbuhan organik"). Mempertahankan 30 kelas dengan bentuk mereka adalah mimpi buruk pengodean berulang dan pencarian semi-manual, mengganti aspek umum membutuhkan waktu tiga puluh kali lebih lama dari yang seharusnya, tetapi menulis skrip untuk menyelesaikan masalah, yang akan menjadi istirahat makan siang ketika proyek dimulai sekarang adalah proyek dua minggu yang menakutkan dengan prospek yang menakutkan setelah sebulan yang terdiri dari memperbaiki bug, mendidik pengguna, dan bahkan mungkin menyerah dan kembali ke basis kode lama. Ironisnya, menulis kekacauan 30-kelas membutuhkan waktu lebih lama daripada solusi bersih, karena Anda bisa menggunakan skrip yang nyaman sepanjang waktu itu. Dalam pengalaman saya, mengotomatiskan pekerjaan berulang sangat terlambat adalah salah satu masalah utama dalam proyek perangkat lunak besar yang sudah berjalan lama. karena Anda bisa saja mengendarai skrip yang nyaman sepanjang waktu itu. Dalam pengalaman saya, mengotomatiskan pekerjaan berulang sangat terlambat adalah salah satu masalah utama dalam proyek perangkat lunak besar yang sudah berjalan lama. karena Anda bisa saja mengendarai skrip yang nyaman sepanjang waktu itu. Dalam pengalaman saya, mengotomatiskan pekerjaan berulang sangat terlambat adalah salah satu masalah utama dalam proyek perangkat lunak besar yang sudah berjalan lama.