Ketika merancang suatu sistem, apakah itu praktik terbaik untuk memenuhi desain di sekitar kerangka kerja yang akan Anda gunakan?

Ketika mengembangkan suatu sistem atau aplikasi yang Anda rencanakan untuk digunakan dengan kerangka kerja tertentu, apakah itu praktik terbaik untuk merancang sistem tanpa kerangka kerja dalam pikiran, atau lebih baik untuk merancang sistem dengan pola pikir "baik kerangka kerja akan memiliki waktu yang lebih mudah dengan ini".

development-process systems

— Robert Pounder
sumber

Kerangka kerja seperti apa yang Anda bicarakan? Apakah maksud Anda beberapa kerangka kerja khusus bisnis yang dirancang untuk menyelesaikan masalah yang sangat spesifik untuk industri tertentu? (mis. medis, nuklir, pertahanan, penerbangan, dll.). Atau apakah Anda berbicara tentang kerangka kerja tujuan umum yang dirancang untuk memecahkan masalah teknis?

— Ben Cottrell

kerangka kerja tujuan umum yang dirancang untuk memecahkan masalah teknis

— Robert Pounder

Skala kecil karena kurangnya waktu (saya sedang bekerja, mungkin akan menguraikan nanti): Saya menulis sebuah sistem yang menghasilkan email berdasarkan desain. - Jika saya menulis ini di Laravel saya mungkin akan menggunakan mesin templating mereka "blade" untuk mendesain email, yang akan membuat perancangan sistem jauh lebih sederhana dalam hal aliran. Namun saya harus menulis mesin templating jika saya melakukannya dengan vanilla PHP, atau mencari alternatif templating system lain yang cocok. Ini akan menambah proses desain, yang merujuk pertanyaan juga.

— Robert Pounder

Pertanyaan ini akan menghasilkan banyak jawaban yang sangat berbeda karena baik "kerangka" dan "desain" adalah kata-kata yang dipenuhi dengan banyak makna di industri kami. Selain itu, bahkan untuk satu definisi kerangka kerja sebagai "kerangka kerja tujuan umum yang dirancang untuk menyelesaikan masalah teknis", itu akan tergantung pada kerangka kerja tertentu - beberapa kerangka kerja lebih banyak pendapat daripada yang lain.

— stannius

Terlalu buruk untuk ditabrak oleh bus sementara tenggelam dalam pikiran untuk mencoba merancang kendaraan angkutan umum roda.

Jawaban:

Desain Anda harus memenuhi kebutuhan klien semaksimal mungkin. Ingatlah bahwa desain mencakup hal-hal kecil seperti:

Pengalaman pengguna
Fungsionalitas
Bagaimana potongan aplikasi Anda berkomunikasi (baik dengan dirinya sendiri atau entitas eksternal)

Tak satu pun dari hal-hal ini harus ditentukan oleh kerangka kerja. Jika jelas bahwa Anda akan memperjuangkan kerangka kerja Anda untuk mencapai tujuan-tujuan ini, maka Anda memilih kerangka kerja baru yang akan membantu Anda mencapai tujuan-tujuan tersebut sebelum Anda mulai menulis kode.

Setelah Anda memilih set alat yang sesuai (kerangka adalah alat), maka saya sarankan menggunakan alat cara mereka dirancang untuk digunakan. Semakin jauh Anda menyimpang dari desain kerangka kerja, semakin Anda meningkatkan kurva belajar untuk tim Anda, dan semakin besar kemungkinan terjadi kesalahan.

Pendeknya

Desain untuk pengguna Anda
Pilih alat yang sesuai untuk menyelesaikan desain Anda
Gunakan alat Anda sebagaimana mereka dirancang untuk digunakan

Pikiran Lebih Lanjut:

Setelah 20+ tahun rekayasa perangkat lunak, dan menggunakan beberapa kerangka kerja, saya telah belajar beberapa pelajaran. Semua kerangka kerja adalah pedang bermata dua: keduanya membatasi dan mengaktifkan. Masalah dengan memutuskan kerangka kerja Anda sebelum Anda melihat 3 besar yang saya sebutkan di atas adalah bahwa Anda mungkin mengorbankan pengalaman pengguna yang baik untuk yang sedang-sedang saja (paling-paling). Atau Anda mungkin terpaksa menyimpang dari desain kerangka kerja untuk mencapai beberapa fungsi spesifik.

— Berin Loritsch
sumber

Maka Anda perlu melakukan beberapa negosiasi dengan klien. Jelaskan apa yang Anda bisa dan tidak bisa lakukan dengan kendala yang mereka buat. Usulkan bagaimana hal itu dapat berubah jika Anda memilih kerangka kerja X. Mereka mungkin tidak mau berubah dan mau hidup dengan pengalaman yang terdegradasi. Atau mereka mungkin memutuskan bahwa Anda tahu apa yang Anda lakukan dan percayai Anda. Itu tergantung pada klien. Pada akhirnya, Anda mengatur harapan mereka.

