Le code scientifique est-il un domaine suffisamment différent pour ignorer les normes de codage communes?

Dernièrement, j'ai essayé de me faire une idée du fait suivant.

D'une part, il existe une multitude de directives et de normes de codage pour ce qui est considéré comme du code "sain", "propre", "bien écrit", etc. Voir le «Clean Code» qui semble également être largement discuté ici. Exemple de règle: méthodes longues de 7 lignes et 1 ou 2 niveaux d'indentation. Le code qui ne suit pas devrait en quelque sorte mourir d'une mauvaise maintenabilité.

D'un autre côté, je travaille avec OpenCV, OpenCascade, VTK, etc. C'est du code scientifique. Ils ont des méthodes de 2 pages (moi-même), OpenCascade a une méthode ou une classe divisée en 10 fichiers (pas de blagues ici), VTK est parfois un gâchis. Pourtant, ces projets prospèrent, sont maintenus et largement utilisés!

Où est le piège? Sommes-nous autorisés à écrire du code scientifique lourd en mathématiques de manière à ce qu'il fonctionne et à le maintenir? Y a-t-il un ensemble distinct de normes pour de tels projets, le cas échéant?

Cela peut être une question naïve, mais je suis dans ce qui semble être un vide de programmation essayant de créer un ensemble de règles sur la façon de faire et de ne pas faire les choses, c'est ainsi qu'on m'a appris à travailler au lycée. Depuis que j'ai obtenu mon diplôme, je n'ai presque pas de soutien pour les directives concernant les choses que j'ai dû faire, principalement la programmation - personne ne se soucie d'enseigner cela.

Le code scientifique est-il un domaine suffisamment différent pour ignorer les normes de codage communes?

Non ce n'est pas.

Le code de recherche est souvent «jeté» et écrit par des personnes qui ne sont pas des développeurs de formation, quelle que soit la solidité de leurs diplômes. Une partie du code de recherche que j'ai écrit me ferait pleurer . Mais ça a marché!

Une chose à considérer est que les gardiens des projets pilotent ce qui est inclus. Si un grand projet a commencé comme un projet de code académique / de recherche, finit par fonctionner et est maintenant un gâchis, quelqu'un doit prendre l'initiative de le refactoriser.

Il faut beaucoup de travail pour refactoriser le code existant qui ne pose pas de problème. Surtout s'il est spécifique à un domaine ou n'a pas de tests. Vous verrez qu'OpenCV dispose d'un guide de style très complet, même s'il n'est pas parfait. L'application rétroactive à tout le code existant? Ce n'est pas pour les faibles de cœur.

C'est encore plus difficile si tout ce code fonctionne. Parce que ce n'est pas cassé. Pourquoi le réparer?

Pourtant, ces projets prospèrent, sont maintenus et largement utilisés!

C'est la réponse, dans un sens. Le code de travail est toujours utile et il est donc plus probable qu'il soit maintenu.

Cela pourrait être un gâchis, surtout au début. Certains de ces projets ont probablement commencé comme un projet unique qui "n'aurait jamais besoin d'être réutilisé et pourrait être jeté".

Considérez également que si vous implémentez un algorithme complexe, il peut être plus judicieux d'avoir des méthodes plus importantes parce que vous (et d'autres familiers avec le côté scientifique) pouvez mieux comprendre conceptuellement l'algorithme. Mon travail de thèse était lié à l'optimisation. Avoir la logique de l'algorithme principal comme une méthode était considérablement plus facile à comprendre qu'il ne l'aurait été de la séparer. Cela a certainement violé la règle des «7 lignes par méthode» mais cela signifiait également qu'un autre chercheur pouvait consulter mon code et comprendre plus rapidement mes modifications de l'algorithme.

Si cette implémentation était abstraite et bien conçue, cette transparence serait perdue pour les non-programmeurs .

