Quel est un moyen judicieux de mettre en page un projet Go

Mise à jour mai 2013: la documentation officielle est dans la section ” Organisation du code ”

Le code Go doit être conservé dans un espace de travail .
Un espace de travail est une hiérarchie de répertoires avec trois répertoires à sa racine:

• src contient des fichiers sources Go organisés en paquets (un paquet par répertoire),
• pkg contient des objects de package, et
• bin contient des commandes exécutables.

L’ go tool crée des paquets source et installe les fichiers binarys résultants dans les répertoires pkg et bin .

Le sous-répertoire src contient généralement plusieurs référentiels de contrôle de version (tels que Git ou Mercurial) qui suivent le développement d’un ou plusieurs packages source.

 bin/ streak # command executable todo # command executable pkg/ linux_amd64/ code.google.com/p/goauth2/ oauth.a # package object github.com/nf/todo/ task.a # package object src/ code.google.com/p/goauth2/ .hg/ # mercurial repository metadata oauth/ oauth.go # package source oauth_test.go # test source 

Mise à jour Juillet 2014: voir ” Structuration des applications dans Go ” dans Ben Johnson

Cet article comprend des astuces comme:

Séparez votre fichier binary de votre application

La combinaison du fichier main.go et de la logique de mon application dans le même package a deux conséquences:

• Cela rend mon application inutilisable en tant que bibliothèque.
• Je ne peux avoir qu’une application binary.

La meilleure façon de résoudre ce problème est d’utiliser simplement un répertoire « cmd » dans mon projet où chacun de ses sous-répertoires est un fichier binary d’application.

 camlistore/ cmd/ camget/ main.go cammount/ main.go camput/ main.go camtool/ main.go 

Développement piloté par la bibliothèque

Déplacer le fichier main.go de votre racine vous permet de créer votre application du sharepoint vue d’une bibliothèque. Votre application binary est simplement un client de la bibliothèque de votre application.

Parfois, vous souhaiterez peut-être que les utilisateurs interagissent de plusieurs manières afin de créer plusieurs fichiers binarys.
Par exemple, si vous adder package « adder » permettant aux utilisateurs d’append des numéros ensemble, vous souhaiterez peut-être publier une version en ligne de commande et une version Web.
Vous pouvez facilement le faire en organisant votre projet comme ceci:

 adder/ adder.go cmd/ adder/ main.go adder-server/ main.go 

Les utilisateurs peuvent installer vos binarys d’application «adder» avec «go get» en utilisant des points de suspension:

 $ go get github.com/benbjohnson/adder/... 

Et voila, votre utilisateur a installé “ adder ” et “ adder-server ”!

Ne pas devenir fou avec des sous-paquets

Généralement, les types de projets sont très liés, ce qui les rend mieux utilisables du sharepoint vue de la facilité d’utilisation et de l’API.
Ces types peuvent également tirer parti de l’appel d’exportés entre eux, ce qui permet de garder l’API petite et claire.

1. Regroupez les types et les codes associés dans chaque fichier. Si vos types et fonctions sont bien organisés, je trouve que les fichiers ont tendance à se situer entre 200 et 500 SLOC. Cela peut sembler beaucoup, mais je trouve facile de naviguer. 1000 SLOC est généralement ma limite supérieure pour un seul fichier.
2. Organisez le type le plus important en haut du fichier et ajoutez les types en importance décroissante vers le bas du fichier.
3. Une fois que votre application commence à dépasser 10 000 SLOC, vous devez sérieusement évaluer si elle peut être divisée en projets plus petits.

Note: cette dernière pratique n’est pas toujours bonne:

Désolé je ne peux pas être d’accord avec cette pratique.
La séparation des types de fichiers facilite la gestion du code, la lisibilité, la maintenance, la testabilité.
Il peut également assurer une responsabilité unique et le respect du principe d’ouverture / de fermeture…
La règle pour ne pas permettre une dépendance circulaire est de forcer nous avons une structure claire des paquets.

(Alternative février 2013, concernant src uniquement)
Vous pouvez trouver la mise en page classique illustrée dans ” GitHub Code Layout “:

L’application et les deux bibliothèques vivent sur Github, chacune dans son propre référentiel.
$GOPATH est la racine du projet – chacun de vos repositorys Github sera extrait de plusieurs dossiers sous $GOPATH .

Votre disposition de code ressemblerait à ceci:

 $GOPATH/ src/ github.com/ jmcvetta/ useless/ .git/ useless.go useless_test.go README.md uselessd/ .git/ uselessd.go uselessd_test.go README.md 

Chaque dossier sous src/github.com/jmcvetta/ est la racine d’une extraction séparée de git.

Cela a cependant suscité quelques critiques sur cette page de reddit :

Je recommande fortement de ne pas structurer le repo comme vous l’avez fait, il va casser ” go get “, qui est l’une des choses les plus utiles sur Go.
Il est de loin préférable d’écrire votre code pour les personnes qui connaissent bien Go, car ce sont elles qui sont le plus susceptibles de le comstackr.
Et pour ceux qui ne le font pas, ils auront au moins une idée de la langue.

Placez le package principal à la racine du repository.
Avoir les ressources dans un sous-répertoire (pour garder les choses propres).
Gardez la viande du code dans un sous-paquet (au cas où quelqu’un voudrait le réutiliser en dehors de votre binary).
Incluez un script d’installation à la racine du repository afin qu’il soit facile à trouver.

Ce n’est encore qu’un processus en deux étapes pour télécharger, créer, installer et configurer .:

• ” go get “: télécharge et installe le code go, avec un sous-répertoire pour les actifs
• $GOPATH//setup.sh : dissortingbue les ressources au bon endroit et installe le service

Je suppose qu’avec «projet», vous ne voulez pas dire un package Go, mais un logiciel que vous développez. Sinon, vous pouvez obtenir de l’aide ici et ici . Cependant, ce n’est pas tellement différent d’écrire des paquets pour Go: Utilisez des packages, créez un dossier pour chaque package et combinez ces packages dans votre application.

Pour vous faire une opinion, vous pouvez regarder les repositorys de Go sur github: https://github.com/trending/go . Des exemples notables sont cayley et zeus .

Le schéma le plus populaire est probablement d’avoir un fichier principal Go et de nombreux modules et sous-modules dans leurs propres répertoires. Si vous avez de nombreux fichiers méta (doc, licence, modèles, …), vous pouvez placer le code source dans un sous-répertoire. C’est ce que j’ai fait jusqu’ici.

Il y a une approche recommandée par les auteurs de Golang qui définit comment mettre en forme votre code pour qu’il fonctionne mieux avec les outils go et pour prendre en charge les systèmes de contrôle de source.

Vous devriez probablement aussi jeter un oeil à ce repo. Il montre beaucoup d’idées sur la façon de structurer les applications: https://github.com/golang-standards/project-layout