Pourquoi certains programmeurs pensent-ils qu'il existe un contraste entre théorie et pratique? [fermé]

En comparant génie logiciel et génie civil, j'ai été surpris d'observer une façon de penser différente: tout ingénieur civil sait que si vous voulez construire une petite hutte dans le jardin, vous pouvez simplement obtenir les matériaux et aller la construire, alors que si vous voulez construire une maison de 10 étages (ou quelque chose comme ça ), vous devez faire quelques calculs pour vous assurer qu’elle ne tombera pas en morceaux.

En revanche, en parlant avec certains programmeurs ou en lisant des blogs ou des forums, je trouve souvent une opinion largement répandue qui peut être formulée plus ou moins comme suit: la théorie et les méthodes formelles sont destinées aux mathématiciens / scientifiques, tandis que la programmation consiste davantage à faire avancer les choses .

Ce qui est normalement impliqué ici est que la programmation est quelque chose de très pratique et que même si les méthodes formelles, les mathématiques, la théorie de l’algorithme, les langages de programmation propres / cohérents, etc., peuvent être des sujets intéressants, ils ne sont souvent pas nécessaires si l’on veut simplement obtenir des résultats. fait .

Selon mon expérience, je dirais que même si vous avez besoin de peu de théorie pour assembler un script de 100 lignes (la cabane), afin de développer une application complexe (le bâtiment de 10 étages), vous avez besoin d'une conception structurée, ainsi -des méthodes définies, un bon langage de programmation, de bons manuels où vous pouvez rechercher des algorithmes, etc.

Donc, la théorie de l’ OMI (la bonne quantité) est l’un des outils pour faire avancer les choses .

Ma question est la suivante: pourquoi certains programmeurs pensent-ils qu’il existe un contraste entre la théorie (méthodes formelles) et la pratique (faire avancer les choses)?

L'ingénierie logicielle (logiciels de construction) est-elle perçue par beaucoup comme facile, comparée au génie civil (construction de maisons)?

Ou bien ces deux disciplines sont-elles vraiment différentes (à part les logiciels critiques, les échecs logiciels sont beaucoup plus acceptables que les échecs de construction)?

J'essaie de résumer ce que j'ai compris des réponses jusqu'à présent.

1. Contrairement au génie logiciel, en génie civil, la quantité de théorie nécessaire (modélisation, conception) est nécessaire pour une tâche donnée.
2. Cela est dû en partie au fait que le génie civil est aussi vieux que l’humanité alors que le génie logiciel n’existe que depuis quelques décennies.
3. Une autre raison est le fait que le logiciel est un type d'artefact plus volatil, avec des exigences plus souples (il peut être autorisé à planter), des stratégies de marketing différentes (un bon design peut être sacrifié pour le mettre rapidement sur le marché), etc.

En conséquence, il est beaucoup plus difficile de déterminer quelle est la bonne quantité de conception / théorie appropriée en génie logiciel (trop peu -> code en désordre, trop -> je ne peux jamais avoir fini) car il n’ya pas de règle générale et seulement (beaucoup) d'expérience peut aider.

Donc, si j’interprète correctement vos réponses, cette incertitude sur le besoin réel de théorie contribue à la confusion des sentiments amour / haine de certains programmeurs.

Je pense que la différence principale réside dans le fait que, dans le génie civil, la physique du monde réel agit comme une vérification de la réalité constante et puissante, qui maintient la théorie saine et limite également les mauvaises pratiques, tandis que dans le génie logiciel, il n’existe pas non plus de force aussi forte pour conserver des concepts impraticables de tours d’ivoire. comme un travail de mauvaise qualité en échec.

De nombreux programmeurs ont eu de mauvaises expériences avec la théorie des emballements qui est devenue un obstacle actif à la réalisation de tâches (par exemple, "UML exécutable", processus de développement super bureaucratiques). Inversement, des hacks et des correctifs sales peuvent vous mener assez loin, bien que lentement au final. Et comme vous le constatez dans votre dernier paragraphe: les échecs ne sont généralement pas aussi définitifs et donc moins problématiques.

Le génie logiciel et le génie civil ont peu de points communs. Les efforts de génie civil sont limités par les propriétés physiques de leurs matériaux et de l'environnement. Les ingénieurs civils passent beaucoup de temps à étudier les propriétés du sol et les caractéristiques des matériaux. Le développement logiciel n’est limité physiquement que par la vitesse des processeurs et le stockage disponible. Les deux sont faciles à comprendre et nous ne prenons pas beaucoup de temps pour les étudier. La principale limite au développement de logiciels est l'intellect humain. Et il n'y a pas deux développeurs identiques. Ce code est-il maintenable? Par qui? Une mise en œuvre de quicksort sur trois lignes en Haskell peut être évidemment correcte pour certains, mais incompréhensible pour d'autres. Une équipe de deux peut remplir une demande en un mois, tandis qu'une autre équipe de dix a du mal à répondre en un an.