— Berin Loritsch

Tampaknya ada beberapa kebingungan antara berbagai tingkat desain di sini: desain sistem dan desain terperinci. Bagi saya, pertanyaan ini menanyakan tentang desain terperinci (metode implementasi) daripada sistem (antarmuka, konkurensi, volume data, antarmuka pengguna, tipe pengguna).

— Gusdor

Jika pertanyaannya berbalik "desain teknis", maka bahasa dan OS mungkin memiliki beberapa kesimpulan dalam desain. Namun tetap saja, desain tidak implementasi. Jika Anda berpikir dalam kemampuan Kerangka, Ini bukan desain, Ini implementasi. Jika Anda mendasarkan keputusan desain pada kekuatan kerangka, siapkan diri Anda untuk menderita kelemahannya. Dan ketika kelemahan memenuhi persyaratan, Anda memiliki masalah besar. Perusahaan terbesar tidak membangun kerangka kerja baru untuk kesenangan.

— Laiv

@Laiv Komentar bagus! Sungguh, ini adalah "beberapa dan beberapa". Nailgun dan screwgun keduanya dapat mempercepat, yang satu lebih reversibel daripada yang lain dan juga bekerja lebih lambat dan lebih kompleks. Setiap pilihan yang diambil orang tidak bisa dihindari merupakan kompromi. Anda membayar uang Anda dan mengambil peluang Anda.

@RobertPounder, Ini adalah alat yang kesesuaian untuk suatu solusi perlu diputuskan saat merancang sistem. Saya mengerti bagaimana kerangka kerja dapat memengaruhi desain, tetapi mereka seharusnya tidak mendiktekannya.

— Berin Loritsch

Kerangka kerja secara alami mempengaruhi desain modul dan sub-sistem khusus (seperti front-end GUI). Seperti jawaban lain yang disebutkan, Anda akan mengalami kesulitan jika Anda menemukan diri Anda berjuang melawan kerangka pilihan Anda.

Namun secara lebih luas, Anda harus menghindari membiarkan kerangka tunggal atau teknologi mendikte atau mengarahkan "gambaran besar" dari keseluruhan arsitektur sistem Anda. Sebagian besar kerangka kerja tujuan umum tidak mendorong ini, jadi jika Anda menemukan diri Anda menulis seluruh sistem Anda di satu kerangka kerja maka Anda mungkin melakukan sesuatu yang tidak dimaksudkan oleh penulis kerangka kerja itu.

Anda mungkin akan menggunakan banyak kerangka kerja yang berbeda untuk menyelesaikan masalah yang berbeda; karena sistem Anda menjadi lebih kompleks, Anda perlu berhati-hati untuk tidak membangun The Big Ball Of Mud . Jika memungkinkan, jaga agar sistem Anda tetap modular dan longgar. Beberapa kerangka kerja mungkin lebih baik disimpan di belakang abstraksi dengan menulis pembungkus dan adaptor yang 'menyembunyikan' alur kerja khusus Kerangka jauh dari komponen lain. Toolkit GUI cenderung hanya melayani fungsionalitas GUI front-end, sehingga modul GUI tersebut harus dijauhkan dari sisa sistem.

Kerangka kerja tujuan umum (seperti kerangka kerja UI, kerangka kerja lapisan data, dll.) Tidak ada untuk meresepkan arsitektur lengkap sistem Anda - paling banyak mereka mungkin meresepkan desain komponen atau modul; misalnya, beberapa teknologi GUI diarahkan untuk pola MV * tertentu.

Arsitektur keseluruhan sistem Anda terutama harus didorong oleh persyaratan bisnis Anda . Anda mungkin mendapati diri Anda sangat bergantung pada alat tertentu (misalnya, alat pesan middleware, atau kerangka kerja ORM) untuk mengikat semuanya, tetapi jika Anda merangkum kerangka kerja dalam abstraksi seperti kelas 'layanan' yang Anda Kecil kemungkinannya untuk menemukan diri Anda dibatasi oleh kerangka itu ketika Anda menemukan keterbatasannya.

Coba perhatikan hal-hal berikut untuk desain gambar besar Anda:

Bertujuan untuk membangun perangkat lunak Modular
Pertimbangkan Pemisahan Masalah saat menulis setiap modul dan komponen
Pertimbangkan arsitektur Multi-tier untuk memisahkan sistem menjadi beberapa lapisan
Jangan membangun Abstraksi Bocor
Singkatan dari pertanyaan terkait ini : Apa itu KERING, CIUMAN, SOLID, dll. Diklasifikasikan sebagai?

