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

63

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.

Giorgio
la source
9
non, 90% des programmeurs sont;)
jk.
24
Dans le logiciel, vous pouvez commencer par construire le toit, puis descendre jusqu'aux fondations, pendant que les pièces finies flottent dans les airs. Si quelque chose ne va pas, vous pouvez utiliser du ruban adhésif pour l'adapter. Essayez ceci lors de la construction d'un gratte-ciel. ;)
sécurité le
65
En théorie, il n'y a pas de différence entre théorie et pratique, mais en pratique, il y en a.
Joris Timmermans
6
Un bon livre pour rechercher des alogrithmes? La plupart des logiciels ne sont que de simples CRUD, sans rien de ce qui est inclus dans un livre ou un cours d'algorithme.
Gilles
44
La théorie concerne les langages modernes et les algorithmes. La pratique commence à travailler le premier jour et se voit confier la tâche d'ajouter une fonctionnalité mineure au logiciel de point de vente fonctionnant sur une caisse enregistreuse utilisant un logiciel converti manuellement de BASIC en K & R C par des personnes ne connaissant pas C , en utilisant un compilateur buggy d'un fournisseur qui a fait faillite et qui devrait avoir la fonctionnalité opérationnelle au plus tard vendredi.
Gort le robot

Réponses:

61

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.

Michael Borgwardt
la source
1
Je conviens avec vous qu’en génie logiciel, il est important d’avoir le formalisme nécessaire. Trop de moyens signifie que vous ne pouvez jamais vous lancer et peut-être que lorsque vous découvrirez que vous avez commis une erreur, il est trop tard. Trop peu signifie que vous pouvez faire un gâchis. Je pense que vous avez un argument très fort qui dit que la productivité et la qualité sont beaucoup plus difficiles à mesurer en génie logiciel qu'en génie civil.
Giorgio
2
"... alors qu'en génie logiciel, il n'y a pas de force tout aussi puissante pour rester irréalisable ..." Je pense que vous voulez dire qu'il n'y a plus de telle force. De retour dans la journée, les limitations imposées par des processeurs plus faibles, moins de mémoire et peu ou pas de stockage agissaient comme une telle force.
Blesh
1
@blesh: Je ne pense pas. Des limites matérielles strictes limitent les bonnes et les mauvaises techniques.
Michael Borgwardt le
Vos exemples ne sont pas la théorie de la programmation. Les contraintes sur les logiciels sont liées aux technologies utilisées et à la capacité mathématique des rédacteurs.
Paul Nathan
5
Il y a vraiment quelque chose de "théorique" dans UML ... ... son utilité!
ObscureRobot
29

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.

kevin cline
la source
1
Je souscris à vos observations selon lesquelles le facteur humain est beaucoup plus fort dans les logiciels, mais je pense néanmoins que tenter d’analyser un problème ou de structurer votre solution est une attitude / un outil général. Ma question est pourquoi certains programmeurs pensent que ce n'est pas une approche utile (ou même une perte de temps). Vous avez mentionné Haskell: j'ai fait l'effort d'apprendre un peu de Haskell même si je ne l'ai utilisé dans aucun projet, car je pensais que cela me permettrait d'écrire un meilleur code (même en C ++ ou en Java). Même si je ne peux pas mesurer cela, mon sentiment est que je suis devenu plus productif: je fais plus de choses.
Giorgio
2
Un tri rapide Haskell à trois lignes? Hmm ... est-il même possible d'implémenter Quicksort dans un langage où tout est immuable de par sa conception?
Mason Wheeler
3
@MasonWheeler Premier résultat de Google: Quicksort in Haskell .
chrisaycock
3
@Mason: le runtime est toujours O (n log n). Il nécessite également de la mémoire O (n log n), contrairement à un tri rapide sur place, qui ne nécessite que de la mémoire supplémentaire O (log n) pour la récursivité.
kevin cline
2
@kevincline Dans la mesure où un projet logiciel typique est unique, je me suis lancé dans un projet unique de rénovation de ma salle de bain. La différence est que si je bousille mon code, mes tests deviennent rouges, et si je bousille mes câbles, ma maison brûle. Bien sûr, ce projet impliquait également des heures supplémentaires et des dépassements de budget, car je ne suis pas expérimenté en résolution de problèmes de remodelage. Le problème principal que j'ai vu sur les projets logiciels est similaire ... ce n'est pas que les bonnes personnes ne pourraient pas résoudre ces problèmes plus rapidement, c'est que les bonnes personnes ne sont pas disponibles et que nous devons devenir les bonnes personnes sur le marché. mouche.
philosodad
17

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.