Le développement logiciel est entièrement conçu, les artefacts conçus sont des ordres de grandeur plus complexes que n'importe quel article fabriqué, et chacun est unique.

En tant qu'ingénieur en mécanique plus ou moins honnête (avec un certain civil) devenu programmeur, puis doctorat en CS (AI), puis enseignant, puis programmeur à nouveau (excusez-moi, ingénieur en logiciel ), j'ai un coup de gueule ce sujet général.

En ingénierie traditionnelle

• tu dois connaître tes maths et tes sciences parce que tout ce que tu fais est basé dessus
• les "héros" sur le terrain sont des personnes qui inventent de nouvelles choses, découvrent de nouvelles idées, résolvent des problèmes considérés comme insolubles

Il existe une "physique" qui s'applique aux logiciels: la théorie de l'information, mais les ingénieurs en logiciels y sont peu exposés, et rien ne s'applique certainement. La théorie qu'ils obtiennent est la calculabilité et le big-O.

De plus, je suis toujours émerveillé par les personnes qui pensent que connaître la programmation est suffisant et qui n'ont pas besoin de comprendre le sujet de leurs programmes.

De plus, l'inventivité n'est pas encouragée. Il est déconseillé, en faveur des méthodes de pensée de groupe du plus petit dénominateur commun, déguisées en "lisibilité". (Imaginez si les ingénieurs aéronautiques ou nucléaires étaient encouragés à ne rien faire qui puisse être difficile à comprendre pour leurs pairs plus jeunes.)

Les choses qu’ils apprennent, comme la programmation d’applications Web, ont une grande valeur. Il en va de même pour les compétences d'un plombier ou d'un électricien, mais ce n'est pas de l'ingénierie.

Si je coupe un coin de la plupart des logiciels et que je fais quelque chose qui n’est pas la meilleure conception, mais que le travail sera fait, personne ne mourra. C'est la même raison pour laquelle une cabane dans le jardin n'a pas besoin des mêmes normes qu'un bâtiment de 10 étages. Cependant, je peux créer une très grosse application comme Facebook, et si elle perd quelques données ou quoi que ce soit, ce n'est pas vraiment un gros problème. Il est également plus simple de réparer les fondations d'une grande application après coup que de remplacer celles d'un bâtiment de 10 étages. Tout se résume au contexte et au calcul du risque.

Je peux aussi, en toute sécurité et simplement continuer à ajouter à une application. Vous ne pouvez pas facilement jeter dans un nouveau troisième étage d'un bâtiment de 10 étages (ce qui en fait 11). Je peux ajouter chaque jour une nouvelle fonctionnalité à une grande application si je le souhaite.

Maintenant, un bon design facilite tout cela en programmation. Mais ce n'est pas impossible avec une mauvaise conception, et les risques sont ... des logiciels bogués. Pas habituellement la mort.

Ours avec moi sur celui-ci. J'ai un point.

Un professeur m'a dit une fois que la procrastination conduisait à la procrastination, même si la plupart des gens, après une nuit d'écriture / de bachotage / de programmation sur papier, se disent: "Je ne referai jamais cela. La prochaine fois, je commencerai tôt. et se faire tôt. " Dans mon expérience en tant que procrastinateur accompli, j'ai trouvé que c'était vrai, et voici l'explication du professeur: pourquoi, même si l'expérience de la procrastination est désagréable, dans la plupart des cas, vous réussissez relativement bien. C'est un comportement à haut risque / récompense élevée. Au bout d'un moment, vous oubliez tout le désagrément et ne vous souvenez plus que de la récompense. Ainsi, la prochaine tentation de procrastiner est d'autant plus séduisante que vous avez réussi la dernière fois.

Je pense qu'une analogie peut être faite ici avec la technique de programmation "faire les choses" que nous voyons trop souvent. Un programmeur ou une équipe de programmeurs, peut-être par ignorance, paresse ou peut-être par une véritable contrainte de temps, adopte l'approche "faire avancer les choses" en matière de programmation, en jetant toute votre théorie, vos maths et vos bonnes pratiques par la fenêtre. Et tu sais quoi? Ils obtiennent des résultats. Ce n'est pas élégant, joli, ou maintenable, mais ça fait le travail. Peut-être qu'un supérieur non technique qui ne connaît pas le point-virgule d'un sémaphore leur fait l'éloge de "faire avancer les choses". Ainsi, la prochaine fois que le programmeur est tenté d’adopter cette approche lâche en matière de programmation, c’est d’autant plus facile, car c’est la dernière fois que cela a fonctionné. C'est la solution "facile", à moins que vous ne soyez pauvres,

