Est-il possible d'écrire des logiciels qui n'ont pas besoin d'être continuellement modifiés?


23

J'ai écrit beaucoup de logiciels dans de nombreuses langues différentes, et j'ai également "écrit" du matériel à utiliser avec des FPGA utilisant Verilog et VHDL.

J'ai tendance à aimer écrire du matériel plus que des logiciels, et je pense que l'une des principales raisons est qu'il est possible d'écrire du matériel qui est "fait" et n'a jamais besoin d'être modifié: vous définissez les interfaces et les fonctionnalités, écrivez un banc de test , implémentez le module matériel, puis testez-le à l'aide d'un simulateur. Ensuite, vous pouvez compter sur ce module matériel comme bloc de construction pour créer quelque chose de plus grand et meilleur: si vous devez ajouter une fonctionnalité à ce module, vous créez un deuxième module et y ajoutez la fonctionnalité. Vous ne jetez jamais le module d'origine car il fonctionne très bien et peut toujours être utile.

Une de mes principales frustrations avec le logiciel est qu'il n'est jamais "fait". Il y a toujours une autre fonctionnalité à ajouter. Souvent, lors de l'ajout d'une fonctionnalité, il introduit un bogue ailleurs qui fonctionnait très bien auparavant. Cela ne se produit pas dans le matériel tant que les interfaces ne sont pas violées.

Pour être clair, je ne préconise pas de créer une version de quelque chose avec une liste de fonctionnalités et c'est tout pour toujours: je suis en faveur d'itérations et de plusieurs versions au fil du temps pour ajouter de nouvelles fonctionnalités. Je ne veux simplement pas pousser le code à gauche et trouver un bogue à droite, et cela semble se produire après l'ajout d'une nouvelle fonctionnalité.

Est-il possible d'écrire un logiciel d'une manière similaire dans laquelle le matériel est "écrit"? Existe-t-il une bonne méthodologie de développement logiciel qui permette toujours d'avancer et permette d'ajouter de nouvelles fonctionnalités sans avoir à réécrire le code existant et introduire de nouveaux bogues?


8
Vous semblez décrire OCP
Oded

Ce principe de principe ouvert-fermé a fière allure! Quelqu'un at-il utilisé cela avec succès?
Nathan Farrington

2
@NathanFarrington: La plupart des modèles de conception (tels que décrits par GOF ) suivent l'OCP. Un exemple serait le modèle de méthode de modèle .
Spoike

2
@NathanFarrington Le principe ouvert-fermé est un principe commun utilisé par les développeurs de logiciels lors de la conception de logiciels.
Jesper

1
J'imagine que bon nombre des programmes que nous utilisons aujourd'hui sont fabriqués à partir de morceaux et de morceaux qui sont des copies conformes au code écrit il y a 20 ans.
Mallow

Réponses:


16

Peut-être que cela a quelque chose à voir avec des interfaces et des tests bien définis, comme le matériel?

Exactement mes pensées!

Les modules bien conçus avec des interfaces claires ont tendance à être essentiellement parfaits. Pensez à quelque chose comme la Stringclasse de Java. C'est un programme informatique, mais il a une interface limpide. Il n'y a aucun bogue connu. Il fait ce qu'il est censé faire, parfaitement. Bien sûr, il a été largement testé au cours des 15 dernières années, et comme pratiquement tous les programmes utilisent Strings comme blocs de construction de base, tout bogue pourrait être rapidement remarqué. Toutes les "bizarreries" - pas strictement des bogues, mais des détails de conception qui méritent d'être connus - tels que ceux décrits ici http://www.jwz.org/doc/java.html sont désormais bien connus et peuvent donc être pris en compte. Compte.

Les logiciels de buggy sont en partie un problème culturel: les gens sont habitués aux logiciels de buggy, et contrairement au matériel, les logiciels peuvent généralement être facilement réparés par la suite, donc il n'a pas besoin d'être parfait au départ (ou jamais, car bon, nous devons expédier maintenant, réparons dans la prochaine version). Mais pour une grande partie, c'est un vrai problème de complexité: la complexité des logiciels n'a cessé d'augmenter depuis une cinquantaine d'années, mais le cerveau humain est le même. Lorsque la difficulté croissante d'atteindre la perfection et la facilité croissante de réparer les choses plus tard (constructions rapides et automatiques, distribution Internet) se combinent avec la pression du calendrier et le manque de discipline, le résultat est ce qu'il est.

