Quelle est la meilleure façon de mettre en page un projet Go ?

Question

J'ai un projet de go qui commence à devenir plus complexe, et je veux disposer le système de fichiers de manière à réduire la douleur.

Existe-t-il de bons exemples de ce qui est logique ?

Answer 1

Mise à jour mai 2013 : la documentation officielle se trouve dans la section " Organisation du code "

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

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

El go tool construit les paquets sources et installe les binaires qui en résultent dans le fichier pkg y bin les répertoires.

El src contient généralement plusieurs dépôts de contrôle de version (comme pour Git ou Mercurial) qui suivent le développement d'un ou plusieurs paquets 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 de juillet 2014 : voir " Structuration des applications en Go " de Ben Johnson

Cet article comprend des conseils comme :

Séparer votre binaire de votre application

en combinant les main.go et ma logique d'application dans le même paquet a deux conséquences :

• Cela rend mon application inutilisable en tant que bibliothèque.
• Je ne peux avoir qu'une seule application binaire.

Le meilleur moyen que j'ai trouvé pour résoudre ce problème est d'utiliser simplement un " cmd Dans mon projet, il y a un répertoire " " dont chacun des sous-répertoires est un binaire d'application.

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

Développement axé sur les bibliothèques

Déplacer le main.go hors de votre Root vous permet de construire votre application du point de vue d'une bibliothèque. Le binaire de votre application est simplement un client de la bibliothèque de votre application.

Il arrive parfois que vous souhaitiez que les utilisateurs interagissent de plusieurs manières et que vous créiez plusieurs binaires.
Par exemple, si vous aviez un " adder "qui permet aux utilisateurs d'additionner des nombres, vous voudrez peut-être publier une version en ligne de commande ainsi qu'une version Web.
Vous pouvez facilement y parvenir en organisant votre projet comme suit :

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

Les utilisateurs peuvent installer les binaires de votre application "adder" avec "go get" en utilisant une ellipse :

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

Et voilà, votre utilisateur a " adder " et " adder-server " installé !

Ne devenez pas fou avec les sous-paquets

En général, les types de mes projets sont tous très proches les uns des autres, de sorte que cela convient mieux du point de vue de la convivialité et de l'API.
Ces types peuvent également tirer parti de l'appel à l'état non exporté entre eux, ce qui permet de conserver une API petite et claire.

1. Regroupez les types et les codes connexes dans chaque fichier. Si vos types et fonctions sont bien organisés, je trouve que les fichiers ont tendance à être entre 200 et 500 SLOC. Cela peut sembler beaucoup, mais je trouve que cela facilite la navigation. 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 par importance décroissante vers le bas du fichier.
3. Lorsque votre demande commence à dépasser les 10 000 SLOC, vous devez sérieusement évaluer si elle peut être divisée en plus petits projets.

Remarque : cette dernière pratique n'est pas toujours bonne :

Désolé, je ne suis pas d'accord avec cette pratique.
La séparation des types de fichiers facilite la gestion du code, la lisibilité, la maintenabilité et la testabilité.
Il peut également garantir une responsabilité unique et le respect du principe d'ouverture/fermeture
La règle pour ne pas autoriser la dépendance circulaire est d'obliger à avoir une structure claire des paquets.

---

(Alternative février 2013, concernant src seulement)
Vous pouvez trouver la disposition classique illustrée dans " Mise en page du code GitHub " :

L'application et les deux bibliothèques se trouvent sur Github, chacune dans son propre dépôt.
$GOPATH est la racine du projet - chacun de vos dépôts Github sera extrait de plusieurs dossiers situés en dessous. $GOPATH .

La disposition de votre code devrait ressembler à 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'un checkout git séparé.

Cela a cependant suscité quelques critiques, dans ce page reddit :

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

Mettez le paquet principal dans la racine du repo.
Placez les actifs dans un sous-répertoire (pour garder les choses en ordre).
Gardez l'essentiel du code dans un sous-paquetage (au cas où quelqu'un voudrait le réutiliser en dehors de votre binaire).
Inclure un setup script dans la racine du repo afin qu'il soit facile à trouver.

C'est toujours un processus en deux étapes pour télécharger, construire, installer et configurer.. :

• " go get <your repo path> " : télécharge et installe le code go, avec un sous-dossier pour les actifs.
• $GOPATH/<your repo path>/setup.sh : distribue les actifs au bon endroit et installe le service

Answer 2

Je suppose que par "projet" vous ne voulez pas dire un paquet Go mais un logiciel que vous développez. Sinon, vous pouvez obtenir de l'aide ici y ici . Cependant, ce n'est pas très différent de l'écriture de paquets pour Go : Utilisez des paquets, créez un dossier pour chaque paquet et combinez ces paquets dans votre application.

Pour vous forger une opinion, vous pouvez regarder les dépôts de Go les plus populaires 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 Go principal et de nombreux modules et sous-modules dans leurs propres répertoires. Si vous avez de nombreux méta-fichiers (doc, licence, modèles, ...), vous pouvez placer le code source dans un sous-répertoire. C'est ce que j'ai fait jusqu'à présent.

Answer 3

J'ai décrit une façon de configurer un environnement Go ici : http://blog.tideland.biz/2013-07-09-go-environment-setup . Il montre également comment gérer les paquets de tiers.

Answer 4

Il existe un approche recommandée des auteurs de Golang, qui définit la manière d'agencer votre code pour qu'il fonctionne au mieux avec les outils de go et prenne en charge les systèmes de contrôle des sources.

Answer 5

Vous devriez probablement aussi jeter un coup d'œil à ce dépôt. Il montre beaucoup d'idées sur la façon de structurer les applications go : https://github.com/golang-standards/project-layout