Comment puis-je rendre mon flux de travail de développement plus «d'entreprise»?

Question

Je suis le seul développeur d'un consortium universitaire dont le siège est situé dans une université du nord-est. Tout mon travail de développement implique des outils internes, principalement en Java, donc rien n’est rendu public. À l’heure actuelle, j’ai le sentiment que mon flux de travail de développement est très "amateur". et ne ressemble en rien à une entreprise de développement logiciel expérimentée. Je serais enclin à dire que cela n'a pas vraiment d'importance puisque je suis le seul développeur, mais il ne fait pas de mal de faire quelques changements, ne serait-ce que pour faciliter mon travail et en obtenir quelques-uns. plus de technologies sur mon CV. En ce moment, mon flux de travail ressemble à ceci:

• Je fais la plupart de mes travaux de développement sous Eclipse sur mon ordinateur portable. Tout est sauvegardé localement sur mon ordinateur portable, et je n'utilise pas de VCS, je ne sauvegarde pas non plus mon code (sauf pour l'envoyer occasionnellement par courrier électronique afin que je puisse le voir sur un autre ordinateur - oui, je vous ai dit mon environnement de développement a besoin de travail).

• Quand j'ai fini avec un projet et que je veux le déployer ou si je veux juste le tester, j'utilise l'outil Jar intégré à Eclipse pour créer un fichier .jar exécutable de mon projet. Si j'utilise des bibliothèques .jar externes, j'utilise le plug-in Fat-Jar pour inclure ces fichiers .jars dans mon exécutable .jar.

• Après avoir créé le fichier .jar, je le télécharge manuellement sur le serveur via SFTP et le teste avec quelque chose comme java -jar MonProjet.jar .

Oh oui, ai-je mentionné que je ne fais pas de test unitaire?

Le problème le plus évident que je voudrais résoudre en premier lieu est mon manque de contrôle de la source. J'aime git en raison de sa nature distribuée, mais il ne semble pas bien s'intégrer à Eclipse et j'ai entendu dire que cela ne fonctionnait pas très bien sous Windows, qui est mon système d'exploitation de développement principal. Donc, je penche en faveur de SVN, avec lequel j'ai une certaine expérience. J'ai mon propre serveur personnel, et je pense l'utiliser pour mon contrôle de source, car je préfère être mon propre administrateur que de traiter avec la bureaucratie universitaire. J'ai déjà eu du mal à configurer SVN une fois, mais je vais essayer encore une fois. J'installerai peut-être aussi quelque chose comme Trac ou Redmine pour le suivi des bogues, la liste de tâches à faire, etc.?

Qu'en est-il de la construction et du déploiement? Il doit exister un meilleur moyen que d’utiliser Fat-Jar et de télécharger manuellement mon fichier jar sur le serveur. J'ai entendu parler d'outils tels que Ant et Maven. Ces outils s'appliquent-ils à ce que je veux faire? Comment puis-je commencer à les utiliser?

Je suppose que je souhaiterais éventuellement intégrer également les tests unitaires avec JUnit. Même si cela devrait probablement être le cas, ce n’est pas ma principale préoccupation pour le moment, car jusqu’à présent, mes applications ne sont pas terriblement complexes. J'aimerais vraiment travailler sur la simplification et la rationalisation de mon flux de travail maintenant, puis je vais passer aux tests unitaires.

Désolé pour la longue question. Je suppose que ma question se résume à: pour un développeur unique, quels outils et quelles méthodologies puis-je utiliser pour faciliter mon travail, mais aussi simplement pour m'exposer à certaines technologies qui seraient attendues des connaissances requises lors d'un développement dédié maison?

edit: Merci pour les bonnes réponses jusqu'à présent. Je ne voulais pas suggérer que je voulais rendre mon flux de travail "entreprise". Juste pour le plaisir de le faire, mais pour me simplifier la tâche et me familiariser avec quelques technologies généralement utilisées dans les environnements de développement d’entreprise. C’est tout ce que je voulais dire par là.

Answer 1

Il me semble que vous avez en fait une assez bonne idée de ce que vous devez faire.

Utiliser Subversion (ou un autre VCS) est indispensable. Cependant, il peut être judicieux de configurer un référentiel SVN distinct pour votre code lié au travail plutôt que d'utiliser un répertoire personnel.

Vous pouvez intégrer Subversion à Eclipse en utilisant un plugin tel que Subclipse, qui, selon moi, fonctionne assez bien.

J'utiliserais certainement Ant ou Maven. Ma préférence va à Ant car elle est plus flexible et je pense que cela conviendrait davantage à votre style de développement que Maven. Cependant, vous pouvez également consulter Apache Ivy , qui gère la gestion des dépendances.

En gros, vous configurez une tâche Ant qui exécute vos étapes de compilation, de construction et de déploiement. Ainsi, lorsque vous créez un package JAR final, vous pouvez être sûr qu'il a été testé par unité car il fait partie de votre script ant. La meilleure façon de se familiariser avec ant est de consulter quelques exemples et de consulter le manuel .