Existe-t-il une bonne méthodologie de développement logiciel qui permette toujours d'avancer et permette d'ajouter de nouvelles fonctionnalités sans avoir à réécrire le code existant et introduire de nouveaux bogues?

Pas de solution miracle probablement, mais une bonne combinaison de meilleures pratiques, y compris mais sans s'y limiter:

  • Modules simples et autonomes. En d'autres termes, faible couplage et forte cohésion.
  • Immutabilité. Particulièrement important avec la concurrence croissante.

Il convient de noter que les deux points visent à réduire la complexité. Voilà le point clé. L'entropie a toujours tendance à augmenter, et à moins de lutter contre cela, nous allons bientôt nous noyer dans la complexité. Il est également intéressant de voir qu'au cours des dernières années, les langages de programmation ont évolué vers l'encouragement ou même l'application des pratiques mentionnées ci-dessus. En particulier, l'essor des langages fonctionnels n'est que cela: les fonctions pures renvoient toujours la même valeur pour la même entrée, il n'y a pas d' état en elles. Ensuite, vous composez simplement des fonctions pures qui prennent et retournent des valeurs immuables , et limitent l'inévitable mutabilité à de petits endroits bien définis au lieu de la répandre tout autour. Vérifiez ceci: http://clojure.org/state


1
jwz n'est pas tout à fait d'accord pour dire que la classe String est exempte de bogues - jwz.org/doc/java.html

1
Il peut fonctionner comme prévu, la question est donc de savoir si la conception sous-jacente est cassée. Je suis d'accord, cependant, que String est une classe très fiable.

1
Excellente réponse. Je code maintenant presque exclusivement en Python et j'essaie de tirer parti des constructions de programmation fonctionnelles. Oui, je pense que vous avez raison: l'immuabilité est la clé. La première fois que je crée un module logiciel, même si je le teste, j'ai probablement gâché l'interface, ou peut-être qu'il a la mauvaise responsabilité ou trop. Je fais donc un deuxième module et laisse le premier tranquille! Je peux toujours utiliser le premier module à l'avenir si je le souhaite, mais jamais le changer, car bien qu'il ne soit pas parfait, il fonctionne. Des langages fonctionnels immuables pourraient donc vous aider comme vous le suggérez.
Nathan Farrington

1
@JoonasPulakka: Oui, s'il y a un résumé en ligne du logiciel, ce pourrait être "il y a toujours un autre bug". :-) Et je pense que c'est l'un des points de Nathan.
Ross Patterson

1
Joonas, tu gagnes. J'ai commencé à apprendre Clojure. Cela semble être la meilleure façon de rendre la programmation encore plus amusante.
Nathan Farrington

9

La différence est à quel point il est plus facile et moins coûteux de modifier un logiciel par rapport au matériel. Si le matériel était aussi facile et bon marché à modifier et à expédier aux clients, ils le feraient.

Je pense que si je pouvais résumer ma question mal exprimée, ce serait quelque chose comme "comment puis-je avoir plus de plaisir à écrire des logiciels en n'introduisant pas de bogues dans le code de travail et en faisant toujours des progrès?" Peut-être que cela a quelque chose à voir avec des interfaces et des tests bien définis, comme le matériel?

Vous devez absolument vérifier le développement piloté par les tests .


Beaucoup de réponses à ma question semblent contenir du folklore. Est-il nécessairement plus facile de trouver et de corriger les bogues logiciels que de les concevoir dès le départ? Combien cela coûte-t-il vraiment de modifier un logiciel? Personne ne sait probablement vraiment. Concernant le développement piloté par les tests, il est logique de tester des logiciels qui peuvent être réutilisés. Le logiciel devient alors un véritable bloc de construction plutôt qu'une boule de boue. Mais cela n'a pas de sens de tester un logiciel s'il va juste changer demain. Je suppose que je me demandais si nous pouvions réellement créer des logiciels à partir de blocs de construction plutôt que de boue.
Nathan Farrington

1
@NathanFarrington: Je pense qu'il y a une énorme différence dans la façon dont les spécifications et la conception du matériel / logiciel sont faites. La plupart des fabricants de matériel ont probablement de meilleures spécifications pour ce qu'ils font qu'un développeur de logiciels dont le client ne peut que dire "Je veux un programme qui fait ça!" Il est à peu près garanti d'obtenir de nouvelles fonctionnalités et quoi d'autre.
RCE