Mike Dunlavey
la source
5
La physique peut vous dire si une structure va s'effondrer sous sa propre charge. CS vous dit que vous ne pouvez pas dire si un programme va s’arrêter avec une entrée donnée. Les méthodes formelles de l'OMI sont bien meilleures en génie civil ou mécanique qu'en logiciel, principalement parce que les systèmes sont moins complexes et moins dynamiques ...
Guy Sirton
6
@GuySirton "Le CS vous dit que vous ne pouvez pas dire si un programme va s'arrêter avec une certaine entrée." si c'est tout ce que vous pensez que CS fait, je pense que vous n'en saurez peut-être pas autant sur CS que vous le pensez ...
gregghz
2
Guy, il est extrêmement improbable que vous ayez déjà utilisé des logiciels que personne n’a utilisés auparavant. McCarthy l'a fait, et Turing l'a fait, mais en réalité, l'ingénierie logicielle n'est pas si terrifiante. Si le fait que le bâtiment plonge au fond de l'océan parce que vous pouvez simplement le redémarrer est acceptable, ce serait un peu comme le génie logiciel.
philosodad
3
Je vous donnerais un +1 sauf la fissure sur la lisibilité. La facilité de maintenance représente 80% du coût du logiciel, la lisibilité n’est donc pas une mince affaire. En outre, lorsque cet ingénieur aéronautique ou nucléaire fabrique quelque chose qui sera fabriqué, il est important que d'autres personnes le comprennent. L'armée, le gouvernement ou même les grandes institutions ne sont pas satisfaits d'une invention magique qui ne peut être reproduite ou comprise par personne d'autre que l'inventeur.
Thomas
2
@Thomas - L'affirmation selon laquelle les solutions viables sont souvent rejetées au détriment de la "lisibilité", ne signifie pas nécessairement que les solutions ne sont pas aussi lisibles qu'elles devraient l'être. Je l'ai vu arriver. Bon sang, je me suis surpris à le faire.
Erik Reppen
13

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.

CaffGeek
la source
Eh bien, vous espérez qu’ils ne mourront pas ... dépend de votre logiciel;)
Rig
3
@Rig, c'est pourquoi j'ai dit «le plus» et «habituellement». Certains logiciels sont beaucoup plus critiques.
CaffGeek
Je pense que cela devient de plus en plus un point de vue très mauvais, que la plupart des logiciels n'a pas de répercussions sur la sécurité , mais il y a de l' argent et la vie privée impliqué dans un grand nombre de logiciels, obtenir ces mauvais pourrait vous conduire aussi à la cour
jk.
11

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é! :)

