Top 5 des tâches minant l’efficacité d’un développeur – et comment les résoudre

Top 5 des tâches minant l’efficacité d’un développeur – et comment les résoudre

16:02 28 novembre in Blogue, Développement web et mobile, Modernisation d'écran vert, Productivité des développeurs IBM i
0 Comments

Depuis mes débuts en prévente chez Fresche, j’ai travaillé avec plusieurs clients IBM i qui recherchaient à améliorer leur infrastructure informatique. Que leur besoin soit de consolider, de moderniser ou de tout simplement comprendre leur infrastructure TI, tous avaient comme but d’améliorer leurs opérations.

J’ai observé des entreprises faire d’incroyables gains en productivité, en se penchant sur leurs défis de façon innovante. Tandis que les entreprises tentent de rester à jour avec les plus récentes technologies tout en demeurant compétitives dans leur industrie respective, les TI sont sous une pression plus forte que jamais pour répondre à ces besoins avec plus d’innovation et d’efficacité et même potentiellement avec de nouveaux développements. Ainsi, le personnel informatique ne peut plus seulement se contenter de maintenir les TI, il doit aussi de plus en plus garder le focus sur l’amélioration des TI.

Voici donc mon décompte des cinq tâches qui ralentissent le plus les développeurs, ainsi que des solutions suggérées pour tirer parti de la puissance de l’automatisation.

1. Créer manuellement les diagrammes d’infrastructure et d’application

Il est crucial pour les preneurs de décisions en TI de comprendre parfaitement le fonctionnement des applications ainsi que leur rôle parmi les processus au quotidien. Les flux de travail doivent être clairement définis, les étapes présentées visuellement et les interactions clairement cartographiées. Sans une bonne compréhension de la manière dont les processus informatiques dépendent de diverses applications et de la manière dont les données sont transférées à travers les systèmes, il est beaucoup plus difficile de faire des changements et de déterminer les améliorations possibles.

Malheureusement, documenter les flux de travail manuellement est compliqué et prend du temps. De nombreuses entreprises ont des systèmes qui sont si étendus, et peut-être si vieux, qu’ils ne savent tout simplement pas comment leurs processus actuels sont mappés à travers leurs applications.

La fonction de création de diagrammes de flux de X-Analysis automatise ce processus de documentation en générant des diagrammes visuels. Vos processus informatiques sont alors documentés dans des workflows visuels. Cette fonction automatisée fournit des informations précieuses sur la manière dont diverses applications sont impliquées dans les processus quotidiens et fournit aux décideurs les connaissances dont ils ont besoin pour aller de l’avant avec les changements.

2. Documenter manuellement les applications

De la même manière que documenter manuellement les workflows est un processus complexe et convoluté, il en va de même pour la documentation des applications. Non seulement ce processus manuel prend du temps, mais il est aussi très vulnérable aux erreurs humaines, et donc risqué. Documenter le code, cependant, reste d’une importance vitale. Sans une documentation solide, il est difficile de comprendre exactement comment fonctionnent les applications, d’extrapoler des données, de faire des changements et, bien sûr, d’intégrer de nouveaux employés. Même un personnel expérimenté peut avoir du mal à comprendre leurs applications sans avoir accès à une documentation claire.

La fonction X-Analysis Document permet de documenter automatiquement les applications et produit du contenu détaillant le code ligne par ligne. Il offre au développeur un niveau de certitude beaucoup plus élevé et une tranquillité d’esprit pour ceux qui cherchent à comprendre et à augmenter leur code.

3. Lire le code source, un membre à la fois, en utilisant STRPDM pour y rechercher les variables, fichiers, etc.

Savoir comment les modifications au code vont affecter vos applications est extrêmement important. Les développeurs se retrouvent trop souvent à deviner, à modifier une ligne et à se croiser les doigts pour que rien d’autre ne se brise. Cela conduit à un jeu risqué, où les développeurs doivent passer par un processus fastidieux d’essais et d’erreurs pour arriver au produit final désiré ou espéré.

Tout comme la documentation, déterminer manuellement tous les endroits où une variable pourrait être utilisée est un processus laborieux d’essai-erreur .

Heureusement, il existe un moyen de déterminer automatiquement le code source des fonctions d’application et de mener une analyse d’impact fiable. La fonction « Where Used » de X-Analysis permet aux développeurs d’apporter des modifications au code en sachant qu’ils ne briseront rien d’autre.

4. La performance et le nettoyage des systèmes: Chercher la présence de code non-exécutable ainsi que de code source et des objets manquants

Comprendre où se situe la majeure partie de vos processus dans vos applications est essentiel pour planifier stratégiquement l’avenir informatique de votre entreprise. Trop d’entreprises comprennent mal où se situent leurs processus les plus cruciaux et comment leurs données sont traitées. Elles ne peuvent pas non-plus mesurer la qualité de leur code ni savoir si leurs mesures répondent aux normes informatiques modernes.

La fonction X-Audit de X-Analysis fournit des informations précieuses sur le code utilisé, le code obsolète, les éléments à améliorer et les doublons. Cette fonctionnalité permet de planifier concrètement l’amélioration du système, en déterminant les vulnérabilités et en cernant le code problématique.

5. Scanner le code RPG pour les valeurs « hard coded », un membre à la fois (tel que « numéro de contrat <> 300000 »)

De nombreuses entreprises utilisant IBM i estiment qu’elles sont sous l’emprise de leurs applications, car elles ne comprennent tout simplement pas ni ne peuvent modifier la logique qui détermine leur fonctionnement. Cela devient particulièrement lourd pour les entreprises qui essaient de mettre en œuvre de nouvelles politiques ou d’en supprimer d’anciennes. La compréhension des règles d’affaires figées dans les applications est essentielle. Comme les autres éléments de cette liste, le processus manuel pour déterminer ces règles est laborieux et nécessite beaucoup d’essais et d’erreurs.

La fonction « Business Rules » de X-Analysis analyse les applications RPG afin de trouver ces valeurs figées (« hard-coded ») et permet aussi aux dévelopeurs de voir la logique guidant leurs fonctions applicatives.

À propos de Stephen Flaherty

Following 25 plus years of work in the IBM arena, starting with the System 38, with exposure to AS/400, iSeries and now the IBMi, Stephen Flaherty has added numerous projects to his portfolio, all specializing in RPG coding. The opportunity he has had to be a part of multiple ERP packages such as JD Edwards, Mapics, PRISM, HFA, and MacPac, in addition to several EDI (Electronic Data Interchange) packages such as Trusted Link, Inovis, and GXS, make him a great asset to the pre-sales team at Fresche for the American market. His current role as a Technical Engineer enables him to ensure the best communication between sales and new and existing customers on a variety of products, helping clients transform or update their systems through individual strategies.

No Comments

Post a Comment