Alasan artikel ini adalah publikasi lain tentang Habré. Ini disebut "Jangan belajar kerangka kerja, belajar arsitektur" dan Anda dapat membacanya di
sini .
Saya akan segera membuat reservasi bahwa saya sepenuhnya setuju dengan penulis dan hanya ingin menambahkan "tiga uang" saya. Pada awalnya saya berpikir untuk melakukannya dengan benar di komentar di bawah artikel, tetapi dengan cepat menyadari bahwa "sen" cukup banyak. Dan teks ini lahir.
Pertama, sedikit tentang diri Anda
Saya telah terlibat dalam pengembangan web selama satu tahun sejak ke-98. Dia bekerja untuk perusahaan dan pekerja lepas. Dia merekrut tim. Baik dalam kehidupan nyata maupun online. Bahasa pemrograman pertama adalah perl, yang sekarang sudah mati, dan saya masih menyesal karena kematiannya yang terlalu cepat. Lalu datanglah php. Beberapa saat kemudian ruby dan era kembang api dimulai.
Big menjanjikan prestasi kecil
Saya bertemu dengannya dengan antusias. Memang - tampaknya alat telah muncul yang dirancang untuk secara signifikan memfasilitasi pengembangan, yang dapat menyelamatkan Anda dari banyak rutinitas. Namun, antusiasme dengan cepat menghilang. Dan inilah alasannya.
Saya tidak tahu siapa caranya, tetapi, pertama-tama, saya berharap untuk menyingkirkan sejumlah besar tindakan monoton yang harus saya lakukan ketika mengerjakan setiap proyek baru. Rancang "tulang punggung" dari pangkalan, tulis output dasarnya halaman teks yang sama, dll, dll. Mereka yang telah menulis cukup banyak situs akan dengan mudah melengkapi daftar ini dengan banyak, banyak poin. Dan kebanyakan kembang api menyimpan banyak rutinitas. Tapi berapa harganya!
Dan kali ini ... dan dua ini ...
Erast Fandorin
Keluhan pertama saya adalah RoR, dan Yii, dan Symfony, dan hampir semua yang harus saya temui - keganjilan mereka dan banyak sekali kode yang benar-benar berlebihan yang selalu berakhir di proyek. Terbiasa bekerja selama bertahun-tahun, bahwa kode harus sebersih dan setepat mungkin, bahwa aplikasi harus secepat mungkin, saya tidak dapat menyetujui sampah (maaf, saya tidak bisa mengatakan sebaliknya) bahwa saya berakhir di proyek.
Klaim kedua adalah upaya oleh semua, tanpa kecuali, penulis kembang api untuk menciptakan, sesuatu seperti bahasa pemrograman mereka. Izinkan saya menjelaskan apa yang saya maksud. Ambil contoh pustaka js jQuery yang paling umum. Pada saat yang sama, saya akan segera membuat reservasi yang saya anggap sebagai satu-satunya julukan yang bermanfaat, kompeten, dan banyak, banyak yang menyanjung. Saya memberikan jq sebagai contoh hanya karena pasti semua orang akan mengerti apa yang saya maksud. Sehingga Anda dapat mengakses elemen dengan ID pada js asli seperti document.getElementById ("id"), dan seperti jQuery $ ("# id"). Fakta bahwa itu ditulis selusin karakter kurang tidak terlalu mengesankan. Pada saat yang sama, jq memiliki banyak kelebihan lain yang siap saya pelajari sintaksinya yang baru. Selain itu, ia dapat diandalkan dan hampir tidak pernah konflik dengan perpustakaan lain. Apa yang tidak bisa dikatakan, dan tumpukan jenisnya, yang diprediksi akan diganti.
Sekali lagi saya akan membuat reservasi - saya tidak akan menentang mempelajari sesuatu yang baru. Tetapi hanya jika yang baru ini membuat kode saya lebih bersih dan lebih cepat. Jika saya perlu mempelajari sesuatu sehingga nantinya saya dapat memukau situs dengan tipe yang sama dengan monyet dan tidak berani mengambil langkah ke kiri, langkah ke kanan, karena saya hanya tidak tahu caranya - terima kasih.
Ya, hal terburuknya adalah bahwa pendekatan pemrograman seperti itu hanya menghabiskan pemikiran dan ketika kerangka kerja yang sangat keren ini gagal, dan ini, percayalah, terjadi segera setelah klien meminta Anda untuk sesuatu yang setidaknya sedikit di luar ruang lingkup, celakalah kerangka itu (saya baru-baru ini tahu) bahwa sekarang ada profesi seperti itu) jatuh pingsan dan mulai mengajukan pertanyaan bodoh di semua forum yang dapat diakses olehnya. Semuanya diunduh oleh fakta bahwa salah satu pemrogram (bukan kerangka kerja) memahat kruk untuk itu dan Tuhan melarang bahwa pelanggan tidak mengaudit kode.
Dan ini tiga ...
Dia adalah
Semua hal di atas berlaku tidak hanya di depan, tetapi juga di belakang. Akibatnya, muncul pertanyaan - pada awalnya saya menyadari bahwa selama perkembangan apa pun saya harus melakukan banyak gerakan yang tidak perlu yang ingin saya optimalkan, tetapi dapatkah ini dilakukan dengan harga seperti itu? Dan selain itu, ada poin lain, yang sebagian besar menyangkut pengembangan di Ruby.
Untuk menerapkan fungsi paling dasar dari aplikasi web, Anda perlu menghubungkan permata terpisah. Untuk memberi makan pada basis data - mysql2, untuk mengirim surat - surat atau poni yang dibuat atas dasar. Dan seterusnya dan seterusnya. Pada pandangan pertama, tidak ada yang salah dengan itu - semua permata di Ruby biasanya diuji dengan baik dan tidak ada masalah dengan mereka. Tetapi ada pengecualian untuk aturan ini juga. Sebagai contoh, sekali seminggu saya harus duduk dengan laporan odf, yang tidak ingin bekerja dengan benar, dan kemudian meludah dan menulis kelas saya. Selain itu, agak menjengkelkan bahwa dengan koneksi setiap permata, waktu pembentukan halaman pasti meningkat. Pada beberapa permata-ahs sangat sedikit. Dan bukan .... Cobalah bereksperimen dengan topik ini dengan kuda poni yang telah disebutkan - lihat sendiri.
Pertanyaan abadi
Dan apa yang harus dilakukan? Di satu sisi, pengembangan dalam bahasa "murni" jelas bukan pilihan, tetapi di sisi lain, alat yang ada tidak puas karena sejumlah alasan? Jalan keluar terlihat dalam menciptakan alat yang akan mengoptimalkan fungsi yang paling sering digunakan dan pada saat yang sama tidak menghalangi programmer, dan tidak akan memaksakan padanya gaya pemrograman yang penulis menganggap alat ini satu-satunya yang benar. Dalam praktiknya, ini berarti bahwa alat tersebut harus:
- berisi sekumpulan minimum standar, fungsi-fungsi yang dioptimalkan maksimal
- alat ini seharusnya tidak memaksa pemrogram untuk mempelajari sesuatu seperti pemrograman “bukan bahasa” baru yang sepenuhnya menonaktifkan otak
- dan semua ini, idealnya, harus dibuat menjadi perpustakaan ringan yang tidak mencoba untuk bersaing dalam hal jumlah kode dengan sistem operasi.
Mungkin saya salah, tapi sejauh ini, tidak ada yang bisa meyakinkan saya sebaliknya. Siap mendengarkan pendapat apa pun.