Bien sûr, s'il y a beaucoup de changements, certains tests pourraient également devoir être modifiés, mais ce n'est pas comme les changements de logiciel du traitement de texte au serveur Web. Votre fonctionnalité "nouveau document" créera toujours une nouvelle fonction et ses tests devraient toujours être valides.
RCE

Vous avez souligné un autre principe clé: meilleures sont les spécifications, moins de changements sont nécessaires en cours de route. Mais ce n'était pas exactement ce à quoi je voulais en venir dans ma question car vous pouvez ajouter des fonctionnalités au matériel avant qu'il ne soit fait comme un logiciel. Je pense que l'OCP était la vraie réponse, malheureusement c'est un commentaire donc je ne peux pas le marquer comme réponse. Un autre point était de toujours progresser et je pense que TDD peut y contribuer en fournissant des tests de régression.
Nathan Farrington

Changer de logiciel semble plus facile et moins cher que le matériel, mais est-ce vraiment le cas? Oui, je peux faire un changement et presque instantanément faire une nouvelle construction avec la pression de mon doigt. Cependant, la construction doit encore passer par la validation / QA. Quel a été le coût d'opportunité? Qu'est-ce que j'aurais fait au lieu de corriger ce bogue. Qu'aurait fait QA s'ils n'avaient pas eu besoin de revalider le logiciel. Des projets différents ont-ils été lancés pour mettre cette solution sur le marché? Il y a beaucoup de coûts «cachés» auxquels les gens ne pensent pas. Cela pourrait être plus facile, mais pas nécessairement moins cher.
Pemdas

6

Je commenterai certaines de vos remarques, en espérant que vous obtiendrez la réponse de ces commentaires.

Une de mes principales frustrations avec le logiciel est qu'il n'est jamais "fait".

Cela est dû au fait que la spécification de la solution est incomplète ou parce que le plan pour apporter des améliorations n'est pas précis. Cela peut arriver à n'importe quel logiciel, matériel ou autre projet.

Existe-t-il une bonne méthodologie de développement logiciel qui permette toujours d'avancer et permette d'ajouter de nouvelles fonctionnalités sans avoir à réécrire le code existant et introduire de nouveaux bogues?

Bien sûr, la création de modules indépendants devrait réduire considérablement la dépendance. Cela doit être pris en compte lors de la conception du logiciel. Vous devez tenir compte de la séparation des préoccupations, des couches, des niveaux, des objets de contrôleur, des interfaces, etc.

"Comment puis-je avoir plus de plaisir à écrire des logiciels en n'introduisant pas de bogues dans le code de travail et en faisant toujours des progrès?"

1-Comprenez soigneusement les exigences. Vous devrez peut-être envisager de fermer les exigences avant la conception. Si vous effectuez un développement itératif, il n'y a aucune chance de le faire. Certaines méthodologies encouragent cela, mais personnellement, je pense que ce n'est pas bon pour tous les types de projets. Construire un logiciel sur des exigences solides permet une meilleure conception.

2-Faites comprendre à votre utilisateur cette philosophie à long terme.

3-Planifiez soigneusement la mise en œuvre

4-Conception avant code.

5-Utilisez une conception générique lorsque cela est approprié.

6-Utilisez des prototypes comme outil de confirmation de conception.


Ce sont tous d'excellents conseils. Pour résumer mes réflexions jusqu'à ce point: (1) faire des versions un BON DEAL et faire beaucoup de tests et d'assurance qualité avant une version, (2) faire des modules un BIG DEAL et s'assurer qu'ils ont des interfaces documentées bien définies avec des tests pour ceux interfaces et assertions pour voir si l'interface est violée et une fois qu'un module est "libéré" il n'est jamais modifié (OCP).
Nathan Farrington

4

Comme les gens le soulignent généralement très rapidement, l'un des avantages du logiciel est qu'il est censé être facile et relativement bon marché à changer par rapport au matériel. Ceci est particulièrement important lorsque vous réalisez tard que vous vous êtes trompé fondamentalement. Faites de même avec le matériel, et vous perdez un million de dollars, donc comme vous l'avez dit, vous utilisez vos simulateurs, etc., et vous en testez le bazinga. Je pense que c'est là que le paradigme échoue quelque peu lorsque vous passez au logiciel.

