Les technologies du programmeur vont encore se complexifier
Quelle influence aura l'open source sur le métier du développeur ?
Raymond Sclison : La première concerne les méthodes de travail. Dans la majorité des cas, face à un problème avec un logiciel de développement open source, un technicien ne demande pas des heures de formation et appelle encore moins l'assistance téléphonique. Il va plutôt s'adresser à d'autres développeurs. Cela nécessite pour les participants de maîtriser les outils de travail collaboratif. Autre différence : la documentation des logiciels. En général, elle apparaît très riche et centralisée chez les éditeurs qui font du propriétaire, mais s'avère en revanche beaucoup plus diffuse dans le libre. Elle se trouve soit centralisée, soit répartie entre les forums, les mailing-lists, et peut aussi être gratuite ou payante... Les développeurs novices connaissent parfois des difficultés à retrouver ces renseignements.Le libre rend donc le travail du développeur plus difficile ?
R.S. : La certitude, c'est que le cycle de vie des applications se révèle particulier dans l'open source. Il est souvent plus court que dans le monde propriétaire, en tout cas pour les petits logiciels. On peut rencontrer des problèmes avec les bibliothèques - Ajax constituant en ce moment l'exemple type. Certaines d'entre elles sont récentes, et les sorties de nouvelles versions peuvent être assez fréquentes - parfois tous les deux ou trois mois. Une plus grande souplesse s'impose dans la manière de travailler. Ensuite, cela dépend du profil du codeur. Ainsi, un développeur-concepteur dispose à la base d'une ouverture d'esprit certaine. Il subira donc moins d'influence. Reste que l'open source requiert d'aller à l'essentiel très rapidement, le plus souvent sans formation. Il faut lire le manuel en diagonale et utiliser son réseau. Les bons développeurs se connaissent, se croisent et profitent d'un réseau. Et comme si cela ne suffisait pas, le travail dans le monde du libre demande de connaître des outils peu usités dans l'industrie, comme CVS pour la gestion des versions, ou ANT pour la construction de programmes.Tout le monde peut-il modifier un logiciel libre ?
R.S. : Cela paraît plus aisé pour le développeur expérimenté qui identifie déjà un certain nombre de patterns (pratiques et modèles de programmation, NDLR). Il va cibler plus vite les endroits où il faut adapter le code. Le débutant, lui, aura du mal à les trouver. Au bout de deux ou trois ans seulement, il reconnaîtra ces patterns d'architecture et de conception dans les logiciels créés par des codeurs expérimentés. Ces choses n'existent évidemment pas dans le monde propriétaire. Voilà d'ailleurs une des particularités du libre : le développeur open source rejoint le concepteur en termes de compétences.Les technologies web 2.0 et les langages plus récents sont censés être plus accessibles à tous les développeurs. Va-t-on assister à une scission entre les débutants accrochés à PHP et les autres travaillant sur Java et .Net ?
R.S. : plus accessible. Ce langage a pris une bonne place dans la réalisation de systèmes web, comme les portails collaboratifs. A l'inverse, rares sont les applications de gestion très importantes écrites dans ce langage. Même s'il existe des exceptions, tel Sugar. Au final, trois familles de développeurs vont se distinguer : avec, par ordre croissant de difficulté, PHP et Visual Basic, puis Python et Ruby, et enfin des langages fortement typés comme Java et C#. Le sens de l'histoire s'oriente vers une complexification des technologies du programmeur. Même PHP n'y échappe pas : les dernières évolutions dans PHP 5 le prouvent.Le mouvement du On Demand, à savoir les services accessibles sur internet, changera-t-il aussi profondément le métier de développeur ?
R.S. : Développer des logiciels ou des fonctions en tant que services ne demande pas les mêmes compétences. Ces services sont en général conçus sur des architectures avec une même instance pour tous les clients (multitenant). Sans être nouveau, cela modifie beaucoup de choses quant à la conception de l'application. On doit stocker des métadonnées pour chaque client, lesquelles vont décrire ses règles métier. C'est donc très paramétré, et fort complexe à concevoir. Le développeur lambda ne peut pas réaliser cela : il ne s'agit pas deffectuer de la programmation directe sur la base de données. La tâche nécessite des architectes et des développeurs très expérimentés.
Raymond Sclison : La première concerne les méthodes de travail. Dans la majorité des cas, face à un problème avec un logiciel de développement open source, un technicien ne demande pas des heures de formation et appelle encore moins l'assistance téléphonique. Il va plutôt s'adresser à d'autres développeurs. Cela nécessite pour les participants de maîtriser les outils de travail collaboratif. Autre différence : la documentation des logiciels. En général, elle apparaît très riche et centralisée chez les éditeurs qui font du propriétaire, mais s'avère en revanche beaucoup plus diffuse dans le libre. Elle se trouve soit centralisée, soit répartie entre les forums, les mailing-lists, et peut aussi être gratuite ou payante... Les développeurs novices connaissent parfois des difficultés à retrouver ces renseignements.Le libre rend donc le travail du développeur plus difficile ?
R.S. : La certitude, c'est que le cycle de vie des applications se révèle particulier dans l'open source. Il est souvent plus court que dans le monde propriétaire, en tout cas pour les petits logiciels. On peut rencontrer des problèmes avec les bibliothèques - Ajax constituant en ce moment l'exemple type. Certaines d'entre elles sont récentes, et les sorties de nouvelles versions peuvent être assez fréquentes - parfois tous les deux ou trois mois. Une plus grande souplesse s'impose dans la manière de travailler. Ensuite, cela dépend du profil du codeur. Ainsi, un développeur-concepteur dispose à la base d'une ouverture d'esprit certaine. Il subira donc moins d'influence. Reste que l'open source requiert d'aller à l'essentiel très rapidement, le plus souvent sans formation. Il faut lire le manuel en diagonale et utiliser son réseau. Les bons développeurs se connaissent, se croisent et profitent d'un réseau. Et comme si cela ne suffisait pas, le travail dans le monde du libre demande de connaître des outils peu usités dans l'industrie, comme CVS pour la gestion des versions, ou ANT pour la construction de programmes.Tout le monde peut-il modifier un logiciel libre ?
R.S. : Cela paraît plus aisé pour le développeur expérimenté qui identifie déjà un certain nombre de patterns (pratiques et modèles de programmation, NDLR). Il va cibler plus vite les endroits où il faut adapter le code. Le débutant, lui, aura du mal à les trouver. Au bout de deux ou trois ans seulement, il reconnaîtra ces patterns d'architecture et de conception dans les logiciels créés par des codeurs expérimentés. Ces choses n'existent évidemment pas dans le monde propriétaire. Voilà d'ailleurs une des particularités du libre : le développeur open source rejoint le concepteur en termes de compétences.Les technologies web 2.0 et les langages plus récents sont censés être plus accessibles à tous les développeurs. Va-t-on assister à une scission entre les débutants accrochés à PHP et les autres travaillant sur Java et .Net ?
R.S. : plus accessible. Ce langage a pris une bonne place dans la réalisation de systèmes web, comme les portails collaboratifs. A l'inverse, rares sont les applications de gestion très importantes écrites dans ce langage. Même s'il existe des exceptions, tel Sugar. Au final, trois familles de développeurs vont se distinguer : avec, par ordre croissant de difficulté, PHP et Visual Basic, puis Python et Ruby, et enfin des langages fortement typés comme Java et C#. Le sens de l'histoire s'oriente vers une complexification des technologies du programmeur. Même PHP n'y échappe pas : les dernières évolutions dans PHP 5 le prouvent.Le mouvement du On Demand, à savoir les services accessibles sur internet, changera-t-il aussi profondément le métier de développeur ?
R.S. : Développer des logiciels ou des fonctions en tant que services ne demande pas les mêmes compétences. Ces services sont en général conçus sur des architectures avec une même instance pour tous les clients (multitenant). Sans être nouveau, cela modifie beaucoup de choses quant à la conception de l'application. On doit stocker des métadonnées pour chaque client, lesquelles vont décrire ses règles métier. C'est donc très paramétré, et fort complexe à concevoir. Le développeur lambda ne peut pas réaliser cela : il ne s'agit pas deffectuer de la programmation directe sur la base de données. La tâche nécessite des architectes et des développeurs très expérimentés.
Contenus sponsorisés
Votre opinion