Aux autres répondeurs: Cette question se réfère à la base de code des bibliothèques open source pour les tâches de calcul intensif dans un ou plusieurs domaines scientifiques. Cette question ne concerne pas le code jetable. Veuillez vous arrêter un moment pour vous assurer de bien saisir tous les aspects mis en évidence avant d'écrire une réponse.

Je pense que les gens ont souvent cette idée que tous les projets open source commencent par, "hé j'ai une excellente idée pour une bibliothèque qui sera extrêmement populaire et utilisée par des milliers / millions d'autres" et ensuite chaque projet se passe comme ça.

La réalité est que de nombreux projets sont lancés et meurent. Un pourcentage ridiculement infime de projets "parviennent" au niveau d'OpenCV ou VTK etc.

OpenCV a commencé comme un projet de recherche d'Intel. Wikipedia le décrit comme faisant partie d'une "série de projets". Sa première version non bêta a été 2006, soit sept ans après son premier lancement . Je soupçonne que l'objectif initial était des versions bêta significatives, pas un code parfait.

De plus, la «propriété» d'OpenCV a considérablement changé. Cela fait changer les normes, à moins que toutes les parties responsables n'adoptent exactement les mêmes normes et ne les conservent pendant la durée du projet.

Je dois également souligner que OpenCV existait depuis plusieurs années avant la publication du Manifeste Agile dont Clean Code s'inspire (et VTK près de 10). VTK a été lancé 17 ans avant la publication de Clean Code (OpenCV n'était "que" 9 ans auparavant).

Les scientifiques ne sont pas des développeurs. Leur travail n'est pas d'écrire du code en soi. Leur travail consiste à résoudre les problèmes et la programmation n'est qu'un des outils qu'ils peuvent utiliser.

La plupart des codes d'entreprise écrits par - comme ils s'appelleraient eux-mêmes - des développeurs professionnels sont un gâchis. La plupart de ce code n'utilise pas de modèles de conception ou ne les utilise pas à mauvais escient. La plupart des commentaires sont des candidats pour TheDailyWTF . Donc, puisque dans notre propre industrie, nous voyons de tels résultats de personnes dont le travail consiste à écrire du code, qu'attendriez-vous de personnes dont le travail n'est pas d'écrire des programmes?

Est-ce que toutes les pratiques qu'un véritable développeur professionnel apprend au cours de sa carrière bénéficieraient à un scientifique? Absolument. Serait-il possible pour chaque scientifique de passer cinq à dix ans de sa vie à développer des logiciels d'apprentissage? Probablement pas. Par conséquent, la qualité du code est telle qu'elle est.

Un autre facteur est la culture. Si vos paires n'écrivent pas de code propre, pourquoi le feriez-vous? Puisque personne ne s'en soucie, vous n'êtes pas vraiment enclin à faire l'effort supplémentaire.

Enfin, la plupart des codes scientifiques ont une durée de vie relativement courte. Vous écrivez du code pour une recherche spécifique et lorsque la recherche est terminée, vous ne réutilisez pas le code. Une fois que vous avez cette habitude, il est difficile de faire la différence entre les bibliothèques réutilisables telles que celles que vous citez et le code jetable.

Ignorer? Non. Repenser et ajuster? Sûr. Beaucoup de code scientifique est intensif en mathématiques et critique en termes de performances. Des choses comme les frais généraux des appels de fonction peuvent en fait devenir un problème, vous pouvez donc vous retrouver avec des structures plus profondément imbriquées que celles que vous voyez dans une application commerciale typique. Cela ne signifie pas que vous devriez plonger tête première dans mille micro-optimisations. Vous devez toujours vous concentrer sur le choix du bon algorithme et ne faire que des optimisations dont vous pouvez mesurer l'effet.

Certaines des différences sont évidentes et insignifiantes. Les directives de codage exigeront généralement le choix de noms de variables significatifs et les noms à une seule lettre seront immédiatement suspects. Une application scientifique voudra toujours des noms de variables significatifs, mais parfois le nom le plus significatif sera une seule lettre, se référant à une variable dans une équation bien connue.

