Il semble que l'ancien fer à repasser est un logiciel de roche solide. Pourquoi donc? Est-ce parce que le logiciel est si mature que tous les bugs ont été élaborés? Ou est-ce parce que les gens se sont tellement utilisés pour les insectes qu'ils ne les reconnaissent même pas et travaillent autour d'eux? Les spécifications logicielles étaient-elles parfaites du premier jour et une fois que le logiciel a été écrit, tout vient de travailler? J'essaie de comprendre comment nous sommes venus de jours de calcul de mainframe que tout le monde épouse maintenant comme il suffit de sentir que TDD est maintenant la voie à suivre.
11 Réponses :
Oh, ils ont définitivement des bugs - voir TheDailyWTF.com pour des exemples plus divertissants. Cela dit, la plupart des applications «mainframe» que l'on voit aujourd'hui ont eu 30 ans pour que tous les kinks soient élaborés, ils ont donc un peu un avantage sur la plupart des applications créées au cours des dernières années.
Comment toutes les nouvelles applications de mainframe sont-elles élaborées sur leurs kinks?
@Joezitzelberger: Ils ne font pas de nouvelles, n'envoyant généralement que les anciennes interfaces EDI dans une sorte de pile de services Web. Et là et il n'y a probablement pas une application non triviale sans un bogue existant.
Les rumeurs de la mort de la plate-forme d'application MVS / OS390 / ZOS-CICS / TS-COBOL circulent tant que les rumeurs de la mort de l'ordinateur Apple et de leur plate-forme de niche. Il y a beaucoup de nouveaux développements dans le monde du mainframe. Désolé si le commentaire initial n'a pas grogné avec suffisamment de sarcasme pour être reconnu.
Pourquoi diable pensez-vous qu'ils ne sont pas des bugs?
IBM a une vaste infrastructure de soutien pour les rapports de bogues et de la résolution (APRM, APAR et PTFs), qui est largement utilisé.
logiciel Mainframe qui n'a pas été touché depuis de nombreuses années sera certainement bien compris (au moins en termes de ses idiosyncrasies) et aura probablement eu de nombreux bugs fixes ou travaillé autour. Toutes les nouveautés en cours d'élaboration de nos jours fait des plans pour un certain nombre de bogues et des correctifs de GA (disponibilité générale) à au moins GA + 36 mois. En fait, un ex-patron de la mine à IBM utilisé pour regimber à être obligé de fournir des chiffres pour les bugs prévus avec la ligne:. « Nous ne sommes pas planification pour avoir des bugs »
L'ordinateur central adopte des principes RAS (fiabilité, disponibilité et maintenabilité) au-delà de ce que la plupart du matériel de bureau et des logiciels pourrait jamais aspirer à - c'est seulement mon avis bien sûr, mais je suis à droite: -)
En effet, IBM sait trop bien que le coût de la correction des bugs augmente beaucoup que vous progressez dans le cycle de développement - il est beaucoup moins cher pour corriger un bug dans les tests unitaires que de fixer une production, en termes à la fois l'argent et réputation.
Il y a beaucoup d'efforts et les coûts dépensés pour que la diffusion des logiciels sans bug, mais même ils ne sont pas bien tout le temps.
Ce n'est certainement pas toujours le cas que l'ancien logiciel central qui n'a pas été touché n'est pas bien compris. Il est beaucoup plus probable que cela soit complètement oublié et que les gestionnaires se lèvent avec des sueurs froides se demandant ce qui se produirait si l'un des anciens programmes qui ne se brisent jamais. Dieu merci, je travaille sur le logiciel Windows. Rien ne fonctionne jamais assez longtemps pour être oublié !!!
@Modan, en termes de faiblesses . Ses stagiaires ne peuvent pas être compris du tout (la source peut même être partie) mais, s'il n'a pas été avancé au cours des vingt dernières années avec toutes les données des ordures aurait été soumise à ce temps. , il est incroyablement improbable de commencer demain. Et si cela avait abendu, vous auriez trouvé une solution de contournement ou remplacée.
Il n'y a pas de bugs dans le logiciel de cadre principal, uniquement des fonctionnalités.
Contrairement aux applications de bureau communes, qui ont fonctionnalités non documentées .
Cela ne fournit pas de réponse à la question. Pour critiquer ou demander des éclaircissements d'un auteur, laissez un commentaire sous leur poste.
@Raul Rene Cette réponse est d'une heure différente et un comportement communautaire différent. Nous sommes là où beaucoup plus petits et beaucoup moins stricts ... Voyez-le comme la différence entre une petite startup et un grand environnement / règles d'entreprise.
@ Itaymoav-Malimovka Je comprends, mais mon commentaire a été généré par un examen
Bien que je n'ai pas d'expérience avec les ordinateurs centraux, je suppose que c'est le premier point que vous avez fait: le logiciel existe depuis des décennies. La plupart des bugs restants auront été élaborés.
En plus, n'oubliez pas les fiascos comme Y2K. Tous les bugs que les gens ont trébuché ont été élaborés et, dans 20 ans, la plupart des situations auront probablement eu lieu. Mais de temps en temps, une nouvelle situation (un autre exemple intéressant de ceci est le bogue trouvé dans, je crois, BSD UNIX. Il a été trouvé il y a un an, et cela fait environ 20 ans sans que personne ne s'envole).
Je pense que la programmation n'était qu'un champ avancé que seuls les ingénieurs choisis pouvaient y travailler. Le monde de la programmation est maintenant beaucoup plus important avec des barrières d'entrée inférieures dans tous les aspects.
Parce que les programmeurs Cobol sans formation officielle n'avaient-ils aucune barrière élevée à l'entrée? Souvent, c'était une promotion de la livraison de la salle de courrier ...
Il y a beaucoup de bugs sur le logiciel centralframe, ils ne sont tout simplement pas publiés autant au groupe relativement petit de développeurs concernés. Il suffit de demander à quelqu'un qui fait le développement du mainframe combien d'abresintes qu'elles voient quotidiennement!
UN VIRAGE! Je semble toujours l'appeler ça de temps en temps et le problème infâme 0C4
// Sysabend DD Sysout = A - Le début à une très longue journée.
Ce ne sont pas touchés par les développeurs, c'est des clients. Et le nombre de personnes touchées par un bogue dans le logiciel centralframe peut être énorme - tel qu'une récente débâcle bancaire en Australie, où aucune information de compte n'était disponible sur le net et de nombreuses transactions en ligne ont été retardées pendant des jours. Selon vous, quel est à la fin de cette infrastructure bancaire en ligne, SQL Server sur quelques PCS? :-)
J'ai appris à utiliser les debuggers et à analyser les décharges de noyau sur les grands ordinateurs principaux. Croyez-moi, ils sont venus seulement à cause de bugs. Vous êtes tout simplement faux.
Cependant, les architectures de mainframe ont été conçues pour la stabilité sous contrainte élevée (bien comparée à des systèmes non centraux non centraux) afin que vous puissiez peut-être argumenter, ils sont meilleurs de cette façon. Mais code sage? Nah bug est toujours là ...
J'avais l'habitude de travailler sur les applications de mainframe. Les applications précédentes n'avaient pas beaucoup de bugs parce qu'elles n'ont pas fait grand chose. Nous avons écrit des centaines, voire des milliers de lignes de Fortrans pour faire ce que vous feriez avec quelques formules d'Excel maintenant. Mais lorsque nous sommes passés de programmes qui ont obtenu leur entrée en mettant une valeur dans les colonnes 12 à 26 de la carte 1 et une autre valeur dans les colonnes 1-5 de la carte 2, etc., à celles qui ont pris l'entrée d'un écran ISPF interactif ou d'une lumière Stylo et sortie sur un traceur Calomp 1012 ou un terminal Tektronix 4107, le nombre de bugs est monté.
Je pense que c'est quelques choses. Premièrement, c'est que le cycle de correctif-a-bug-recompile était plus cher dans des ordinateurs centraux habituellement. Cela signifiait que le programmeur ne pouvait pas simplement sortir du code et «voir si cela fonctionne». En effectuant des simulations de compilation et d'exécution dans votre tête, vous pouvez repérer plus de bugs que de laisser le compilateur les attraper.
Deuxièmement, tout le monde et leur frère n'étaient pas un "programmeur". Ils étaient généralement des spécialistes hautement qualifiés. Maintenant, les programmes proviennent de gars assis dans leur sous-sol avec un diplôme d'études secondaires. Aucun problème avec cela!!! Mais il a tendance à avoir plus de bugs que l'ingénieur qui l'a fait professionnellement depuis 20 ans.
Troisièmement, les programmes de mainframe ont tendance à avoir moins d'interaction avec leurs voisins. Sous Windows, par exemple, une mauvaise application peut se bloquer celui-ci à côté ou tout le système. Sur les ordinateurs centraux, ils ont généralement une mémoire segmentée afin que tout ce qu'il puisse crancer est lui-même. Compte tenu des tonnes de choses qui fonctionnent sur votre système de bureau typique de toutes sortes de sources marginalement fiables, il a tendance à effectuer tout programme squaly dans une certaine mesure.
La maturité est définitivement un facteur. Un programme de traitement de carte de crédit COBOL qui a été écrit il y a 20 ans et a été raffiné sur et sur l'élimination des bugs est moins susceptible de poser un problème qu'une version 0.1 de tout programme. Bien sûr, il y a la question que ces anciens programmes d'infinis réécrits finissent généralement par le code spaghetti, qui est presque impossible à maintenir.
Comme n'importe quoi, cela dépend principalement du ou des programmeurs et de leur méthodologie. Est-ce qu'ils font des tests unitaires? Est-ce qu'ils documentent et écrivent du code de nettoyage? Est-ce qu'ils ne sont que du code sur le pont-and-déposer dans le compilateur pour voir s'il y a des bugs (en espérant que le compilateur peut tous les attraper)?
Mon expérience avec le logiciel d'application centralframe (par opposition aux systèmes d'exploitation) est assez obsolète, mais mon souvenir est que la majorité des applications sont des applications par lots, logiquement, très simples:
a) lire un fichier d'entrée
b) Processus Chaque enregistrement (si vous vous sentez audacieux, mettez à jour une base de données)
c) Écris un fichier de sortie
aucun événement d'entrée utilisateur à vous inquiéter, une équipe d'opérateurs qualifiés pour surveiller le travail en fonctionne, peu d'interaction avec des systèmes externes, etc., etc.
Maintenant, la logique commerciale peut être complexe (surtout si elle est écrite dans Cobol 68 et la base de données n'est pas relationnelle) mais si c'est tout ce que vous devez vous concentrer sur, il est plus facile de faire des logiciels fiables.
«Lot» prend différentes connotations dans de grands systèmes. Le traitement par lots est (en petite partie) à l'écoute pour donner un temps de processeur maximum ou identifié vers un travail vs interrompu et reporté comme ce qui peut arriver dans un système UNIX commun. Les 3 étapes que vous avez données ci-dessus sont la même chose que cela a fonctionné sur chaque système en même temps. Les ordinateurs centraux d'aujourd'hui font à peu près tout ce que nous faisons ailleurs aujourd'hui.
Je n'ai jamais travaillé sur des logiciels pour les ordinateurs centraux moi-même, mais mon père était un programmeur COBOL dans les années 1970.
Lorsque vous avez écrit des logiciels à cette époque, la recherche de bogues n'était pas aussi simple que celle de la compilation de votre code source et de la recherche sur les messages d'erreur du compilateur vous accueillant ou en exécutant votre programme et en regardant ce qu'il faisait mal. Un typiste a dû frapper le programme dans des cartes de frappe, qui seraient ensuite lus sur l'ordinateur, qui imprimeraient les résultats de votre programme.
Mon père m'a dit qu'un jour, quelqu'un est venu avec un chariot de cases de papier et les a mis à côté de la porte de la pièce où il travaillait. Il a demandé: "Qu'est-ce que c'est ça ?!" Et le gars lui a dit "c'est la sortie de votre programme". Mon père a commis une erreur qui a provoqué le programme d'imprimer une énorme quantité de gibbacish sur une pile de papier qui aurait pu utiliser un arbre entier.
Vous apprenez rapidement de vos erreurs de cette façon ...
Une idée fausse commune est que les ordinateurs centraux sont certains de la manière dont de différence de distribution en matière d'utilisation et de développement aujourd'hui. Toutes les grandes banques et le gouvernement utilisent toujours fortement les ordinateurs centraux et nécessitent une mise à niveau constante (merci IBM!). Je pense que vous référencez la théorie du développement "cascade" qui, oui, était fortement utilisée sur les ordinateurs centraux, car au début, ils utilisaient des cartes de poinçon et des impressions, donc si vous pouviez planifier tôt et éviter les erreurs. Toutefois, "TDD" aborde le problème que lorsqu'un environnement est si compliqué, il est très difficile de dépanner.