Welche erfolgreiche Konvertierung / Neuschreibung haben Sie an der Software vorgenommen, an der Sie beteiligt waren? Was waren die Sprachen und der Rahmen, die an dem Prozess beteiligt waren? Wie groß war die Software in Frage? Schließlich, was ist das Beste, was Sie gelernt haben, wenn Sie in den Prozess involviert sind.
Dies steht im Zusammenhang mit dieser Frage
Ich habe 20.000 Perl-Zeilen umgeschrieben, um "use strict" in jeder Datei zu verwenden. Ich musste "mein" hinzufügen, wo immer es gebraucht wurde, und ich musste die Fehler beheben, die während des Prozesses aufgedeckt wurden.
Das größte, was ich daraus gelernt habe, ist: "Es dauert immer länger als du denkst."
Ich musste es auf einmal über Nacht erledigen, damit die anderen Programmierer nicht gleichzeitig neuen, unfixierten Code schreiben würden. Ich dachte, es würde schnell gehen, aber es tat es nicht, und ich war immer noch am nächsten Morgen um 6 Uhr dran.
Ich habe es abgeschlossen und eingecheckt, bevor alle anderen mit der Arbeit begonnen haben!
Ich habe aus verschiedenen Gründen eine große Java-Webanwendung in eine ASP.Net-Anwendung für eine Immobilienfirma umgeschrieben.
Das Größte, was ich gelernt habe, ist, dass, egal wie trivial das Feature des ursprünglichen Systems ist, wenn es nicht im zweiten System ist, der Client denkt, dass das Neuschreiben ein Fehler ist. Erwartungsmanagement ist alles, wenn man das neue System schreibt.
Dies ist der Hauptgrund, warum das Umschreiben so schwierig ist: Es scheint dem Kunden so einfach zu sein ("Mach einfach das wieder, was ich bereits habe und füge ein paar Dinge hinzu.").
Der coolste für mich war meiner Meinung nach der Port von MAME zum iPod . Es war eine großartige Lernerfahrung mit eingebetteter Hardware, und ich konnte mit vielen tollen Leuten arbeiten. Offizielle Seite .
Ich schreibe ein Inhouse Project Managment System auf ein Standard MVC Modell um. Es ist in der LAMP-Stack (PHP) und ich bin in der Nähe des ersten Meilenstein.
Die Dinge, die ich daraus gelernt habe, ist, wie einfach sich das Programm am Anfang anfühlt, und ich habe versucht, die Komplexität nicht zu erhöhen, bis ich muss.
Beispiel ist, dass ich die ganze Funktionalität zuerst programmiert habe (wie ich ein Admin-Benutzer war) und dann, wenn das aussortiert wird, addiere die Schwierigkeit, Beschränkungen zu haben (Benutzerebenen usw.)
Ich habe eine PowerBuilder-App für mehrere hundert Bildschirme in eine ASP.NET-App (C #) portiert.
Aufgrund von Leistungs- und Wartungsproblemen hatte ich im vergangenen Jahr eine Tonne Embedded SQL aus den Powerbuilder-Skripten in gespeicherte Prozeduren verschoben.
Obwohl viele von Ihnen mit der Geschäftslogik in der Datenbank zusammenzucken würden, bedeutet dies, dass die Powerbuilder-App relativ "leicht" war und wir beim Aufbau des .Net-Frontends die Vorteile von SQL nutzen konnten Codebase und haben eine Menge Funktionalität bereits gebaut und getestet.
Ich sage nicht, dass ich empfehlen würde, Apps auf diese Weise zu erstellen, aber es hat in diesem Fall sicherlich zu unserem Vorteil funktioniert.
Wir hatten in unserem Anwendungsframework ein Codegenerierungstool, mit dem textbasierte Datendateien eingelesen wurden. Etwa 20 andere Anwendungen nutzten es.
Wir wollten XML-Dateien anstelle von strukturierten textbasierten Dateien verwenden. Der ursprüngliche Code war ziemlich veraltet und schwer zu pflegen. Wir haben dieses Tool durch eine Kombination aus XSLT-Skripten und einer Dienstprogrammbibliothek ersetzt. Für die Utility-Bibliothek könnten wir etwas Code im alten Tool verwenden.
Das Ergebnis war, dass alle 20 Anwendungen nun entweder das veraltete textbasierte Dateiformat oder das neue XML-basierte Format verwenden konnten. Außerdem haben wir ein Tool zur Konvertierungserstellung bereitgestellt, mit dem alte Datendateien in neue XML-Datendateien konvertiert wurden.
Nachdem wir ein oder zwei Releases veröffentlicht haben, haben wir nun entschieden, dass wir das alte textbasierte Format nicht mehr unterstützen werden und jeder seine Daten in XML konvertieren kann.
Wir mussten kaum manuelle Conversions durchführen,
Konvertiert die Hauptanwendungs-App von vordefiniertem C ++ in Standard-C ++. Wir hatten eine Verkaufsauslastung in Höhe von mehreren Millionen Dollar, damit es unter AIX funktioniert, und nachdem wir es betrachtet hatten, entschieden wir, dass die Umstellung auf C ++ genauso einfach sein würde wie die Umstellung auf IBMs traditionelles C ++.
Ich kenne die Zeilenanzahl nicht, aber der Quellcode lief auf Hunderte von Megabyte.
Wir haben Standard-Unix-Tools dazu verwendet, einschließlich vi und den verschiedenen Compilern.
Es hat ein paar Monate gedauert. Die meisten Fixes waren einfache, wurden vom Compiler abgefangen und fast mechanisch repariert. Einige von ihnen waren viel komplizierter.
Ich glaube, mein wichtigstes Ziel war: Machen Sie sich nicht allzu schlau mit Code in einer Sprache, die noch nicht standardisiert ist, oder dass sich Dinge auf unerwartete Weise ändern. Wir mussten einige der genialen Anpassungen / Missbräuche von C ++ - Streams gründlich durchforsten.
Vor zehn Jahren leitete ich ein Team, das ein CAD-System von DOS in Windows umwandelte. Die DOS-Version verwendete selbst erstellte Bibliotheken für Grafikzeichnungen, die Windows-Version verwendete MFC. Die Software umfasste zum Zeitpunkt der Konvertierung etwa 70.000 Zeilen C-Code. Das Wichtigste, was wir dabei gelernt haben, ist die Kraft der Abstraktion. Alle gerätespezifischen nicht-portablen Routinen wurden in wenigen Dateien isoliert. Es war daher relativ einfach, die Aufrufe der DOS-basierten Bibliothek, die durch den direkten Zugriff auf den Framebuffer mit Windows-API-Aufrufen zeichnen würde, zu ersetzen. In ähnlicher Weise haben wir für die Eingabe die Ereignisschleife, die auf Tastatur- und Mausereignisse geprüft hat, durch die entsprechende Windows-Ereignisschleife ersetzt. Wir haben unsere Richtlinie, den nicht portablen Code (diesmal Windows) vom Rest des Systems zu isolieren, fortgesetzt, aber das haben wir noch nicht für besonders nützlich befunden. Vielleicht werden wir eines Tages das System auf Mac OS X portieren und wieder dankbar sein.
Mehrere. Aber ich erwähne eins.
Es war ein Performance Modeling Tool. Teil Delphi 1, Teil Turbo Pascal. Es brauchte eine Neufassung, sonst würde es nicht überleben. Also starteten wir als 2er Team, aber nur ich überlebte bis zum Ende. Und ich war vor dem Stichtag fertig; -).
Mehrere Dinge, die wir gemacht haben:
Wir haben das hier wirklich sauber gemacht und am Ende hat es sich bezahlt gemacht. So eine große Lernerfahrung.
Ein System für ein Unternehmen neu geschrieben, das legale Rechnungen bearbeitet - das ursprüngliche System war eine VB-Monstrosität, die keine Ahnung von guten OO-Prinzipien hatte - alles war gemischt. Das HTML hat SQL und das SQL hat HTML geschrieben. Ein großer Teil davon war eine benutzerdefinierte Regel-Engine, die für die Regeln so etwas wie XML verwendete.
Zwei Teams haben das Neuschreiben durchgeführt, was ungefähr 9 Monate gedauert hat. Ein Team hat das Web-Frontend und den Backend-Workflow durchgeführt, während das andere Team (auf dem ich mich befand) die Regel-Engine neu geschrieben hat. Das neue System wurde in C # geschrieben und zuerst als Test ausgeführt. Das Hinzufügen neuer Regeln zu dem System, als wir fertig waren, war einfach und alles war testbar. Unterwegs haben wir Dinge wie die Umwandlung des Unternehmens von VSS in SVN, die Implementierung einer kontinuierlichen Integration, die Automatisierung der Bereitstellung und das Lehren der anderen Entwickler, wie man TDD und andere Scrum / XP-Praktiken durchführt, gemacht.
Das Management der Erwartungen war durch das Projekt entscheidend. Ein Kunde, der sich mit Software auskannte, war sehr hilfreich.
Eine Mischung aus umfangreichen (End-to-End-) Tests und umfangreichen Unit- und Integrationstests hat dazu beigetragen.
Konvertiert vBulletin, das in PHP geschrieben ist in C # / Asp.NET. Ich bin mit beiden Sprachen ziemlich vertraut, aber PHP ist der Gewinner der Gewinner dieser Software. Der größte Nachteil in der Rückseite war, dass man ein C # -Äquivalent von PHPs eval () zum Aufruf der Templates machen musste.
Es war meine erste Herausforderung, eine Conversion zu machen. Ich habe gelernt, dass ich mehr Erfahrung mit C # brauche und dass es manchmal einfacher ist, es von Grund auf neu zu schreiben.
Ich habe einen komplett in Perl geschriebenen dynamischen Build-Prozess in eine C # /. Net-Lösung umgewandelt, indem ich eine Workflow-Engine eines Mitarbeiters entwickelt habe (die noch in der Beta war - also musste ich etwas verfeinern). Das gab mir die Möglichkeit, dem Build-Prozess Ausfallsicherheits- und Failover-Funktionalität hinzuzufügen.
Bevor Sie fragen - nein - Microsoft Workflow-Foundation konnte nicht verwendet werden, da Sie einen Prozess während seiner Laufzeit nicht dynamisch ändern können.
Was ich gelernt habe:
Am Ende wurden ca. 5k - 6k (inkl. Wf-Engine) LoC-Ursprung aus 3 200 LoC Perl-Dateien abgedeckt. Aber es hat Spaß gemacht - und am Ende viel besser;)
Konvertieren von theoretisch portierbarem C-Code in theoretisch portablen C-Code über Architekturen, um eine Hardwareänderung zu unterstützen, die der Firma X Dollar pro Einheit erspart.
Die Größe variiert - das ist ein häufiges Bedürfnis, und ich habe kleine und große Projekte gemacht.
Ich habe gelernt, mehr portablen C-Code zu schreiben. Eleganz ist großartig, aber wenn es darauf ankommt, kümmert sich der Compiler um die Leistung und der Code sollte so einfach und portabel wie möglich sein.
Portierte eine in Fortran 77 geschriebene Simulation (obwohl sie in den 90er Jahren geschrieben wurde) nach C / Java, da das Original nur mit kleinen Datensätzen funktionierte. Ich habe gelernt, die große O-Notation zu lieben, nachdem ich mehrmals erklärt habe, warum die gesamte Datentabelle beim Start des Programms nicht in den Speicher verschoben werden konnte.
Migration der B-2 Stealth Bomber-Missionssoftware von JOVIAL nach C. 100% vollautomatische Konvertierung . Ernsthaft!
Haupt Lektion: mit konfigurierbaren automatisierten Konvertierungstools ist ein großer Gewinn .
Tags und Links refactoring code-migration