Quelles pratiques spécifiques pourraient être appelées «artisanat logiciel» plutôt que «génie logiciel»? [fermé]

Bien qu'il ne s'agisse pas d'une idée nouvelle, il semble y avoir eu une grande augmentation de l'intérêt pour la fabrication de logiciels au cours des deux dernières années (notamment le titre complet du livre souvent recommandé Clean Code est Clean Code: A Handbook of Agile Software Craftsmanship ).

Personnellement, je considère le savoir-faire logiciel comme une bonne ingénierie logicielle avec un intérêt supplémentaire à s'assurer que le résultat final est une joie de travailler avec (à la fois en tant qu'utilisateur final et en tant que personne assurant la maintenance de ce logiciel) - et aussi que son objectif est davantage au niveau du codage des choses que les choses de processus de niveau supérieur.

Pour faire une analogie - il y avait beaucoup de bâtiments construits dans les années 50 et 60 dans un style très moderne qui tenait très peu compte des personnes qui y vivraient ou de la façon dont ces bâtiments vieilliraient au fil du temps. Beaucoup de ces bâtiments se sont rapidement transformés en bidonvilles ou ont été démolis bien avant leur durée de vie prévue. Je suis sûr que la plupart des développeurs ayant quelques années à leur actif auront connu des bases de code similaires.

Quelles sont les choses spécifiques qu'un artisan logiciel pourrait faire qu'un ingénieur logiciel (peut-être un mauvais) pourrait ne pas faire?

Je dirais que la seule différence entre un professionnel et un artisan est de prendre soin d'un peu de passion . Il n'y a pas de pratique spécifique et observable qui classerait un artisan, mais plutôt un ensemble de qualités:

• Un artisan se soucie de la qualité réelle de son travail, et pas seulement de la qualité perçue.
• Un artisan a un intérêt pour son métier qui va au-delà de la réalisation du travail, et qui gravite naturellement vers son métier.
• Un artisan se soucie de son métier, aspirant à améliorer ses compétences et non seulement à faire progresser sa carrière .
• Un artisan passe un certain temps en dehors de ses heures de travail rémunérées (même si c'est une petite quantité de temps) pour faire quelque chose avec son artisanat, que ce soit pour discuter, apprendre ou même y penser.
• Un artisan sait à quel point il en sait peu et en est humilié.
• Un artisan est prêt à enseigner à ceux qui veulent apprendre, à guider ceux qui cherchent des conseils et à chercher ces choses lui-même quand il en a besoin.

Un peu de passion couvre tout cela sans se suer.

Personnellement, je considère le savoir-faire logiciel comme une bonne ingénierie logicielle avec un intérêt supplémentaire à s'assurer que le résultat final est une joie de travailler avec (à la fois en tant qu'utilisateur final et en tant que personne assurant la maintenance de ce logiciel) - et aussi que son objectif est davantage au niveau du codage des choses que les choses de processus de niveau supérieur.

Comme l'a dit un de mes professeurs (paraphrasé): "En tant qu'ingénieur logiciel, ce n'est pas seulement votre travail de fournir des logiciels. C'est votre travail de fournir des logiciels qui rendent vos clients heureux."

Quelles sont les choses spécifiques qu'un artisan logiciel pourrait faire qu'un ingénieur logiciel (peut-être un mauvais) pourrait ne pas faire?

Rien - un ingénieur est un artisan ... mais plus. L'ingénierie repose sur l'artisanat.

En tant qu'artisan et ingénieur, vous êtes des individus qualifiés, grâce à une combinaison d'éducation et d'expérience. Vous suivez les procédures établies. Vous êtes également pragmatique et réalisez ce qui est cassé et doit être amélioré.

Cependant, un ingénieur ajoute des préoccupations d'économie, de théorie et de science en plus de cela. Vous souhaitez obtenir le plus d'avantages au moindre coût. Vous souhaitez appliquer des théories de la psychologie, de la sociologie, de la gestion, des interactions homme-ordinateur et de l'informatique pour résoudre vos problèmes (interpersonnels et techniques). Et vous avez certainement une éducation pour sauvegarder vos expériences.

Le mouvement du savoir-faire logiciel a été initié en réaction aux échecs et aux résultats insatisfaisants de l'ingénierie logicielle "traditionnelle" qui (avec l'insouciance de certains développeurs) conduisent aujourd'hui à la méfiance des parties prenantes et des utilisateurs envers notre profession.

Son objectif est double: restaurer la confiance dans les programmeurs, et pour ce faire, élever la barre de la qualité des logiciels et des compétences des développeurs.