J'ai été cette pauvre âme malheureuse, et beaucoup d'entre vous probablement. Je vous implore tous. Ne prenez pas la solution de facilité! :)

Votre prémisse est imparfaite. La principale raison pour laquelle les ingénieurs civils utilisent l'ingénierie lors de la conception de grands bâtiments, ponts, tunnels, etc., est de s'assurer qu'ils utilisent une quantité minimale de matériau (béton, acier de construction, etc.) répondant aux normes de sécurité requises. Il est tout à fait possible de construire un bâtiment de grande hauteur sans trop de difficultés en mathématiques (par exemple, les pyramides des civilisations égyptienne et maya), si les coûts de la matière et du travail ne sont pas un objet, mais une fois construits, il est généralement inutile de modifier leur faire utiliser le matériel plus efficacement.

Il existe une dynamique quelque peu différente dans la conception de grands systèmes logiciels. En fait, ils sont généralement sous-conçus, mais cela est dû au fait que la conception peut être modifiée de manière dynamique au fur et à mesure des travaux, ce qui est tout simplement impossible avec des projets de génie civil.

Le facteur commun est le coût. Concevoir sur un projet de génie civil traditionnel réduit les coûts (réels, en termes de matériaux et de potentiel, en termes de responsabilité), alors qu'il arrive un moment dans le développement logiciel où le coût de la conception augmente au-delà de la valeur retournée.

Je voudrais également souligner, en plus de plusieurs autres excellentes réponses, que l'humanité a fait l'équivalent du "génie civil" depuis le temps des Egyptiens. Nous avons donc eu beaucoup de temps pour perfectionner la théorie générale de la manière dont les choses devraient se dérouler. être terminé. Nous construisons des logiciels depuis environ 70 ans (selon ce que vous considérez comme le premier "logiciel"); Je veux dire que nous n'avons pas eu le même temps pour développer le même type d'expérience.

Les plans d'un architecte / ingénieur civil ne sont pratiquement jamais identiques aux plans "tel que construit". Quelque chose change TOUJOURS. Pourquoi? Parce qu'il y a et qu'il y aura toujours des "inconnus inconnus". Il y a des choses que vous savez et que vous pouvez donc planifier, des choses que vous savez être inconnues et vous pouvez donc effectuer des recherches et des estimations, puis il y a des choses que vous ne savez pas que vous ne connaissez pas; "surprises". Vous voulez éliminer ces problèmes dans la plupart des systèmes en apprenant tout ce que vous pouvez, mais il suffit d’une petite violation du code du bâtiment (qui peut être basée sur une règle qui n’existait pas il ya 2 ans lorsque votre bâtiment était en cours de conceptualisation). - Le plan directeur doit évoluer, parfois de manière drastique.

Le logiciel ressemble beaucoup à ceci; il y a toujours un inconnu inconnu. Cependant, contrairement à l'ingénierie civile ou structurelle, le développement logiciel est intrinsèquement beaucoup plus tolérant vis-à-vis des changements, en fonction des problèmes créés par les inconnus. Si vous construisez un bâtiment de 10 étages et que vous surestimez la capacité portante de la fondation que vous mettez dans votre conception, vous ne pouvez pas construire le bâtiment à 10 étages ou vous devez effectuer beaucoup de travail. Revenez à la base et renforcez-la ou reconstruisez-la. Toutefois, dans le logiciel, si vous avez sous-estimé les exigences imposées à un niveau particulier de la structure de la solution globale, de nombreuses options de correction de ce niveau n’impliquent pas l’invalidation de tous les autres travaux. Vous pouvez remplacer un serveur de base de données par un serveur plus puissant, ou un cluster de réplication / basculement, ou un cluster d'équilibrage de charge / distribué. Même chose pour le serveur web. Si vous avez codé un algorithme inefficace mais simple basé sur des hypothèses de taille d’entrée erronées, vous pouvez presque toujours simplement supprimer et réécrire l’implémentation de manière relativement chirurgicale, sans affecter les autres codes connaissant l’algorithme (appels et passants). ou en attend un résultat).

