So vermeiden Sie das Überschreiben von Teilen einer Anwendung

Ich arbeite in einem Unternehmen an einem Projekt für die Verkaufsabteilung. Es ist mein erster professioneller Programmierjob, aber ich habe jahrelang alleine programmiert und gelernt. Ein Teil des Projekts besteht darin, einige Daten zu erfassen und mit Eingaben zu kombinieren, um ein Diagramm zu erstellen. Speichern Sie dann die Daten ... usw. Also habe ich den Code dafür in weniger als einem Tag geschrieben. Am nächsten Tag zeigte ich meinem Projektleiter, und er mochte es, aber "was wäre, wenn wir das hätten", und wollte, dass ich etwas zum Diagramm hinzufüge. Dies war keine große Änderung des Aussehens oder der Funktion des Programms, aber es änderte drastisch, wie ich Daten speichern, verarbeiten usw. musste.

Ich brauchte erneut ungefähr einen Tag, um die Datenbanktabelle neu zu strukturieren und den Code im Grunde genommen von Grund auf neu zu schreiben, um diese neue Anforderung zu unterstützen. Ich brachte es ihm wieder zurück und genau das gleiche passierte. Er verlangte etwas anderes, was die Art und Weise, wie ich die Daten verarbeitete, drastisch veränderte. Also musste ich es nochmal umschreiben. Schließlich hat er sich abgemeldet, und ich hoffe, dass ich es nicht noch einmal schreiben muss.

Sei nur klar, ich werde meinen Manager nicht verprügeln oder so etwas. Er ist ein großartiger Kerl und die Dinge, die er verlangte, waren nicht von dieser Welt, sie waren einfach nicht kompatibel mit dem, was ich zuvor getan hatte.

Ich frage mich nur, ob ich in Zukunft etwas tun kann, um ein vollständiges Umschreiben zu vermeiden. Ich verstehe, wie man flexiblen Code erstellt, und habe versucht, dies zu tun, aber ich möchte nur wissen, welche Praktiken oder Dinge ich hätte anders machen können, um dies zu vereinfachen. Daher verbringe ich in Zukunft keine 3 Tage mit etwas, das hätte nehmen sollen 1.

Wie ich bereits sagte, habe ich das starke Gefühl, dass die Anforderungen beim ersten Mal nicht klar waren oder dass Sie wahrscheinlich einige wichtige Details übersehen haben.

Nicht alles kann mit besserem Code, Best Practices, Entwurfsmustern oder OOP-Prinzipien angegangen werden. Keiner von ihnen wird Sie daran hindern, die gesamte Anwendung zu wiederholen, wenn die Implementierung auf falschen Annahmen oder falschen Prämissen basiert.

Versuchen Sie nicht, die Lösung zu codieren. Bevor Sie ein einzelnes LOC eingeben, müssen Sie die Anforderungen klären. Je tiefer Sie tauchen Sie ein in die Anforderungen, desto mehr was , wenn Fragen auftauchen. Warten Sie nicht, bis der Manager Sie mit dem nächsten Was-wäre-wenn überrascht . Dinge selbst antizipieren. Diese kleine Übung kann den Überraschungsfaktor erheblich reduzieren .

Haben Sie keine Angst, so oft zu fragen, wie Sie brauchen. Manchmal lassen uns die Bäume (Details) den Wald (das Gesamtbild) nicht sehen. Und es ist der Wald, den wir zuerst sehen müssen.

Wenn die Anforderungen klar sind, ist es einfacher, während der Entwurfsphase bessere Entscheidungen zu treffen.

Denken Sie schließlich daran, dass das Gesamtbild ein Ziel ist. Der Weg zu diesem Ziel ist weder einfach noch unkompliziert. Änderungen werden weiterhin stattfinden, seien Sie also agil.

Es gibt keine Möglichkeit, dies basierend auf dem, was Sie gegeben haben, zu wissen. Es ist schneller und schmutziger, was Sie in diesem Moment brauchten. Aber dann hat es jemand gemocht und es wird komplex, und jetzt beginnt man zu sehen, dass sich viele Probleme erst zeigen, wenn die Komplexität einsetzt. Es gibt so viele verschiedene Dinge, die man tun kann. Es ist einfach überwältigend.

Es gibt das alte "No Silver Bullet" und es ist wahr. Auch hier gibt es keine Möglichkeit zu wissen, was mit vollständigen Spezifikationen (oder besser noch laufenden Spezifikationen für Agile) und der Fähigkeit zu tun ist, gute Programmierprinzipien und gute Designs zu verwenden. Programmierer lieben es, immer wieder neu zu schreiben . Ich sage nicht, dass Sie unbedingt darauf hereinfallen, weil es in diesem Moment klein ist.

Nutzen Sie diese Gelegenheit, um einige Grundprinzipien anzuwenden. Sie werden feststellen, dass sie funktionieren, aber dann wird jemand sagen: "Oh nein, das ist schlecht" oder Sie werden etwas anderes, das Sie mögen. Sie können nicht alles für das Geld des Unternehmens tun, aber wenn Sie Zeit zum Erkunden haben, nutzen Sie dies als Gelegenheit. Es gibt immer jemanden, irgendeine Grundlage, irgendeine Person, die die "beste" Art und Weise oder eine "neue" Art und Weise hat, Dinge zu tun.

Ihr Vorgesetzter hatte höchstwahrscheinlich in jedem Ihrer Schritte Recht. Dies liegt nicht daran, dass er der Manager ist, sondern daran, dass er die Ergebnisse und die Benutzerfreundlichkeit sowie wahrscheinlich die Anzahl der vorherigen Transaktionen mit Kunden oder Kundenanfragen berücksichtigt.

