it-swarm-id.com

Kapan TIDAK menggunakan framework

Saat ini, orang dapat menemukan kerangka kerja untuk hampir semua bahasa, sesuai dengan proyek apa pun. Sebagian besar kerangka kerja modern cukup kuat (secara umum), dengan jam pengujian, kode peer review, dan ekstensibilitas yang luar biasa.

Namun, saya pikir ada kerugian untuk kerangka kerja APAPUN dalam programer itu, sebagai komunitas, dapat menjadi sangat bergantung pada kerangka kerja yang mereka pilih sehingga mereka tidak lagi memahami cara kerja yang mendasarinya, atau dalam kasus programmer baru, tidak pernah mempelajari cara kerja yang mendasarinya untuk mulai dengan. Sangat mudah untuk menjadi terspesialisasi sampai tingkat bahwa Anda tidak lagi seorang 'programmer PHP' (misalnya), tetapi seorang "programmer Drupal", dengan mengesampingkan hal lain.

Siapa yang peduli, bukan? Kami memiliki kerangka kerja! Kita tidak perlu tahu bagaimana "melakukannya dengan tangan"! Baik?

Hasil dari hilangnya keterampilan dasar ini (terkadang sampai-sampai programmer yang tidak menggunakan kerangka kerja dianggap "ketinggalan jaman") adalah bahwa itu menjadi praktik umum untuk menggunakan kerangka kerja di mana tidak diperlukan atau sesuai. The fitur kerangka kerja memfasilitasi akhirnya bingung dengan apa bahasa dasar mampu. Pengembang mulai menggunakan kerangka kerja untuk menyelesaikan bahkan tugas yang paling dasar, sehingga apa yang sebelumnya dianggap sebagai proses yang belum sempurna sekarang melibatkan perpustakaan besar dengan kebiasaan, bug, dan dependensi mereka sendiri. Apa yang pernah dicapai dalam 20 baris sekarang dicapai dengan memasukkan kerangka 20.000 baris DAN menulis 20 baris untuk menggunakan kerangka kerja.

Sebaliknya, seseorang tidak ingin menemukan kembali roda. Jika saya menulis kode untuk menyelesaikan beberapa tugas dasar yang umum, saya mungkin merasa seperti membuang-buang waktu ketika saya tahu bahwa framework XYZ menawarkan semua fitur yang saya cari, dan banyak lagi. Bagian "lebih banyak" masih membuat saya khawatir, tetapi tampaknya tidak banyak yang mempertimbangkannya lagi.

Harus ada metrik yang baik untuk menentukan kapan waktu yang tepat untuk menggunakan kerangka kerja. Apa yang Anda anggap sebagai ambang batas, bagaimana Anda memutuskan kapan harus menggunakan kerangka kerja, atau, ketika tidak.

38
Chris

"Harus ada metrik yang baik untuk menentukan kapan waktu yang tepat untuk menggunakan kerangka kerja."

Tidak juga. Jika ada metrik yang baik untuk menentukan penggunaan yang tepat dari teknologi apa pun, Anda tidak akan melihat perang suci bahasa, editor, dan metodologi.

Semua kelompok yang pernah bekerja sama dengan saya melakukan hal yang sama - membuat perkiraan biaya dan manfaat, memilih rute yang paling produktif, dan berharap mereka benar. Ini tidak terlalu ilmiah - satu bagian intuisi, tiga bagian pengalaman, satu bagian kerentanan terhadap pemasaran, satu bagian licik, dan pendapat lima bagian peringkat.

27
Corbin March

Kerangka hanyalah alat. Saya tidak berpikir itu kesalahan kerangka kerja jika terlalu sering digunakan, melainkan orang yang menggunakannya secara berlebihan. Pepatah lama "jika Anda memiliki palu, semuanya terlihat seperti paku" menunjukkan cara berpikir ini telah ada jauh sebelum komputer.

Menjadi terlalu terspesialisasi memang dapat berubah menjadi masalah dalam jangka panjang - untuk pengembang maupun spesies biologis. Untuk bertahan hidup jangka panjang, seseorang harus dengan hati-hati menyeimbangkan upaya untuk mengembangkan keterampilannya di berbagai bidang.

Untuk menjawab pertanyaan spesifik Anda, saya rasa tidak ada metrik untuk ini. Saya lebih suka menggunakan kerangka kerja ketika menyederhanakan pemecahan masalah. Jika menggunakan framework membantu saya memecahkan masalah dengan 2 baris kode alih-alih 20, saya jelas akan menggunakannya. Tetapi bahkan jika 20 baris terhadap 20, saya mungkin memutuskan untuk menggunakan kerangka kerja jika memberi saya abstraksi yang lebih baik, lebih dekat ke domain masalah, membuat kode lebih mudah untuk dipahami dan dipelihara.

