Un bon code est-il impossible dans le développement de logiciels modernes? [fermé]

Il semble que même si les outils de développement sont devenus plus solides et robustes, écrire du bon code est devenu un défi. Même que les outils sont plus puissants, la qualité du code ne s'est pas améliorée. Je viens avec deux facteurs importants, il y a moins de temps et les projets sont plus complexes. Parce que les outils que nous utilisons aujourd'hui sont plus puissants, il est plus facile d'écrire du code plus complexe, mais ne pas avoir le temps de planifier et sans regarder en arrière diminue la qualité du code et augmente les bogues et la maintenance. Ce n'est pas que nous n'avions pas écrit de code complexe auparavant. C'est que nous écrivons du code plus complexe.

Ma question est la suivante: considérant que nous avons un langage et des outils plus puissants.

• Pourquoi est-il plus difficile d'écrire un bon code?
• Les facteurs, le temps et la complexité y contribuent-ils?
• Les méthodologies ne sont-elles pas correctement appliquées?

Le type de projet que je considère est une application d'entreprise avec une grande complexité et une logique métier. La définition de «bon code» est individuelle, veuillez ne pas vous coincer dans l'interprétation de «bon code».

Comme il a été déclaré par DeMarco et Lister dans Peopleware il y a une vingtaine d'années, la grande majorité des projets logiciels échoués échouent non pas en raison de problèmes techniques, mais de problèmes sociologiques . Cela n'a pas changé au cours des dernières décennies, peu importe à quel point nos outils se sont améliorés.

Mauvaise gestion, attentes irréalistes, ne pas trouver les bonnes personnes pour le travail et / ou ne pas les laisser faire leur travail, donc ne pas les garder; des lieux de travail et des outils qui ne conviennent pas aux travaux de développement de logiciels; conflits personnels non gérés; politique ; ce ne sont là que quelques-uns des problèmes typiques qui peuvent rendre un projet condamné dès le départ.

Pourquoi écrire un bon code est plus difficile?

Je ne suis pas tout à fait convaincu qu'il est vraiment plus difficile d'écrire du bon code maintenant qu'il y a des décennies. En fait, par rapport au code machine ou à l'assembly, tout ce que nous avons maintenant dans le courant dominant est beaucoup plus facile à gérer. Il nous suffira peut-être d'en produire davantage.

Est-ce uniquement à cause des facteurs de mention, du temps et de la complexité?