Cette relative facilité de changement permet à un ingénieur logiciel de coder en fonction de ce qu'il sait sans trop se soucier de ce qu'il ne sait pas. Cela permet une application plus souple de la théorie et une conception conceptuelle initiale; vous plongez dedans et le faites, et en cours de route, vous trouvez et changez les éléments que vous avez codés qui doivent être modifiés. Vous devez toujours connaître les concepts et la théorie, car lorsqu'un problème est découvert, ce sont ces éléments qui vous aideront à identifier la cause et à trouver une solution. Mais vous êtes autorisé à prendre une décision rapide sans succomber à la "paralysie de l'analyse", car s'il s'avère que vous avez pris la mauvaise décision en vous basant sur quelque chose que vous ne saviez pas ou qui n'avait pas pris en compte vos "calculs", l'erreur est plus facile à corriger.

La différence tient principalement aux exigences connues:

• Sur le plan théorique, tout est défini d’emblée, vous pouvez donc savoir exactement ce dont vous avez besoin avant de commencer.
• En pratique, ils ne sont souvent pas tous présents, ou vous découvrez quelque chose au milieu de la mise en œuvre qui vous oblige à redéfinir quelque chose. Il est donc préférable de sauter avec des conceptions au moins rudimentaires afin de pouvoir découvrir ces problèmes très tôt.

De plus, quand on parle de "théorie", cela signifie généralement le côté théorique de l'informatique, plutôt que le génie logiciel. C'est la partie de l'informatique qui consiste principalement à trouver des algorithmes meilleurs et plus efficaces, à démontrer si quelque chose est possible ou non (P et NP, par exemple), etc. Bien qu'il soit bon de les avoir à l'esprit, cela ne se produit pas souvent dans le développement de logiciels.

Nous utilisons les bibliothèques pour ce genre de choses autant que possible.

En fait, il existe plusieurs niveaux d'ingénierie logicielle en fonction de ce que le logiciel que vous construisez est en train de faire.

La NASA a besoin d'un logiciel pour contrôler les navettes habitées dans l'espace. Le processus d'ingénierie est donc naturellement beaucoup plus strict que celui de la création d'un site Web permettant d'afficher des images de fusées.

L'un de mes collègues qui travaillait pour la NASA a précédemment décrit son processus d'ingénierie logicielle comme écrivant des centaines de pages de justification et des centaines d'heures de réunions pour justifier l'écriture d'une seule ligne de code!

Ne me comprenez pas mal car je n'essaie pas de paraître irrespectueux quand je dis cela, mais même après tout ce coût en temps, en ressources et en milliards de dollars, la navette spatiale a encore explosé.

Même les ingénieurs civils savent que, quelle que soit la théorie qu’ils mettent dans une conception, quelque chose finira par la briser, ils doivent également élaborer des plans d’urgence.

Lors de la création d'un logiciel, le coût de son crash entraîne rarement la perte de vies humaines. Il est donc beaucoup plus facile de lancer rapidement des éléments et de les tester. Convenons que faire les choses rapidement donne un code faible. Même si c'est toujours le cas, voir un logiciel en action est le meilleur moyen pour un développeur de voir où il est faible et doit être rendu plus fort par rapport à où il est faible et encore bien plus fort qu'il ne le faut pour rester à la hauteur. la charge.

Pour résumer, Premature optimization is the root of all evil ou comme dirait toujours mon patronShipping is a feature!

Beaucoup de bonnes réponses ici, mais je pense que la comparaison entre l'informatique et le génie civil est imparfaite.

Strictement parlant, ce que font les développeurs de logiciels professionnels s'apparente davantage à l'ingénierie logicielle qu'à l'informatique. Une meilleure analogie est que l'informatique est la physique du génie logiciel. De même, Civil Engieering est un recueil de simplifications et d'approximations de la physique pour des travaux pratiques.

J'imagine que les ingénieurs civils doivent rarement prendre en compte la relativité générale dans l'exercice de leurs fonctions. Une grande partie du génie civil peut être construite en toute sécurité dans la mécanique newtonienne. De même, le génie logiciel peut être réalisé avec beaucoup de succès avec une compréhension approximative approximative de l'informatique théorique.

La grande différence est que les ponts, les gratte-ciel et les autres produits de génie civil sont relativement bien compris. Les ingénieurs en logiciel construisent souvent de nouvelles constructions ou utilisent de nouvelles méthodes pour construire des choses bien comprises. Le génie logiciel est FAR moins matures que le génie civil, et cela continuera vraisemblablement dans un avenir prévisible.

TL; DR : La théorie et la pratique sont différentes en génie logiciel, comme partout ailleurs. La bonne analogie est Génie logiciel: Génie civil :: Informatique: Physique. Mais en pratique, c'est un peu plus complexe que ça :)