Entrez dans la tête du développeur de logiciels moyen, et ce que vous avez est une personne très occupée avec un délai incroyablement serré. Son manager dit qu'il est correct de laisser quelques bugs car vous pouvez toujours le corriger plus tard. Les tests sont souvent une réflexion après coup, mais même dans un scénario piloté par les tests, les tests sont minimisés et le code écrit au minimum des tests, et souvent des raccourcis sont pris afin que de nombreux cas limites puissent être manqués. Le système peut être minutieusement testé à l'unité, mais il est rarement testé rigoureusement dans son ensemble, et tout aussi rarement testé à un degré élevé. Ajoutez à cela que vous écrivez des logiciels à partir de zéro, et il y a peu d'occasions de simuler le logiciel avant de vous engager à l'écrire, principalement parce que nous écrivons rarement des logiciels à partir du même type de blocs de construction à grain fin que vous trouveriez dans le matériel.

Revenons à la question du PO. Pourriez- vous définir un système de blocs de construction à partir duquel dériver tous vos logiciels? Peut-être. Serait-ce très rentable? Probablement pas, car au moment où vous vous familiarisez avec le développement d'un système suffisamment robuste de composants, de tests et d'autres accessoires pour soutenir cela idéalsystème de programmation, vous constateriez que votre concurrence vous aurait déjà battu sur le marché, et pire encore, du point de vue du programmeur moyen, vous trouveriez probablement un style de système de programmation "coupe-biscuit" très limitant et très probablement très ennuyeuse. Personnellement, je travaille sur une API, où la majeure partie du code du module a été affinée et normalisée si complètement, que tout ce que je fais maintenant est de générer un modèle de code et de remplir les blancs. La plupart de mon temps peut être consacré à l'écriture de code de connecteur simple et à la sortie des modules le plus rapidement possible. C'est vraiment engourdissant. Il y a très peu d'occasions de faire plus que simplement coder le même genre de choses encore et encore, donc quand une autre opportunité de projet se présente, je saute sur l'occasion de pouvoir faire TOUT autre chose.

Alors, comment pouvez-vous arriver à fournir des logiciels de haute qualité et bien factorisés, tout en vous amusant à le faire? Je crois que cela se résume à votre choix d'outils et de méthodologie. Pour moi, la réponse a été d'employer une bonne API BDD, car elle m'a permis de créer un code très facile à lire, mais très granulaire. Je peux construire une suite de tests à partir d'un nombre minimal de méthodes réutilisables et décrire mes tests dans le langage des spécifications. De cette façon, je me rapproche d'une approche de développement plus composante, sauf pour le fait que je suis responsable de la conception et de la vérification des blocs de construction. De plus, la sortie du test identifie la partie exacte du test où l'échec se produit, de sorte que je n'ai pas à deviner si les échecs sont dans la configuration ou l'assertion.

Ajuster votre méthodologie est également utile. Je suis un ardent défenseur de l'application des principes du développement Lean et de leur combinaison avec de nombreuses autres techniques et principes que le mouvement Agile frappe depuis de nombreuses années. Ayant éliminé la plupart des pratiques inutiles que je trouvais si frustrant, j'ai beaucoup aidé à faire du développement une activité plus agréable. Je reste avec le problème que parfois - mais j'espère pas trop souvent - des bugs apparaîtront dans mon code, mais je me retrouve maintenant avec plus de temps, et encore plus d'incitation à passer plus de temps à écrire des tests plus robustes et à viser 100 % Couverture de test. Encore mieux, c'est vraiment génial de voir tous ces feux verts apparaître à la fin de ma journée,


Je suis curieux, vous écrivez que les tests sont importants mais aussi angoissants.
Nathan Farrington

@NathanFarrington Merci d'avoir signalé cela. Mon but était de parler positivement des tests, mais j'y pensais en tapant autre chose, donc ça s'est totalement mal passé dans ce paragraphe! J'ai corrigé pour convenir au point réel que j'essayais d'éclairer!
S.Robins

3

Une de mes principales frustrations avec le logiciel est qu'il n'est jamais "fait". Il y a toujours une autre fonctionnalité à ajouter.

Si cela vous frustre, envisagez une autre carrière. Sérieusement.

