Apakah Anda dapat menerapkan pola desain dalam tenggat waktu yang ketat?

Saya bertanya-tanya, dalam tenggat waktu yang ketat, siapa yang punya waktu untuk menerapkan pola desain? Ini lebih banyak pekerjaan dan pemrograman overhead untuk memperbaikinya pertama kali dan dalam kerangka waktu. Saya tahu bahwa itu memiliki keuntungan jangka panjang, tetapi apakah Anda dapat menerapkan pola desain dengan benar ketika klien duduk di atas kepala Anda dan tekanan tumbuh.

Saya pikir begitu versi pertama Anda dirilis dan Anda punya banyak waktu untuk rilis berikutnya, daripada yang dapat Anda pikirkan untuk meningkatkan kualitas kode dan pengelolaan dengan pola desain.

Ini lebih banyak pekerjaan dan pemrograman overhead untuk memperbaikinya pertama kali dan dalam kerangka waktu.

Itu salah.

Tanpa manfaat dari seseorang yang telah memikirkan pola desain, dan menjelaskan dan mendokumentasikannya, itu akan menjadi dua kali lebih sulit.

Pola desain menyederhanakan semua pemikiran dan bertanya-tanya dan memutuskan.

Anda tidak perlu menemukan sesuatu yang baru. Anda dapat menggunakan sesuatu yang sudah dipahami dengan baik oleh Anda dan orang lain.

Pola desain memungkinkan Anda untuk berpikir lebih sedikit. Itu benar-benar intinya. Ada sedikit dikotemik palsu yang tersirat dalam pertanyaan itu. Ini menunjukkan bahwa Anda menggunakan pola desain, atau tidak menggunakan pola sama sekali. Pilihan yang sebenarnya adalah antara menggunakan pola yang dibuat atau pola buatan sendiri. Terkadang desain Anda akan lebih baik daripada pendekatan yang direkomendasikan, tapi ... biasanya tidak. Mengapa harus melalui semua pekerjaan memecahkan masalah yang telah dipecahkan dengan baik. Versi setengah matang Anda sendiri hampir tidak akan pernah sebagus ini, dan Anda harus membuang semua pemikiran yang berpikir itu.

Dalam pengalaman saya, cepat & kotor adalah sebuah oxymoron. Setiap saat Anda dapat menghemat dengan menghemat desain hampir selalu dikonsumsi oleh debugging tambahan.

Jangan berkomitmen pada tenggat waktu yang tidak memberi Anda cukup waktu untuk melakukan hal-hal yang benar. Anda harus membayar kembali hutang teknis pada akhirnya, dan semakin banyak kode yang Anda miliki sebelum Anda mulai memasukkan kembali hal-hal menjadi desain yang waras, semakin sulit. Itu berarti lebih banyak pekerjaan dan pemrograman overhead.

Daftar pola desain sangat panjang (orang suka memberi nama benda). Bahkan jika Anda tidak memikirkan "Oke, saya menggunakan _ di sini", hal yang Anda lakukan kemungkinan adalah pola yang seseorang beri nama. Semakin banyak Anda memprogram, semakin banyak Anda akan memiliki gagasan tentang bagaimana melakukan sesuatu dan semakin sedikit Anda harus khawatir tentang pola apa yang Anda gunakan.

Saya pikir begitu versi pertama Anda dirilis dan Anda punya banyak waktu untuk rilis berikutnya, daripada yang dapat Anda pikirkan untuk meningkatkan kualitas kode dan pengelolaan dengan pola desain.

Saya berbagi situasi yang sama. Untuk pemeliharaan aplikasi, mungkin diperlukan refactoring yang luas untuk membuat pola desain bermanfaat. Jika ada downtime besar di tikungan maka yang terbaik untuk menunda sampai Anda punya waktu untuk memperbaiki masalah.

Apalagi jika klien menuntut suatu produk kemarin. Segitiga kualitas perangkat lunak ada apakah Anda mengakuinya atau menyadarinya. "Melakukannya dengan benar pertama kali" seringkali membutuhkan perencanaan awal yang berat termasuk persyaratan yang baik dan ruang lingkup yang rendah. Ini berarti klien harus bersedia untuk berpartisipasi aktif dalam keberhasilan proyek bersama.

Juga perlu diingat bahwa OO 101 mengharuskan seseorang untuk membuat bagian sampai persyaratan lengkap. LALU refactor, kalau tidak Anda hanya memutar roda Anda.

Bukanlah lebih banyak pekerjaan dan overhead untuk memperbaikinya pertama kali.

Jika tidak rusak kemungkinan itu tidak akan diperbaiki. Dan tidak benar bukan berarti harus rusak. Akan selalu ada hal lain yang perlu dilakukan. Jadi Anda akan menghabiskan lebih banyak waktu untuk mendukungnya dan lebih sedikit waktu untuk memperbaikinya atau membuat sesuatu yang baru.

