BeegoはもうGoではありません

横から見たときの誇大広告は非常に面白いです。 自分が直接関与していることに気付いたときはあまり面白くない



Hype Goは2014年頃に発生しました。1000RPM（1分あたりのリクエスト数）のアプリケーションの作成者は、1000RPMが1000RPSになりそうであったため（これもそれほど多くないため、実際に）。



誇大宣伝の結果、Spring、Django、Ruby on Railsなど、アプリケーションのMVCアーキテクチャに慣れた多くの人々がGoに参加しました。 そして、このアーキテクチャは、地球上のフクロウのように、Goを使用し始めました。 そのため、死体はBeegoやRevelのように登場しました。 Revelは無事に亡くなりましたが、彼らはまだそれを排出しようとしています。 しかし、Beegoについては別に話をしたいと思います。



Richard Engは、一連の記事「A bee the Beegoist」で、大衆の間でBeegoを促進することに多大な貢献をしました。 実際には「リチャードの福音書」。 皮肉なことに、Richardは必死にGoを宣伝していますが、彼自身はGoを書いていません。



順番に、私はGoで働き、さらに悪いことに、Beegoで多くの仕事をしました。 そして、これは明らかにGoの開発が進むべき道ではないと言えるでしょう。



Beegoのいくつかの基本的な側面と、Goおよび業界全体でさまざまなベストプラクティスと矛盾する理由を見てみましょう。

フォルダー構造

ボブおじさんとして知られるロバートC.マーティンは、アプリケーションの構造がその本質を伝えるべきであるという考えを繰り返し表明しています。 彼は、上から見ることができる大聖堂の例を挙げたいと思い、これが大聖堂であることをすぐに理解します。



Robertは、フォルダー構造（コントローラー、モデル、ビューなど）についてRuby on Railsを繰り返し批判しています。 このアプローチの問題は、最も売れている靴下アプリが食品注文アプリとまったく同じように見えることです。 そして、アプリケーションの本質を理解するために、いくつかのモデルフォルダーに登り、最終的にどのようなエンティティーになるかを確認する必要があります。



複製するのはこの病気のビーゴの行動です。 同じSpringがDomain Driven Designとフォルダー構造の本質に向かっている一方で、Beegoはすでにアンチパターンになっている構造の使用を強制しています。



しかし、問題はさらに深刻です。 Goの場合、フォルダー構造とパッケージ構造は分離されていません。 したがって、Beegoでは、UsersControllerとOrdersControllerは1つのパッケージ（コントローラー）の下にあります。 また、2種類のコントローラーがある場合、UIにサービスを提供するコントローラーと、APIに使用されるコントローラーは、まともな社会で一般的にバージョン管理されていますか？ 次に、apiv1のようなフリークの準備をします。

ORM

奇妙なことに、Beegoは失敗したRuby on Railsクローンであるため、ActiveRecordパターンを使用していません。 彼のORMは非常に奇妙な光景です。 行の読み取り/行の書き込みなど、非常に基本的な操作に適している場合は、たとえば、単純なサンプルのように見えます（以下の例はドキュメントから直接引用しています）。

qs.Filter("profile__age__gte", 18) // WHERE profile.age >= 18
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、Beego ORMの主な問題は、プロプライエタリな言語を扱う必要があるということすらありませんが、インポートsideffectsであるかどうかにかかわらず、Goのすべての最悪のプラクティスを使用することです。

 import ( _ "github.com/go-sql-driver/mysql" _ "github.com/lib/pq" _ "github.com/mattn/go-sqlite3" )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

または、init（）でモデルを登録します。

 func init(){ orm.RegisterModel(new(User)) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Beegoと連携する理由を説明できない理由で決定した場合でも、Beego ORMを使用しないでください。 ORMのないあなたの人生が良くないなら（そしてGoの世界で何をしているのか、愛しい人ですか？）、 GORMを使用してください。 少なくともサポートされています。 それ以外の場合は、 「database / sql」が役立ちます。

蜂ツール

また、Ruby on Railsからコピーされたのは、単にBeeと呼ばれるコマンドラインツールです。 しかし、RoRの世界にレールがあり、熊手だった場合にのみ、蜂はすべてにとってそのようなゴミです。 彼と 'boostrap'のMVCアプリケーション、および移行を実行すると、ファイルウォッチャーが起動します。 後者は別の問題です。 結局のところ、Goの主な利点の1つは何ですか？ ローカルで開始されるものは、実稼働で開始されるものに可能な限り近いものです。 もちろん、蜂を使わないなら。

自動ルーティング

Goは、ジェネリックまたは注釈をサポートしない、厳密に型指定された言語です。 これでMVCフレームワークを形成する方法は？ もちろん、コメントを読んでファイルを生成します。



次のようになります。

 // @Param body body models.Object true "The object content" // @Success 200 {string} models.Object.Id // @Failure 403 body is empty // @router / [post] func (this *ObjectController) Post() { var ob models.Object json.Unmarshal(this.Ctx.Input.RequestBody, &ob) objectid := models.AddOne(ob) this.Data["json"] = map[string]string{"ObjectId": objectid} this.ServeJson() }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、証拠はゼロです。 Post（）関数は何も受け取りも返さない。 http.Request？ いいえ、聞いていません。



さて、すべてのルーティングはどのように機能しますか？ 悪名高いミツバチを起動すると、別のファイルcommentsRou​​ter_controllers.goが生成されます。このファイルには、このようなすばらしいコードの例が含まれています。

 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}) ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

変更を行うたびに、このファイルを再生成して「コミット」することを忘れないでください。 最近まで、状況はさらに悲しく、テスト中にこのファイルは自動的に生成されたため、実稼働環境の問題については既に学習しました。 最近のバージョンでは、この奇妙な動作が修正されたようです。

コンポーネントテスト

それで、テストのトピックに行きます。 Goは、他のほとんどのプログラミング言語とは異なり、すぐに使えるテストフレームワークを備えています。 一般に、Goの哲学は、テストをテストファイルの隣に置くことです。 しかし、私たちはMVCの世界にいて、Goの哲学に唾を吐きますよね？ したがって、 DHHが遺贈したとおり 、すべてのテストを/ test daddyに配置してください。



Go package == folderで思い出すように、これはそれほど些細なことではありません。 また、同じパッケージにあるテストがプライベートメソッドを呼び出すことができる場合、別のパッケージにあるテストはもう存在しません。



しかし、大丈夫、すべてがフォルダ構造に制限されます。 Beegoコードは、その中のすべてが副作用であるため、原則として、テストが非常に困難です。



これは、Beegoがルーターを照会する方法です。

 import ( _ "github.com/../../routers" )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ミドルウェアとコントローラーについても同じことが言えます。これについては、前に説明しました。

ドキュメント

それは、私にとってケーキのソフトウェアアーキテクトのようなものです。 BeeGoのドキュメントは、あなたの中国語と同じくらい良いです。 いいえ、過去2年間のコード内の中国語へのコメントは、一種の除去されました。



現在、中国語ではプルリクエストはわずかです：







そして、特に問題で：

結論の代わりに

Ruby / PHP / Pythonコードライターのチームがあり、それらをGoに早急に翻訳したい場合、彼らのためにできる最悪のことは、GoのMVCフレームワークに切り替えることです。 MVC全体はまあまあのアーキテクチャパターンであり、Goでは一般に不適切です。 または、Go以外に何も役に立たないと確信している場合は、Goで受け入れられる方法で、できる限りフラットで明示的に学習し直してください。 または、おそらく、彼らは自分のタスクを解決するためのどのツールを使用してよりよく知っていますか？