Le but du logiciel est de pouvoir ajouter des fonctionnalités. La raison principale de l'invention du "logiciel" était en premier lieu afin que nous puissions ajouter des fonctionnalités.

Souvent, lors de l'ajout d'une fonctionnalité, il introduit un bogue ailleurs qui fonctionnait très bien auparavant.

C'est un problème d'AQ.

Cela ne se produit pas dans le matériel tant que les interfaces ne sont pas violées.

C'est également vrai pour les logiciels.

Existe-t-il une bonne méthodologie de développement logiciel qui permette toujours d'avancer et permette d'ajouter de nouvelles fonctionnalités sans avoir à réécrire le code existant et introduire de nouveaux bogues?

Oui. Vous devez réellement pratiquer l'assurance qualité.


1
Soit dit en passant, je n'essaie pas de troller, et oui, je ne suis peut-être pas fait pour les logiciels. Mais vous dites que «l'intérêt du logiciel est de pouvoir ajouter des fonctionnalités». Est ce que c'est vraiment? von Neumann a inventé un logiciel pour pouvoir construire un ordinateur capable de calculer plus d'une fonction mathématique sans recâbler ses unités logiques et arithmétiques. Je suis curieux de savoir d'où vient cette philosophie des fonctionnalités logicielles. Le matériel a des fonctionnalités, mais le but du matériel n'est pas d'ajouter des fonctionnalités.
Nathan Farrington

Je suppose que par assurance qualité, vous entendez des tests. Oui, mon intuition dit que des tests approfondis sont nécessaires pour produire des logiciels de qualité. Mais je pense que cela va au-delà. Dans le matériel, un module peut contenir un bogue. Mais lorsque vous ajoutez du nouveau matériel, cela n'introduit pas de nouveaux bogues dans un module matériel existant. Finalement, tous les bogues de tous les modules peuvent être trouvés et corrigés. Mais dans les logiciels, le code est souvent modifié (les modules sont modifiés) plutôt qu'ajouté, ce qui peut introduire des bogues. Je suppose que je cherchais une méthodologie de développement logiciel purement additive.
Nathan Farrington

J'ai maintenant un commentaire plus intelligent sur votre réponse. La raison pour laquelle j'ai critiqué le fait que les logiciels ne soient jamais "terminés" est probablement parce que j'ai toujours utilisé une approche très lâche pour les versions. Une nouvelle fonctionnalité équivaut à la prochaine version, sans test de régression et très peu d'assurance qualité. Si les versions étaient une GRANDE AFFAIRE, je parie que mes reproches à propos d'un logiciel qui ne serait jamais fait disparaîtraient.
Nathan Farrington

@NathanFarrington: Turing a inventé un logiciel pour briser les codes Enigma en constante évolution. "par assurance de la qualité, vous entendez des tests". Faux. Je veux dire l'assurance qualité - chaque aspect du développement doit avoir des normes de qualité qui doivent être respectées. Les tests sont un moyen (limité) d'évaluer la qualité d'un type d'artefact. msgstr "le code est changé ... ce qui peut introduire des bugs". Correct. C'est un échec de l'assurance qualité - pas une caractéristique inhérente des logiciels.
S.Lott

Nous sortons définitivement du sujet. Selon ce lien , le colosse de Turing n'était pas universel (au sens informatique) et n'utilisait pas de programmes stockés (logiciels).
Nathan Farrington

2

Est-il possible d'écrire un logiciel d'une manière similaire dans laquelle le matériel est "écrit"? Existe-t-il une bonne méthodologie de développement logiciel qui permette toujours d'avancer et permette d'ajouter de nouvelles fonctionnalités sans avoir à réécrire le code existant et introduire de nouveaux bogues?