— Ben Cottrell
sumber

Kadang-kadang tampaknya beberapa pembuat kerangka tidak keberatan sama sekali memiliki penggunanya menulis kode aplikasi yang erat dengan kerangka kerja.

— DATANG DARI

@COMEFROM - Menggabungkan kode Anda dengan ketat ke suatu kerangka kerja akan didorong oleh pengembang karena mereka menganggap Anda memilih kerangka kerja mereka untuk memecahkan masalah yang sama seperti yang mereka rancang untuk tempat pertama.

— JeffO

Anda sedikit keluar dari subjek, beralih dari prinsip desain ke prinsip pengkodean, tapi saya mengerti apa yang Anda katakan, bagaimana jika persyaratan bisnisnya adalah bahwa kerangka kerja tertentu digunakan? (anggap perusahaan outsourcing dan para pengembang di rumah hanya tahu satu bahasa) Saya pikir saya harus membuat ini lebih jelas di posting asli.

— Robert Pounder

@RobertPounder Poin sebenarnya yang saya coba dapatkan (mungkin tidak terlalu baik) adalah bahwa kadang-kadang ada kecenderungan orang untuk menggunakan kerangka kerja tertentu sebagai 'landasan' untuk seluruh aplikasi mereka - yang pasti mengarah pada logika bisnis dan lainnya. kode yang tidak terkait digabungkan secara tidak tepat ke kerangka itu - misalnya logika bisnis yang digabungkan dengan kontrol UI hanya karena cepat pada saat itu tidak mudah. Sangat mudah untuk melakukan itu, jadi itu sesuatu yang harus diwaspadai

— Ben Cottrell

Saya harus tidak setuju dengan @nocomprende di sini; tidak semua persyaratan di masa depan dapat diprediksi, tetapi kadang-kadang sistem ditulis ulang hanya karena perangkat lunak sebelumnya terlalu sulit untuk diperluas / dipelihara .

— SeldomNeedy

Ya, Anda harus tetap sedekat mungkin dengan apa yang dikatakan "kerangka kerja" yang harus Anda lakukan.

Alasannya adalah karena semakin dekat Anda dengan kerangka berpikir "cara", semakin mudah Anda akan dapat berbicara dengan pengembang lain tentang masalah / ide Anda yang juga menggunakan kerangka itu.

Anda meningkatkan interoperabilitas dan kemudahan penggunaan untuk orang lain yang menggunakannya nanti, Anda akan memahami dan menggabungkan tutorial atau solusi umum dengan lebih baik jika Anda tetap pada filosofi yang mendasari apa pun yang Anda gunakan.

Satu-satunya alasan bagus yang dapat saya pikirkan mengapa Anda akan "mematahkan" kerangka kerja adalah bahwa Anda benar-benar membutuhkan sesuatu yang tidak dapat disediakan dengan konfigurasi / penerapan prinsip "default" -nya. Tapi kemudian, itu mungkin bukan kerangka kerja yang tepat untuk memulai.

Pada dasarnya, ini dapat diterapkan pada keputusan lain juga. Anda harus menggunakan bahasa yang Anda gunakan sedekat yang seharusnya digunakan, karena itu membuat segalanya lebih mudah jika Anda berbicara bahasa yang sama dengan orang lain.

— FP
sumber

Mungkin Anda harus meninjau jawaban Anda karena perubahan pertanyaan. Jawaban Anda sebenarnya tidak menjawab pertanyaan OP.

— Laiv

@Laiv Saya tidak melihat bagaimana itu tidak menjawab pertanyaan, meskipun mungkin tidak sesuai dengan pendapat Anda tentang topik, itu masih merupakan jawaban. Anda dipersilakan untuk menulis jawaban Anda sendiri untuk menampilkan sifat yang bertentangan dari topik tersebut.

— FP

Maafkan saya jika saya sendiri tidak menjelaskan dengan baik. Saya tidak lancar berbahasa Inggris seperti yang saya inginkan. Saya hanya ingin mengatakan itu, IMO, pertanyaan dan jawaban Anda berbicara tentang hal-hal yang berbeda. Jika Anda pikir tidak, itu tidak masalah. Saya tidak akan membantah hal itu. Itu dia.

— Laiv

Ini benar-benar itu. Ini mirip dengan cara kerja Bahasa Khusus Domain dan gagasan serupa. Produk Anda dibentuk oleh alat (Kerangka) bukan sebaliknya. Kerangka kerja "menang". Jika Anda tidak dapat menikahinya, maka pilihlah yang berbeda. (Petunjuk: tidak ada Kerangka ideal . Hanya sayin '.)

Desain Anda harus memengaruhi kerangka kerja mana yang Anda pilih (jika ada!), Bukan sebaliknya.

— RubberDuck