Apakah kerangka kerja terlalu banyak abstraksi? [Tutup]

Saya telah memprogram selama kurang dari setahun dan memiliki beberapa pengalaman menulis aplikasi sistem, aplikasi web, dan skrip untuk bisnis / organisasi. Namun, satu hal yang belum pernah saya lakukan adalah bekerja dengan kerangka kerja seperti Django, Rails atau Zend.

Melihat kerangka Django, saya sedikit frustrasi dengan berapa banyak yang disarikan dalam kerangka kerja. Saya memahami tujuan inti KERING dan kode minimal, tetapi beberapa ketergantungan berlebihan pada modul yang berbeda dan abstraksi berat fungsi inti terasa seperti itu:

1. Membuat program mendapatkan tanggal sangat cepat karena sifat modul / kerangka kerja yang selalu berubah,

2. Membuat kode sulit dimengerti karena kebanyakan kerangka kerja dan modul yang tersedia dan semua keistimewaan mereka,

3. Membuat kode menjadi kurang logis kecuali Anda sudah membaca semua dokumentasi; yaitu, saya dapat membaca beberapa daftar pemahaman dan logika kondisional dan mencari tahu apa yang sedang dilakukan suatu program, tetapi ketika Anda melihat fungsi-fungsi yang memerlukan melewati string dan kamus yang berubah-ubah, segala sesuatunya menjadi sedikit sulit untuk dipahami kecuali Anda sudah menjadi guru di modul yang diberikan; dan:

4. Membuatnya sulit dan membosankan untuk beralih antar kerangka kerja. Beralih antar bahasa sudah merupakan tantangan, tetapi dapat dikelola jika Anda memiliki pemahaman yang cukup kuat tentang fungsionalitas / filosofi inti mereka. Beralih di antara kerangka kerja tampaknya lebih merupakan masalah menghafal, yang dalam beberapa hal tampaknya mendorong inefisiensi kerangka kerja ini dirancang untuk dihilangkan.

Apakah kita benar-benar harus meletakkan seperti 50 lapisan abstraksi di atas sesuatu yang sederhana seperti permintaan MySQL? Mengapa tidak menggunakan sesuatu seperti antarmuka PDO PHP, di mana pernyataan disiapkan / pengujian input ditangani tetapi query SQL yang dapat dimengerti secara universal masih merupakan bagian dari fungsi?

Apakah abstraksi itu benar-benar bermanfaat? Bukankah fitur mengasapi menjadikannya tidak berguna, membuat aplikasi lebih sulit dibandingkan dengan aplikasi serupa yang ditulis tanpa menggunakan kerangka kerja?

Kerangka memang bisa rumit. Masalah dapat dengan mudah muncul ketika suatu kerangka kerja terlalu "pendapat", yaitu ketika itu benar-benar lebih memilih satu gaya aplikasi tertentu dan semua bagian diarahkan untuk mendukung gaya tertentu ini.

Misalnya, jika kerangka kerja sepenuhnya mengabstraksi proses otentikasi pengguna dengan memungkinkan Anda untuk hanya menambahkan satu komponen, tambahkan template login di suatu tempat dan voila, Anda mendapatkan otentikasi pengguna secara gratis. Ini menyelamatkan Anda dari banyak pekerjaan yang berulang dalam mengkhawatirkan cookie, penyimpanan sesi, hashing kata sandi dan yang lainnya.

Masalah dimulai ketika Anda menyadari bahwa perilaku default kode otentikasi kerangka kerja bukanlah yang Anda butuhkan. Mungkin itu tidak mengikuti praktik keamanan terbaik terbaru. Mungkin Anda memerlukan pengait khusus dalam proses untuk memicu beberapa tindakan, tetapi kerangka kerja tidak menawarkannya. Mungkin Anda perlu mengubah detail cookie yang sedang diatur, tetapi kerangka tidak menawarkan cara untuk menyesuaikan ini.

Abstraksi yang diberikan oleh kerangka kerja memungkinkan Anda untuk menambahkan fitur penting ke situs Anda dalam beberapa menit, bukan beberapa hari pada awalnya, tetapi pada akhirnya Anda mungkin harus berjuang melawan kerangka kerja untuk membuatnya melakukan apa yang Anda perlukan, atau Anda akan harus menemukan kembali fungsi dari awal lagi sesuai dengan kebutuhan Anda.