Je vous recommande de rechercher des " méthodes formelles " pour vérifier l'exactitude des conceptions et des logiciels. Les outils de simulation que vous utilisez pour la conception matérielle essaient de faire quelque chose de proche. Je ne pense pas que les outils pour les méthodes formelles soient loin d'être utiles dans l'industrie en ce moment, et les seules industries qui ont de fortes incitations à être exemptes de défauts sont l' avionique et la médecine (curieusement, la FDA dit clairement que "le logiciel est différent" du matériel "sur ce lien). De plus, si vous développez avec Verilog / VHDL, vous vous en tenez à la logique binaire. Cela réduit considérablement la complexité. Il n'y aura pas de matériel équivalent à un problème Y2K.

Le gros problème est que les choses sont complexes. Et vous ne pouvez pas éliminer la complexité, vous ne pouvez que la déplacer.


1

il est possible d'écrire du matériel «fait» et qui n'a jamais besoin d'être modifié: vous définissez les interfaces et les fonctionnalités, écrivez un banc de test, implémentez le module matériel, puis testez-le à l'aide d'un simulateur. Ensuite, vous pouvez compter sur ce module matériel comme bloc de construction pour créer quelque chose de plus grand et meilleur: si vous devez ajouter une fonctionnalité à ce module, vous créez un deuxième module et y ajoutez la fonctionnalité. Vous ne jetez jamais le module d'origine car il fonctionne très bien et peut toujours être utile.

Dans le monde du logiciel, nous appelons ce "module" une bibliothèque, et nous l'utilisons de la même manière. De nombreuses bibliothèques sont construites au point de fonctionner correctement, puis de s'asseoir avec contentement sans changement jusqu'à ce que quelque chose d'important mène à la prochaine révision. Considérez-les comme des logiciels enrobés d'époxy :-)

Une de mes principales frustrations avec le logiciel est qu'il n'est jamais "fait". Il y a toujours une autre fonctionnalité à ajouter. Souvent, lors de l'ajout d'une fonctionnalité, il introduit un bogue ailleurs qui fonctionnait très bien auparavant. Cela ne se produit pas dans le matériel tant que les interfaces ne sont pas violées.

Poudlard. Peut-être que vous êtes personnellement meilleur que beaucoup d'autres personnes "matérielles" sans fer à souder, mais j'ai vu un certain nombre de mauvaises conceptions de circuits, des puces défaillantes ( par exemple , le fameux problème Intel "f00f"), mais cela ne veut pas parler au domaine dans son ensemble. Et à mesure que les articles de contrefaçon deviennent plus «mous», les problèmes deviennent plus difficiles à prévenir.

Est-il possible d'écrire un logiciel d'une manière similaire dans laquelle le matériel est "écrit"? Existe-t-il une bonne méthodologie de développement logiciel qui permette toujours d'avancer et permette d'ajouter de nouvelles fonctionnalités sans avoir à réécrire le code existant et introduire de nouveaux bogues?

Oui. Nous n'utilisons simplement pas beaucoup ces méthodologies. Ils ont tendance à être extrêmement coûteux à exploiter, et la plupart des programmeurs n'aiment pas travailler dans le cadre de leurs restrictions. Mais quand la vie humaine est impliquée, par exemple, eh bien, oui, nous essayons de ne pas tuer les utilisateurs.

Un dernier point: le logiciel a un modèle financier différent du matériel, même du matériel programmé. La plupart des logiciels non grand public, et certains logiciels grand public également, sont vendus de manière à encourager le changement. Lorsque vous pouvez dire à une entreprise "Payez-nous 10 000 $ maintenant plus 18% par an", vous pouvez essentiellement revendre le produit toutes les quelques années. Mais pour justifier ces frais, vous devez donner au client les changements qu'il souhaite. Hmm ... en pensant à la courbe d'obsolescence matérielle d'Apple, ce n'est peut-être pas une différence après tout - le matériel vous fait vraiment le racheter!


Je n'ai jamais dit que j'étais meilleur que quiconque. ;-) Quand le matériel a un bug, il devient une nouvelle. Quand le logiciel a un bogue, ummm, le logiciel d'attente a toujours des bogues. Quelles sont les méthodologies que nous n'utilisons pas car elles sont trop chères et pas amusantes?
Nathan Farrington

0

comment puis-je avoir plus de plaisir à écrire des logiciels en n'introduisant pas de bogues dans le code de travail et en faisant toujours des progrès?

J'adorerais trouver une réponse définitive à votre question. Mais la réalité est qu'il n'y a pas de moyen facile de le faire, c'est pourquoi la programmation extrême et les techniques TDD deviennent si populaires. Vous devez accepter le changement, car cela va se produire. Je ne sais pas si c'est plus drôle de cette façon, mais beaucoup moins stressant à coup sûr ;-)

http://en.wikipedia.org/wiki/Extreme_Programming