Ma question est donc la suivante: pourquoi certains programmeurs pensent-ils qu’il existe un contraste entre la théorie (méthodes formelles) et la pratique (faire avancer les choses)?

Le logiciel de construction est différent de la construction d'un pont. Dans le logiciel, il y a beaucoup d'objets à construire qui peuvent être définis ou non au début. Des normes existent pour accroître la facilité de maintenance et la collaboration des développeurs, et non pour adhérer à des formules mathématiques arbitraires ou à d'autres idéaux de ce type. Par exemple, lors de la sélection d'un comportement basé sur une variable, il est parfois judicieux d'utiliser un commutateur, parfois un modèle d'usine. Cela dépend de la facilité de maintenance et des points de douleur identifiés tels que les problèmes de performances.

Un autre exemple peut être fait avec la manipulation de données. Il est souvent utile d’utiliser des délégués dans le contexte de .NET. Ce n’est pas si facile en Java car il n’a pas le support du framework pour le style de programmation fonctionnel que possède .NET. En d'autres termes, dans le cas général, il n'est tout simplement pas possible de faire X dans la situation Y. Cela est dû au fait que X et Y dépendent de N nombre de facteurs variables.

L'ingénierie logicielle (logiciels de construction) est-elle perçue par beaucoup comme facile, comparée au génie civil (construction de maisons)?

Je ne suis pas sûr que «facile» soit le terme correct. Un manque de preuves tangibles peut donner l’impression qu’aucun travail n’est accompli. De même, le travail existant est facilement modifié.

Ou bien ces deux disciplines sont-elles vraiment différentes (à part les logiciels critiques, les échecs logiciels sont beaucoup plus acceptables que les échecs de construction)?

L'ingénierie traditionnelle et l'ingénierie logicielle sont très différentes pour les raisons que j'ai déjà mentionnées.

Votre perception peut être fausse ici, ou bien elle inclut de nombreuses ressources de personnes qui n’ont pas écrit de logiciels suffisamment complexes.

Votre expérience va dans le sens de ce que la plupart des personnes que je connais (qui ont conçu et écrit un logiciel suffisamment complexe) diraient.

Cela dit, quand il s’agit pour la plupart des programmeurs , lorsque la tâche d’écrire leur arrive quelque chose, le design ("le calcul" comme vous le dites) a déjà été fait par l’architecte / lead / etc. avant que la tâche d'écrire ne leur parvienne. Cela peut donc apparaître ainsi depuis le niveau de première ligne.

Je pense que la raison de ce contraste est que le cycle de vie d’un projet logiciel et d’un projet matériel ou architecture est différent. La plupart des logiciels évoluent progressivement, cela n’est pas prévu du début à la fin. Les développeurs de logiciels peuvent appliquer une approche itérative au développement: planifier, mettre en œuvre et écouter les commentaires. Si le retour est positif, continuez, ça ne va pas - prenez du recul et réexaminez votre stratégie. C'est pourquoi les développeurs de logiciels ont des choses comme le développement agile, un produit minimum viable, etc.

Les ingénieurs civils n'ont pas ce luxe. Pour eux, une fois que quelque chose est planifié, vous ne pouvez plus le changer aussi facilement qu'avec un logiciel, car le coût de tels changements peut être énorme. Par contre, pour le développement de logiciels, cela ne coûte pas très cher et cela peut être utilisé à leur avantage.

Mais toutes les branches du développement logiciel ne peuvent pas se permettre une telle approche. La création de logiciels, par exemple, pour l'aviation ou les services médicaux nécessite une planification très minutieuse et de nombreux calculs préalables.

Cela me semble pareil. Vous construisez un grand bâtiment à partir de blocs standard, de béton à résistance standard, d'acier standard. Vous construisez une grosse application à partir de bibliothèques standard.

Vous n'essayez pas de prouver mathématiquement formellement une application volumineuse correcte de la même manière que vous n'essayez pas d'écrire la fonction d'onde pour un bâtiment de 100 étages.

J'étais ingénieur en mécanique et en fabrication avant de découvrir, il y a une vingtaine d'années, que mes aptitudes reposaient sur le logiciel. Je sympathise avec beaucoup des éléments que vous avez présentés.

Je soupçonne que la vraie nature du problème réside dans la manière dont nous réalisons les choses. Nous avons maintenant une dizaine d'années de développement agile sous notre ceinture collective, et le message est clair. Ne progresse pas par couches; progrès par fonctionnalités. Bien sûr, il y aura des projets lorsque vous aurez besoin de progresser par couches (par exemple, construisez votre pile réseau avant votre serveur Web), mais pour la grande majorité des projets du monde réel, nous avons appris une fois, c’est beaucoup plus efficace de construire d’énormes théories non vérifiées, puis d’essayer de les appliquer.

