Discutons des projets communs dans l'éditeur - pourquoi et où ils vont - page 6
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
J'ai formé quelqu'un à MQL5 aujourd'hui et il a créé un projet à partir de zéro sans mon aide. C'est vraiment très simple, qu'est-ce qui inquiète les gens... Ils n'ont jamais dû s'occuper de projets auparavant.
J'ai eu quelques bugs avec l'entrepôt jusqu'à ce qu'il commence à fonctionner correctement et je n'ai jamais compris où étaient mes erreurs.
Imaginons maintenant que j'essaie de déterminer si je dois diviser toute ma bibliothèque en plusieurs projets distincts ou si je dois tout regrouper en un seul. Si je la divise en sections distinctes, alors, en théorie, l'accès aux différentes sections de la bibliothèque est simplifié, mais en même temps certains fichiers tombent dans plusieurs projets à la fois - puis-je faire cela ?
Je ne peux pas vraiment m'identifier à l'éditeur, mais maintenant qu'il y a des projets d'équipe, y aura-t-il un suivi des tâches ? Qu'en sera-t-il en termes d'organisation de l'équipe, de définition des tâches, de révision du code ?
Non, je ne fais que "souffler sur l'eau" - j'ai toujours eu des problèmes avec l'entrepôt, jusqu'à ce qu'il commence à fonctionner correctement, et je n'ai jamais compris quelles étaient mes erreurs.
Imaginons maintenant que j'essaie de déterminer si je dois diviser toute ma bibliothèque en plusieurs projets distincts ou si je dois tout regrouper en un seul. Si je la divise en sections séparées, alors, en théorie, l'accès aux sections individuelles de la bibliothèque est ordonné, mais il se retrouve avec certains fichiers dans plusieurs projets à la fois - puis-je faire cela ?
Si vous ne le faites que pour vous-même, la bibliothèque doit être déplacée dans un projet séparé à l'intérieur du répertoire et du travail de MQL5.
Si vous voulez des projets communs, créez un projet de bibliothèque distinct et des projets de travail distincts. À partir des projets de travail, faites référence au projet de la bibliothèque voisine par des chemins relatifs.
Pourriez-vous créer un fil similaire sur le Testeur ?
)))))))))))))) C'était une blague d'humour ? Faisons un bugzilla dans le méta-éditeur).
Imaginez que vous êtes le commandant du projet, que plusieurs participants vous envoient du code sur le projet. Comment regarderiez-vous leur code, comment feriez-vous des commentaires, etc. Comment allez-vous fixer des tâches spécifiques pour chaque membre de l'équipe ? Comment allez-vous garder la trace de qui a ajouté quoi et quand ?
Ce n'est pas vraiment un problème - il existe de nombreux services externes.
Quels sont les avantages du service du développeur individuel en question par rapport aux classiques ?
Quels sont les avantages du service discuté pour le développeur individuel par rapport aux classiques ?
1) Créer des programmes complexes et les gérer de manière pratique. Plus besoin de s'embêter avec un seul fichier.
2) Ils apprendront à utiliser les systèmes de contrôle de version. La plupart d'entre eux ne les ont jamais utilisés auparavant.
3) Ils apprendront à travailler sur des projets communs.
4) Il sera plus facile de préparer et de publier des produits dans un appstore et de coder pour une kodobase.
5) Il est plus facile de travailler en tant qu'indépendant, lorsque le client peut non seulement suivre l'évolution du projet, mais aussi participer au processus de développement.
6) Les projets publics sont un autre endroit où ils peuvent montrer leurs compétences en tant qu'auteur et contributeur/contributeur à d'autres projets.
7) Améliorer leurs compétences en programmation : +1 sur le contrôle de version, +1 sur le travail en groupe.
C'est ce qui se trouve à la surface.
Eh bien pas bugzilla - il existe de nombreuses solutions. Le même visual studio a des outils, tfs est spécifiquement intégré dans l'éditeur.
Imaginez que vous êtes le chef de projet et que plusieurs contributeurs vous envoient du code pour un projet. Comment regarderiez-vous leur code, comment feriez-vous des commentaires, etc. Comment allez-vous fixer des tâches spécifiques pour chaque membre de l'équipe ? Comment allez-vous garder la trace de qui a ajouté quoi et quand ?
Ce n'est pas vraiment un problème - il existe de nombreux services externes.
Je plaisante.
MQ ne gaspillera pas de ressources pour des conneries dont 0,1% des utilisateurs ont besoin.
1) Sera capable de créer des programmes complexes et de les gérer de manière pratique. Plus besoin de s'embêter avec un seul fichier.
2) Ils apprendront à utiliser les systèmes de contrôle de version. La plupart des gens ne les ont jamais utilisés.
3) Ils apprendront à travailler sur des projets communs.
4) Il sera plus facile de préparer et de publier des produits dans l'appstore et des codes pour la codobase.
5) Il sera plus facile de travailler en tant qu'indépendant, lorsque le client pourra non seulement suivre l'évolution de la situation, mais aussi participer au développement.
6) Les projets publics sont un endroit de plus pour démontrer vos compétences en tant qu'auteur et contributeur/contributeur à d'autres projets.
7) Améliorer leurs compétences en programmation : +1 sur le contrôle de version, +1 sur le travail en groupe
C'est ce qui se trouve à la surface.
4-6 pouvez-vous développer ? Pourrai-je lancer le KB sans la paperasserie actuelle ?