Lorsque vous interagissez avec du matériel, le matériel a besoin d'une valeur x et c'est tout (en théorie), mais lorsque vous interagissez avec des gens aujourd'hui, ils ont besoin de x, et demain ils peuvent avoir besoin de y, etc. . Parce que Personnes! = Machines, un code qui ne change JAMAIS la plupart du temps n'est pas possible.

Aussi, comme je l'ai dit dans ma réponse précédente / supprimée, essayez d'éviter les changements qui ne sont pas importants en faisant réfléchir les gens avant de commencer à coder. Impliquez davantage les utilisateurs sur la prise de décision, etc. Clarifiez les coûts des changements, planifiez plus, etc.


1
Bonne réponse. J'ai fait de la programmation extrême. Cela semble être exactement le contraire de ce que je cherchais, où toute la direction du projet peut changer chaque semaine en fonction des caprices du client. Je ne suis pas contre les versions itératives, je ne veux tout simplement pas que la 2ème version introduise des bogues qui n'étaient pas présents dans la 1ère version. Et vous avez raison de dire que la conception initiale peut économiser des efforts à long terme.
Nathan Farrington

Comme je le dis toujours, le meilleur code n'est pas un code. :-)
H27studio

0

Est-il possible d'écrire un logiciel de la même manière?

Oui, ça l'est. Soyez aussi prudent que si vous développez du matériel, testez tout ce que vous pouvez et votre logiciel sera de qualité similaire.

au fait, vous n'avez pas entendu parler des bugs HW? Beaucoup plus méchant que tout bogue SW et plus difficile à corriger (pas seulement la mise à niveau du logiciel)


1
Oui, le matériel a aussi des bugs, même du matériel mature et bien testé comme les processeurs. Un bon matériel est conçu pour que les bogues matériels puissent être corrigés dans le logiciel! La raison de ma question initiale est que j'ai écrit beaucoup de logiciels, mais j'ai toujours été consterné par la facilité avec laquelle il est possible d'introduire des bogues et par le désordre du système dans son ensemble. Je suis une personne nette et la méthodologie de développement matériel m'a toujours paru plus naturelle. Cela pourrait également avoir quelque chose à voir avec la portée.
Nathan Farrington

1
@NathanFarrington Le logiciel est généralement plus complexe qu'un HW. HW est testé de manière plus approfondie. SW peut changer plus facilement, donc les gens ont tendance à ne pas y prêter autant d'attention.
BЈовић

0

Je voudrais également souligner que les bogues logiciels dans le matériel peuvent souvent tuer des gens. Il y a donc plus de soin à déterminer soigneusement les exigences et à les tester de manière approfondie à l'avance. Et ces exigences n'ont pas besoin de changer tant que le matériel ne le fait pas. Et comme le nouveau matériel peut nécessiter une réécriture, je soupçonne que la cruauté ne s'accumule pas beaucoup non plus.

D'un autre côté, les exigences commerciales changent constamment, il est parfois difficile de mettre une exigence en production avant qu'un changement ne soit demandé. Parfois, les exigences ont changé plusieurs fois avant d'arriver à la production. C'est le résultat de plusieurs choses. D'abord, la partie prenante du projet du côté des entreprises est souvent moins intéressée à consacrer du temps à définir ce qu'il veut parce qu'il est "occupé" et "important" et les gens ne mourront pas et les familles le poursuivront ou le jetteront en prison si il souffle sa partie du processus. Deuxièmement, les parties prenantes du projet ont généralement une meilleure idée de ce qu'elles veulent que le matériel fasse, car il est moins abstrait pour elles. Ils ne savent vraiment pas ce qu'ils veulent tant qu'ils ne le voient pas. Ce qui est moins problématique avec le matériel.


Vous avez un point valide. Les types de choses que nous fabriquons traditionnellement dans le matériel sont bien compris: processeurs, contrôleurs USB, points de terminaison PCI Express, contrôleurs de mémoire, etc. Ensuite, nous poussons toute cette logique métier d'application dans le logiciel. Peut-être que pendant que nous progressons dans la pile logicielle, les choses deviennent plus compliquées et moins bien comprises?
Nathan Farrington

-1

Il existe des outils de haut niveau avec beaucoup de «briques» finies, comme vous les appelez, que vous pouvez combiner en applications. Les briques sont des pièces finies que vous pouvez utiliser, il vous suffit de les combiner. Peut-être pensez-vous que c'est plus facile ... jusqu'à ce que votre client vous demande des changements étranges et inattendus.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.