14
Péter Török

Saya pikir kerangka kerja dapat digunakan secara berlebihan dalam beberapa konteks, ya. Kerangka kerja hanyalah alat, ya. Kerangka kerja memungkinkan Anda menjalankan sesuatu dengan sangat cepat, dan karenanya merupakan alat prototyping yang sangat baik.

Di suatu tempat di sepanjang garis, ketika aplikasi Anda mencapai tingkat kompleksitas, pembatasan yang melekat dalam kerangka kerja mulai menghambat pertumbuhan lebih lanjut, menurut saya. Triknya adalah mengenali kapan Anda mengalami titik kritis, dan kemudian memutuskan apa yang akan Anda lakukan.

6
leed25d

Saya cenderung bekerja paling banyak dengan aplikasi web dan meskipun saya mencoba bersikap umum, jawaban saya mungkin tidak berlaku untuk area pemrograman Anda.

Saya juga akan menggunakan "framework" sinonim dengan "library".


Sebelum menerapkan suatu kerangka kerja, seseorang harus mempertimbangkan beberapa hal, berikut adalah beberapa contoh umum.

# 1. Akankah kerangka menghemat waktu dan tenaga?

Jawaban atas pertanyaan ini hampir selalu ya . Kerangka kerja cenderung dibangun untuk menyelesaikan masalah khusus , dan menyelesaikannya dengan sangat baik. Misalnya, kerangka kerja seperti EntityFramework dapat menyelamatkan Anda seluruhnya dari penulisan kode-SQL. Yang bisa fantastis jika tim pemrograman Anda tidak lancar dalam SQL.

Kerangka kerja dibangun untuk, a) menambahkan antarmuka yang ramah programmer ke komponen kompleks atau b) menambahkan abstraksi ke komponen yang sudah dikenal (atau mapan).

Yang terakhir (atau bahkan yang pertama dalam beberapa kasus) sebenarnya dapat menghalangi pengembangan. Ini berlaku terutama ketika Anda atau tim pemrograman Anda akan menerapkan kerangka kerja baru, di mana mereka belum pernah bekerja sebelumnya.

Ini berpotensi memperlambat proses pengembangan Anda, yang bisa berpotensi mahal.

# 2 Skala aplikasi Anda

Dikatakan bahwa "apa pun yang layak dilakukan adalah layak dikalahkan" , tetapi biasanya bukan itu masalahnya. Mungkin tidak ada alasan yang baik untuk menerapkan kerangka kerja berukuran super jika tujuan aplikasi Anda adalah mencetak "potato" .

Ketika Anda sedang mengembangkan suatu aplikasi (baik itu web, desktop, seluler, atau jenis aplikasi apa pun lainnya) - jika Anda merasa bahwa ukuran kerangka kerja Anda "mengerdilkan" implementasi Anda (mungkin di masa depan), maka ini mungkin besar tanda peringatan bahwa kerangka kerja Anda mungkin hanya membengkak aplikasi Anda. Anekdot yang bagus adalah jika Anda memasukkan jQuery, hanya untuk menambahkan "load" -class ke tag tubuh Anda ketika dokumen siap. Melakukannya hanya dengan JavaScript asli mungkin menjadi sedikit lebih sulit , tetapi itu tidak mengasapi aplikasi Anda.

Di sisi lain jika kerangka kerja tidak banyak pekerjaan kotor bagian dalam (yaitu kerangka kerja basis data), maka mungkin layak untuk mengimplementasikannya, bahkan jika Anda hanya "sebagian" menggunakan kerangka tersebut. Anekdot yang bagus adalah tidak mencoba membuat ADO.NET atau driver MongoDB Anda sendiri, hanya karena Anda tidak perlu menggunakan seluruh pustaka .

Kadang-kadang kerangka kerja datang open-source (dan dengan lisensi 'lakukan-apa pun yang Anda inginkan'). Ini membuka kemungkinan baru di mana tim pemrograman mungkin hanya memilih bagian-bagian kerangka kerja.

Ini akhirnya terkait kembali ke pertanyaan # 1 dan # 3.

Dampak # 3.

Terkadang menerapkan kerangka kerja dapat berdampak langsung pengguna akhir. Ini terutama berlaku untuk aplikasi web, karena memiliki kerangka kerja sisi klien yang besar dapat berdampak negatif terhadap pengalaman pengguna akhir. Pengguna dengan mesin yang lebih lambat mungkin mengalami rendering yang lambat, masalah kinerja dengan javascript atau masalah serupa yang disebabkan oleh mesin sub-par. Pengguna dengan koneksi lambat mungkin mengalami waktu pemuatan yang lambat (setidaknya awal).

