Concernant le débat "clavier vs souris", il faudra toujours les deux. Un clavier permet de faire rapidement de multiples actions (grâce aux combinaisons) par contre pour ce qui est sélection et navigation ca sera toujours approximatif.
Cependant je plussoie tout de même la puissance des éditeurs textes faussement simples. J'ai pratiqué un peu Emacs à l'IUT et je dois dire que quand on connaît bien on fait des trucs sorti de l'espace, faut juste apprendre à avoir une bonne organisation des buffers.
A la défenses des IDE moderne, ils sont quasi capables de mes prouesses si on fait le même effort de configuration et d'apprentissage ou pour les plus feignants il existe très souvent des mode vi ou emacs.
---------------------
Pour le debugger sur des systèmes temps réels (ou pour les problèmes de synchro), c'est bel et bien possible. Il suffit pour cela d'arrêter tous les systèmes synchronisés et de faire le pas à pas en synchrone.
Je me sers souvent de cette technique quand je veux vérifier que j'ai bien codé mes synchronisations/locks/sémaphores/etc.
---------------------
Les tests automatiques (surtout unitaires) sur des batchs sont tout à fait possible, JCL ou pas. Ayant participé à l'intégration des données A380 dans les chaînes du calcul du Bureau d'Etude, je peux te dire que sans des tests automatiques ca aurait été impossible de faire la recette. Surtout grâce aux utilitaires fournis par IBM z/OS (lien).
Concernant la programmation (schedule) en test unitaire, on n'attend pas la nuit et on déclenche manuellement la chaîne : soit en invoquant le premier script de la chaîne en dev, soit en exprimant la demande au scheduler en recette.
Pour chaque batch, on génère les entrées, on exécute, on compare les fichiers générés avec des fichiers de référence. Ensuite on peut réitérer avec des morceaux plus grand et ainsi de suite.
Partager