Kapan TIDAK menggunakan kerangka kerja [ditutup]

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 pengujian setiap jam, 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 mendasari 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 punya kerangka! Kita tidak perlu tahu bagaimana "melakukannya dengan tangan"! Kanan?

Akibat 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 tidak sesuai. The fitur yang memfasilitasi kerangka angin 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 kecil dasar, umum, saya mungkin merasa seperti membuang-buang waktu ketika saya tahu bahwa kerangka kerja 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, kapan tidak.

"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.

Kerangka hanyalah alat. Saya tidak berpikir itu kesalahan kerangka kerja jika itu digunakan secara berlebihan, 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 dan juga 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.

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 beberapa tingkat kompleksitas, pembatasan yang melekat dalam kerangka kerja mulai menghambat pertumbuhan lebih lanjut, menurut saya. Kuncinya adalah mengenali kapan Anda telah menemukan titik kritis, dan kemudian memutuskan apa yang akan Anda lakukan.

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. Apakah kerangka kerja ini menghemat waktu dan usaha?

Jawaban atas pertanyaan ini hampir selalu ya . Kerangka kerja cenderung dibangun untuk memecahkan masalah tertentu , dan menyelesaikannya dengan sangat baik. Misalnya, kerangka kerja seperti EntityFramework dapat menyelamatkan Anda sepenuhnya 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 yang kompleks atau b) menambahkan abstraksi ke komponen yang sudah dikenal (atau mapan).

Yang terakhir (atau bahkan yang pertama dalam beberapa kasus) sebenarnya dapat menghalangi pembangunan. 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 layak untuk dilakukan" , tetapi biasanya bukan itu masalahnya. Mungkin tidak ada alasan yang baik untuk menerapkan kerangka kerja berukuran super jika tujuan aplikasi Anda adalah mencetak "kentang" .

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" -kelas ke tag tubuh Anda ketika dokumen siap. Melakukannya hanya dengan JavaScript asli mungkin sedikit lebih sulit , tetapi itu tidak mengasapi aplikasi Anda.

Di sisi lain jika suatu kerangka kerja melakukan banyak pekerjaan kotor di dalam (yaitu kerangka kerja basis data), maka mungkin layak untuk mengimplementasikannya, bahkan jika Anda hanya "sebagian" menggunakan kerangka kerja tersebut. Anekdot yang bagus adalah dengan tidak mencoba membuat ADO.NET atau driver MongoDB Anda sendiri, hanya karena Anda tidak perlu memanfaatkan 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 pada akhirnya terkait kembali ke pertanyaan # 1 dan # 3.

Dampak # 3.

Terkadang menerapkan kerangka kerja dapat berdampak langsung pada pengguna akhir. Ini terutama berlaku untuk aplikasi web, karena memiliki kerangka kerja sisi klien yang besar dapat berdampak negatif pada 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 setidaknya selalu mengambil beberapa ruang disk, dan jika Anda sedang mengembangkan sebuah aplikasi ponsel (atau bahkan aplikasi desktop) ini mungkin perlu dipertimbangkan.

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 banyak sumber daya.

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.

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 pembelajaran 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 untuk mengkhawatirkan ketidakmampuan orang lain? Tidak. (Berdasarkan asumsi bahwa anggota baru komunitas ini tidak segera bekerja dengan Anda.)

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 benar-benar pilihan lagi. 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 hanya menulis aplikasi yang mereka inginkan.

Tim proyek mampu bekerja dalam kerangka tersebut. Beberapa orang tidak atau tidak dapat meluangkan waktu untuk memahami bagaimana 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.