Die Benutzeroberfläche ist hart, normalerweise haben 5 Personen 15 verschiedene Ansichten. Und Daten und Datenstrukturierung und Datenanalyse ändern sich tendenziell, multiplizieren mit Faktor 10 :). UI ist wie Mode, manche Kombinationen sind cool, manche schrecklich oder es fehlt der gesunde Menschenverstand.

Ganz zu schweigen davon, dass zum Beispiel beim LEAN-Prozess nichts in Stein gemeißelt wird. Sie erleben so etwas wie eine iterative Bewertung und bei jedem Schritt ist es wenig besser oder es wird ein falscher Weg vermieden.

Die Antwort ist so einfach, dass es überhaupt kein Umschreiben gibt.

Iterative Entwicklung (was Sie im Grunde genommen getan haben, wenn auch eintägige Iterationen) ist oft so. Frühe Versuche, Lösungen zu finden, scheitern oft, und durch das Sammeln von Feedback gelangt das System zu einer Lösung. Die Abbildung 2.2 leihe ich mir aus Craig Larmans Lehrmaterial für sein Buch „ Applying UML and Design Patterns “ aus.

Zu Beginn eines Projekts lernen Sie, mit den scheinbar instabilen Versionen zu leben. Ich bin mit den Antworten nicht einverstanden, die besagen: "Man muss frühzeitig mehr Anforderungen stellen", denn das ist Wasserfalldenken. Es ist richtig, dass Sie sich bemühen sollten, so viele Anforderungen wie möglich zu erfüllen. Aus vielen Gründen ist es jedoch nicht möglich, vollständige und genaue Anforderungen zu erstellen.

Dies bedeutet nicht, dass Sie nicht reduzieren können, wie viel Sie neu schreiben müssen, nachdem Sie Feedback erhalten haben. Was häufig zutrifft, ist, dass sich die Mensch-Computer-Interaktion von Software sehr wahrscheinlich ändert, da es schwierig ist, dies beim ersten Mal zu korrigieren.

Denken Sie an Microsoft Word und wie sich das Datenformat (.doc) im Laufe der Jahre nicht wirklich weiterentwickelt hat. Das liegt daran, dass sich ein Textdokument als Problemdomäne nicht wirklich weiterentwickelt hat (eine Seite ist immer noch eine Seite, ein Absatz ist immer noch ein Absatz usw.). Die Benutzeroberfläche von Word hat sich jedoch stark weiterentwickelt (und ist es auch weiterhin). Der Code für die Präsentation oder Eingabe ist in der Regel zwischen den Versionen instabil. Daher ist es am besten, die anderen Teile des Systems nicht direkt mit ihnen zu verbinden (um sie vor dem Umschreiben zu schützen).

Softwarearchitekturen, die die Darstellung von der zugrunde liegenden Logik und den Daten zum Problem trennen können, ermöglichen ein geringeres Neuschreiben. Viele Softwaremuster wie die Model-View-Trennung sind darauf zurückzuführen, dass Menschen wie Sie unter vielen Umschreibungen gelitten haben und nach einem besseren Weg gesucht haben.

Das klingt vielleicht sehr buddhistisch, aber Sie können sich glücklich schätzen, diese Umschreibungen erlitten zu haben! So viele Menschen lernen etwas über MVC-Muster oder andere Entwurfsmuster, ohne die Albträume zu "erleiden", die durch die Muster vermieden werden sollen.

Ich habe keine Antwort, eher eine Übung - eine, die Sie wahrscheinlich in Ihrer eigenen Zeit machen müssen, obwohl Sie je nach Organisation möglicherweise die Erlaubnis erhalten, sie während der Arbeitszeit zu machen.

Entwerfen Sie Ihre erste Lösung neu, um genau das zu tun, was sie getan hat, aber vereinfachen Sie das Hinzufügen des zweiten oder zweiten und dritten Schritts. Fügen Sie diese Schritte nicht hinzu, streichen Sie sie nicht heraus. Erstellen Sie einfach eine Lösung, die alle ursprünglichen Anforderungen erfüllt, aber problemlos mit der neuen Funktion erweitert werden kann. Machen Sie dasselbe für Ihre 2. Lösung.

Anforderungen ändern sich, das ist eine Tatsache des Lebens. Rückblickend: Hätte die erste Lösung anders aussehen können, wäre die gesamte Programmierzeit kürzer gewesen? So lernst du mit Erfahrung umzugehen.

Das ist die erste steile Lernkurve. Wenn Sie dies schaffen, gibt es die zweite Herausforderung: Wie gehen Sie mit geänderten Anforderungen um, wenn Benutzer Daten im Wert von einem Jahr gespeichert haben, die sie nicht wegwerfen möchten?

Aus Ihrer Geschichte geht hervor, dass die Anforderungen und bevorzugten Architekturentscheidungen nicht gut genug kommuniziert wurden. Einer von Ihnen oder vielleicht beide sind schlechte Kommunikatoren.

Dies kann auch der Architekt sein, da einige Architekten einen hohen Stellenwert für gute Leistungen beim Programmieren alleine oder für eine gute Ausbildung (meistens auch für das Studieren alleine) oder dafür, dass sie der erste Entwickler im Unternehmen sind (offensichtlich alleine) Nicht unbedingt gut in der Kommunikation mit dem Team. Es ist nicht ungewöhnlich, dass sie sich weiterhin stark auf die Programmierung konzentrieren, anstatt Entwürfe zu dokumentieren und das Team zu unterstützen.

Aber auch in diesem Fall können Sie versuchen, dies zu kompensieren, indem Sie länger sprechen, Fragen stellen und Notizen machen. Sie können sogar selbst eine kleine Spezifikation schreiben und den Architekten bitten, diese zu genehmigen.