Par S\u00e9bastien Julliand <\/h3>\n<\/div><\/div><\/div>Sommaire<\/h2>\n\n- \u00c0 b\u00e2bord toute<\/a><\/li>\n
- Temps de cerveau d\u00e9veloppeur disponible<\/a><\/li>\n
- Rien ne se perd, tout se partage<\/a><\/li>\n
- Pendant ce temps, sur IBM i <\/a><\/li>\n
- Et la s\u00e9curit\u00e9? <\/a><\/li>\n
- Le mot de la fin <\/a><\/li>\n<\/ol>\n<\/div><\/div>
Je ne vous apprendrai rien en vous disant que la revue de code est une \u00e9tape essentielle du d\u00e9veloppement. Il est fondamental pour un d\u00e9veloppeur de soumettre son code \u00e0 l\u2019appr\u00e9ciation de ses pairs, afin d’en garantir sa qualit\u00e9, et donc, sa maintenabilit\u00e9.<\/p>\n
Car en effet, le code a une odeur. Il est fr\u00e9quent de rencontrer la notion de \u201cCode smell\u201d dans le lexique anglophone de la revue de code. Et pour cause, un d\u00e9veloppeur exp\u00e9riment\u00e9 saura reconna\u00eetre un code qui “sent bon” d\u2019un code plus suspect, et ce presque par automatisme. Ce sont ces heuristiques que se propose d\u2019appliquer les outils de revue de code, via des ensembles de r\u00e8gles de qualit\u00e9 pr\u00e9d\u00e9finies qui permettent de mettre en exergue les d\u00e9fauts les plus fr\u00e9quents. Maintenir du code propre est beaucoup plus facile (voir agr\u00e9able, dirons certains passionn\u00e9s) que du code tombant dans les \u00e9cueils les plus communs tel que le spaghetti code<\/em> ou le god object<\/em>.<\/p>\n<\/p>\n<\/div>\n1. \u00c0 b\u00e2bord toute<\/strong><\/h2>\nTout l\u2019int\u00e9r\u00eat d\u2019une revue de code est de d\u00e9tecter les probl\u00e8mes le plus t\u00f4t possible dans le cycle de d\u00e9veloppement.<\/b> C\u2019est le principe du shift left testing<\/em>: tester t\u00f4t. <\/b>Plus un bug est d\u00e9tect\u00e9 t\u00f4t, moins il sera co\u00fbteux \u00e0 corriger. Mais ce principe ne r\u00e9pond qu\u2019\u00e0 la moiti\u00e9 de la maxime de Larry Page: \u201cTester t\u00f4t et souvent\u201d.<\/b> <\/p>\nL\u2019automatisation de la revue de code r\u00e9pond \u00e0 ce besoin fr\u00e9quent de contr\u00f4le en permettant d\u2019appliquer les r\u00e8gles de qualit\u00e9 directement dans l\u2019environnement de d\u00e9veloppement ou encore \u00e0 interval r\u00e9gulier via des traitements par lot.<\/p>\n<\/p>\n
<\/div>\n2. Temps de cerveau d\u00e9veloppeur disponible<\/strong><\/h2>\nUne revue de code prend du temps, notamment du temps de d\u00e9veloppement. En automatisant ce qui peut l\u2019\u00eatre dans la revue de code, on \u00e9vite aux \u00e9quipes de passer trop de temps sur les aspects les plus r\u00e9barbatifs de l\u2019exercice. Le respect et l\u2019application d\u2019une norme de codage (ie. l\u2019indentation, le nommage des objets, champs, m\u00e9thodes, \u2026) peuvent tout \u00e0 fait \u00eatre contr\u00f4l\u00e9s par un outil,<\/b> tout comme d\u2019autres r\u00e8gles mettant en lumi\u00e8re le code jug\u00e9 inefficient voir mort, laissant ainsi plus de temps aux d\u00e9veloppeurs pour se concentrer sur des probl\u00e8mes plus complexes, que seule une revue de code manuelle saura d\u00e9tecter. L\u2019automatisation permet donc d\u2019augmenter la disponibilit\u00e9 des d\u00e9veloppeurs (ou du moins de ne pas la diminuer) et ainsi limiter les goulots d\u2019\u00e9tranglement.<\/p>\n
N\u00e9anmoins, il va de soi qu\u2019un outil, aussi performant soit-il, ne remplacera jamais l\u2019oeil per\u00e7ant et la p\u00e9dagogie d\u2019un d\u00e9veloppeur exp\u00e9riment\u00e9 sur les cas les plus complexes.<\/p>\n<\/div><\/div><\/div>
V\u00e9rifiez automatiquement la qualit\u00e9 de votre code RPG. \u00c9liminez la \u00ab dette technique \u00bb de votre application IBM i.<\/strong><\/p>\n<\/div>Voir le webinar<\/span><\/i><\/a><\/div><\/div><\/div><\/div><\/div><\/div>\n3. Rien ne se perd, tout se partage<\/strong><\/h2>\nLe partage de la connaissance est un point crucial et souvent probl\u00e9matique au sein des \u00e9quipes de d\u00e9veloppement.<\/b> Au mieux, les bonnes pratiques techniques et les normes de codage seront consign\u00e9es dans un outil de type GED et au pire elles seront…dans l\u2019inconscient collectif! On pourra alors difficilement reprocher \u00e0 un nouveau venu de ne pas avoir respect\u00e9 les normes, celles-ci n\u2019\u00e9tant finalement appliqu\u00e9es que par les membres chevronn\u00e9s de l\u2019\u00e9quipe. <\/p>\n
Un contr\u00f4leur de qualit\u00e9 des sources sera de facto la r\u00e9f\u00e9rence documentaire en ce qui concerne les normes et bonne pratiques, s\u2019enrichissant au fil du temps, permettant ainsi un partage efficace de la connaissance sur un projet et facilitant l\u2019application des standards. Id\u00e9alement, le contr\u00f4leur de source est directement int\u00e9gr\u00e9 dans l\u2019environnement de d\u00e9veloppement, permettant un contr\u00f4le du code en continu et une application au fil de l\u2019eau des r\u00e8gles de qualit\u00e9, \u00e9vitant au d\u00e9veloppeur de faire des aller-retours entre son \u00e9diteur et une source de connaissance externe.<\/p>\n<\/p>\n
<\/div>\n4. Pendant ce temps, sur IBM i<\/strong><\/h2>\n\u201cC\u2019est dans les vieux pots qu\u2019on fait la meilleure soupe\u201d<\/em>, voil\u00e0 une expression toute trouv\u00e9e en ce qui concerne la plateforme IBM i. Boud\u00e9e au d\u00e9part par la sc\u00e8ne DevOps, l\u2019OS historique d\u2019IBM fait un retour en force sur le devant de la sc\u00e8ne, gr\u00e2ce \u00e0 la mobilisation d\u2019acteurs majeurs de l\u2019\u00e9dition logicielle et du monde Open Source.<\/p>\nLe d\u00e9veloppement sur la plateforme IBM i se fait via le langage RPG, <\/b>sur lequel IBM a fortement investi sur les vingt derni\u00e8res ann\u00e9es en lui donnant un nouveau souffle gr\u00e2ce \u00e0 sa forme RPG-Free et surtout RPG-FullyFree, le faisant ainsi entrer dans la cour des langages modernes. Prendre en charge les sp\u00e9cificit\u00e9s du RPG dans une revue de code automatique n\u00e9cessite des outils adapt\u00e9s, et c\u2019est pr\u00e9cis\u00e9ment ce que se propose de faire ARCAD CodeChecker,<\/a> le contr\u00f4leur de qualit\u00e9 de code source de la gamme ARCAD for Devops d\u2019ARCAD Software.<\/p>\n Toutes les formes et \u00e9volutions du langage sont prises en charge par le produit, du RPG III au RPG-FullyFree,<\/b> et m\u00eame les cas de mixit\u00e9 Colonn\u00e9\/Free. Les d\u00e9veloppeurs RPG chevronn\u00e9s se faisant de plus en plus rare, CodeChecker capitalise sur plus de 25 ans d\u2019exp\u00e9rience dans ce domaine en apportant une centaine de r\u00e8gles de qualit\u00e9s applicables non seulement au RPG, mais aussi au langage CL et tr\u00e8s prochainement au COBOL.<\/b><\/p>\n<\/p>\n<\/div>\n5. Et la s\u00e9curit\u00e9?<\/strong><\/h2>\nIl est un sujet qui revient de plus en plus, surtout depuis l\u2019av\u00e8nement de la m\u00e9thodologie DevOps: la s\u00e9curit\u00e9 au sein du code. On parlera alors de <\/b>DevSecOps<\/a><\/b>.<\/a> Sur le principe, il s\u2019agit de penser \u00e0 la s\u00e9curit\u00e9 d\u2019une application d\u00e8s le d\u00e9part, dans son design m\u00eame. Par exemple, en appliquant des r\u00e8gles de contr\u00f4le de qualit\u00e9 bas\u00e9es sur les pr\u00e9conisations de la communaut\u00e9 OWASP, de graves failles de s\u00e9curit\u00e9 pourront \u00eatre \u00e9vit\u00e9es, tel que les risques d\u2019injection SQL, les risques de d\u00e9passement de m\u00e9moire tampon, etc.<\/p>\nLes syst\u00e8mes Legacy ne sont pas non plus \u00e9pargn\u00e9s par ces probl\u00e9matiques de s\u00e9curit\u00e9. Dans le cas de la plateforme IBM i, la tendance est \u00e0 la modernisation, et les programmes historiques se retrouvent expos\u00e9s en tant que service Web, par exemple. Il devient alors critique de pouvoir d\u00e9tecter au plus t\u00f4t les failles de s\u00e9curit\u00e9 dans le code RPG, et c\u2019est pr\u00e9cis\u00e9ment ce que se propose de faire ARCAD CodeChecker via son ensemble de r\u00e8gles d\u00e9di\u00e9e \u00e0 DevSecOps, qui pourra d\u00e9tecter et mettre en \u00e9vidence les risques d\u2019injection SQL en RPG.<\/b><\/p>\n<\/p>\n
Sommaire<\/h2>\n\n- \u00c0 b\u00e2bord toute<\/a><\/li>\n
- Temps de cerveau d\u00e9veloppeur disponible<\/a><\/li>\n
- Rien ne se perd, tout se partage<\/a><\/li>\n
- Pendant ce temps, sur IBM i <\/a><\/li>\n
- Et la s\u00e9curit\u00e9? <\/a><\/li>\n
- Le mot de la fin <\/a><\/li>\n<\/ol>\n<\/div><\/div>
Je ne vous apprendrai rien en vous disant que la revue de code est une \u00e9tape essentielle du d\u00e9veloppement. Il est fondamental pour un d\u00e9veloppeur de soumettre son code \u00e0 l\u2019appr\u00e9ciation de ses pairs, afin d’en garantir sa qualit\u00e9, et donc, sa maintenabilit\u00e9.<\/p>\n
Car en effet, le code a une odeur. Il est fr\u00e9quent de rencontrer la notion de \u201cCode smell\u201d dans le lexique anglophone de la revue de code. Et pour cause, un d\u00e9veloppeur exp\u00e9riment\u00e9 saura reconna\u00eetre un code qui “sent bon” d\u2019un code plus suspect, et ce presque par automatisme. Ce sont ces heuristiques que se propose d\u2019appliquer les outils de revue de code, via des ensembles de r\u00e8gles de qualit\u00e9 pr\u00e9d\u00e9finies qui permettent de mettre en exergue les d\u00e9fauts les plus fr\u00e9quents. Maintenir du code propre est beaucoup plus facile (voir agr\u00e9able, dirons certains passionn\u00e9s) que du code tombant dans les \u00e9cueils les plus communs tel que le spaghetti code<\/em> ou le god object<\/em>.<\/p>\n<\/p>\n<\/div>\n1. \u00c0 b\u00e2bord toute<\/strong><\/h2>\nTout l\u2019int\u00e9r\u00eat d\u2019une revue de code est de d\u00e9tecter les probl\u00e8mes le plus t\u00f4t possible dans le cycle de d\u00e9veloppement.<\/b> C\u2019est le principe du shift left testing<\/em>: tester t\u00f4t. <\/b>Plus un bug est d\u00e9tect\u00e9 t\u00f4t, moins il sera co\u00fbteux \u00e0 corriger. Mais ce principe ne r\u00e9pond qu\u2019\u00e0 la moiti\u00e9 de la maxime de Larry Page: \u201cTester t\u00f4t et souvent\u201d.<\/b> <\/p>\nL\u2019automatisation de la revue de code r\u00e9pond \u00e0 ce besoin fr\u00e9quent de contr\u00f4le en permettant d\u2019appliquer les r\u00e8gles de qualit\u00e9 directement dans l\u2019environnement de d\u00e9veloppement ou encore \u00e0 interval r\u00e9gulier via des traitements par lot.<\/p>\n<\/p>\n
<\/div>\n2. Temps de cerveau d\u00e9veloppeur disponible<\/strong><\/h2>\nUne revue de code prend du temps, notamment du temps de d\u00e9veloppement. En automatisant ce qui peut l\u2019\u00eatre dans la revue de code, on \u00e9vite aux \u00e9quipes de passer trop de temps sur les aspects les plus r\u00e9barbatifs de l\u2019exercice. Le respect et l\u2019application d\u2019une norme de codage (ie. l\u2019indentation, le nommage des objets, champs, m\u00e9thodes, \u2026) peuvent tout \u00e0 fait \u00eatre contr\u00f4l\u00e9s par un outil,<\/b> tout comme d\u2019autres r\u00e8gles mettant en lumi\u00e8re le code jug\u00e9 inefficient voir mort, laissant ainsi plus de temps aux d\u00e9veloppeurs pour se concentrer sur des probl\u00e8mes plus complexes, que seule une revue de code manuelle saura d\u00e9tecter. L\u2019automatisation permet donc d\u2019augmenter la disponibilit\u00e9 des d\u00e9veloppeurs (ou du moins de ne pas la diminuer) et ainsi limiter les goulots d\u2019\u00e9tranglement.<\/p>\n
N\u00e9anmoins, il va de soi qu\u2019un outil, aussi performant soit-il, ne remplacera jamais l\u2019oeil per\u00e7ant et la p\u00e9dagogie d\u2019un d\u00e9veloppeur exp\u00e9riment\u00e9 sur les cas les plus complexes.<\/p>\n<\/div><\/div><\/div>
V\u00e9rifiez automatiquement la qualit\u00e9 de votre code RPG. \u00c9liminez la \u00ab dette technique \u00bb de votre application IBM i.<\/strong><\/p>\n<\/div>Voir le webinar<\/span><\/i><\/a><\/div><\/div><\/div><\/div><\/div><\/div>\n3. Rien ne se perd, tout se partage<\/strong><\/h2>\nLe partage de la connaissance est un point crucial et souvent probl\u00e9matique au sein des \u00e9quipes de d\u00e9veloppement.<\/b> Au mieux, les bonnes pratiques techniques et les normes de codage seront consign\u00e9es dans un outil de type GED et au pire elles seront…dans l\u2019inconscient collectif! On pourra alors difficilement reprocher \u00e0 un nouveau venu de ne pas avoir respect\u00e9 les normes, celles-ci n\u2019\u00e9tant finalement appliqu\u00e9es que par les membres chevronn\u00e9s de l\u2019\u00e9quipe. <\/p>\n
Un contr\u00f4leur de qualit\u00e9 des sources sera de facto la r\u00e9f\u00e9rence documentaire en ce qui concerne les normes et bonne pratiques, s\u2019enrichissant au fil du temps, permettant ainsi un partage efficace de la connaissance sur un projet et facilitant l\u2019application des standards. Id\u00e9alement, le contr\u00f4leur de source est directement int\u00e9gr\u00e9 dans l\u2019environnement de d\u00e9veloppement, permettant un contr\u00f4le du code en continu et une application au fil de l\u2019eau des r\u00e8gles de qualit\u00e9, \u00e9vitant au d\u00e9veloppeur de faire des aller-retours entre son \u00e9diteur et une source de connaissance externe.<\/p>\n<\/p>\n
<\/div>\n4. Pendant ce temps, sur IBM i<\/strong><\/h2>\n\u201cC\u2019est dans les vieux pots qu\u2019on fait la meilleure soupe\u201d<\/em>, voil\u00e0 une expression toute trouv\u00e9e en ce qui concerne la plateforme IBM i. Boud\u00e9e au d\u00e9part par la sc\u00e8ne DevOps, l\u2019OS historique d\u2019IBM fait un retour en force sur le devant de la sc\u00e8ne, gr\u00e2ce \u00e0 la mobilisation d\u2019acteurs majeurs de l\u2019\u00e9dition logicielle et du monde Open Source.<\/p>\nLe d\u00e9veloppement sur la plateforme IBM i se fait via le langage RPG, <\/b>sur lequel IBM a fortement investi sur les vingt derni\u00e8res ann\u00e9es en lui donnant un nouveau souffle gr\u00e2ce \u00e0 sa forme RPG-Free et surtout RPG-FullyFree, le faisant ainsi entrer dans la cour des langages modernes. Prendre en charge les sp\u00e9cificit\u00e9s du RPG dans une revue de code automatique n\u00e9cessite des outils adapt\u00e9s, et c\u2019est pr\u00e9cis\u00e9ment ce que se propose de faire ARCAD CodeChecker,<\/a> le contr\u00f4leur de qualit\u00e9 de code source de la gamme ARCAD for Devops d\u2019ARCAD Software.<\/p>\n Toutes les formes et \u00e9volutions du langage sont prises en charge par le produit, du RPG III au RPG-FullyFree,<\/b> et m\u00eame les cas de mixit\u00e9 Colonn\u00e9\/Free. Les d\u00e9veloppeurs RPG chevronn\u00e9s se faisant de plus en plus rare, CodeChecker capitalise sur plus de 25 ans d\u2019exp\u00e9rience dans ce domaine en apportant une centaine de r\u00e8gles de qualit\u00e9s applicables non seulement au RPG, mais aussi au langage CL et tr\u00e8s prochainement au COBOL.<\/b><\/p>\n<\/p>\n<\/div>\n5. Et la s\u00e9curit\u00e9?<\/strong><\/h2>\nIl est un sujet qui revient de plus en plus, surtout depuis l\u2019av\u00e8nement de la m\u00e9thodologie DevOps: la s\u00e9curit\u00e9 au sein du code. On parlera alors de <\/b>DevSecOps<\/a><\/b>.<\/a> Sur le principe, il s\u2019agit de penser \u00e0 la s\u00e9curit\u00e9 d\u2019une application d\u00e8s le d\u00e9part, dans son design m\u00eame. Par exemple, en appliquant des r\u00e8gles de contr\u00f4le de qualit\u00e9 bas\u00e9es sur les pr\u00e9conisations de la communaut\u00e9 OWASP, de graves failles de s\u00e9curit\u00e9 pourront \u00eatre \u00e9vit\u00e9es, tel que les risques d\u2019injection SQL, les risques de d\u00e9passement de m\u00e9moire tampon, etc.<\/p>\nLes syst\u00e8mes Legacy ne sont pas non plus \u00e9pargn\u00e9s par ces probl\u00e9matiques de s\u00e9curit\u00e9. Dans le cas de la plateforme IBM i, la tendance est \u00e0 la modernisation, et les programmes historiques se retrouvent expos\u00e9s en tant que service Web, par exemple. Il devient alors critique de pouvoir d\u00e9tecter au plus t\u00f4t les failles de s\u00e9curit\u00e9 dans le code RPG, et c\u2019est pr\u00e9cis\u00e9ment ce que se propose de faire ARCAD CodeChecker via son ensemble de r\u00e8gles d\u00e9di\u00e9e \u00e0 DevSecOps, qui pourra d\u00e9tecter et mettre en \u00e9vidence les risques d\u2019injection SQL en RPG.<\/b><\/p>\n<\/p>\n
Je ne vous apprendrai rien en vous disant que la revue de code est une \u00e9tape essentielle du d\u00e9veloppement. Il est fondamental pour un d\u00e9veloppeur de soumettre son code \u00e0 l\u2019appr\u00e9ciation de ses pairs, afin d’en garantir sa qualit\u00e9, et donc, sa maintenabilit\u00e9.<\/p>\n
Car en effet, le code a une odeur. Il est fr\u00e9quent de rencontrer la notion de \u201cCode smell\u201d dans le lexique anglophone de la revue de code. Et pour cause, un d\u00e9veloppeur exp\u00e9riment\u00e9 saura reconna\u00eetre un code qui “sent bon” d\u2019un code plus suspect, et ce presque par automatisme. Ce sont ces heuristiques que se propose d\u2019appliquer les outils de revue de code, via des ensembles de r\u00e8gles de qualit\u00e9 pr\u00e9d\u00e9finies qui permettent de mettre en exergue les d\u00e9fauts les plus fr\u00e9quents. Maintenir du code propre est beaucoup plus facile (voir agr\u00e9able, dirons certains passionn\u00e9s) que du code tombant dans les \u00e9cueils les plus communs tel que le spaghetti code<\/em> ou le god object<\/em>.<\/p>\n<\/p>\n Tout l\u2019int\u00e9r\u00eat d\u2019une revue de code est de d\u00e9tecter les probl\u00e8mes le plus t\u00f4t possible dans le cycle de d\u00e9veloppement.<\/b> C\u2019est le principe du shift left testing<\/em>: tester t\u00f4t. <\/b>Plus un bug est d\u00e9tect\u00e9 t\u00f4t, moins il sera co\u00fbteux \u00e0 corriger. Mais ce principe ne r\u00e9pond qu\u2019\u00e0 la moiti\u00e9 de la maxime de Larry Page: \u201cTester t\u00f4t et souvent\u201d.<\/b> <\/p>\n L\u2019automatisation de la revue de code r\u00e9pond \u00e0 ce besoin fr\u00e9quent de contr\u00f4le en permettant d\u2019appliquer les r\u00e8gles de qualit\u00e9 directement dans l\u2019environnement de d\u00e9veloppement ou encore \u00e0 interval r\u00e9gulier via des traitements par lot.<\/p>\n<\/p>\n Une revue de code prend du temps, notamment du temps de d\u00e9veloppement. En automatisant ce qui peut l\u2019\u00eatre dans la revue de code, on \u00e9vite aux \u00e9quipes de passer trop de temps sur les aspects les plus r\u00e9barbatifs de l\u2019exercice. Le respect et l\u2019application d\u2019une norme de codage (ie. l\u2019indentation, le nommage des objets, champs, m\u00e9thodes, \u2026) peuvent tout \u00e0 fait \u00eatre contr\u00f4l\u00e9s par un outil,<\/b> tout comme d\u2019autres r\u00e8gles mettant en lumi\u00e8re le code jug\u00e9 inefficient voir mort, laissant ainsi plus de temps aux d\u00e9veloppeurs pour se concentrer sur des probl\u00e8mes plus complexes, que seule une revue de code manuelle saura d\u00e9tecter. L\u2019automatisation permet donc d\u2019augmenter la disponibilit\u00e9 des d\u00e9veloppeurs (ou du moins de ne pas la diminuer) et ainsi limiter les goulots d\u2019\u00e9tranglement.<\/p>\n N\u00e9anmoins, il va de soi qu\u2019un outil, aussi performant soit-il, ne remplacera jamais l\u2019oeil per\u00e7ant et la p\u00e9dagogie d\u2019un d\u00e9veloppeur exp\u00e9riment\u00e9 sur les cas les plus complexes.<\/p>\n<\/div><\/div><\/div> V\u00e9rifiez automatiquement la qualit\u00e9 de votre code RPG. \u00c9liminez la \u00ab dette technique \u00bb de votre application IBM i.<\/strong><\/p>\n<\/div> Le partage de la connaissance est un point crucial et souvent probl\u00e9matique au sein des \u00e9quipes de d\u00e9veloppement.<\/b> Au mieux, les bonnes pratiques techniques et les normes de codage seront consign\u00e9es dans un outil de type GED et au pire elles seront…dans l\u2019inconscient collectif! On pourra alors difficilement reprocher \u00e0 un nouveau venu de ne pas avoir respect\u00e9 les normes, celles-ci n\u2019\u00e9tant finalement appliqu\u00e9es que par les membres chevronn\u00e9s de l\u2019\u00e9quipe. <\/p>\n Un contr\u00f4leur de qualit\u00e9 des sources sera de facto la r\u00e9f\u00e9rence documentaire en ce qui concerne les normes et bonne pratiques, s\u2019enrichissant au fil du temps, permettant ainsi un partage efficace de la connaissance sur un projet et facilitant l\u2019application des standards. Id\u00e9alement, le contr\u00f4leur de source est directement int\u00e9gr\u00e9 dans l\u2019environnement de d\u00e9veloppement, permettant un contr\u00f4le du code en continu et une application au fil de l\u2019eau des r\u00e8gles de qualit\u00e9, \u00e9vitant au d\u00e9veloppeur de faire des aller-retours entre son \u00e9diteur et une source de connaissance externe.<\/p>\n<\/p>\n \u201cC\u2019est dans les vieux pots qu\u2019on fait la meilleure soupe\u201d<\/em>, voil\u00e0 une expression toute trouv\u00e9e en ce qui concerne la plateforme IBM i. Boud\u00e9e au d\u00e9part par la sc\u00e8ne DevOps, l\u2019OS historique d\u2019IBM fait un retour en force sur le devant de la sc\u00e8ne, gr\u00e2ce \u00e0 la mobilisation d\u2019acteurs majeurs de l\u2019\u00e9dition logicielle et du monde Open Source.<\/p>\n Le d\u00e9veloppement sur la plateforme IBM i se fait via le langage RPG, <\/b>sur lequel IBM a fortement investi sur les vingt derni\u00e8res ann\u00e9es en lui donnant un nouveau souffle gr\u00e2ce \u00e0 sa forme RPG-Free et surtout RPG-FullyFree, le faisant ainsi entrer dans la cour des langages modernes. Prendre en charge les sp\u00e9cificit\u00e9s du RPG dans une revue de code automatique n\u00e9cessite des outils adapt\u00e9s, et c\u2019est pr\u00e9cis\u00e9ment ce que se propose de faire ARCAD CodeChecker,<\/a> le contr\u00f4leur de qualit\u00e9 de code source de la gamme ARCAD for Devops d\u2019ARCAD Software.<\/p>\n Toutes les formes et \u00e9volutions du langage sont prises en charge par le produit, du RPG III au RPG-FullyFree,<\/b> et m\u00eame les cas de mixit\u00e9 Colonn\u00e9\/Free. Les d\u00e9veloppeurs RPG chevronn\u00e9s se faisant de plus en plus rare, CodeChecker capitalise sur plus de 25 ans d\u2019exp\u00e9rience dans ce domaine en apportant une centaine de r\u00e8gles de qualit\u00e9s applicables non seulement au RPG, mais aussi au langage CL et tr\u00e8s prochainement au COBOL.<\/b><\/p>\n<\/p>\n Il est un sujet qui revient de plus en plus, surtout depuis l\u2019av\u00e8nement de la m\u00e9thodologie DevOps: la s\u00e9curit\u00e9 au sein du code. On parlera alors de <\/b>DevSecOps<\/a><\/b>.<\/a> Sur le principe, il s\u2019agit de penser \u00e0 la s\u00e9curit\u00e9 d\u2019une application d\u00e8s le d\u00e9part, dans son design m\u00eame. Par exemple, en appliquant des r\u00e8gles de contr\u00f4le de qualit\u00e9 bas\u00e9es sur les pr\u00e9conisations de la communaut\u00e9 OWASP, de graves failles de s\u00e9curit\u00e9 pourront \u00eatre \u00e9vit\u00e9es, tel que les risques d\u2019injection SQL, les risques de d\u00e9passement de m\u00e9moire tampon, etc.<\/p>\n Les syst\u00e8mes Legacy ne sont pas non plus \u00e9pargn\u00e9s par ces probl\u00e9matiques de s\u00e9curit\u00e9. Dans le cas de la plateforme IBM i, la tendance est \u00e0 la modernisation, et les programmes historiques se retrouvent expos\u00e9s en tant que service Web, par exemple. Il devient alors critique de pouvoir d\u00e9tecter au plus t\u00f4t les failles de s\u00e9curit\u00e9 dans le code RPG, et c\u2019est pr\u00e9cis\u00e9ment ce que se propose de faire ARCAD CodeChecker via son ensemble de r\u00e8gles d\u00e9di\u00e9e \u00e0 DevSecOps, qui pourra d\u00e9tecter et mettre en \u00e9vidence les risques d\u2019injection SQL en RPG.<\/b><\/p>\n<\/p>\n1. \u00c0 b\u00e2bord toute<\/strong><\/h2>\n
2. Temps de cerveau d\u00e9veloppeur disponible<\/strong><\/h2>\n
3. Rien ne se perd, tout se partage<\/strong><\/h2>\n
4. Pendant ce temps, sur IBM i<\/strong><\/h2>\n
5. Et la s\u00e9curit\u00e9?<\/strong><\/h2>\n
![\"S\u00e9bastien](\"https:\/\/www.arcadsoftware.com\/arcad\/wp-content\/uploads\/2020\/02\/sebastien-julliand.jpg\")
<\/p>\n<\/div><\/div><\/div>