Traduction d'un article de Patrick Lee Dooley
http://organicprogramming.blogspot.com/2011/04/op-is-software-development-art-or-craft.html
Durant la dernière année et demi, j'ai travaillé sur les fondements de l'approche de développement logiciel appelée "Programmation Organique" (PO). Les résultats de mes recherches sont très intéressants. Je voudrais partager ces découvertes et générer une discussion riche. Je pense que cela est la clé du concept d'Artisanat du logiciel - un sujet qui est cher à mon cœur. Et tant que nous ne l'aurons pas défini, nous ne serons pas en mesure d'énoncer clairement ce que nous entendons par ce terme. Il y a eu beaucoup de discussions au cours des années pour savoir si le développement logiciel (Software Development) doit être considérée comme un Art. Nous sentons intuitivement qu'il est plus correctement compris comme un artisanat (Craft). Nous sommes plus à l'aise en le considérant comme un artisanat. Nous pensons de cette façon pour la simple raison que nous avons été formés comme artisans, et non pas comme des artistes. Il est inersessant dans la compréhension et le traitement du SD comme un artisanat. Après tout, les fruits de notre profession témoignent de la validité de ce point de vue. Cependant, je ne suis plus convaincu que ce point de vue soit suffisant. J'ai réalisé que le SD est aussi un art.
N'étant pas un psychologue, j'ai récemment réalisé qu'il ya deux façons distinctes de décrire la réalité. La première est très concise et succincte (Craft). Les mathématiques tombent dans cette catégorie. La seconde est élaborée et sophistiquée (Art). La peinture ou la littérature entre dans cette catégorie. Ce sont les deux extrémités du spectre de l'activité humaine. Notre capacité à bien exprimer la réalité dans ces deux approches détermine la façon dont nous pouvons Interpréter, Modèliser et Communiquer la réalité. Notre capacité à résoudre des problèmes est déterminée par notre capacité à faire ces activités, et aussi - tout aussi important - par notre capacité à déterminer la bonne approche pour ces différents aspects de la réalité. Si nous nous trompons dans le choix de l'approche appropriée, notre capacité à créer des solutions en sera affaiblie. Nous pourions encore être en mesure de résoudre le problème, mais nous ne serions pas en mesure de le résoudre de manière efficace. Comme exemple simple, si nous souhaitons communiquer la beauté d'un paysage, le choix d'utiliser des représentations en fil de fer pour les éléments dans l'espace du problème entravera notre capacité à transmettre cette beauté. Nous allons être obligés de passer beaucoup plus de temps et d'efforts à tenter de corriger la solution en agitant la main jusqu'à ce que nous soyons en mesure de transmettre cette beauté. Tenter de résoudre ce problème en le réduisant s'avère totalement inefficace. Le logiciel n'est pas différent. La création efficace d'un système logiciel requiert la capacité à la fois:
- Représenter certains aspects de l'espace de problème avec la sémantique concise et succincte (Craft -. Sémantique à savoir la théorie des ensembles, la sémantique d'analyse, de la sémantique algorithmique etc)
- Représenter d'autres aspects de l'espace de problème avec la sémantique complexe et sophistiquée (Art - c'est à dire le modèle du logiciel des entités et les relations à multiples facettes entre les entités).
Un système logiciel efficace doit être à la fois de l'art et de l'Artisanat. Mais ce n'est pas différent de toute autre profession qui tente de résoudre un problème particulier. Une voiture - quand elle est conçue correctement, est également à la fois de l'art art et de l'artisanat. C'est vraiment un argument pour le principe selon lequel la forme est définie par la fonction. On pourrait avancer que dans la profession du logiciel - comme dans aucune autre profession - , la fonction véritable dépendent de la forme du logiciel - particulièrement lorsque la sophistication du système augmente. La Nature elle-même fournit de nombreux exemples où la forme permet la fonction. Il y a des discussions étonnantes sur le gecko sur le site TED. Donc, en résumé, je crois que le logiciel a besoin d'être traitée comme un art, quand cela est nécessaire, et elle doit être traitée comme un artisanat - quand cela est nécessaire. Et nous avons besoin de développer la capacité d'être en mesure de déterminer où se situent ces exigences. C'est mon expérience, que nous ne sommes pas armés pour faire ce type de distinctions. Nous avons été formés uniquement avec les compétences d'un artisan. Nous avons été amenés à croire que ces compétences sont suffisantes pour l'ensemble de nos problèmes de conception. Nous avons un outil dans notre coffre à outils, et nous nous sentons tellement en confiance avec cet outil qui nous l'utilisons partout. Et pourtant, nous sommes surpris lorsque les résultats sont plutôt satisfaisants. Je pense qu'il est impératif que nous étendions notre ensemble d'outils et d'apprendre leurs usages respectifs.
Pour réaliser cette traduction, je me suis aidé de http://translate.google.fr et http://www.granddictionnaire.com
Merci à Patrick Lee Dooley de m'avoir autorisé à publier cette traduction.
Pour en savoir plus sur la programmation organique :
http://www.organicprogramming.com/2010/08/what-is-organic-programming-op/
Aucun commentaire:
Enregistrer un commentaire
Feedback...