Setiap hype sangat lucu ketika Anda melihatnya dari samping. Kurang lucu ketika Anda terlibat langsung di dalamnya.
Hype Go jatuh di suatu tempat pada tahun 2014, ketika penulis aplikasi yang memiliki 1000RPM (permintaan per menit) tiba-tiba memutuskan sebagai salah satu yang mereka sangat membutuhkan konkurensi, karena 1000RPM mereka akan berubah menjadi 1000RPS (yang juga tidak begitu banyak, sebenarnya).
Hasil dari hype adalah bahwa banyak orang yang terbiasa dengan arsitektur MVC dari aplikasi bergabung dengan Go, baik itu Spring, Django atau Ruby on Rails. Dan arsitektur ini, seperti burung hantu di dunia, mereka mulai menarik Go. Jadi kadavres muncul seperti Beego dan
Revel . Revel meninggal dengan selamat, meskipun mereka masih berusaha untuk memompa keluar. Tetapi saya ingin berbicara tentang Beego secara terpisah.
Richard Eng membuat kontribusi yang signifikan untuk mempromosikan Beego di antara massa dengan serangkaian artikelnya
“A word the Beegoist” . Praktis "Injil Richard." Ironisnya, terlepas dari kenyataan bahwa Richard dengan panik mempromosikan Go, dia sendiri tidak menulis di situ.
Pada gilirannya, saya bekerja dengan Go, dan lebih buruk lagi, dengan Beego, saya banyak bekerja. Dan saya dapat mengatakan bahwa ini jelas bukan jalan pengembangan yang seharusnya.
Mari kita lihat beberapa aspek dasar Beego, dan mengapa mereka bertentangan dengan berbagai praktik terbaik di Go, dan di industri secara keseluruhan.
Struktur folder
Robert C. Martin, lebih dikenal sebagai
Paman Bob , telah berulang kali menyuarakan gagasan bahwa struktur aplikasi harus menyampaikan esensinya. Ia sangat suka memberi contoh dengan katedral, yang bisa dilihat dari atas, dan langsung mengerti bahwa ini adalah katedral.
Robert telah berulang kali mengkritik Ruby on Rails karena struktur foldernya - pengontrol, model, tampilan, itu saja. Masalah dengan pendekatan ini adalah bahwa aplikasi kaus kaki terlaris akan terlihat persis seperti aplikasi pemesanan makanan. Dan untuk memahami esensi aplikasi, Anda harus masuk ke beberapa folder model dan melihat entitas seperti apa yang akhirnya kita miliki.
Perilaku Beego yang sakit inilah yang mereplikasi. Sementara Spring yang sama telah bergerak ke arah Domain Driven Design dan esensi dari struktur folder, Beego memaksa penggunaan struktur yang telah menjadi antipattern.
Tetapi masalahnya bahkan lebih serius. Untuk Go, tidak ada pemisahan antara struktur folder dan struktur paket. Oleh karena itu, di Beego dan UsersController dan OrdersController akan berada di bawah satu paket - pengendali. Dan jika Anda memiliki dua jenis pengontrol, yang melayani UI dan yang digunakan untuk API, apalagi, apakah lazim untuk versi mereka dalam masyarakat yang layak? Kemudian bersiap-siap untuk orang aneh seperti apiv1.
ORM
Anehnya, Beego, menjadi klon Ruby on Rails yang gagal, tidak menggunakan pola ActiveRecord. ORM-nya adalah pemandangan yang sangat aneh. Jika untuk operasi yang sepenuhnya dasar, seperti membaca garis / menulis garis, itu masih cocok, maka, misalnya, terlihat seperti sampel sederhana (selanjutnya, contoh diambil langsung dari dokumentasi):
qs.Filter("profile__age__gte", 18)
Tetapi masalah utama dengan Beego ORM adalah bahkan Anda tidak perlu berurusan dengan bahasa berpemilik, tetapi menggunakan semua praktik Go terburuk, apakah itu efek samping impor:
import ( _ "github.com/go-sql-driver/mysql" _ "github.com/lib/pq" _ "github.com/mattn/go-sqlite3" )
Atau mendaftar model di init ():
func init(){ orm.RegisterModel(new(User)) }
Bantulah diri Anda sendiri, bahkan jika Anda masih memutuskan untuk beberapa alasan yang tidak dapat dijelaskan untuk bekerja dengan Beego, jangan gunakan Beego ORM. Jika hidup Anda tanpa ORM tidak menyenangkan (dan apa yang Anda lakukan di dunia Go, sayang?), Gunakan
GORM . Setidaknya didukung. Kalau tidak,
"database / sql" akan membantu Anda.
Alat lebah
Alat baris perintah, yang hanya disebut
Bee , disalin dari Ruby on Rails. Tetapi hanya jika di dunia RoR ada rel dan disapu, maka lebah adalah sampah bagi semuanya. Dia dan aplikasi MVC untuk 'boostrap', dan menjalankan migrasi, dan pengamat file akan diluncurkan. Yang terakhir adalah masalah lain. Lagi pula, apa salah satu keunggulan utama Go? Apa yang dimulai secara lokal sedekat mungkin dengan apa yang dimulai dalam produksi. Jika Anda tidak menggunakan lebah, tentu saja.
Perutean otomatis
Go adalah bahasa yang sangat diketik yang tidak mendukung generik atau anotasi. Bagaimana cara membuat kerangka MVC pada ini? Dengan membaca komentar dan menghasilkan file, tentu saja.
Itu terlihat seperti ini:
Bukti, seperti yang Anda lihat, adalah nol. Fungsi Post () tidak menerima atau mengembalikan apa pun. http.pertanyaan? Tidak, tidak terdengar.
Nah, bagaimana cara kerja semua rute? Saat Anda memulai lebah jahat, file lain dihasilkan, commentsRouter_controllers.go, yang berisi contoh kode yang luar biasa:
func init() { beego.GlobalControllerRouter["github.com/../../controllers:ObjectController"] = append(beego.GlobalControllerRouter["github.com/../../controllers:ObjectController"], beego.ControllerComments{ Method: "Post", Router: `/`, AllowHTTPMethods: []string{"post"}, MethodParams: param.Make(), Filters: nil, Params: nil}) ... }
Lihat, jangan lupa untuk membuat ulang dan 'melakukan' file ini setelah setiap perubahan. Sampai baru-baru ini, situasinya bahkan lebih menyedihkan, dan selama pengujian file ini dihasilkan secara otomatis, jadi Anda sudah belajar tentang masalah dalam produksi. Tampaknya dalam versi terbaru perilaku aneh ini telah diperbaiki.
Pengujian komponen
Jadi kita sampai pada topik pengujian. Go, tidak seperti kebanyakan bahasa pemrograman lainnya, hadir dengan kerangka uji di luar kotak. Secara umum, filosofi Go adalah bahwa tes harus duduk di sebelah file tes. Tapi kita berada di dunia MVC, meludahi filosofi Go, kan? Oleh karena itu, mohon berbaik hati untuk menempatkan semua tes Anda di / tes ayah, karena
DHH mewariskan kepada kami.
Dan ini bukan hal yang sepele, karena, saya ingat, di folder Go package ==. Dan jika tes yang terletak di paket yang sama dapat memanggil metode pribadi, maka tes yang terletak di paket lain tidak lagi ada.
Tapi oke, semuanya akan terbatas pada struktur folder. Kode Beego, pada prinsipnya, sangat sulit untuk diuji, karena semua yang ada di dalamnya adalah efek samping.
Ini adalah bagaimana Beego menanyakan router:
import ( _ "github.com/../../routers" )
Kisah yang sama dengan middlewares, dan dengan pengontrol yang saya sebutkan sebelumnya.
Dokumentasi
Ini seperti arsitek perangkat lunak bagi saya pada kue. Dokumentasi BeeGo sama baiknya dengan bahasa Mandarin Anda. Tidak, komentar dalam bahasa Cina di dalam kode selama dua tahun terakhir telah terbuang.
Sekarang dalam bahasa Cina hanya ada beberapa permintaan tarik:
Dan terutama dalam masalah:
Alih-alih sebuah kesimpulan
Jika Anda memiliki tim penulis kode Ruby / PHP / Python dan Anda sangat ingin menerjemahkannya ke Go, hal terburuk yang dapat Anda lakukan untuk mereka adalah membuat mereka beralih ke kerangka kerja MVC di Go. MVC secara keseluruhan adalah pola arsitektur yang begitu-begitu, dan di Go umumnya tidak pada tempatnya. Atau, jika Anda benar-benar yakin bahwa apa pun selain Go akan menyelamatkan Anda, biarkan mereka mempelajari kembali dan menulis dengan cara itu diterima di Go - sel flat dan sejelas mungkin. Atau, mungkin mereka lebih tahu, dengan alat apa untuk menyelesaikan tugas mereka?