Je travaille depuis deux ans dans l'industrie du logiciel. Certaines choses qui me sont perplexes sont les suivantes:
Il y a manque d'application de mathématiques dans l'industrie du logiciel actuel.
Par exemple: Lorsqu'un ingénieur mécanique conçoit un pôle d'électricité, il calcule le stress sur la fondation en utilisant des techniques d'analyse de contrainte (des équations mathématiques en lecture) afin de déterminer exactement quel type et quelle qualité d'acier doit être utilisée, mais lorsqu'un développeur de logiciel Déploie une application de serveur Web qu'il devine simplement sur la charge estimée sur son serveur et laisse le reste de la chance et de Dieu, il n'y a rien qu'il puisse utiliser pour simuler mathématiquement pour répondre à son problème (mon observation).
super logiciels (simulateurs de tunnel éolienx, etc.) et des programmes informatiques (comme Matlab, etc.) sont là pour simuler des problèmes mondiaux réels (car ils ont leurs équations mathématiques), mais nous, dans l'industrie du logiciel, sont toujours désemparés de la manière dont les ressources réelles En termes de mémoire, de ressources informatiques, de vitesse d'horloge, de RAM, etc. serait nécessaire lorsque notre application côté serveur serait déployée. Nous continuons simplement à deviner sur la solution et à résoudre ce problème par de tels problèmes par plus ou moins «Hit and Essay» (mon observation).
La programmation est effectuée sur les API, que ce soit en C, C #, Java, etc. Nous ne pouvons jamais vérifier exactement la complexité de notre code et donc l'efficacité, car quelque part nous utilisons une abstraction écrite par quelqu'un d'autre dont le code source Nous n'avons ni que nous n'avons pas eu le temps de le vérifier.
E.g. Si j'écris une simple application de serveur client dans C # ou Java, je ne suis jamais capable de calculer à l'avance la quantité d'efficacité et de complexité de ce code ou quel serait le minimum de cette application de serveur client entière nécessitera (mon observation). .
L'équilibrage de la charge et l'analyse de l'évolutivité sont trop vagues et sont simplement résolues en ajoutant plus de nœuds si les demandes sur le serveur augmentent (mon observation).
Veuillez poster des réponses à l'une de mes observations susmentionnées. Veuillez également poster des références pertinentes.
Je serais heureux si quelqu'un me prouve tort et montre la bonne façon.
Merci d'avance
ashish
12 Réponses :
La réponse à la plupart d'entre elles est pour avoir des mesures significatives (et des équations acceptées, des limites, des tolérances, etc.) que vous avez dans l'ingénierie du monde réel, vous avez d'abord besoin d'une façon de mesurer ce que vous regardez.
La plupart de ces choses ne peuvent pas être mesurées facilement - la complexité du logiciel est un classique, quel est le "complexe"? Comment regardez-vous le code source et décidez s'il est complexe ou non? La complexité cyclomatique de McCabe est la norme la plus proche que nous avons pour cela, mais il suffit de compter uniquement les instructions de la branche dans les méthodes.
Il y a peu de mathématiques dans des logiciels car les programmes eux-mêmes sont l'équation. Il n'est pas possible de comprendre l'équation avant qu'il ne soit réellement exécuté. Les ingénieurs utilisent des programmes simples (et très complexes) pour simuler ce qui se passe dans le monde réel. Il est très difficile de simuler un simulateur. De plus, de nombreux problèmes en informatique n'ont même pas de réponse mathématiquement: voir le vendeur de voyage.
Une grande partie des mathématiques est également intégrée aux langues et aux bibliothèques. Si vous utilisez une table de hachage pour stocker des données, vous savez que tout élément peut être effectué dans le temps constant O (1), peu importe le nombre d'éléments dans la table de hachage. Si vous le stockez dans un arbre binaire, il faudra plus de temps en fonction du nombre d'éléments [0 (n ^ 2) si je me souviens bien].
Le problème du vendeur itinérant a une réponse, c'est juste que cela fait partie d'une très grande classe de problèmes que nous ne pouvons obtenir de réponses pour efficacement (et doutons plutôt que nous ayons jamais peut-être possible). Le problème d'arrêt est prouvé sans réponse.
TSP a le plus certainement une réponse, il ne peut tout simplement pas être calculé en temps polynomial par une machine à trouble déterministe (supposant P! = NP). Peut-être pensais-tu au problème d'arrêt? en.wikipedia.org/wiki/halting_problem
Pensez aux sciences de l'ingénierie, ils disposent tous de lois très bien définies applicables à la conception et à la construction d'objets physiques, de choses comme la gravité, la force des matériaux, etc., tandis que dans l'informatique, il n'y a pas beaucoup bien défini lois pour la création d'une demande contre.
Je peux penser à de nombreuses façons différentes d'écrire un programme World Bonjour simple qui satisferait l'obligation. Cependant, si je dois construire un pôle d'électricité, je suis gravement contraint par le monde physique et les exigences du pôle.
Le problème est que le logiciel parle avec d'autres logiciels, écrits par les humains. Les exemples d'ingénierie que vous décrivez concernent le phénomène physique, qui sont constants. Si je développe un simulateur électrique, tout le monde dans le monde peut l'utiliser. Si je développe un simulateur de protocole X pour mon serveur, cela m'aidera, mais ne vaudra probablement pas le travail.
Personne ne peut concevoir un système à partir de zéro et des personnes qui écrivent des bibliothèques semi-communes ont généralement de nombreuses améliorations et extensions pour travailler plutôt que de rédiger un simulateur pour leur bibliothèque.
Si vous souhaitez un simulateur de trafic réseau, vous pouvez en trouver un, mais il vous indiquera peu de choses sur votre charge de serveur, car le trafic n'utilisera pas le protocole que votre serveur comprend. Chaque serveur va voir des ensembles de trafic complètement différents.
Il manque une application de mathématiques dans l'industrie du logiciel actuelle.
Par exemple: Lorsqu'un ingénieur mécanique conçoit un pôle d'électricité, il calcule le stress sur la fondation en utilisant des techniques d'analyse de contrainte (des équations mathématiques en lecture) afin de déterminer exactement quel type et quelle qualité d'acier doit être utilisée, mais lorsqu'un développeur de logiciel Déploie une application de serveur Web qu'il devine simplement sur la charge estimée sur son serveur et laisse le reste de la chance et de Dieu, il n'y a rien qu'il puisse utiliser pour simuler mathématiquement pour répondre à son problème (mon observation).
Je ne dirais pas que la chance ou Dieu est toujours la base de l'estimation de la charge. Les données souvent réalistes peuvent être utilisées.
Il n'est pas non plus vrai qu'il n'y a pas de techniques mathématiques pour répondre à la question. La recherche sur les opérations et la théorie de la queue peuvent être appliquées au bon avantage.
Le problème réel est que l'ingénierie mécanique est basée sur des lois de la physique et une fondation de milliers d'années d'une enquête empirique et scientifique. L'informatique est seulement aussi vieux que moi. L'informatique sera beaucoup plus approfondie au moment où vos enfants et vos petits-enfants appliquent les meilleures pratiques de leur journée.
point par point
Un pôle d'électricité doit résister au temps, une charge, une corrosion, etc. et ceux-ci peuvent être quantifiés et modélisés. Je ne peux pas quantifier le succès de mon site Web, ni comment ma base de données se développera.
Optimisation prématurée? Assez bon, c'est exactement cela, réparez-le en cas de besoin. Si vous êtes un vendeur, vous ne savez pas ce qui allait exécuter votre code dans la vie réelle ou la manière dont elle est configurée. Encore une fois, vous ne pouvez pas le quantifier.
Optimisation prématurée
Voir point 1. Je peux ajouter au besoin.
porter sur ... Même les ingénieurs Bollix Up. Effondrement des ponts, une panne d'électricité, des rappels de sécurité des voitures, "mauvais type de neige", etc., etc. Devons-nous changer la question à "Pourquoi les ingénieurs n'utilisent-ils pas d'observations plus empiriques?"
Je pense qu'il y a quelques raisons à cela. L'un est que dans de nombreux cas, il suffit de faire le travail est plus important que de la rendre le plus performant aussi bien que possible. Beaucoup de logiciels que j'écris sont des trucs qui ne seront exécutés que lors de petits ensembles de données ou de substances dans lesquelles les implications de la performance sont assez triviales (c'est une boucle qui fait un calcul fixe sur chaque élément, il est donc de manière triviale O (n) ). Pour la plupart de ce logiciel, il serait idiot de passer du temps à analyser la durée de fonctionnement en détail.
Une autre raison est que le logiciel est très facile à changer plus tard. Une fois que vous avez construit un pont, tous les correctifs peuvent être incroyablement chers, il est donc bon d'être très sûr de votre conception avant de le faire. Dans le logiciel, sauf si vous avez réalisé un choix architectural horrible tôt, vous pouvez généralement trouver et optimiser les points chauds de performances une fois que vous avez des données plus réelles sur le monde réel sur la performance. Afin d'éviter ces chuits architecturaux horribles, vous pouvez généralement faire des calculs approximatifs et arrière de l'enveloppe (assurez-vous que vous n'utilisez pas d'algorithme O (2 ^ N) sur un ensemble de données volumineux et estimation dans un facteur. de 10 ou donc combien de ressources vous aurez besoin pour la charge la plus lourde que vous attendez). Celles-ci nécessitent une analyse, mais il peut généralement être assez rapide et éteint le brassard.
Et puis il y a des cas dans lesquels vous avez vraiment besoin de presser la performance ultime d'un système. Dans ce cas, les personnes se trouvent fréquemment sur lesquelles reposent souvent sur les caractéristiques de performance des systèmes avec lesquelles ils travaillent et effectuent des analyses très détaillées. Voir, par exemple, le papier très impressionnant d'Ulrich Drepper Ce que chaque programmeur doit savoir sur la mémoire (PDF) .
1) La plupart des logiques commerciales sont généralement décomposées en arbres de décision. C'est l'équation «d'équation» qui devrait être vérifiée avec des tests unitaires. Si vous mettez x, vous devriez avoir y, je ne vois aucun problème là-bas.
2,3) Le profilage peut fournir un aperçu de la situation de la performance. Pour la plupart, vous ne pouvez pas dire que le logiciel prendra X cycles car cela va changer au fil du temps (la base de données devient plus grande, le système d'exploitation commence à aller funky, etc.). Les ponts, par exemple, nécessitent une maintenance constante, vous ne pouvez pas gifler un et vous attendre à ce qu'il dure 50 ans sans passer du temps et de l'argent dessus. L'utilisation de bibliothèques est comme ne pas essayer de comprendre PI à chaque fois que vous souhaitez trouver la circonférence d'un cercle. Il a déjà été prouvé (et est rentable), il n'est donc pas nécessaire de réinventer la roue.
4) Pour l'échelle des applications Web la plus sévères bien horizontalement (plusieurs machines). L'échelle verticale (multithreading / multiprocessé) a tendance à être beaucoup plus complexe. L'ajout de machines est généralement relativement facile et rentable et évite certains goulots d'étranglement qui deviennent limités assez facilement (Disk E / S). L'équilibrage de la charge peut également éliminer la possibilité d'une machine étant un point d'échec central.
Ce n'est pas exactement la science de la fusée, car vous ne savez jamais combien de consommateurs viendront à la ligne de service. Généralement, il vaut mieux avoir trop de capacité alors d'avoir des erreurs, énervées de clients et de quelqu'un (généralement votre patron) en mâchant votre cachette.
Un mit EE Grad n'aurait pas ce problème;)
Mes pensées:
Certaines personnes appliquent réellement des mathématiques pour estimer la charge du serveur. Les équations sont très complexes pour de nombreuses applications et de nombreuses personnes ont recours à des règles de pouce, de deviner et d'ajuster ou de stratégies similaires. Quelques applications (applications en temps réel avec une pénalité élevée pour l'échec ... Les systèmes d'armes, les applications de contrôle des powerplants, l'avionique) calculer soigneusement les ressources requises et s'assurer qu'ils seront disponibles au moment de l'exécution.
même que 1.
Les ingénieurs utilisent également des composants fournis par d'autres, avec une interface publiée. Pensez à l'ingénierie électrique. Vous ne vous souciez généralement pas des internomains d'un transistor, de son interface et d'une spécification de fonctionnement. Si vous vouliez examiner tous les composants que vous utilisez dans toute la complexité, vous seriez limité à ce qu'une personne célibataire peut accomplir.
J'ai écrit des algorithmes assez complexes qui déterminent quoi d'élaborer lorsqu'il est basé sur divers facteurs tels que la consommation de mémoire, la charge de la CPU et l'IO. Cependant, la solution la plus efficace est parfois de mesurer et d'ajuster. Ceci est particulièrement vrai si l'application est complexe et évolue au fil du temps. L'effort investi dans la modélisation de l'application mathématiquement (et la mise à jour de ce modèle au fil du temps) peut être plus que le coût de l'efficacité perdue en essayant de corriger les approches. Finalement, je pouvais envisager une meilleure compréhension de la corrélation entre le code et l'environnement qu'il exécute pourraient conduire à des systèmes qui prédisent l'utilisation des ressources à l'avance. Puisque nous n'avons pas cela aujourd'hui, de nombreuses organisations chargent le code de test dans un large éventail de conditions pour rassembler de manière empirique cette information.
L'ingénierie logicielle est très différente des champs typiques de l'ingénierie. Lorsque l'ingénierie "normale" est liée au contexte de notre univers physique et des lois qui y sont identifiées, il n'y a pas de telles limites dans le monde du logiciel.
Le logiciel producteur est généralement une tentative de refléter un sous-ensemble du monde de la vie réelle dans une réalité virtuelle. Ici, nous définissons nous-mêmes les lois, en choisissant seulement ceux dont nous avons besoin et en les faisant aussi complexe que nécessaire. En raison de cette différence fondamentale, vous devez examiner la résolution de problèmes d'une perspective différente. Nous essayons de faire des abstractions pour rendre des pièces complexes moins complexes, comme nous enseignons des enfants que jaune + bleu = vert = vert, quand c'est vraiment la longueur d'onde de la lumière qui rebondit sur le papier qui change.
Une fois de temps en temps, nous sommes liés par différentes lois cependant. Des trucs comme Big-O, la couverture de test, la complexité-mesurements, les mesures d'assurance-chômage et les goûts sont tous des modèles de lois mathématiques. Si vous regardez dans le traitement du signal numérique, la programmation en temps réel et la programmation fonctionnelle, vous constaterez souvent que les programmeurs utilisent des équations pour comprendre un moyen de faire ce qu'ils veulent. - Mais ces techniques ne sont pas vraiment utiles pour créer un domaine virtuel, qui peut résoudre une logique complexe, ramifiante et interagir avec un utilisateur.
J'ai souvent trouvé ce rouge + vert = jaune.
Les raisons pour lesquelles les tunnels à vent, les simulations, etc. sont nécessaires dans le monde de l'ingénierie, c'est qu'il est beaucoup moins cher de construire un prototype à l'échelle à l'échelle, que de construire toute la chose, puis de le tester. En outre, un test échoué sur un pont à pleine échelle est destructeur - vous devez en créer un nouveau pour chaque test.
Dans le logiciel, une fois que vous avez un prototype qui transmet les exigences, vous avez la solution complète. Il n'est pas nécessaire de construire la version complète. Vous devez exécuter des simulations de charge sur vos applications de serveur avant d'aller vivre avec eux, mais comme les charges sont variables et souvent imprévisibles, vous ferez mieux de construire l'application pour pouvoir réduire à n'importe quelle taille en ajoutant plus de matériel que de cibler une certaine charge. Les constructeurs de ponts ont une charge cible donnée dont ils ont besoin de gérer. S'ils avaient une utilisation prédite de 10 voitures à un moment donné, puis un an plus tard, la popularité du pont a grimpé à 1 000 000 voitures par jour, personne ne serait surpris s'il était échoué. Mais avec des applications Web, c'est le genre de mise à l'échelle qui doit se produire.
Il n'est pas toujours possible de construire un prototype ou de comprendre tous les problèmes d'échelle. C'est pourquoi les simulations informatiques des problèmes de physique sont si populaires. Le logiciel est largement disponible et le matériel est suffisamment puissant de nos jours pour effectuer des solutions très complexes possibles. Il faut toujours être conscient des cygnes noirs, des effets non linéaires et des limites des mathématiques.
Devrait être un wiki communautaire
C'est une vraie question et très valable.
Eric J., il est lié à la programmation et convient probablement à un wiki communautaire, mais il n'y a aucune question claire. Je n'aime pas m'attarder sur la sémantique, mais ils peuvent jouer un rôle important en sachant comment répondre. "Je suis somnolent" n'est pas la même chose que "Comment puis-je être moins somnolent?" ou "Pourquoi suis-je endormi si souvent?" ou "Comment les gens empêchent-t-il habituellement la somnolence?"
Je pense que c'est un sujet raisonnable pour la discussion, si un peu large et vague. Ce devrait probablement être un wiki communautaire, car ce n'est pas quelque chose qui a une réponse correcte bien définie.