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

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?

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

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 .

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.

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,

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é.

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.

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!

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.

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)

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.

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.