Alors prenons votre exemple de cabane (je parle habituellement de faire un pont en lançant une bûche à travers un ruisseau plutôt qu’un pont suspendu d’un kilomètre de long ... peu importe!) Et introduisons-le dans le monde du génie logiciel. La principale différence que je vois est que dans le logiciel, la majeure partie du travail a une envergure telle qu’elle n’a pas besoin d’une grande modélisation en amont pour réussir. L'erreur du débutant est souvent de supposer que les choses ont besoin de plus que cela, et pour la plupart d'entre nous, après avoir commis cette erreur à quelques reprises, nous nous efforçons de le répéter trop souvent.

Aucun argument - il y a des projets qui doivent commencer avec un comité de 17 architectes de logiciels. En vérité, ils sont aussi rares que les diamants de 20 carats.

Je pense que l'analogie est imparfaite. Autant que je sache, le génie civil n'a pas le même fondement théorique que l'informatique; l'informatique est née des mathématiques théoriques, comme les machines de Turing. Le génie civil consiste à créer des structures résistantes à la nature et peut-être même superbes. Encore une fois, je ne connais vraiment pas grand chose au génie civil, mais je ne pense pas qu'il existe des équivalents d'ingénieur civil de P vs NP, du vendeur itinérant et d'autres choses amusantes contre lesquelles vous battre. Et notre théorie informatique a définitivement sa place: si quelqu'un résout le problème du vendeur itinérant ou du problème persistant, nous sommes confrontés à de nombreuses avancées incroyables. Mais pour un ingénieur en logiciel, dont le métier est de concevoir des logiciels, de tels problèmes ne sont en réalité que des jeux et du plaisir.

Maintenant, je pense aussi que cela dépend de ce que vous entendez par "théorie". Parlons-nous des modèles de conception ou pompons-nous le lemme? Parce qu’être un bon ingénieur en logiciel, il est absolument essentiel de bien comprendre les modèles de conception. Cependant, lors de l’architecture d’un système logiciel volumineux, il n’est pas utile de théoriser sur les problèmes P / NP. En ce sens, je pense qu’il existe un contraste frappant entre le génie logiciel et l’informatique théorique.

Ou bien la théorie se réfère-t-elle à des algorithmes? Vous ne dépensez pas beaucoup d'algorithmes d'écriture de synchronisation que vous avez appris dans votre classe d'algorithmes. Pourquoi? Parce que vous n’avez généralement besoin d’eux que dans des cas particuliers (et ensuite vous le recherchez et le recherchez), ou vous utilisez une bibliothèque déjà écrite pour vous. Pas besoin d'écrire un autre classifieur bayésien. L'abstraction est un principe important en informatique. Je pense que les ingénieurs en logiciel ont tendance à ne pas apprendre le fonctionnement d'un algorithme tant qu'ils n'en ont pas besoin.

Une autre raison est qu’il existe actuellement plusieurs méthodes de développement de logiciels populaires, efficaces. Par exemple, dans le développement agile, vous n’archivez pas au préalable un système entier. La raison en est que vous ne savez pas encore exactement ce que vous construisez. Vous souhaitez que vos réalisations soient flexibles et s'adaptent aux nouvelles informations et exigences. Tout concevoir dès le départ, puis la construction qui ne produit pas toujours le meilleur logiciel. Cependant, ce n'est pas la solution pour tout. Par exemple, imaginons que vous concevez une chose folle-nouvelle en matière d’informatique distribuée. Vous ne pouvez pas faire de croquis de serviette et lancer votre SCRUM.

TL; DR. Je pense qu'il y a une équivoque autour du mot "théorie". Traditionnellement, la théorie fait référence aux aspects mathématiques théoriques de l’informatique. À moins que vous ne cherchiez de nouvelles méthodes d’informatique, l’informatique théorique n’a généralement pas d’importance dans la vie quotidienne d’un ingénieur en logiciel. Les ingénieurs en logiciel se soucient des modèles de conception et de l'architecture système. Les détails de mise en œuvre spécifiques de certains algorithmes ne sont pas importants. Souvent, avec des idées moins compliquées, il convient de ne pas concevoir beaucoup et de commencer simplement à coder. Et je pense que c'est de là que vient l'idée que les programmeurs n'aiment pas la théorie.

