Tout battage médiatique est très drôle quand on le regarde de côté. Moins drôle quand vous vous impliquez directement.
Hype Go est tombé quelque part en 2014, lorsque les auteurs d'applications qui avaient 1000 tr / min (demandes par minute) ont soudainement décidé comme un besoin urgent de simultanéité, car leur 1000 tr / min était sur le point de se transformer en 1000 tr / min (ce qui n'est pas tellement, en fait).
Le résultat du battage médiatique a été que de nombreuses personnes qui se sont habituées à l'architecture MVC de l'application ont rejoint le Go, que ce soit Spring, Django ou Ruby on Rails. Et cette architecture, comme un hibou sur un globe, ils ont commencé à tirer sur Go. Les cadavres sont donc apparus comme Beego et
Revel . Revel est mort en toute sécurité, bien qu'ils essaient toujours de le pomper. Mais je veux parler de Beego séparément.
Richard Eng a apporté une contribution significative à la promotion de Beego auprès des masses avec sa série d'articles
«A word the Beegoist» . Pratiquement "l'Evangile de Richard". Ironiquement, malgré le fait que Richard fasse une promotion frénétique de Go, il n'y écrit pas lui-même.
À mon tour, j'ai travaillé avec Go, et pire encore, avec Beego, j'ai beaucoup travaillé. Et je peux dire que ce n'est clairement pas la voie à suivre pour le développement sur Go.
Examinons quelques aspects de base de Beego, et pourquoi ils contredisent les meilleures pratiques de Go et de l'industrie dans son ensemble.
Structure des dossiers
Robert C. Martin, mieux connu sous le nom d'
Oncle Bob , a exprimé à plusieurs reprises l'idée que la structure d'une demande devrait transmettre son essence. Il aime beaucoup donner un exemple avec une cathédrale, qui peut être vue d'en haut, et comprendre immédiatement qu'il s'agit d'une cathédrale.
Robert a critiqué à plusieurs reprises Ruby on Rails pour sa structure de dossiers - contrôleurs, modèles, vues, c'est tout. Le problème avec cette approche est que l'application de chaussettes la plus vendue ressemblera exactement à une application de commande de nourriture. Et pour comprendre l'essence de l'application, vous devrez monter dans un dossier de modèles et voir avec quel type d'entités nous nous retrouvons.
C'est ce comportement malade de Beego qui se reproduit. Alors que le même printemps s'est déplacé vers la conception pilotée par domaine et l'essence de la structure de dossiers, Beego force l'utilisation d'une structure devenue anti-modèle.
Mais le problème est encore plus grave. Pour Go, il n'y a pas de séparation entre la structure de dossiers et la structure de packages. Par conséquent, dans Beego et UsersController et OrdersController seront sous un seul paquet - les contrôleurs. Et si vous avez deux types de contrôleurs, ceux qui servent l'interface utilisateur et ceux qui sont utilisés pour l'API, de plus, dans une société décente, sont-ils généralement versionnés? Alors préparez-vous à des monstres comme apiv1.
ORM
Curieusement, Beego, étant un clone Ruby on Rails infructueux, n'utilise pas le modèle ActiveRecord. Son ORM est un spectacle extrêmement étrange. Si pour des opérations complètement basiques, comme la lecture d'une ligne / l'écriture d'une ligne, cela convient toujours, alors, par exemple, ressemble à un simple exemple (ci-après, des exemples sont directement extraits de la documentation):
qs.Filter("profile__age__gte", 18)
Mais le principal problème avec Beego ORM n'est même pas que vous ayez besoin de gérer le langage propriétaire, mais qu'il utilise toutes les pires pratiques de Go, qu'il s'agisse d'effets secondaires d'importation:
import ( _ "github.com/go-sql-driver/mysql" _ "github.com/lib/pq" _ "github.com/mattn/go-sqlite3" )
Ou enregistrer des modèles dans init ():
func init(){ orm.RegisterModel(new(User)) }
Rendez-vous service, même si vous décidez pour une raison inexplicable de travailler avec Beego, n'utilisez pas Beego ORM. Si votre vie sans ORM n'est pas agréable (et que faites-vous dans le monde de Go, mon cher?), Utilisez
GORM . Il est au moins pris en charge. Sinon,
"database / sql" vous aidera.
Outil d'abeille
L'outil de ligne de commande, qui est simplement appelé
Bee , est copié à partir de Ruby on Rails. Mais seulement si dans le monde de RoR il y avait des rails et du râteau, alors l'abeille est une poubelle pour tout. Lui et l'application MVC pour «boostrap», et exécutez la migration, et l'observateur de fichiers se lancera. Ce dernier est un autre problème. Après tout, quel est l'un des principaux avantages de Go? Ce qui commence localement est aussi proche que possible de ce qui commence en production. Si vous n'utilisez pas d'abeille, bien sûr.
Routage automatique
Go est un langage fortement typé qui ne prend en charge ni les génériques ni les annotations. Comment mouler un framework MVC là-dessus? En lisant les commentaires et en générant des fichiers, bien sûr.
Cela ressemble à ceci:
La preuve, comme vous pouvez le voir, est nulle. La fonction Post () ne reçoit ni ne renvoie rien du tout. http.Request? Non, pas entendu.
Eh bien, comment fonctionne tout routage? Lorsque vous démarrez l'abeille notoire, un autre fichier est généré, commentsRouter_controllers.go, qui contient un exemple de ce merveilleux code:
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}) ... }
Voir, n'oubliez pas de régénérer et de «valider» ce fichier après chaque modification. Jusqu'à récemment, la situation était encore plus triste, et pendant les tests, ce fichier était généré automatiquement, vous avez donc déjà pris connaissance des problèmes de production. Il semble que dans les versions récentes, ce comportement étrange ait été corrigé.
Test des composants
Et nous arrivons donc au sujet des tests. Go, contrairement à la plupart des autres langages de programmation, est livré avec un framework de test prêt à l'emploi. En général, la philosophie de Go est que le test doit être placé à côté du fichier de test. Mais nous sommes dans le monde MVC, crachez sur la philosophie Go, non? Par conséquent, veuillez placer tous vos tests dans le papa / test, comme nous l'a légué
DHH .
Et ce n'est pas si insignifiant, car, je me souviens, dans le dossier Go package ==. Et si le test situé dans le même package peut appeler la méthode privée, le test situé dans un autre package n'est plus là.
Mais d'accord, tout serait limité à la structure des dossiers. Le code Beego est, en principe, très difficile à tester, car tout ce qu'il contient est un effet secondaire.
Voici comment Beego interroge les routeurs:
import ( _ "github.com/../../routers" )
La même histoire avec les middlewares et les contrôleurs que j'ai mentionnés plus tôt.
La documentation
C'est comme un architecte logiciel pour moi sur un gâteau. La documentation BeeGo est aussi bonne que votre chinois. Non, les commentaires en chinois dans le code au cours des deux dernières années se sont en quelque sorte débarrassés.
Maintenant, en chinois, il n'y a que quelques demandes de tirage:
Et surtout dans les dossiers:
Au lieu d'une conclusion
Si vous avez une équipe de rédacteurs de code Ruby / PHP / Python et que vous souhaitez de toute urgence les traduire en Go, la pire chose que vous puissiez faire pour eux est de les amener à passer au framework MVC sur Go. MVC dans son ensemble est un modèle architectural médiocre, et dans Go, il est généralement hors de propos. Ou, si vous êtes absolument sûr que rien d'autre que Go ne vous sauvera, laissez-les réapprendre et écrire de la manière qui est acceptée dans Go - aussi plate et explicite que possible. Ou, peut-être qu'ils connaissent mieux, avec quel outil pour résoudre leurs tâches?