Bahkan dalam aplikasi jenis lain, pengguna akhir mungkin terkena dampak negatif oleh ketergantungan aplikasi Anda. Kerangka kerja setidaknya selalu mengambil beberapa ruang disk, dan jika Anda sedang mengembangkan aplikasi seluler (atau bahkan aplikasi desktop) ini mungkin perlu diambil mempertimbangkan.

Kerangka kerja sisi server (bahkan lebih khusus web) kemungkinan besar tidak akan memengaruhi pengguna akhir Anda, tetapi itu akan memengaruhi infrastruktur Anda . Beberapa kerangka kerja memiliki dependensi sendiri yang mungkin mengharuskan Anda untuk me-restart server web Anda, baik hanya layanan atau server sepenuhnya.

Beberapa kerangka kerja mungkin juga sangat sumber daya berat.

Ini tentu saja terkait kembali ke poin # 1 dan # 2.


Itu semua hanya "lingkaran pertimbangan" besar, dan tidak ada metode ilmiah nyata untuk memutuskan apakah Anda harus menerapkan kerangka kerja atau tidak.

Corbin March merangkumnya dengan sangat baik:

Semua kelompok yang pernah bekerja sama dengan saya melakukan hal yang sama - membuat perkiraan biaya dan manfaat, memilih rute yang paling produktif, dan berharap mereka benar. Ini tidak terlalu ilmiah - satu bagian intuisi, tiga bagian pengalaman, satu bagian kerentanan terhadap pemasaran, satu bagian licik, dan pendapat lima bagian peringkat.

Penting juga untuk tidak menjadi elitis . Kerangka adalah alat yang dimaksudkan untuk digunakan. Saya tahu orang-orang dari kedua ekstrem; di satu sisi Anda memiliki pria yang membuat hidup sangat sulit untuk dirinya sendiri, di sisi lain Anda memiliki pria yang membuat aplikasi yang lambat dan membengkak.

Semua kerangka kerja memiliki kasus penggunaan, hanya masalah menerapkannya untuk tujuan yang benar.

6
die maus

Apakah pengembang lain tahu kerangka kerjanya?

Jika semua pengembang tahu framework X, maka dengan alasan lain mengapa menggunakan framework itu layak, lakukan saja! Bagi saya, tidak masuk akal untuk menegakkan belajar kerangka kerja tertentu ketika sebagian besar waktu pengembangan akan dihabiskan untuk mempelajari seluk-beluk kerangka kerja.

Mengenai pernyataan Anda tentang programmer baru yang tidak mengetahui dasar-dasarnya, Anda jauh lebih berbelas kasih daripada saya! Ya, itu memalukan, tetapi apakah saya akan menghabiskan waktu saya mengkhawatirkan ketidakmampuan orang lain? Tidak. (Berdasarkan asumsi bahwa anggota baru komunitas ini tidak segera bekerja dengan Anda.)

4
J.K.

Saya akan menggunakan kerangka kerja jika (dan HANYA jika) kondisi berikut ini berlaku:

Kerangka kerja ini sepertinya akan didukung untuk beberapa waktu. Saya sudah meminta mereka untuk mengakhiri hidup saya sebelumnya, dan itu SANGAT menyebalkan. Terutama ketika Anda 9 bulan ke dalam proyek Anda, dan beralih bukan lagi pilihan. Dan jika kerangka kerja SUDAH tidak lagi didukung, maka pikirkan tiga kali sebelum Anda menulis sesuatu yang baru menggunakan kerangka itu. Tidak peduli seberapa baik Anda sudah mengetahuinya.

Proyek ini sebenarnya cocok dengan kerangka kerja. Sebagai contoh yang cukup tua, sudahkah Anda melihat hal-hal yang dilakukan MFC? Orang tidak kehabisan hal-hal aneh untuk membuatnya berfungsi untuk jenis aplikasi yang tidak masuk akal. Biasanya menghabiskan lebih banyak waktu mengalahkan MFC daripada menghabiskan waktu hanya menulis aplikasi yang mereka inginkan.

Tim proyek mampu bekerja dalam kerangka tersebut. Beberapa orang tidak atau tidak dapat meluangkan waktu untuk memahami bagaimana suatu aplikasi harus ditulis dalam kerangka kerja tertentu, dan sebaliknya mereka menulis hal-hal seperti biasanya, alih-alih dengan cara yang dibutuhkan kerangka kerja. Ketidakcocokan antara kode dan kerangka kerja ini biasanya menghabiskan banyak waktu dan upaya semua orang.

4
Michael Kohne