So vermeiden Sie das Überschreiben von Teilen einer Anwendung

13

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.

SH7890
quelle
2
Welches Programmierparadigma verwenden Sie? Prozedural, objektorientiert, funktional, sonstiges?
Tulains Córdova
2
Um Überschreibungen zu vermeiden, entkoppeln Sie Ihre Datenbank und Ihre Anwendungsebene. Es ist kein einfaches Konzept, wie Sie Code schreiben. Es ist ein komplexes Konzept, das Ihren Code einfach und anpassungsfähig macht.
StackOverFowl
6
Es sieht so aus, als wären die Anforderungen nicht klar oder Sie haben sie falsch verstanden. Kein Prinzip oder Best Practice kann Sie davor bewahren, eine ganze Anwendung erneut durchzuführen, wenn die Implementierung aufgrund falscher Annahmen vorgenommen wurde. Bevor Sie ein einzelnes LOC eingeben, sollten Sie nach den Anforderungen " Was wäre wenn ... " fragen. Warten Sie nicht, bis der Manager Sie mit einem neuen Was wäre wenn ... überrascht . Wenn Sie einige Zeit auf der Suche nach Funktionslücken verbringen, wird sich auch der Überraschungsfaktor verringern .
Laiv
3
Dependency Injection ist dein Freund. Google es und finde heraus, wie du es auf deine Sprache / dein Framework anwenden kannst. Dadurch können Sie einen wesentlich modulareren Code schreiben, wodurch die Menge des Codes verringert werden sollte, der bei Änderungen der Anforderungen neu geschrieben werden muss.
Eternal21
2
Während es so aussieht, als ob viele Neuschreibungen eine schlechte Sache sind, ist es wirklich wichtig, wie schnell Sie auf Anfragen Ihrer Endbenutzer reagieren können. Obwohl es von der Komplexität des Projekts abhängt, würde ich sagen, dass 1 Tag eine ziemlich gute Vorlaufzeit ist - Sie müssen etwas richtig machen! In der Tat ist Software, die signifikante Änderungen sieht, ein gutes Zeichen - sie bedeutet, dass sie nützlich ist und sich verbessert. Software, die seit Jahren nicht wesentlich verändert wurde, ist viel schwieriger zu warten.
Justin

Antworten:

22

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.

Laiv
quelle
3
Dies. Diese Antwort ist der beste Weg, es auszudrücken. Holen Sie sich diese Voraussetzungen, bevor Sie überhaupt etwas tun.
Rhys Johns
1
Dies ist eine gute Antwort, aber ich habe das unangenehme Gefühl, dass es eine bessere Möglichkeit gibt, die Anwendung so zu strukturieren, dass diese Anforderungen leichter berücksichtigt werden können. Ich glaube nicht, dass eines der so genannten "Prinzipien" helfen würde; Die Lösung muss spezifisch für das Problem sein. Ohne weitere Informationen ist Ihre Antwort die einzige, die Sinn ergibt.
Frank Hileman
Nun, ich hatte das starke Gefühl, dass das Problem das war, das ich kommentiert habe, weil es genau das war, was mir in meinen frühen Tagen als Entwickler passiert ist. Ich übersetzte Phrasen sofort in LOC oder Module, und als ich etwas ändern musste, war das für mich ziemlich dramatisch. Refactor über Refactor jeden Tag oder jede Woche. Ich gebe nicht einmal mein Bestes mit SoC, SPR, Polymorphismus, ... Viele der Konflikte, die ich mit Veränderungen hatte, wurden durch mein allgemeines Sehvermögen verursacht.
Laiv
2
Aufbauend auf dieser Antwort: Es ist wichtig, auch beim Sammeln von Anforderungen agil zu sein. Manchmal bekommen die Leute neue Ideen oder erinnern sich an etwas, das sie vergessen haben, als sie das Produkt gesehen haben. Sie sagen vielleicht: "Ich weiß, dass ich dich gebeten habe, das zu bauen, aber es ist nicht das, was ich gemeint habe." Sie können dies verhindern, indem Sie einen schnellen und schmutzigen "Proof of Concept" erstellen. Dies kann sogar ein Modell wie eine gefälschte Grafik sein. Es hilft Ihrem Kunden beim Nachdenken.
Akhil
1
Einige mögen argumentieren, dass das Abstrahieren der Datenbank aus dem Code kein Muss ist, weil "Datenbankanbieter sich selten ändern". Ich stimme Ihnen zu, aber meine Antwort lautet: Vergessen Sie beim Sammeln von Anforderungen, dass Sie Entwickler sind. Konzentrieren Sie sich auf das Sammeln von Anforderungen. Denken Sie wie ein Manager, fragen Sie wie ein Manager. Denken Sie nicht wie ein Entwickler.
Laiv
4

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.

Johnny
quelle
Guter Artikel, den Sie verlinkt haben.
SH7890
1
Guter Artikel in der Tat! Ich denke, das ist nicht der OP-Fall, aber ich könnte dem Autor nicht mehr zustimmen.
Laiv
1
Ich dachte nicht, dass es eins für eins war, aber es las sich so, als könnte es eines Tages sein. Hoffentlich hilft das dem OP.
Johnny
2

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.

ipavlu
quelle
2

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.

Bildbeschreibung hier eingeben

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.

Fuhrmanator
quelle
Ich würde es vorziehen, wenn diese Antwort akzeptiert würde. Es ist besser, auf eine Lösung hinzuarbeiten, als alle Anforderungen von vornherein festzulegen. Vor allem, wenn die gesamte Anwendung innerhalb eines Tages neu geschrieben werden kann.
Euphoric
Ich bin sicher, der Chef wusste nicht, was er in der zweiten Wiederholung wollte, bis die erste abgeschlossen war. „Es wäre unmöglich gewesen, vorher mehr Anforderungen zu stellen.
gnasher729
1

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.

jmoreno
quelle
1

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?

gnasher729
quelle
-1

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.

h22
quelle