Le savoir-faire SW favorise les pratiques techniques telles que:

• Principes de conception SOLIDES
• Modèles de conception
• TDD (métaphore de la "comptabilité en partie double")
• ...

Et pratiques d'équipe / organisationnelles:

• Programmation en binôme
• Le mentorat
• Code katas
• Retraites Dojos / Code
• ...

Je dirais donc que la différence entre les 2 est claire: le savoir-faire logiciel essaie de résoudre une grande partie des problèmes rencontrés par l'ingénierie logicielle depuis plus de 40 ans, ce qui rend notre discipline peu fiable et paralysée par une histoire d'échecs.

Aller par http://manifesto.softwarecraftsmanship.org/ Je dériverais ce qui suit.

Un artisan est différent des perceptions traditionnelles d'un "ingénieur" car

• Ils se concentrent sur la valeur, pas seulement sur la satisfaction des exigences.
• Ils se concentrent sur la qualité même dans le style de leur code, pas seulement sur les exigences.
• Ils participent à la communauté plus large de développement de logiciels, pas seulement à leur lieu de travail.
• Ils ne comprennent pas seulement que l'état de l'art d'aujourd'hui est la ferraille de demain, ils sont actifs pour la réaliser à un niveau ou à un autre.
• Ce n'est pas seulement un travail, c'est qui ils sont .

L'oncle Bob a en quelque sorte laissé entendre que la programmation est une discipline très jeune qui n'a pas encore un ensemble stable de lois ou de règles reconnues par les gouvernements (ou était-ce Frederick Brooks?). Je ne fais pas de citation verbatine ici.

Vous ne pouvez révoquer à quiconque le permis de programmer en raison d'une faute professionnelle. Il manque à la programmation un ensemble de lois et de règles qui soient légalement appliquées par une législation conforme à une "profession". Un médecin tue un patient en raison de son incompétence et il risque de lui retirer son titre de médecin ou sa permission.

Un programmeur crée un programme bogué ou fait échouer un projet en raison de son incompétence et il est libre de poursuivre la programmation.

Je pense que c'est à peu près ce qui fait de la programmation un métier. Un fabricant de pot en argile ne fait pas deux pots identiques. Vous n'avez pas non plus entendu parler d'un fabricant de pots en argile obligé de rappeler des pots défectueux. La programmation est encore un travail très manuel et personnel. Parfois, vous pouvez même dire qui a écrit un morceau de code à en juger par le style.

Refactoring aux modèles.

Autrement dit, construisez quelque chose qui satisfait 90% des exigences logicielles, puis refactorisez l'ensemble du projet en un design épuré et élégant.

Normalement, l'ingénierie logicielle vous empêcherait de le faire, car satisfaire 90% des exigences signifie que le logiciel a suffisamment de valeur commerciale pour le client qu'il ne devrait pas être modifié de manière significative (à l'exception des corrections de bogues de haute priorité).

L'ingénierie logicielle vous conseille plutôt de stabiliser le logiciel à ce stade.

De plus, si un projet ne démarre pas avec cette conception élégante dès le début, il serait considéré comme un projet mal exécuté (quel que soit le résultat du projet), selon l'ingénierie logicielle.

Solution de pointe.

Une conception inspirée d'une solution de pointe n'est normalement pas acceptable selon la méthodologie d'ingénierie logicielle en vigueur.

Obsolescence , quelle qu'en soit la raison.

En génie logiciel, tout type de dépréciation n'est autorisé qu'à la fin du cycle de vie d'un système logiciel. Cela doit être planifié dans le cadre du SDLC.

Dans la pratique, il est assez courant que les lacunes d'une partie spécifique de l'interface logicielle soient découvertes après quelques années de production, et que cette partie spécifique puisse être déconseillée au milieu du cycle de vie, sans invalider le reste du logiciel. Cela aurait nécessité une recertification de l'ensemble du système logiciel après la dépréciation, selon l'ingénierie logicielle.

En fin de compte, le savoir-faire logiciel est une recherche personnelle de bons jugements de la part des individus, tandis que le génie logiciel est un ensemble conservateur de connaissances. Permettre ce bon jugement dans la prise de décision du projet est ce qui sépare le savoir-faire logiciel du génie logiciel.

Je dirais que des tests unitaires couvrant 100% du code seraient une bonne chose. Comme cela permet de retirer les choses en excès.

Je compare parfois le développement logiciel à la sculpture. Ce n'est pas ce que vous ajoutez, c'est ce que vous enlevez.

Évidemment, vous pouvez aller trop loin. Personne ne dira qu'un petit caillou brillant est une bonne sculpture: S