L'écart entre la théorie et la pratique est trop grand pour le moment. En faisant de la théorie, on vous donne trois axiomes et il est ensuite montré qu'un théorème à une ligne a une preuve de mille pages, voire aucune preuve. En génie logiciel, des API incohérentes comportant des milliers de fonctions vous sont attribuées, ce qui vous donne une myriade de (mauvaises) méthodes pour implémenter une fonctionnalité sous-spécifiée.

Une véritable ingénierie logicielle rendrait fous la plupart de ceux qui travaillent dans le secteur formel et un véritable développement de logiciels mathématiques rend fous ceux qui travaillent dans l'ingénierie. Les deux domaines exigent des personnes d'aptitudes différentes, et je ne pense pas que les aptitudes se chevauchent souvent.

La théorie formelle suppose que vous pouvez tout planifier à l’avance avec précision, comme un produit fabriqué, que les logiciels existeront indéfiniment dans le même environnement et que la solution d’un problème abstrait général est toujours le but recherché. Cela suppose un cycle de vie logiciel 4D en tant que produit: concevoir, développer, déployer, faire. La théorie formelle consiste à résoudre le problème de la conception de logiciels en utilisant l'analyse, l'abstraction, la généralisation et la prévision des changements futurs. C'est bien si vous avez un problème bien défini dans un domaine simple, facilement analysable, prévisible et relativement statique.

La programmation pratique consiste à résoudre le bon problème (pas celui de la conception de logiciel) de la bonne manière pour que vos collègues puissent faire leur travail mieux / plus vite / du tout, ou que des revenus puissent être versés à l'entreprise. La plupart des logiciels ne sont pas comme un produit, jamais "réalisés", mais plutôt comme un être vivant, hautement spécialisé pour une niche écologique donnée, et pouvant avoir une durée de vie très variable au cours de laquelle il est nécessaire de résoudre de nouveaux problèmes imprévus. grande variété d'environnements en constante évolution. Dans le monde des affaires, avec la politique et la légalité, la concurrence et les organisations, structures et tendances en constante évolution, les exigences sont souvent ambiguës, compliquées par toutes sortes de cas particuliers, mal définies et sujettes à de rapides changements inattendus. Ils ne sont pas analysables, prévisibles ou statiques, et souvent pas logique ou raisonnable. Le logiciel est tout aussi susceptible de ne plus être utile dans deux semaines que d’être encore utilisé dans 20 ans. Il vient au monde sans trop savoir ou trop peu savoir et doit être nourri, formé et formé tout au long de sa vie pour devenir fort, flexible et capable de s'adapter à ses environnements en constante évolution et à de nouveaux problèmes. Si vous le négligez après la naissance, il deviendra sauvage s'il survit assez longtemps et provoque la douleur et la souffrance en résolvant les problèmes avec une force contondante.

La théorie formelle ne répond pas aux besoins de nombreux logiciels de gestion du monde réel. Cela nous amène à croire que les logiciels peuvent être conçus et réalisés. Qu'il s'agisse d'un produit qui peut être réparé ou poli de temps à autre, mais pas d'un élément vivant qui doit être correctement élevé avec soin et attention tout au long de sa vie. Nous nous retrouvons donc avec un code héritage vraiment vilain, mais la théorie formelle n’aurait probablement pas été utile.

Tout cela semble assez négatif, mais en réalité, j'adore utiliser la théorie formelle. Un beau design me fait toujours sourire. Cependant, c'est principalement dans ma programmation amateur que les entreprises ne sont pas soumises aux vicissitudes. Au travail, je m'occupe principalement de code biologique et espère pouvoir lui accorder suffisamment d’attention pour qu’il grandisse correctement, me rende fier et ne soit pas odieux et impoli avec ceux qui doivent le gérer.

Les enjeux sont moins importants, le travail est plus facile et la direction voit rarement la valeur d'un bon design. L’instabilité, la maintenabilité et l’intégrité du système constituent un problème «informatique» et non un problème «professionnel». Tous les cadres ont une chose en commun. Ils sont soit concentrés à 95% sur l'argent, ou ils relèvent de quelqu'un qui l'est.

Le reste de la bataille est avec vos collègues programmeurs. Beaucoup d’entre eux ne peuvent ou ne veulent pas s’engager à penser à un problème avant que le codage ne commence. En raison de ce qui précède, bon nombre de ces personnes sont des développeurs expérimentés, ce qui rend encore plus difficile la mise en production d’une bonne conception.