Oui, la complexité réalisable a certainement augmenté (et continue d'augmenter) à mesure que la puissance de nos outils augmente. En d'autres termes, nous continuons à repousser les limites. Ce qui pour moi se traduit par qu'il est tout aussi difficile de résoudre les plus grands défis d'aujourd'hui qu'il y a 30 ans pour résoudre les plus grands défis de ce jour.

OTOH étant donné que le domaine s'est tellement développé, il y a beaucoup plus de "petits" problèmes ou de "problèmes connus" qu'il y a 30 ans. Ces problèmes ne sont techniquement (devraient) plus (être) un défi, mais ... ici entre la maxime ci-dessus :-(

Le nombre de programmeurs a également considérablement augmenté depuis. Et au moins ma perception personnelle est que le niveau moyen d'expérience et de connaissances a diminué, tout simplement parce qu'il y a beaucoup plus de juniors qui arrivent en permanence sur le terrain que de seniors qui pourraient les éduquer.

Est-ce que les méthodologies ne sont pas pratiquées correctement?

IMHO certainement pas. DeMarco et Lister ont des mots durs à propos des méthodologies big-M. Ils disent qu'aucune méthodologie ne peut réussir un projet - seuls les membres de l'équipe le peuvent. OTOH les petites méthodologies dont ils font l'éloge sont assez proches de ce que nous connaissons aujourd'hui comme «agile», qui se répand largement (à mon humble avis pour une bonne raison). Sans parler de bonnes pratiques telles que les tests unitaires et la refactorisation, qui, il y a seulement 10 ans, n'étaient pas largement connues, et de nos jours même de nombreux diplômés les connaissent.

Les problèmes liés au codage dans des délais irréalistes et au traitement de la dette technique sont connus depuis Weinberg '71 et Brooks '72. La littérature devient difficile à trouver en ligne avant cela, mais je suis presque sûr que d'anciens rapports CDC, IBM et NASA disent la même chose.

Je pense que nous avons tous nos propres idées et seuils pour un «bon code». Cependant, il existe un certain nombre de problèmes qui contribuent tous:

• Une mauvaise application de "faire fonctionner puis l'améliorer" signifie que nous laissons le code mort et 10 variantes différentes de la même méthode où chacun n'est utilisé qu'une seule fois dans la base de code. Ce truc ne semble jamais être nettoyé.
• Manque de temps et de budget. Le client veut 100 nouvelles fonctionnalités en 3 mois, certaines non triviales, et il ne veut pas dépenser d'argent pour des choses qu'il ne peut pas voir directement.
• Manque de soins. Avouons-le, certains développeurs se soucient de l'apparence et du comportement du code plus que d'autres. Voir le premier point pour un exemple.
• Nous ne savons vraiment pas comment créer un "bon code". Mon concept de bon code est en constante évolution. Ce que je pensais être bon il y a une décennie n'est plus aussi bon.
• Un «bon code» est un jugement de valeur. À part "ça marche", et il n'y a pas de bugs connus, tout autre critère pour un bon code est essentiellement une question d'opinion.

En fin de compte, je pense qu'il vaut mieux poursuivre mieux que de poursuivre "bien" ou "mieux". Si nous voyions le meilleur code, le reconnaîtrions-nous comme tel?

Pourquoi écrire un bon code est plus difficile?

Parce que les logiciels sont de plus en plus construits au-dessus des couches d'abstraction. Chaque nouvelle technologie qui prétend rendre le développement plus facile et plus rapide ne fait qu'ajouter un niveau de complexité supplémentaire qu'un développeur doit comprendre. Maintenant, ces abstractions peuvent avoir d'énormes avantages pour la productivité, mais si vous ne comprenez pas ce qu'elles tentent de cacher, cela rend le logiciel plus vulnérable aux bogues et de mauvaise qualité.

Un bon code est-il impossible dans le développement de logiciels modernes?

En effet, ce n'est pas possible. Mais pas pour l'une des raisons que vous avez déjà entendues.

La portée de la grande majorité des projets dépasse largement la capacité d'un cerveau humain. C'est pourquoi les gens ont eu l'idée de l' abstraction , c'est-à-dire garder les détails et grimper plus haut dans l'arbre d'abstraction jusqu'à ce que la densité des branches (quantité d'informations à gérer) diminue à un taux acceptable.

Nous l'avons fait, nous avons résolu le problème de complexité, mais cela n'a pas éliminé le problème plus vaste que nous avions auparavant.

C'est encore trop complexe à gérer pour nous.

Afin de créer une solution de haute qualité , nous devons être en mesure de voir en même temps et comprendre tout en même temps, qui est de tous les modules à un grand et tous les petits détails de mise en œuvre. Tout à la fois pour voir les écarts, voir chaque morceau de code dans le contexte de tous les scénarios possibles et optimiser la base de code entière en même temps.

Nous ne pourrons jamais le faire.

Et si nous ne pouvons pas, nous ne produirons jamais de code de qualité.

Les gestionnaires verront la dispersion des modules mais ne connaîtront pas les problèmes internes et les limitations par module.

Les programmeurs de modules connaîtront les limites locales mais ne pourront pas l'optimiser dans le contexte d'une image plus grande.

Il n'y a aucun moyen de communiquer la compréhension entre les gestionnaires et les programmeurs (et même entre les programmeurs). Et même s'il y en avait, la capacité du cerveau humain ne pouvait pas gérer cela.

Il n'y a pas grand-chose que nous puissions faire, sauf continuer à essayer (un exercice futile). Gardons simplement le code plus ou moins opérationnel et profitez de la vie.

Je nie la prémisse de votre question. Il est plus facile que jamais d'écrire du bon code, et à cause de cela, nous nous attaquons à des problèmes beaucoup plus difficiles que nous avons abordés auparavant.

Je ne veux pas choisir un fournisseur particulier, mais comparer Windows 1.0 à Windows 7. Ce dernier contient des milliers de fois plus de code, mais le temps moyen entre les plantages a été multiplié par cent. Nous étions censés pouvoir incorporer une feuille de calcul Excel dans un document Word depuis Windows 3.1, mais de nos jours, cela fonctionne plus ou moins.

Sans vouloir tomber dans la sentimentalité "Vous les enfants ces jours-ci avec votre typage de canard et votre VM", je dirais que vous n'avez aucune idée de la difficulté d'écrire du bon code dans les années 80: modèles de mémoire minuscules, petits et énormes, superpositions , appels OS non rentrants (frémissement). Bon débarras de tout ça.

Les applications modernes sont plus complexes qu'elles ne l'étaient il y a 20-30 ans, car leur environnement est plus riche et plus polyvalent.

Il était typique pour un programme DOS de s'asseoir dans une boucle étroite en attendant la prochaine pression de touche de l'utilisateur, puis d'appeler le code correspondant, et de revenir à l'attente de la prochaine pression de touche.

Toute application moderne où vous ne pouvez pas utiliser la souris pour TOUT, a un sérieux problème d'explication. Et les choses peuvent arriver dans n'importe quel ordre, car il est parfaitement possible pour l'utilisateur de taper, de cliquer avec la souris et de continuer à taper pendant que les flux RSS sont mis à jour dans l'application, montrant les dernières entrées à l'utilisateur pendant qu'il tape.

Toutes ces tâches multitâches sont intrinsèquement beaucoup plus complexes que lorsque vous ne deviez penser qu'aux clés de l'utilisateur. Cela rend plus difficile l'écriture d'un code vraiment bon.

Si tout va bien quand les chercheurs ont compris comment nous pouvons rendre les programmes multitâches plus utilisables du point de vue des développeurs, cela peut se détendre, mais pour l'instant nous sommes coincés avec tout le monde essayant de le faire bien, mais ne sachant pas vraiment comment le faire il.

Il me semble que le logiciel s'est étendu pour remplir la vitesse du processeur, la mémoire, le disque et le temps de programmation disponibles. On pourrait affirmer que c'est parce que le logiciel accomplit beaucoup plus. Eh bien, je suis sûr que cela en fait beaucoup plus, mais pas assez pour justifier le ballonnement.

Je pense qu'il y a une ancienne loi de la science qui mérite d'être rappelée:

La nature a horreur du vide.

François Rabelas (moine et satiriste français 1494-1553)

En fait, je pense qu'il est devenu plus facile d'écrire du bon code, c'est-à-dire des programmes qui fonctionnent comme prévu et sont maintenables, au cours de la dernière décennie. Les outils disponibles sont meilleurs maintenant, les bibliothèques sont plus matures et complètes, le matériel est devenu beaucoup plus rapide, nous n'avons donc pas besoin d'utiliser des astuces d'optimisation.

Alors pourquoi pas nous?

OMI, la raison principale est que nous cherchons constamment des moyens et des excuses pour abuser des choses. Au lieu d'aller à l'ancienne, facile, probablement ennuyeux, comme la création d'un exécutable Windows, nous repoussons les limites du possible et cherchons par exemple à recréer quelque chose comme PhotoShop en tant qu'application Web. Pourquoi? Parce que nous pouvons. Ou du moins nous le pensons.

À quand remonte la dernière fois que QUELQU'UN n'a pas écrit un exploit ou étudié pour le faire avec le montage (sans compter les pirates du noyau et les gars ASIC)? Combien de bogues ont été découverts dans les bibliothèques de base C? Presque aucun et quelques-uns. Tout ce que je dis, c'est que les gens sont capables d'un excellent code. De meilleurs outils et langues le rendent moins «requis» et plus «facultatif». Non pas que je pense que nous devrions tous écrire du code vraiment horrible, mais quand je pense à des constructions logiques compliquées ... personne n'aurait rêvé d'écrire quelque chose avec des tableaux de hachage en assembleur. Il devait y avoir une «meilleure» façon de gérer la logique au lieu d'utiliser une construction compliquée. Même si le code est beau, parfois l'approche n'est pas aussi élégante. Je pense que cela résout en quelque sorte le problème que vous avez mentionné. Un bon code n'est pas toujours organisé,

Je pense que c'est parce que de meilleurs outils et des ordinateurs plus réactifs et plus rapides signifient que nous nous attendons à obtenir beaucoup plus de temps final de complexité du produit que nous ne l'avons fait il y a quelques années (ou quelques décennies). Ainsi, la complexité des applications ne cesse d'augmenter, et nos hypothèses sur ce qu'est un niveau raisonnable de productivité ne cesse de croître.

Là où je travaille, les développeurs sont toujours pressés (car il y a toujours plus de choses que les clients voudraient alors qu'ils ont le temps). Ainsi, beaucoup de blocs de code sont copiés avec un minimum d'édition et sans effort pour vraiment les comprendre. Et bien sûr, des erreurs sont commises. Je viens de voir un bug corrigé, où un développeur avait copié du code que j'avais optimisé, sans se rendre compte que les hypothèses qui rendaient l'optimisation valide n'étaient pas vraies là où il le mettait.

Tout cela se résume aux attentes, à la fois internes (nos propres attentes) et de nos organisations. Nous essayons d'en faire autant que possible en un minimum de temps. Et il en résulte inévitablement des erreurs.

La réactivité de l'ordinateur encourage également une modification rapide et rapide, puis une compilation et un test. Dans l'ancien temps (comme il y a 35 ans), le délai d'exécution était si lent, que j'imprimais du code (la source était alors des cartes perforées) et faisais une étape manuelle du code avant de soumettre mon deck. Maintenant, nous éditons simplement compiler et exécuter. Donc, beaucoup de bogues que nous aurions repérés, via une procédure méthodique, nous comptons maintenant sur le compilateur et / ou la suite de tests unitaires pour les attraper à la place.

Comment les gens ont-ils empiré de produire un bon code?

Si vous prenez .NET et un langage comme C #, par exemple (et je sais que ce n'est pas la seule plate - forme / langue), je dirais que le codage bien est devenue beaucoup, beaucoup plus facile grâce à l'automatisation de beaucoup de choses dans le Visual Studio environnement.

Si quoi que ce soit, le simple fait que nous avons maintenant des IDE très sophistiqués capables de nous guider à travers le processus de codage et de développement rend le "bon code" plus facile à réaliser.

Les programmeurs peuvent désormais se concentrer sur la production d'une bonne structure au lieu de passer autant de temps à taper des crochets et des accolades et de nouvelles lignes et à se souvenir des appels de méthode et des noms de classe.

Mes deux centimes.

Oui, en tant qu'industrie, nous ne pratiquons pas ce que l'on sait être de bonnes méthodes. Référence: Low Hanging Fruit de Steve McConnell's Construx Software Software Development .

la qualité du code ne s'est pas améliorée

s'il vous plaît ne restez pas coincé dans l'interprétation de "bon code"

Grande tautologie logique.

Le code ne s'améliore pas parce que les gens continuent de déplacer la définition de «bon».

Si vous pouvez «discuter de« bon code », alors vous ne pouvez pas comparer et vous ne pouvez vraiment pas décider si c'est« un défi »ou non.