FishBasketGordo
la source
3
Si vous devez le faire une fois et oublier, c'est bien. Mais si vous devez l'étendre et le maintenir après, vous êtes à la recherche de problèmes. Vous devez avoir une idée de la théorie: trop signifie que vous ne le ferez jamais, trop peu signifie que vous allez le faire 10 fois avant que cela ne soit vraiment fait. Mes 2 centimes
Giorgio
6
Mais parfois, vous devez sortir votre logiciel MAINTENANT . Vous devez battre un concurrent sur le marché. Ou vous avez une obligation légale de fournir certaines informations. Ou vous avez simplement besoin d'obtenir des liquidités pour pouvoir exister quand le gâchis que vous avez provoqué avec votre approche "faites-le" est un problème ... qui est parfois un bon problème. Parce que si vous ne l'aviez pas, vous ne libériez pas à temps, et votre entreprise est morte avant que cela ne commence.
CaffGeek
1
@Chad - Je suis d'accord avec vous. C'est un équilibre. Toutes les choses que vous mentionnez tomberaient dans "une véritable contrainte de temps" pour justifier la programmation "get-it-done", et à court terme, c'est correct et même avantageux de le faire.
FishBasketGordo
@FBG: brillamment dit.
Kuba Ober le
@Chad, bon point. Martin Fowler fait une remarque similaire à martinfowler.com/bliki/TechnicalDebt.html . Parfois, c'est un compromis qui en vaut la peine.
John M Gant
9

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.

James McLeod
la source
"Il arrive un moment dans le développement logiciel où le coût de la conception augmente au-delà de la valeur renvoyée": j'ai explicitement écrit "la bonne quantité de théorie". Je sais que trop d'ingénierie n'augmente pas la productivité.
Giorgio
Il n’ya presque aucun projet IMO conçu à l’avance qui suit leur conception. Le génie civil est (généralement?) Construit la même chose encore et encore (une route, un putain de tunnel, un tunnel, un bâtiment, un pont). Les techniques sont bien connues. Ce n'est pas vrai dans le logiciel. Parce que cela peut être changé facilement et parce que les gens ne savent pas ce qu'ils veulent ou ce qui fonctionne jusqu'à ce qu'ils l'essaient sérieusement, la conception initiale est une perte de temps. Nous construisons, testons et itérons. Quelque chose qui n'est pas possible avec le génie civil, comme indiqué ci-dessus. Les 2 disciplines ne sont pas comparables.
Gman
5
Désolé, je dois signaler la faute de frappe: je ne pense pas que les ingénieurs civils en construisent à rien. ;-)
Giorgio
2
J'imagine qu'à l'avenir, lorsque nos ingénieurs en logiciel construiront un logiciel de simulation en génie civil, les ingénieurs civils pourront se passer de tout cela. Il suffit de construire un gratte-ciel virtuel de 10 km de haut. S'il ne s'effondre pas sous son propre poids au cours des 100 premières années virtuelles et qu'il peut résister à un ouragan virtuel de catégorie 5, utilisez-le avec l'imprimante 3D Skyscraper spéciale pour le construire.
emory
1
@RexKerr: vous avez coupé la moitié de sa déclaration: "... ce qui satisfait aux normes de sécurité requises"
Lie Ryan
7

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.

Onorio Catenacci
la source
6

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.

KeithS
la source
3
Il existe également de nombreuses inconnues inconnues dans le développement logiciel - vous pouvez commencer par construire un gratte-ciel, mais lorsque le client le regarde, il vous dit "en fait, je voulais un cube Rubix de dix étages".
Tacroy
@Tacroy: Curieusement, un ingénieur civil considérerait probablement cela comme un mauvais client qui gaspille votre temps et vos ressources, un ingénieur en logiciel essaiera de développer une nouvelle méthodologie pour le satisfaire. :-)
Giorgio
1
@Giorgio, ou facture en conséquence ...
CaffGeek
5

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.

Izkata
la source
1
+1 pour "quand on parle de 'théorie', cela signifie généralement le côté théorique de l'informatique".
Joshua Drake
5

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!

Albert Lang
la source
3
+1 pour "L'expédition est une fonctionnalité"! Une fois, j’ai entendu une phrase similaire: "La perfection n’existe pas. Ce logiciel a l’avantage d’exister." Bien sûr, c'est une blague. En ce qui concerne les logiciels critiques: une exception non interceptée peut provoquer le crash d’une fusée.
Giorgio
this software has the advantage that it exists... Je ne l'avais pas encore entendu, mais il entre dans ma liste de citations géniales sur les logiciels. Je l'aime
Albert Lang
@Giorgio: JSF et MISRA C sont écrits pour qu'il n'y ait pas d'exception. Les exceptions et les fusées ne font pas bon ménage.
Codeur
5

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 :)