En ce qui concerne les tests unitaires - vous pouvez progressivement construire avec les tests unitaires. Je recommanderais d'utiliser JUnit avec un outil de couverture de code tel que Cobertura (facile à configurer). - cela vous aidera à comprendre la quantité de code que vos tests couvrent et est un indicateur de l'efficacité de vos tests.

Cela vaut également la peine de mettre en place quelque chose comme Trac - il est important de pouvoir garder une trace des bogues, et un wiki est étonnamment utile pour la documentation.

En d'autres termes, tout semble indiquer que vous êtes sur la bonne voie. Il vous suffit de commencer à utiliser certains de ces outils!

Answer 2

Si vous êtes vraiment déterminé à contrôler les sources distribuées, nous vous conseillons de consulter Bazaar . Son contrôle de source distribué de type GIT est conçu pour réaliser des fusions de très haute qualité. Par défaut, il fonctionne sur toutes les plates-formes, y compris Windows, et dispose d’un client TortoiseBZR .

Cependant, tout contrôle de source est meilleur que rien. Si vous êtes le seul développeur, rien de plus complexe que SVN n'est nécessaire. Les grandes entreprises et les projets utilisent SVN à tout moment, sans problème.

En ce qui concerne les tests unitaires, vous devez vous familiariser avec JUnit . Le fait que vous soyez au courant des tests unitaires et que vous sachiez que vous devriez le faire a encore plusieurs longueurs d'avance sur la plupart des développeurs ad-hoc.

Answer 3

Utilisez le contrôle de version. Période. SVN a une intégration excellente avec Eclipse et Windows. Récupérez le client TourtisSVN pour Windows et utilisez le plugin subclipse avec Eclipse.

Je vous conseillerais de vous procurer un disque dur externe ou d'utiliser l'un des serveurs de votre entreprise pour mettre votre référentiel sur et d'effectuer souvent des sauvegardes. Subversion fonctionne également très bien avec le déploiement et la mise à niveau. Apprenez simplement à le faire et vous ne regarderez jamais en arrière:)

En ce qui concerne les tests unitaires, certaines personnes diraient que c’est la voie à suivre, mais je n’ai pas trouvé suffisamment de preuves pour commencer la pratique moi-même. Si tout le monde peut me convaincre du contraire sur cette question, faites-le, s'il vous plaît!

En outre, ne cherchez pas l’entreprise " votre flux de travail - cherchez à l'améliorer. Des pratiques qui fonctionnent bien avec d’énormes équipes et sociétés risquent de ne pas bien fonctionner pour vous. Je suis à peu près le seul développeur et je connais la situation dans laquelle vous vous trouvez. Essayez tout et ne gardez que ce qui semble naturel au bout d'un moment.

Mais assurez-vous d’essayer SVN! Si votre société a un serveur LINUX avec Apache, voyez si vous pouvez configurer votre serveur à l’aide de DAV-SVN.

:

Answer 4

Je pense que vous avez répondu à la plupart de vos propres questions.

• Contrôle de la source: choisissez SVN - installation facile, excellente intégration avec Eclipse (subclipse).
• Utilisez Ant pour construire votre projet et le déployer (tâche SCP / SFTP)
• Conservez tous vos paramètres (paramètres de projet Eclipse, génération de xml, etc.) dans SVN.
• Utilisez Bugzilla pour suivre vos bugs / problèmes / requêtes / idées.

Answer 5

Il serait très avantageux de commencer à travailler avec le contrôle de version. Commencez maintenant, ne tardez pas! Git va VRAIMENT vite, et il y a déjà un TortoiseGit en cours de développement. SVN est toujours un excellent standard avec lequel travailler. Et je n’ai pas travaillé avec Mercurial, mais c’est un autre VCS qui mérite d’être étudié.

À part cela, je ne vois pas pourquoi votre flux de travail doit être d'entreprise. Il faut juste être efficace et confortable. Cela dit, je pense que vous devriez essayer de travailler avec un simple éditeur de texte et de compiler à partir de la ligne de commande. La plupart des meilleurs programmeurs du monde l'utilisent encore au lieu d'un IDE, ce qui vous aidera à comprendre les processus sous votre IDE préféré.

Answer 6

Découvrez le Kit de démarrage pragmatique pour les programmeurs pragmatiques.

Il vous familiarise avec les bases importantes du développement de logiciels que les universités / etc. semble passer, comme le contrôle de version, les tests unitaires et l’automatisation de projet (dans cet ordre), et le fait de manière très abordable.

Cela vous donnera une base solide pour continuer à partir de là.

Answer 7

Jetez un oeil à Appfuse de Matt Raible.

Il intègre les tests Maven et les tests unitaires.

http://raibledesigns.com/rd/tags/appfuse

Answer 8