Ini bukan untuk mengatakan kerangka kerja abstraksi itu buruk, ingatlah. Dapat dikatakan bahwa ini selalu merupakan kemungkinan yang perlu Anda ingat. Beberapa kerangka kerja secara eksplisit diarahkan untuk ini, mereka menawarkan cara untuk mendapatkan sesuatu dengan sangat cepat sebagai prototipe atau bahkan kerangka kerja produksi untuk jenis aplikasi yang sangat spesifik dan terbatas. Kerangka kerja lainnya lebih seperti kumpulan longgar komponen yang dapat Anda gunakan, tetapi yang masih memungkinkan Anda banyak fleksibilitas untuk mengubahnya di kemudian hari.

Saat menggunakan abstraksi, Anda harus selalu memahami setidaknya secara kasar apa yang diabstraksi. Jika Anda tidak memahami cookie dan sistem otentikasi, mulai dari abstraksi bukan ide yang baik. Jika Anda mengerti apa yang Anda coba lakukan dan hanya perlu kode yang sudah melakukannya alih-alih harus menulis sendiri, abstraksi adalah penghemat waktu yang tepat. Abstraksi yang ditulis dengan buruk bisa membuat Anda kesulitan nanti, jadi pedang bermata dua.

Anda juga harus membedakan antara abstraksi teknis dan "aturan bisnis" . Pemrograman dalam bahasa tingkat yang lebih tinggi adalah abstraksi yang Anda mungkin tidak ingin ketinggalan (Python, PHP, C # vs C vs. Assembler; Lebih sedikit vs CSS), sementara "abstraksi aturan bisnis" bisa sulit jika mereka tidak Memenuhi kebutuhan Anda dengan tepat (autentikasi satu klik vs. cookie pengkodean tangan).

Itu karena abstraksi teknis jarang "bocor", yaitu Anda hampir tidak perlu men-debug kode mesin saat menulis aplikasi dengan Python. Abstraksi aturan bisnis bekerja pada tingkat teknis yang sama dan hanya "kumpulan kode" sebenarnya. Anda mungkin akan perlu untuk debug cookie yang diatur atau password hash yang dibuat di beberapa titik, yang berarti Anda akan menyelam melalui banyak kode pihak ke-3.

Sepertinya saya salah paham abstraksi dan penggunaan kembali kode.

Seluruh industri pengembangan perangkat lunak dibangun di atas abstraksi. Hanya karena tidak menggunakannya, yaitu menghindari menggunakan kerangka kerja, perpustakaan dan kode umum yang tidak ditulis di rumah, akan meningkatkan biaya yang Anda butuhkan untuk menghasilkan perangkat lunak hingga ratusan ribu, bahkan mungkin lebih.

Seperti Anda tidak membuat jet jumbo dari awal, tanpa menggunakan pengetahuan teknik yang dikembangkan selama bertahun-tahun ketika membangun pesawat lain, Anda tidak menulis perangkat lunak bisnis dari awal.

Anda mendapatkannya dengan menggunakan PHP atau Ruby sejak awal, Anda sudah memiliki banyak abstraksi, bukan? Yang paling jelas:

1. Sistem operasi, bahasa pemrograman dan kompiler memberikan abstraksi besar atas Assembler dan perangkat keras,

2. Server web menyediakan abstraksi soket, failover, protokol HTTP, dll.,

3. SQL menyediakan abstraksi tentang bagaimana data disimpan pada dukungan penyimpanan permanen dan disimpan dalam memori untuk akses yang lebih cepat, memastikan ACID, mirroring, dll.

Anda mungkin selalu mencoba membuat aplikasi web tanpa menggunakan sistem operasi, atau server web, database atau bahasa pemrograman tingkat tinggi. Anda akan segera menemukan bahwa Anda menghabiskan bertahun-tahun menciptakan kembali roda, yaitu menciptakan Anda bahasa pemrograman, Anda web server dan Anda basis data, mengingat bahwa kualitas mereka akan jauh dari kualitas produk yang kami benar-benar menggunakan.

Kerangka tidak berbeda dari itu. Anda dapat melakukan apa yang mereka lakukan. Hanya saja Anda akan membuang-buang waktu untuk mengulangi fungsionalitas yang sama, dengan perbedaan bahwa kerangka kerja itu akan melakukannya dengan lebih baik dan seringkali kode mereka akan diuji dan didokumentasikan dengan lebih baik daripada milik Anda.

Ambil contoh gerobak untuk situs web e-commerce. Anda dapat menemukan milik Anda dan menghabiskan beberapa minggu untuk mengembangkannya, atau Anda dapat mengambil yang dikembangkan selama bertahun-tahun oleh sekelompok orang di dalam suatu kerangka kerja. Mereka diharapkan akan diuji, tidak termasuk fakta bahwa selama beberapa tahun, para pengembang menemukan dan menambal banyak bug yang tidak akan Anda bayangkan ketika mengembangkan keranjang Anda sendiri.

Anda dapat menjawab bahwa masalahnya lebih rumit karena memiliki lebih banyak kasus pengguna. Misalnya, mereka harus berurusan dengan rabat, sementara Anda tidak memiliki rabat di situs web Anda dan tidak memerlukan fitur ini di troli. Yah, Anda tidak dipaksa untuk menggunakan fitur ini, dan itu tidak seperti itu akan menghukum kinerja aplikasi web Anda.

Anda mungkin memiliki skenario yang sangat mendasar ketika benar-benar lebih mudah untuk mengembangkan keranjang Anda sendiri daripada menggunakan yang ada. Dengan cara yang sama, jika satu-satunya hal yang dibutuhkan aplikasi Anda adalah menyimpan daftar angka, tidak lebih, Anda tidak memerlukan database: isi teks sederhana sudah cukup. Dalam kasus tersebut, jangan terlalu merekayasa aplikasi Anda: skenario sederhana memerlukan solusi sederhana.

Faktor lain adalah keterbacaan kode Anda. Bayangkan Anda telah membuat situs web e-commerce. Kemudian, Anda meninggalkan proyek, dan pengembang lain harus memeliharanya.

• Jika Anda telah menggunakan kereta yang disediakan oleh suatu kerangka kerja, kolega Anda akan merasa lega: ia harus memelihara sepotong kecil kode yang bergantung pada kerangka kerja yang andal dan banyak didokumentasikan. Bahkan lebih baik: pengembang ini mungkin telah terbiasa bekerja dengan kerangka kerja ini dan akrab dengannya. Jika tidak, ia dapat mengajukan pertanyaan tentang Stack Overflow: pasti, seseorang telah menggunakan kerangka kerja.

• Jika Anda memiliki gerobak sendiri, maka kolega Anda harus menjaga beberapa kode khusus, bahkan mungkin tidak didokumentasikan, tanpa dapat memperoleh bantuan di mana pun.

Dengan menggunakan framework, Anda mengandalkan kode yang:

• Ditulis oleh pengembang berpengalaman,

• Sering ditinjau pasangan,

• Unit-diuji,

• Didokumentasikan secara luas,

• Digunakan selama bertahun-tahun oleh ribuan pengembang,

• Sering didukung, sehingga Anda dapat melaporkan bug dan melihatnya benar-benar diperbaiki,

• Dikenal oleh banyak pengembang yang mengetahui kemungkinan peringatan dan masalah dan dapat membantu di situs-situs seperti Stack Overflow.

• Tersedia untuk Anda sekarang, gratis.

Saya setuju - sebagian besar kerangka kerja menjadi diktator yang membengkak. Mereka menjanjikan kebebasan tetapi Anda berakhir dalam perbudakan. jadi lihatlah kerangka kerja seperti alat - alat terbaik adalah yang tidak menghalangi Anda. Jika dalam PHP saya akan menyarankan memeriksa kerangka Codeigniter, karena ini adalah keseimbangan yang elegan antara konvensi dan kebebasan dan memiliki komunitas yang hebat. Dan untuk poster yang menggunakan contoh gerobak e-commerce - saya sangat berharap saya bisa setuju dengan Anda. tetapi setelah melihat kode untuk banyak solusi e-commerce - dan merancang beberapa - saya akan dengan hormat tidak setuju dengan contoh Anda.

Hmmm Salah satu aspek dari LedgerSMB yang sering kami kerjakan adalah pendekatan kami terhadap kerangka kerja. Ada dua masalah mendasar yang muncul dengan abstraksi semacam ini. Ini adalah:

1. Ketergantungan ledakan, dan

2. Abstraksi yang salah

Yang pertama sebenarnya lebih baik daripada alternatif yang menciptakan kembali roda. Yang kedua agak sulit untuk dilabeli karena bisa berasal dari kasus masalah yang tidak jelas atau, lebih sering, dari orang yang menggunakan sesuatu di luar penggunaan yang dimaksudkan.

Mari kita lihat ORM misalnya. Saya menghindari menggunakan ORM karena sangat sering terjadi bahwa db akhirnya dirancang untuk model objek dari aplikasi karena yang terbaik adalah lapisan abstraksi yang bocor. Ini belum tentu demikian. Saya telah bertemu dengan pengembang yang berhasil melestarikan desain DB yang bagus dan aplikasi yang baik saat menggunakan ORM tetapi mereka menggunakan banyak hal yang menurut hype organisasi tidak diperlukan, seperti merangkum API relasional dari db di belakang tampilan yang dapat diperbarui.

Masalah utama tentu saja adalah bahwa semakin tinggi kode terotomatisasi, terutama ketika juga buram, semakin sulit untuk melihat apa yang salah. Ini adalah poin tentang ORM yang dibuat @jhewlett di atas (lihat /software//a/190807/63722 ).

Paralel yang baik mungkin avionik canggih sebagai kerangka kerja untuk mengemudikan pesawat. Ini telah sangat direkayasa untuk keandalan dan merupakan faktor dalam peningkatan keselamatan penerbangan. Namun, seperti banyak artikel dalam Spectrum IEEE menunjukkan ini datang dengan biaya pemulihan dari kesalahan di luar batas dari apa yang dianggap dapat diterima dari perspektif otomatisasi. Hal yang sama berlaku untuk debugging. Itu satu hal untuk men-debug kode SQL di program Anda. Ini adalah hal yang sangat berbeda untuk men-debug bagian dari program Anda yang menulis kode SQL untuk digunakan oleh program Anda.

Kami menulis kerangka kerja LedgerSMB dari awal karena pada saat kami mulai, tidak ada kerangka kerja yang benar-benar bagus yang melakukan apa yang kami inginkan. Ini sebenarnya satu hal yang cukup saya sukai, dan menurut pengembang yang lebih baru dalam proyek ini, itu membuat penyesuaian aplikasi cukup mudah. (Kami benar-benar menjaga pembuatan kode SQL seminimal mungkin dan alih-alih fokus pada fungsi yang ditentukan pengguna yang ditulis tangan, artinya bagian penulisan sql adalah lem yang sangat tipis). Ya itu memberikan banyak abstraksi di beberapa tempat, lebih dari beberapa pemrogram merasa nyaman (khususnya "memetakan properti objek ke argumen dalam prosedur tersimpan" membuat kita mundur dari waktu ke waktu). Kami mencoba, bagaimanapun, untuk menjaga semuanya sederhana dan konsisten sehingga mudah untuk menentukan apa yang salah. Ini bekerja dengan cukup baik.

Pada akhirnya "terlalu banyak" agak subyektif, tetapi pada tingkat obyektif itu juga tergantung pada apa yang Anda lakukan. Jika Anda melakukan persis seperti apa kerangka kerja itu dirancang untuk dilakukan, kerangka kerja yang dirancang dengan baik akan memberikan jumlah abstraksi yang sempurna. Jika Anda melakukan sesuatu yang sedikit kurang pas, abstraksi akan menjadi terlalu banyak dan terlalu bocor.

Ya, mereka berguna. Mereka memberi Anda manfaat dari banyak pengembang berpengalaman lainnya yang melakukan pekerjaan untuk menyelesaikan masalah yang perlu Anda selesaikan, dengan manfaat tambahan setelah mengujinya, memperbaiki banyak bug, dan memberikan solusi untuk masalah rumit yang tidak perlu Anda khawatirkan. diri Anda dengan menggunakan framework.

Bisakah mereka membengkak berlebihan? Yakin. Ini semua tergantung pada apa yang Anda butuhkan, dan apa yang dibawa kerangka kerja ke meja. Jika Anda memiliki aplikasi web sederhana, mungkin Rails terlalu berat untuk Anda, dan Anda harus melihat sesuatu yang lebih sederhana seperti Sinatra sebagai solusinya.

Pasti ada kurva belajar untuk semua kerangka kerja, dan lebih curam dengan lebih banyak pekerjaan yang disimpan untuk Anda. Namun, mempelajari kerangka kerja berarti Anda menghemat waktu dan dapat memanfaatkan semua pengetahuan itu pada proyek berikutnya, alih-alih menulis ulang aplikasi Anda dari awal, untuk kedua kalinya.

Tetapi, Anda berkata, saya hanya akan menyalin kode saya dari proyek lama, dan saya dapat menggunakannya sebagai titik awal untuk proyek baru saya! Saya hanya akan mengubah apa yang berbeda, dan mungkin membuat beberapa objek / fungsi saya lebih umum, dan memikirkan cara yang lebih baik untuk menyelesaikan kode yang sedikit rumit itu! Selamat, Anda baru saja membuat kerangka kerja. Lakukan ini beberapa ribu kali lagi, dan Anda memiliki sesuatu seperti Django, Rails atau Zend.

Kerangka kerja biasanya menghasilkan lebih banyak produktivitas (mungkin setelah sedikit kurva belajar), tetapi sering ada trade-off yang terlibat. Dalam beberapa kasus, misalnya, Anda mendapatkan produktivitas programmer dengan biaya penurunan kinerja.

Pertimbangkan Object-Relational Mappers (ORMs). Mereka hebat karena mereka mengurus banyak kode pemetaan yang membosankan untuk Anda. Mereka bahkan dapat membuat objek untuk Anda. Namun, dalam mengabstraksi SQL, jauh lebih sulit untuk alasan tentang kinerja dan mengoptimalkan kemacetan Anda.

Jika Anda membuat aplikasi yang tidak memiliki banyak data atau kueri kompleks, kinerja mungkin tidak menjadi masalah bagi Anda. Memang, waktu programmer adalah penghambat bagi banyak proyek, dan kerangka kerja, perpustakaan, dan bahasa tingkat tinggi membantu meringankannya.

Saya setuju bahwa "Anda menggunakan perpustakaan, tetapi kerangka kerja menggunakan Anda". Itu cara yang sangat rapi untuk mengatakannya. Saya tidak setuju bahwa segera setelah Anda mulai menggunakan kembali kode Anda mulai membangun kerangka kerja, karena Anda biasanya tidak perlu melakukan lebih dari sekadar salin dan tempel cepat untuk menggunakan kode Anda lagi - itu adalah perpustakaan yang sedang Anda bangun; tidak perlu aneh tentang bagaimana Anda membawa kode ke situs atau aplikasi Anda.

Bagi saya, poin krusialnya adalah saya harus mendapatkan lebih banyak dari sumber daya daripada yang saya butuhkan untuk berinvestasi. Atau, dari sudut lain, saya akan mengatakan bahwa segera setelah kebutuhan kerangka kerja lebih besar dari hadiah yang tersedia, semua keuntungan tidak ada. Jadi itu 'Ya! Silahkan! Dan terima kasih!' untuk semua orang yang membuat aset yang akan jatuh lurus dan berfungsi sesuai kebutuhan dalam html / CSS / PHP dan SQL saya sendiri.

Satu hal yang saya temukan tidak dapat dipahami adalah bahwa kerangka dikatakan membuat perawatan lebih mudah? Jika kaitan kompleks dari bagian-bagian yang saling bekerja tidak berkinerja seperti yang dimaksudkan, Anda sebaiknya tahu segala sesuatu yang perlu diketahui tentang kerangka kerja yang dimaksud. Atau bersiaplah untuk input besar sintaks baru.

Beberapa orang mengatakan ini adalah Prinsip Kerangka Kerja Hollywood : "Jangan panggil kami, kami akan memanggilmu". Sebaliknya, setiap kali Anda menggunakan perpustakaan, kode Anda memanggil perpustakaan , bukan sebaliknya.

Seperti yang Anda lihat, poin penting adalah siapa yang memegang kendali - yaitu, mengendalikan aliran kontrol. Siapa yang memutuskan pernyataan mana yang dijalankan setelah itu?

Ada argumen pro dan kontra, dan setiap kali saya melihat diskusi tanpa akhir seperti itu, saya cenderung berpikir ini pasti masalah selera, bukan pertanyaan yang dapat ditentukan secara obyektif. Kalau tidak, itu sudah diputuskan.

Dalam pandangan saya, apakah Anda lebih suka menggunakan kerangka kerja atau perpustakaan memberi tahu sesuatu tentang pengembang seperti apa Anda, dan bukan apakah salah satu dari kedua pendekatan itu lebih unggul dan pada akhirnya akan menang.

Jika Anda lebih suka kerangka kerja, Anda lebih suka bertukar kebebasan untuk keamanan: Anda mungkin lebih pragmatis dan Anda cenderung memercayai orang lain untuk melakukan pekerjaan mereka dengan benar. Jika Anda lebih suka perpustakaan, Anda lebih suka bertukar keamanan untuk kebebasan: Anda mungkin lebih idealis dan Anda mempertanyakan ide dan klaim orang lain.

Saya tidak berpikir akan lebih bijaksana untuk memutuskan lebih baik menjadi seperti yang pertama atau yang terakhir.

Menjawab pertanyaan Anda: Apakah kerangka kerja terlalu banyak abstraksi? Itu tergantung pada siapa Anda, dan secara khusus pada jarak dari prinsip-prinsip pertama apa Anda merasa nyaman.

...

Dan lebih khusus lagi, jika Anda tidak suka kerangka kerja seperti Django, cari "mikroframeworks" seperti Flask :)