Toutes les réponses existantes ont couvert cette question de manière exhaustive. Cependant, je voudrais souligner quel est le véritable antipode entre les goûts d'OpenCV, etc., par opposition à un code développé selon les bonnes pratiques commerciales (Code Complete, Clean Code, SOLID, etc.)

En général, il y a beaucoup d'avantages commerciaux pour que le code source soit KISS - "restez simple, stupide". Il y a aussi un YAGNI - "Vous n'en aurez pas besoin".

Malheureusement, pour les logiciels à forte intensité de calcul dans les domaines scientifiques, le code source est rarement simple ou allégé .

Traditionnellement, OpenCV avait souffert d'un manque de généralisations (beaucoup de duplication de code pour prendre en charge différentes options), tandis que VTK avait souffert de généralisations excessives (modèles).

Au début, certaines parties d'OpenCV ont été initialement développées en C. Plus tard, OpenCV a adopté l'API C ++ que nous connaissons aujourd'hui. Certains algorithmes sont réécrits pour tirer parti des interfaces C ++ (classes de base abstraites) et des modèles C ++. D'autres algorithmes étaient simplement des wrappers pour le code C d'origine. Des restes de ces codes peuvent être trouvés éparpillés dans le module "imgproc".

OpenCV contient beaucoup de programmation SIMD (vectorisation). À ce jour, la programmation SIMD en C ++ nécessite toujours l'utilisation d' intrinsèques (intel.com) , (arm.com) .

Les intrinsèques SIMD se lisent comme un langage d'assemblage, sauf que le compilateur s'occupe de l'affectation des registres aux variables et que le compilateur a la liberté de permuter l'ordre des instructions pour des gains de performances. Les algorithmes écrits pour utiliser les intrinsèques SIMD avaient un coût de maintenance élevé. C'est la raison pour laquelle j'ai mentionné une question que j'ai posée plus tôt - Coût de maintenance de la base de code de programmation SIMD .

Une personne qui ne fait pas de programmation SIMD peut facilement être amenée à croire que SIMD peut être encapsulé avec élégance et qu'une programmation SIMD de bas niveau ne devrait plus être nécessaire. C'est en fait assez loin de la vérité. Je mets au défi quiconque d'essayer de mettre en œuvre un algorithme utile dans SIMD (pas les fractales) et de voir la difficulté d'utilisation de ces encapsulations proposées.

Voici une longue liste d'idées lorsque j'essaie d'analyser pourquoi un logiciel de calcul ne peut pas être KISS ou YAGNI. Cependant, toutes ces idées sont des généralisations excessives, et elles ne semblent pas soutenir l'observation ci-dessus.

Les principaux facteurs contributifs sont:

• Performances logicielles
• La nécessité de prendre en charge de nombreuses options d'algorithmes et compromis
• La nécessité de prendre en charge de nombreuses plates-formes matérielles et compilateurs différents
  • Cela aggrave le problème de performances logicielles - les performances doivent être bonnes pour de nombreuses plates-formes matérielles et compilateurs.
• Le manque de modernisation continue de la base de code , en raison du manque de ressources, du manque de personnes compétentes qui peuvent améliorer la qualité du code sans compromettre les autres facteurs, etc.
  • Les projets open source souffrent de la tragédie des communs .
  • Les projets open source qui reçoivent des subventions devaient répondre à des livrables spécifiques - la qualité du code n'en fait généralement pas partie.
  • En particulier, il y a même un manque de personnes compétentes qui peuvent apporter ou suggérer des améliorations incrémentielles de la qualité du code . Il s'agit du problème des "globes oculaires manquants" - de nombreuses personnes bénéficient du code, mais peu ont pris le temps de le lire.