Bien que ce soit la dernière chose à faire, je pense que vous devriez commencer à utiliser jUnit sans délai.

En effet, c’est probablement la plus facile des ambitions que vous avez identifiées, et les outils sont presque certainement déjà intégrés à votre version d’Eclipse.

Créez un nouveau dossier dans votre projet appelé "jUnit".

Supposons que vous avez une classe Employee, avec les méthodes setAnnualSalary () et getMonthlySalary ().

Cliquez avec le bouton droit sur le dossier jUunit, nouveau - > "jUnit test case". Cela fera une nouvelle classe. Appelez-le TestEmployee. Eclipse génère les commandes standard, comme d’habitude.

Ajouter une méthode void avec un nom commençant par 'test':

public void testSalaryCalc() {
    Employee emp = new Employee("John Doe");
    emp.setAnnualSalary(12000);
    assertEquals(1000,emp.getMonthlySalary());
}

Cliquez avec le bouton droit de la souris sur "Exécuter en tant que". - > "jUnit test". (La première fois, Eclipse peut vous inviter à configurer le projet. Faites ce qu'il dit.)

Si Employee fonctionne correctement, une barre verte s’affiche. Sabotez la classe Employé, relancez le test et vous verrez apparaître une barre rouge ainsi qu'un résultat vous indiquant la nature de l'échec.

Félicitations: vous effectuez des tests unitaires!

Cliquez avec le bouton droit sur le répertoire parent et choisissez "Exécuter en tant que test jUnit". exécutera toutes les classes Testcase du répertoire. Plus tard, vous pourrez incorporer jUnit à votre processus de construction, mais ne vous en faites pas pour l'instant.

La saisie semi-automatique vous montrera toutes les variantes de assert () que vous pouvez utiliser. Vous pouvez en prendre connaissance, et viser des pratiques dans lesquelles vous écrivez les scénarios de test avant la mise en œuvre qui les passe. Mais le simple fait de faire les choses ci-dessus vous procure de gros avantages.

Answer 9

Une fois que vous avez configuré le contrôle de version et quelques tests unitaires, je considérerais un serveur d'intégration continue (vous vouliez être d'entreprise, n'est-ce pas?).

Même si vous êtes et restez le seul développeur, cela pourrait vous aider à découvrir quelques erreurs. Les choses que vous avez oublié de vérifier ou les goûts. Un serveur CI vérifie régulièrement toutes vos sources, effectue une nouvelle construction et exécute tous vos tests. Il vous contactera également en cas d'erreur.

Ceci vous donne la garantie que vous (ou toute autre personne) pourrez extraire votre code et construire / exécuter vos projets.

Je vous conseillerais de consulter Hudson

.

Answer 10

Comme d’autres l’ont dit, vous savez déjà clairement ce que vous devez faire. Un VCS est un must, un CI ou un suivi de bogues peut être excessif (pour un seul développeur, une feuille de calcul peut suffire pour le suivi de bogues).

Une des choses qui pourrait vous être très bénéfique est de conserver un arriéré de produits organisé. En développement solo, je trouve que rester concentré sur les fonctionnalités hautement prioritaires et que l’évitement du glissement de fonctionnalités est l’un de mes plus grands défis. Garder un arriéré aide énormément. Il ne doit pas y avoir beaucoup plus qu'une liste de fonctionnalités hiérarchisées avec quelques notes sur la portée de chacune. Sur mon lieu de travail, nous conservons ces informations dans Trac, mais ici encore, un tableur peut suffire.

Et je souhaite créer une prise pour les tests unitaires, en particulier le développement piloté par les tests (TDD). Le le livre de Kent Beck est un bon point de départ. Je trouve que TDD m'aide à rester honnête et concentré sur ce que je dois vraiment faire, en particulier sur un projet à développeur unique sans assurance qualité. Parfois, il semble que le code s’écrit tout seul.

Answer 11

Vous avez obtenu des réponses très solides et une courte publication en ajoutant un lien vers un article sur le développement piloté par les tests, qui est une pratique agile qui aura fière allure dans votre CV. TDD

Answer 12

Si vous utilisez un serveur Windows sur lequel vous voulez placer votre serveur SVN, utilisez Visual SVN en tant que serveur. Il est très facile à installer et à utiliser. Il prend en charge l’authentification de base et l’authentification Windows. Il est également gratuit à utiliser.

Eclipse a de nombreux modules à intégrer à un serveur SVN, utilisez donc l’un de ceux-ci, ou le SVN Tortoise déjà suggéré.

Answer 13

Tous les commentaires précédents couvraient presque tout ce dont vous pourriez avoir besoin :-)

Je souhaite ajouter une autre approche sur la manière de développer (le flux de travail de développement).

Je suggère que vous lisiez l'article suivant et bien que ce soit un workflow git, vous pouvez utiliser la même idée pour tout autre outil que vous pourriez utiliser.

http://nvie.com/posts/a-successful-git modèle de branchement /