ObscureRobot
la source
"J'imagine que les ingénieurs civils doivent rarement prendre en compte la relativité générale dans leur travail. Une grande partie du génie civil peut être construite en toute sécurité dans la mécanique newtonienne.": Autant que je sache, ils doivent utiliser beaucoup de calcul et des trucs comme ça). Ce n’est pas de la mécanique quantique, mais à l’OMI, ce n’est certainement pas trivial.
Giorgio
2
Bien sûr, mais vous n'avez pas besoin de dériver une équation d'onde pour chaque composant de votre pont, puis d'expliquer comment ils interagissent.
ObscureRobot
Tu as raison. Cependant, ce que je veux dire n’est pas la quantité de théorie utilisée en génie civil par rapport au génie logiciel. Au contraire, les ingénieurs civils savent qu'ils doivent utiliser leurs formules et calculer comment construire un bâtiment. En génie logiciel, j'ai l'impression qu'il y a plus d'improvisation et parfois, si vous voulez vous asseoir et analyser un problème (juste pour le résoudre correctement, ne pas écrire une thèse de doctorat à ce sujet), vous pouvez être mal vu: nous voulons l'obtenir. fini, pas pour le rendre parfait. Mais à notre connaissance, une théorie (pas trop) est exactement ce qui peut aider à la terminer plus rapidement!
Giorgio
Vous devez trouver un point d'équilibre approprié à votre projet. Les développeurs juniors sont généralement plus enclins à jeter de la merde ensemble pour voir ce qui va coller. S'ils viennent d'un contexte très théorique, ils peuvent même avoir des idées plus folles et excessivement complexes. Gérer efficacement les développeurs débutants implique souvent de les aider à prendre du recul et à analyser leur travail. D'un autre côté, les développeurs expérimentés peuvent être trop concentrés sur les problèmes de conception à long terme au point où ils ont du mal à se concentrer sur les besoins immédiats.
ObscureRobot
Wow, désolé, c'est hors sujet, mais sans lire votre réponse, je l'ai terminée exactement de la même manière, avec un TL; DR puis, littéralement, exactement la même analogie. Format SAT. Je l'ai retranché de ma réponse pour ne pas avoir l'air de vous copier, mais cela me fait encore paniquer. Peut-être que les programmeurs pensent trop de la même façon.
Jarsen
3

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.

P.Brian.Mackey
la source
1

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.

Steven Evers
la source
3
"les maths ... a déjà été fait": non seulement, considérez toutes les fonctions de la bibliothèque, les frameworks, les SGBD, les protocoles, et des tonnes d'autres choses lourdes que nous pouvons simplement utiliser dans notre code en appelant une fonction avec certains paramètres. En tant que programmeur, je me sens parfois plus comme un ouvrier qui marche sur l'échafaud que comme un ingénieur qui a conçu le bâtiment.
Giorgio
1

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.

v-star
la source
1

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.

