Processus de développement Java
Fermé
assiah10
Messages postés
2
Date d'inscription
jeudi 23 juin 2022
Statut
Membre
Dernière intervention
25 juin 2022
-
23 juin 2022 à 16:11
KX Messages postés 16733 Date d'inscription samedi 31 mai 2008 Statut Modérateur Dernière intervention 31 janvier 2024 - 28 juin 2022 à 13:26
KX Messages postés 16733 Date d'inscription samedi 31 mai 2008 Statut Modérateur Dernière intervention 31 janvier 2024 - 28 juin 2022 à 13:26
1 réponse
KX
Messages postés
16733
Date d'inscription
samedi 31 mai 2008
Statut
Modérateur
Dernière intervention
31 janvier 2024
127
28 juin 2022 à 13:26
28 juin 2022 à 13:26
Bonjour,
"Je me demande simplement à quoi ressemble le flux de travail de développement d'un développeur Java chevronné"
La très grande majorité du cycle de développement se fait "de tête" en écrivant des centaines de lignes de code d'une traite sans réellement démarrer l'application.
Puis il y a différentes phases de tests, les tests unitaires d'abord, qui se concentrent sur quelques lignes de codes, puis les tests d'intégration plus lourd mais avec un certain nombre de bouchons pour isoler le test, et enfin la phase de recette avec une application démarrée en condition réelle d'exécution mais sur un jeu de données de test.
Mais en tout état de cause, on ne fait pas des allers retours entre la phase d'écriture du code et la phase de recette, on ne teste pas ce que l'on fait après chaque ligne modifiée, on fait tout les changements d'un coup et après on vérifie tout en une fois.
"Existe-t-il un moyen de ne travailler que sur une partie spécifique sans avoir à recompiler le tout?"
L'IDE est suffisamment intelligent pour ne recompiler que ce qui a changé, les tests unitaires permettent aussi de vérifier une partie du code sans avoir à reprendre tout le processus à partir du main de l'application, en particulier sans avoir à charger tout le contexte Spring.
"comment les gens développent-ils de grandes applications qui nécessitent beaucoup de temps pour compiler ?"
En vrai ce n'est pas le temps de compilation qui est le plus long, mais le temps d'exécution des tests et de qualité du code (contrôles Sonar &co) qui mis bout à bout peuvent nécessiter plusieurs dizaines de minutes, toutefois c'est le genre de contrôles que l'on ne fait qu'à certains points clés du développement, en général au moment de la validation d'une merge request.
Et si vraiment ce temps devient trop long à supporter pour les développeurs, c'est qu'il est nécessaire de découper l'application en modules, chacun étant développés à part, ce qui peut poser d'autres problèmes de développement, comme par exemple devoir faire une modification sur plusieurs projets en même temps.
"Je me demande simplement à quoi ressemble le flux de travail de développement d'un développeur Java chevronné"
La très grande majorité du cycle de développement se fait "de tête" en écrivant des centaines de lignes de code d'une traite sans réellement démarrer l'application.
Puis il y a différentes phases de tests, les tests unitaires d'abord, qui se concentrent sur quelques lignes de codes, puis les tests d'intégration plus lourd mais avec un certain nombre de bouchons pour isoler le test, et enfin la phase de recette avec une application démarrée en condition réelle d'exécution mais sur un jeu de données de test.
Mais en tout état de cause, on ne fait pas des allers retours entre la phase d'écriture du code et la phase de recette, on ne teste pas ce que l'on fait après chaque ligne modifiée, on fait tout les changements d'un coup et après on vérifie tout en une fois.
"Existe-t-il un moyen de ne travailler que sur une partie spécifique sans avoir à recompiler le tout?"
L'IDE est suffisamment intelligent pour ne recompiler que ce qui a changé, les tests unitaires permettent aussi de vérifier une partie du code sans avoir à reprendre tout le processus à partir du main de l'application, en particulier sans avoir à charger tout le contexte Spring.
"comment les gens développent-ils de grandes applications qui nécessitent beaucoup de temps pour compiler ?"
En vrai ce n'est pas le temps de compilation qui est le plus long, mais le temps d'exécution des tests et de qualité du code (contrôles Sonar &co) qui mis bout à bout peuvent nécessiter plusieurs dizaines de minutes, toutefois c'est le genre de contrôles que l'on ne fait qu'à certains points clés du développement, en général au moment de la validation d'une merge request.
Et si vraiment ce temps devient trop long à supporter pour les développeurs, c'est qu'il est nécessaire de découper l'application en modules, chacun étant développés à part, ce qui peut poser d'autres problèmes de développement, comme par exemple devoir faire une modification sur plusieurs projets en même temps.
