Singkatnya: Tergantung
Dalam Rincian
Apakah Anda akan membutuhkan barang yang bersih dan berkilau?
Ada hal-hal yang perlu diwaspadai di sini, dan Anda perlu mengidentifikasi batas antara apa yang nyata, perolehan terukur dan apa yang hanya preferensi pribadi Anda dan kebiasaan buruk potensial untuk menyentuh kode yang seharusnya tidak boleh.
Lebih khusus, ketahui ini:
Ini anti-pola, dan dilengkapi dengan masalah bawaan:
- itu mungkin lebih extensible , tetapi mungkin tidak mudah untuk memperluas,
- itu mungkin tidak sederhana untuk memahami ,
- terakhir, tapi jelas tidak kalah pentingnya di sini: Anda mungkin memperlambat seluruh kode.
Beberapa juga dapat menyebutkan prinsip KISS sebagai referensi, tetapi ini berlawanan dengan intuisi: apakah cara yang dioptimalkan adalah cara yang sederhana atau cara yang dirancang secara jelas? Jawabannya belum tentu absolut, seperti yang dijelaskan dalam sisanya di bawah ini.
The Prinsip YAGNI tidak sepenuhnya ortogonal dengan masalah lain, tetapi hal ini membantu untuk bertanya pada diri sendiri pertanyaan: Anda akan membutuhkannya?
Apakah arsitektur yang lebih kompleks benar-benar memberikan manfaat bagi Anda, selain memberikan penampilan yang lebih dapat dipertahankan?
Tulis ini di poster besar dan gantung di samping layar Anda atau di area dapur di tempat kerja, atau di ruang rapat pengembang. Tentu saja ada banyak mantra lain yang layak untuk diulangi, tetapi mantra ini penting setiap kali Anda mencoba melakukan "pekerjaan pemeliharaan" dan merasakan dorongan untuk "memperbaikinya".
Wajar bagi kita untuk ingin "meningkatkan" kode atau bahkan hanya menyentuhnya, bahkan secara tidak sadar, ketika kita membacanya untuk mencoba memahaminya. Ini adalah hal yang baik, karena itu berarti kami memiliki pendapat dan mencoba untuk mendapatkan pemahaman yang lebih dalam tentang internal, tetapi juga terikat dengan tingkat keterampilan kami, pengetahuan kami (bagaimana Anda memutuskan apa yang lebih baik atau tidak? Baik, lihat bagian di bawah ini ...), dan semua asumsi yang kami buat tentang apa yang kami pikir kami tahu tentang perangkat lunak ...:
- sebenarnya,
- sebenarnya perlu dilakukan,
- pada akhirnya perlu dilakukan,
- dan seberapa baik melakukannya.
Apakah itu benar-benar perlu dioptimalkan?
Semua ini mengatakan, mengapa "dioptimalkan" sejak awal? Mereka mengatakan bahwa pengoptimalan prematur adalah akar dari semua kejahatan, dan jika Anda melihat kode yang tidak terdokumentasi dan tampaknya dioptimalkan, biasanya Anda dapat menganggapnya mungkin tidak mengikuti Aturan Pengoptimalan yang tidak terlalu membutuhkan upaya pengoptimalan dan itu hanya keangkuhan pengembang yang biasa. Sekali lagi, mungkin itu hanya milik Anda yang berbicara sekarang.
Jika ya, dalam batas apa ia diterima? Jika ada kebutuhan untuk itu, batas ini ada, dan memberi Anda ruang untuk meningkatkan hal-hal, atau garis keras untuk memutuskan untuk melepaskannya.
Waspadalah terhadap karakteristik yang tidak terlihat. Kemungkinannya, versi "extensible" dari kode ini akan membuat Anda lebih banyak kehabisan memori saat runtime, dan bahkan menghadirkan jejak memori statis yang lebih besar untuk dieksekusi. Fitur-fitur OO yang mengkilap datang dengan biaya tidak intuitif seperti ini, dan mereka mungkin penting bagi program Anda dan lingkungan yang seharusnya dijalankan.
Mengukur, Mengukur, Mengukur
Sebagai orang Google sekarang, ini semua tentang data! Jika Anda dapat mencadangkannya dengan data, maka itu perlu.
Ada kisah yang tidak terlalu tua ini bahwa untuk setiap $ 1 yang dihabiskan dalam pengembangan itu akan diikuti oleh setidaknya $ 1 dalam pengujian dan setidaknya $ 1 dalam dukungan (tapi sungguh, itu jauh lebih banyak).
Ubah dampak banyak hal:
- Anda mungkin perlu membuat bangunan baru;
- Anda harus menulis unit test baru (pasti jika tidak ada, dan arsitektur Anda yang lebih luas mungkin menyisakan ruang lebih banyak, karena Anda memiliki lebih banyak permukaan untuk bug);
- Anda harus menulis tes kinerja baru (untuk memastikan ini tetap stabil di masa depan, dan untuk melihat di mana hambatannya), dan ini sulit dilakukan ;
- Anda harus mendokumentasikannya (dan lebih dapat diperluas berarti lebih banyak ruang untuk detail);
- Anda (atau orang lain) perlu mengujinya secara ekstensif di QA;
- kode (hampir) tidak pernah bebas bug, dan Anda harus mendukungnya.
Jadi bukan hanya konsumsi sumber daya perangkat keras (kecepatan eksekusi atau jejak memori) yang perlu Anda ukur di sini, tetapi juga konsumsi sumber daya tim . Keduanya perlu diprediksi untuk menentukan tujuan sasaran, diukur, dipertanggungjawabkan, dan diadaptasi berdasarkan pembangunan.
Dan bagi Anda manajer, itu berarti memasukkannya ke dalam rencana pengembangan saat ini, jadi jangan berkomunikasi tentang hal itu dan jangan masuk ke pengkodean cow-boy / submarine / black-ops yang marah.
Secara umum...
Ya tapi...
Jangan salah paham, secara umum, saya akan mendukung melakukan apa yang Anda sarankan, dan saya sering menganjurkannya. Tetapi Anda harus menyadari biaya jangka panjang.
Di dunia yang sempurna, ini adalah solusi yang tepat:
- perangkat keras komputer menjadi lebih baik dari waktu ke waktu,
- kompiler dan platform runtime menjadi lebih baik dari waktu ke waktu,
- Anda mendapatkan kode yang hampir sempurna, bersih, dapat dipelihara dan mudah dibaca.
Dalam praktek:
Anda dapat memperburuknya
Anda membutuhkan lebih banyak bola mata untuk melihatnya, dan semakin rumit, semakin banyak bola mata yang Anda butuhkan.
Anda tidak dapat memprediksi masa depan
Anda tidak dapat mengetahui dengan pasti jika Anda akan membutuhkannya dan bahkan jika "ekstensi" yang Anda perlukan akan lebih mudah dan lebih cepat untuk diterapkan dalam bentuk lama, dan jika mereka perlu dioptimalkan secara super. .
itu mewakili, dari perspektif manajemen, biaya besar tanpa keuntungan langsung.
Jadikan itu Bagian dari Proses
Anda menyebutkan di sini bahwa ini adalah perubahan yang agak kecil, dan Anda memiliki beberapa masalah spesifik dalam pikiran. Menurut saya biasanya tidak apa-apa dalam kasus ini, tetapi kebanyakan dari kita juga memiliki kisah pribadi tentang perubahan kecil, suntingan yang hampir gagal, yang akhirnya berubah menjadi mimpi buruk pemeliharaan dan tenggat waktu yang nyaris terlewat atau meledak karena Joe Programmer tidak melihat satu pun. alasan di balik kode dan menyentuh sesuatu yang seharusnya tidak.
Jika Anda memiliki proses untuk menangani keputusan seperti itu, Anda mengambil keunggulan pribadi dari mereka:
- Jika Anda menguji sesuatu dengan benar, Anda akan tahu lebih cepat jika ada yang rusak,
- Jika Anda mengukurnya, Anda akan tahu jika mereka membaik,
- Jika Anda meninjaunya, Anda akan tahu jika itu membuat orang lain kesal.
Cakupan Tes, Profiling, dan Pengumpulan Data cukup rumit
Namun, tentu saja, kode pengujian dan metrik Anda mungkin mengalami masalah yang sama dengan yang Anda coba hindari untuk kode Anda yang sebenarnya: apakah Anda menguji hal-hal yang benar, dan apakah itu hal yang tepat untuk masa depan, dan apakah Anda mengukur yang benar sesuatu?
Namun, secara umum, semakin Anda menguji (sampai batas tertentu) dan mengukur, semakin banyak data yang Anda kumpulkan dan semakin aman Anda. Waktu analogi yang buruk: anggap itu seperti mengemudi (atau kehidupan secara umum): Anda bisa menjadi pengemudi terbaik di dunia, jika mobil mogok pada Anda atau seseorang memutuskan untuk bunuh diri dengan mengendarai mobil Anda dengan hari ini, Anda keterampilan mungkin tidak cukup. Ada dua hal lingkungan yang dapat menimpa Anda, dan kesalahan manusia juga penting.
Ulasan Kode adalah Pengujian Lorong Tim Pengembang
Dan saya pikir bagian terakhir adalah kuncinya di sini: lakukan review kode. Anda tidak akan tahu nilai peningkatan Anda jika Anda membuatnya sendiri. Ulasan kode adalah "pengujian lorong" kami: ikuti versi Hukum Linus Raymond untuk mendeteksi bug dan mendeteksi rekayasa berlebihan dan pola-anti lainnya, dan untuk memastikan bahwa kode tersebut sesuai dengan kemampuan tim Anda. Tidak ada gunanya memiliki kode "terbaik" jika tidak ada orang lain tetapi Anda dapat memahami dan memeliharanya, dan itu berlaku untuk optimasi samar dan desain arsitektur 6-lapisan yang mendalam.
Sebagai kata penutup, ingat:
Semua orang tahu bahwa debugging dua kali lebih sulit daripada menulis program di tempat pertama. Jadi, jika Anda sepintar ketika Anda menulisnya, bagaimana Anda akan men-debug-nya? - Brian Kernighan