J'ai vu des chefs de projet perdre des années à ajouter des fonctionnalités ad-hoc et des correctifs à des projets qui étaient initialement difficiles, puis abattre toutes les tentatives visant à mettre de l'ordre dans le chaos avec des phrases telles que "trop ​​compliqué" ou "perdre du temps". Il n’est pas agréable d’assister à une inévitable catastrophe qui pèse sur un projet majeur car la direction n’admettra pas qu’elle construit sa propre prison au quotidien; Cependant, je crains que ce ne soit une réalité regrettable dont de nombreux développeurs ont été témoins et - pour le meilleur ou pour le pire - tirés de l'expérience.

J'essaie de trouver un support dans mon travail. Je n'écris pas plus de code dans les projets "contaminés" qu'il n'est absolument nécessaire, et je saisis toutes les occasions possibles pour en extraire les fonctionnalités . "Entre projets", je consacre du temps à la conception et au nettoyage des projets que je contrôle réellement.

En fin de compte, c'est un grand gâchis de politique et d'intégrité personnelle que 75% des programmeurs du monde n'ont pas l'estomac. Je peux à peine le supporter moi-même.

Tout d'abord, j'adore cette question. J'ai écrit environ trois mille mots et ils avaient tous horriblement tort au moment où j'ai fini.

Je pense que le problème de la comparaison des deux comme étant analogue est que la programmation est un processus de modélisation qui peut être aussi abstrait que étroitement lié au concret que vous voulez.

La théorie de l'ingénierie structurelle, en revanche, est étroitement liée à des ensembles très spécifiques de lois fondées sur la réalité auxquelles vous devez vous conformer. Vous ne pouvez pas simplement modifier le contexte ou les lois. Le problème lui-même est enraciné dans ces lois. En programmation, cependant, parfois, la solution modifie réellement la nature de la question ou la place simplement dans un contexte différent.

Si le modèle MVC, par exemple, est un ajustement parfait, cela a beaucoup à voir avec ce contexte. Une application de bureau utilise généralement une seule langue et une seule langue, sans compter les fichiers de configuration.

Le front-end d'une application Web, quant à lui, consiste principalement en deux langages déclaratifs (sans programmation) et JavaScript. La seule chose physique à laquelle vous ne pouvez pas totalement faire abstraction est le fait qu’il existe toujours ce mur HTTP pour jeter les objets entre serveur et navigateur. Quelle que soit la manière dont vous l'enfouissez dans le code, cela prend du temps et une conception asynchrone.

Évidemment, vous ne pouvez pas utiliser un modèle populaire et bien considéré, tel que MVC, pour traiter exclusivement les problèmes frontaux sur le Web sans modifier la façon dont vous pourriez le gérer dans un contexte d'application de bureau. En fait, je dirais que vous devriez savoir ce qui rend MVC utile mais ne pas même essayer de le mettre en œuvre de manière particulièrement exigeante ou globale. Le paradigme des applications Web est unique en ce que tous les éléments qui me ressemblent sont gérés par le navigateur de l'utilisateur et que tous les éléments relatifs aux données et aux modèles se trouvent généralement quelque part sur le serveur. Mais où cela laisse-t-il le contrôleur? Tout sur le serveur ou tout sur le front-end? Quelqu'un doit le savoir. Ou peut-être que MVC n'est pas à 100% la meilleure solution pour le scénario. Ce n’est pas mal adapté aux projets de back-office .NET Pas terrible dans le contexte de widgets d'interface utilisateur spécifiques.

Construire une maison résout un problème. Cependant, les problèmes de programmation classiques impliquent souvent la résolution de problèmes au sein de problèmes et parfois, la solution consiste à redéfinir le problème externe. La réalité ne tient pas particulièrement à cette idée, malheureusement.

Glenn Vanderburg présente un excellent point de vue sur les différences entre le génie logiciel et les disciplines plus traditionnelles du génie: http://www.youtube.com/watch?v=NP9AIUT9nos

Si un ingénieur civil pouvait tester ses conceptions sans aucun coût avant de construire la dernière chose, il ferait beaucoup moins appel à la théorie. Si en quelques secondes il pouvait construire un pont mille fois gratuitement pour tester quand il allait se briser, il le ferait au lieu de passer des mois à calculer quand il pourrait freiner en théorie ...

En développement logiciel, c’est exactement ce que vous faites. Au lieu de calculer la rapidité de votre algorithme en théorie, vous pouvez simplement le tester et connaître la réponse en quelques secondes.

En fait, la plupart des logiciels actuels ne sont plus limités par des contraintes physiques telles que la puissance de calcul ou la mémoire. La limitation des logiciels réside dans la complexité des systèmes de plus en plus grands. Sa gestion de cette complexité en faisant en sorte que le système continue à être compris par les humains est l’enjeu majeur de la programmation actuelle.