• Manque historique de portes de qualité du code telles que la révision du code, les tests unitaires, l'analyse statique, etc.
  • Pour un projet à grande échelle, ces portes de qualité de code ne sont pas simplement des étapes manuelles - chacune nécessiterait une infrastructure (un système basé sur le Web, un système de test unitaire, un système d'automatisation de construction, etc.)

Plusieurs des facteurs contributifs ci-dessus sont des antipodes pour le développement de logiciels d'entreprise:

• En règle générale, les logiciels d'entreprise n'ont pas besoin de gérer les mêmes débits de données élevés que ceux des logiciels informatiques.
• Les logiciels d'entreprise peuvent être liés à un seul système d'exploitation et à une seule architecture informatique.
• Le logiciel d'entreprise peut être économe pour décider des fonctions à inclure. En fait, le développement de logiciels d'entreprise encourage les gestionnaires à dire non aux nouvelles fonctionnalités, sauf s'il existe une bonne analyse de rentabilisation.
  • Les utilisateurs de logiciels d'entreprise internes peuvent être formés pour faire les choses différemment, en évitant d'avoir à modifier le code.
  • Si un logiciel commercial perd un client en raison d'une fonction manquante, mais gagne deux nouveaux clients en raison d'une simplicité et d'une facilité d'utilisation améliorées (voir "Le paradoxe du choix" ), dans l'ensemble, c'est un gain net - c'est un bon chose que cette seule fonctionnalité est manquante.
• Les logiciels d'entreprise sont pris en charge par un flux de revenus continu, de sorte qu'ils peuvent se permettre d'en consacrer une partie à la modernisation continue de la base de code.

Le code scientifique est-il un domaine suffisamment différent pour ignorer les normes de codage communes?

Cela dépend de ce que vous appelez des "normes de codage communes". Je n'appellerais pas les extrêmes d'Agile «communs». En particulier, considérer une fonction de huit lignes comme trop longue, ou qui a plus de deux niveaux d'indentation pour être trop complexe sont des normes ridicules dans le domaine de la programmation numérique / scientifique.

Une fonction de matrice multipliée par matrice très simple comporte plus de sept lignes et possède trois niveaux d'indentation. La fonction deviendra considérablement plus complexe que cela si l'on se préoccupe de l'efficacité. Il s'agit d'une opération si courante que l'efficacité est importante. Le décomposer en morceaux est exactement ce que vous ne voulez pas faire. Une décomposition matricielle va être encore plus complexe.

J'ai décidé de poster ceci comme une nouvelle réponse car c'est une perspective complètement différente.

Jetons un coup d'œil à un exemple de code que je considère comme du "code propre" en termes de vision par ordinateur et de compréhension d'image:

https://github.com/opencv/opencv/blob/05b15943d6a42c99e5f921b7dbaa8323f3c042c6/modules/photo/src/sireless_cloning_impl.cpp

Pour ceux qui connaissent MATLAB et l'informatique scientifique, le code en C ++ est presque aussi concis que le code MATLAB le plus propre possible.

Maintenant, nous devons nous demander pourquoi la base de code de la bibliothèque entière (OpenCV dans cet exemple) n'est pas écrite selon la même norme que cet exemple de code?

Nous devons stratifier la base de code d'une grande bibliothèque scientifique en niveaux d'abstraction .

Au bas niveau , vous réimplémentez littéralement des ajouts et des soustractions. Ou, remappant littéralement chaque opération aux implémentations les plus rapides sur chaque plate-forme.

https://github.com/opencv/opencv/blob/master/modules/core/src/hal_replacement.hpp

Le niveau intermédiaire est l'endroit où nous trouvons le code "le plus sale", dans lequel peut-être 80% - 90% du temps d'exécution du processeur est dépensé. (De même, peut-être 80% à 90% des efforts de développement ont été dépensés au niveau intermédiaire, si nous comptons séparément les efforts de développement de logiciels de la recherche scientifique.)

Au niveau supérieur , nous avons le code le plus propre, écrit par des chercheurs.

Une forte excellence dans l'organisation du code source est nécessaire pour s'assurer que ces niveaux ne se mélangent pas. Cela va au - delà des normes de codage , plus a à voir avec l' intendance open source .

Par exemple, il est parfois décidé de diviser un projet open-source en deux. Vous ne pouvez pas faire en sorte que ces choses se produisent par des validations de code.