Martin Beckett
la source
Alors, quel est l’équivalent logiciel d’une analyse par éléments finis du bâtiment de 100 étages? Combien de grands immeubles ont des insectes dans therm / crash? :-)
Guy Sirton
@GuySirton - vous ne pouvez analyser qu'un grand bâtiment à un niveau très grossier, avec moins de détails que vous ne testeriez à l'unité une application typique. Beaucoup de grands bâtiments ont des défauts, des fenêtres tombent, des allées s’effondrent, elles créent des effets de soufflerie. Ou, dans le cas d'un hôtel très réfléchissant et incurvé à Vegas, vous créez un rayon de la mort dans la piscine!
Martin Beckett
Vous pouvez très bien analyser la FEA et prédire le comportement avec un très haut degré de précision. Les gens font encore des erreurs. OMI, il est tout simplement impossible de faire des prédictions similaires sur un logiciel complexe. Les défauts que vous mentionnez ne représentent qu'une infime fraction du nombre total de bâtiments. Les taux de défauts dans les logiciels doivent être deux ordres de grandeur plus élevés. Cela dit, il s’agit évidemment d’un continuum entre les méthodes formelles qui sont utiles et les méthodes inutiles.
Guy Sirton
@GuySirton - Je pense que le problème est que vous comptez sur autre chose. La NASA peut tester l'avionique de vol à un niveau très détaillé (bien que ce ne soit toujours pas le prouver), car ils créent également le système d'exploitation et le matériel. Écrire sur un système d’exploitation général avec des boîtes à outils et des bibliothèques équivaut à construire un pont où il n’est pas permis de connaître les détails de l’acier ou du béton.
Martin Beckett
1
@MartinBeckett, et le coefficient de gravité change de façon aléatoire d'heure en heure ... comme lorsque votre administrateur système décide de manière aléatoire de mettre à niveau un serveur sans prévenir personne, car "il sera transparent".
CaffGeek
1

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.

Dominic Cronin
la source
1

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.

Jarsen
la source
1
Je vois des similitudes entre nos réponses, mais vos idées sont évidemment originales et il y a quelques différences. Je ne suis pas d'accord que comprendre P / NP n'est pas utile. Vous n'avez pas à étudier la théorie de la complexité en profondeur, mais un ingénieur en logiciel qui travaille devrait pouvoir être en mesure d'estimer le O (n) d'un morceau de code donné et de dire des choses intelligentes sur le coût des solutions alternatives. Un point que vous avez presque dit, mais que vous n’avez pas fait, est que la théorie est souvent encapsulée dans des bibliothèques. C'est un bon à considérer.
ObscureRobot
"Si quelqu'un résout ... le problème qui nous arrête, nous sommes confrontés à de nombreuses et incroyables nouvelles avancées.": Malheureusement, la théorie a prouvé que cela est insoluble (il n'existe aucun programme qui puisse le décider). des efforts de recherche sont déployés pour tenter de résoudre le problème qui fait obstacle.
Giorgio
Les machines de Turing ne peuvent pas "Cependant, toutes les machines imaginables par l'imagination humaine ne sont pas sujettes à la thèse de Church-Turing ... La question reste ouverte de savoir s'il peut exister des processus physiques déterministes réels qui, à la longue, échappent à la simulation Machine de Turing, et en particulier si un tel processus hypothétique pourrait utilement être exploité sous la forme d’une machine à calculer (un hypercalculateur) qui pourrait résoudre le problème persistant… La question de savoir si de tels processus physiques inconnus sont impliqués est également en suspens le fonctionnement du cerveau humain ... "-Halting Problem, Wikipedia
Jarsen
Donc, autant que je sache, et corrigez-moi si je me trompe, je pense que nous avons encore beaucoup de découvertes à faire sur le calcul. Comme cela a été mentionné à plusieurs reprises dans ce fil, l'informatique est encore très jeune; Turning Machines et l’architecture de Von Neumann pourraient faire l’objet de beaucoup.
Jarsen
@Jarsen: Il est vrai que l'informatique est très jeune, mais tout ordinateur qui a été construit jusqu'à présent ne peut effectuer que des tâches informatisées de Turing. Autant que je sache (très peu en effet), même les ordinateurs quantiques ne peuvent pas en faire plus (ils pourraient résoudre certains problèmes plus rapidement, mais ils ne pourraient pas en résoudre davantage). Alors, oui, qui sait ce qui peut être inventé, mais tout formalisme informatique imaginé au cours des 70 dernières années ne peut faire plus qu’une machine de Turing.
Giorgio
1

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.

Marco Devillers
la source
0

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.

Rayon
la source
0

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.

Daniel
la source
0

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.

Erik Reppen
la source
0

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.

mirkok
la source