Tidak hanya melakukan itu dengan benar tidak membutuhkan waktu lebih lama daripada melakukan yang salah. Ini mungkin muncul dalam jangka pendek seperti Anda tidak memenuhi tenggat waktu atau tonggak sejarah. Tetapi pada akhirnya semuanya bersatu dalam jumlah waktu yang sama. Tetapi kualitas Rilis QA pertama akan jauh melampaui rilis qa pertama dari kursi celana. Ini akan mengurangi pengerjaan ulang sebelum rilis. Pada akhirnya melakukannya dengan benar tidak hanya mengikat, ia menang setiap saat.

Kemungkinannya adalah, jika Anda membutuhkan waktu lebih lama untuk menerapkan pola desain, maka pola yang Anda coba gunakan tidak cocok untuk masalah yang Anda coba selesaikan. Anda tidak mendapatkan "poin bonus" dalam ulasan kode Anda berikutnya untuk menerapkan pola baru, intinya adalah untuk dapat lebih mudah mengidentifikasi cara-cara yang terbukti untuk memecahkan masalah umum. Pola desain adalah cara bagi orang untuk berbagi pendekatan untuk masalah ini, dan dapat membicarakannya secara umum.

Sangat mungkin bahwa Anda sudah menggunakan pola desain, mereka hanya klasifikasi formal untuk konsep arsitektur yang sering berulang.

Untuk menggunakan analogi konstruksi - di mana Anda dapat menyebut bagian tertentu dari bangunan Anda sebagai "bagian yang menahan hujan dan panas", seseorang yang berpengalaman dalam bangunan hanya akan menyebut bagian itu "atap". Tidak ada kerugian yang bisa saya lihat dalam menerapkan "atap" di rumah sebagai lawan menerapkan "bagian yang mencegah hujan dan panas masuk"

Overhead utama adalah mencari tahu apa pola desain cocok di mana, karena mereka sering sangat abstrak ketika dilihat di luar konteks. Anda hampir pasti menggunakan Fasad / Pabrik kecuali Anda sedang menulis prosedural. Saya menemukan Pengamat, Strategi dan Pabrik yang paling mudah untuk memulai.

Seperti orang lain catat, melakukan yang benar pertama kali tentu saja paling murah. Tetapi saya juga akan menunjukkan bahwa setiap pemrograman membangun apapun jatuh di suatu tempat pada pola-pola anti-spektrum. Anda bisa mengimplementasikan sesuatu dengan tertib atau tidak; kode 'goto' penuh mengikuti pola, itu hanya sesuatu yang diakui sejak awal sebagai berpotensi berbahaya. Tetapi perhatikan bahwa semua kode bermuara ke lompatan dan cabang di beberapa titik dalam siklus kompilasi. Tidak ada yang salah dengan melompat: itu hanya membuat proyek yang lebih besar lebih sulit untuk dipahami.

Mudah disesatkan oleh pola yang tampak sepele untuk kasus penggunaan sederhana. Segera setelah Anda mulai membutuhkan lebih banyak fleksibilitas, sebagian besar pola getas akan berubah menjadi pola anti. Jadi aturan saya adalah hanya menulis kode yang dapat saya mengerti dan memiliki peluang yang wajar untuk debugging. Jika saya memutuskan untuk menerapkan pola pintar secara membabi buta, saya harus setidaknya sama pintar dengan pola-kode untuk men-debug itu. Jadi kuncinya adalah memastikan Anda mengisolasi dan memanfaatkan pola yang berlaku khusus untuk masalah Anda secara langsung, bahwa Anda mendekati masalah pada tingkat abstraksi yang tepat, dan bahwa Anda dapat memahami dan men-debug setiap baris dalam kode Anda.

Salah satu kunci di sini adalah menyeimbangkan keseimbangan yang tepat antara persyaratan jangka pendek dan jangka panjang. Perlu diingat bahwa menulis kode yang baik dengan cepat adalah sesuatu yang dimulai dari pola yang dipahami dengan baik tentunya dapat membantu - kode spageti mungkin tampak lebih cepat, terutama pada awalnya. Tetapi Anda akan segera melihat keterbatasan pola anti dalam proyek yang lebih besar, di mana dekomposisi, modularitas, dll., Menjadi sangat penting.

Saya menentang arus dan mengatakan bahwa mereka dapat membantu tetapi paling sering sakit ketika dalam keadaan yang Anda gambarkan.

Mereka membantu JIKA Anda sangat terbiasa dengan mereka DAN (Anda memiliki cakupan tes yang baik dari semua bagian yang akan efektif ATAU ini adalah pengkodean bidang hijau).

Tapi, sungguh, jika Anda mengajukan pertanyaan ini maka Anda juga A. Jangan menggunakan pola sebagai cara alami untuk melakukan sesuatu (karena jika Anda melakukannya Anda tidak akan berpikir untuk bertanya, Anda hanya akan melakukannya tanpa berpikir) ATAU B. Kode sangat tidak kompatibel dengan penerapan pola dalam jumlah yang diberikan sehingga tidak realistis untuk menggunakan pola.

Tidak. Tampaknya perlu waktu untuk menerapkan praktik terbaik (Pola Desain, MVC, di mana pun) ke masalah, dan bukan karena saya atau pengembang lain tidak tahu Pola Desain dengan baik.

Beberapa praktik yang baik ini, dapat diterapkan bahkan jika Anda terburu-buru, tetapi, sistem yang baik, membutuhkan waktu untuk merancang.