Es wurde mir gesagt, dass ich der einzige Entwickler hinter einem großen neuen System sein werde. Unter anderem werde ich ein UI und ein Datenbankschema entwerfen.
Ich bin mir sicher, dass ich eine Anleitung bekommen werde, aber ich würde gerne in der Lage sein, ihnen die Socken zu klopfen. Was kann ich in der Zwischenzeit tun, um mich vorzubereiten, und was muss ich beachten, wenn ich mich mit der Spezifikation an meinen Computer setze?
Ein paar Dinge zu beachten: Ich bin ein College-Student bei meinem ersten echten Programmierjob. Ich werde Java verwenden. Wir haben SCM bereits mit automatisierten Tests usw. eingerichtet, so dass Tools kein Problem darstellen.
Wissen Sie viel über OOP? Wenn ja, schauen Sie in Spring und Hibernate, um Ihre Implementierung sauber zu halten und orthogonal . Wenn Sie das bekommen, sollten Sie TDD eine gute Möglichkeit finden, Ihr Design kompakt und schlank zu halten, besonders da Sie "automatisiertes Testen" in Betrieb haben.
UPDATE: Wenn ich die ersten Antworten ansehe, kann ich nicht mehr widersprechen. Insbesondere im Java-Bereich sollten Sie viele Mentoren / Ressourcen finden, um Ihre Anwendung mit Objects zu erstellen, kein datenbankzentrierter Ansatz . Datenbank-Design ist in der Regel der erste Schritt für Microsoft-Leute (die ich täglich, aber bin in einem Wiederherstellungsprogramm, äh, Alt.Net). Wenn Sie sich darauf konzentrieren, was Sie an einen Kunden liefern müssen, und lassen Sie Ihr ORM herausfinden, wie Sie Ihre Objekte beibehalten, sollte Ihr Design besser sein.
Das klingt sehr nach meinem ersten Job. Direkt nach der Universität wurde ich gebeten, die Datenbank und die Geschäftslogikschicht zu entwerfen, während andere sich um die Benutzeroberfläche kümmern würden. Währenddessen schaute der Chef über meine Schulter und war nicht willens, das zu verlassen, was früher sein Baby war und jetzt mein war, und steckte seinen Finger hinein. Drei Jahre später flohen die Entwickler aus dem Unternehmen und wir waren noch X Monate davon entfernt, etwas zu verkaufen.
Der große Fehler war, zu ehrgeizig zu sein. Wenn dies Ihr erster Job ist, werden Sie Fehler machen und Sie müssen ändern, wie die Dinge funktionieren, lange nachdem Sie sie geschrieben haben. Wir hatten alle möglichen Funktionen, die das System komplizierter als nötig machten, sowohl auf Datenbankebene als auch in der API, die es anderen Entwicklern präsentierte. Am Ende war das Ganze einfach viel zu kompliziert, um alle gleichzeitig zu unterstützen und einfach zu sterben.
Also mein Rat:
Wenn Sie sich nicht sicher sind, ob Sie eine so große Arbeit alleine übernehmen, dann tun Sie das nicht. Sagen Sie Ihren Arbeitgebern und lassen Sie sie jemanden finden oder einstellen, mit dem Sie arbeiten können, der Ihnen helfen kann. Wenn Leute zu dem Projekt hinzugefügt werden müssen, dann sollte es in der Nähe des Starts gemacht werden, und nicht nachdem die Dinge falsch laufen.
Überlegen Sie sich genau, wofür das Produkt geeignet ist und kochen Sie es auf die einfachste Reihe von Anforderungen, die Sie sich vorstellen können. Wenn die Leute, die Ihnen die Spezifikation geben, nicht technisch sind, versuchen Sie zu sehen, was sie geschrieben haben, was tatsächlich funktioniert und Geld verdient. Sprechen Sie mit Kunden und Verkäufern und verstehen Sie den Markt.
Es ist keine Schande zuzugeben, dass du falsch liegst. Wenn sich herausstellt, dass das gesamte System neu geschrieben werden muss, weil Sie in Ihrer ersten Version einen Fehler gemacht haben, ist es besser, dies so schnell wie möglich zuzulassen, damit Sie es erreichen können. Versuchen Sie dementsprechend nicht, eine Architektur zu erstellen, die jede mögliche Kontingenz in Ihrer ersten Version vorwegnimmt, weil Sie nicht wissen, was jede Kontingenz ist und werden es nur falsch verstehen. Schreib einmal mit dem Auge, wegzuwerfen und wieder anzufangen - du musst vielleicht nicht, die erste Version mag in Ordnung sein, aber gib es zu, wenn du es tust.
Ich stimme auch nicht mit der Datenbank zu beginnen. Die DB ist einfach ein Artefakt dafür, wie Ihre Geschäftsobjekte persistent sind. Ich kenne keine Entsprechung in Java, aber .Net hat stellare Werkzeuge wie SubSonic , die Ihrem DB-Design erlauben, flüssig zu bleiben, wenn Sie iterieren durch Ihre Geschäftsobjekte Design. Ich würde in erster Linie sagen (noch bevor Sie entscheiden, welche Technologien eingeführt werden), konzentrieren Sie sich auf den Prozess und identifizieren Sie Ihre Substantive und Verben ... dann bauen Sie aus diesen Abstraktionen aus. Hey, es funktioniert wirklich in der "echten Welt", genau wie OOP 101 es dir beigebracht hat!
Bevor Sie mit dem Programmieren beginnen, planen Sie Ihr Datenbankschema aus - alles andere wird davon ausgehen. Wenn Sie die Datenbank früh genug korrigieren, sparen Sie später Zeit und Probleme.
Die Hauptsache ist, dass Sie die Komplexität des Systems abstrahieren können, so dass Sie sich nicht davon verzetteln, sobald Sie anfangen.
Lesen Sie zuerst die Spezifikation wie eine Geschichte (durchstreichen). Hören Sie nicht bei jeder Anforderung auf, es genau dort zu analysieren. So erhalten Sie ein Gesamtbild des Systems ohne zu viele Details. An diesem Punkt würden Sie beginnen, die wichtigsten funktionalen Komponenten des Systems zu identifizieren. Fangen Sie an, diese herunter zu setzen (verwenden Sie ein Mindmap-Tool, wenn Sie möchten).
Nehmen Sie dann jede Komponente und beginnen Sie, sie zu explodieren (und jedes Detail mit den Anforderungen im Spezifikationsdokument zu verbinden). Tun Sie dies für alle Komponenten, bis Sie alle Anforderungen abgedeckt haben.
Nun sollten Sie sich die Beziehungen zwischen den Komponenten ansehen und feststellen, ob es Wiederholungen von Features oder Funktionen zwischen den verschiedenen Komponenten gibt (die Sie dann herausziehen können, um Hilfskomponenten zu erstellen oder ähnliches). Um diese Zeit haben Sie eine gute detaillierte Karte Ihrer Anforderungen in Ihrem Kopf.
JETZT sollten Sie darüber nachdenken, die Datenbank, ER-Diagramme, Class Design, DFDs, Deployment usw. zu entwerfen.
Das Problem mit dem letzten Schritt zuerst ist, dass Sie in der Komplexität Ihres Systems stecken bleiben können, ohne wirklich ein Gesamtverständnis zu bekommen.
Ich mache es andersherum. Ich finde, dass das Datenbankschema - zuerst - das System in einem datengetriebenen Design festhält, das nur schwer aus der Persistenz zu abstrahieren ist. Wir versuchen, Domänenmodell-Designs zuerst zu erstellen und dann das Datenbankschema auf diesen zu basieren.
Und dann ist da noch das Infrastruktur-Design: Das Team sollte sich auf Konventionen über die Strukturierung des Programms in erster Linie einigen. Und dann arbeiten wir zusammen, um uns zunächst auf ein Design für die allgemeine Funktionalität des Systems zu einigen (z. B. Dinge, die jeder braucht, wie Persistenz, Protokollierung usw.). Dies wird der Rahmen des Systems.
Wir arbeiten alle zusammen daran, bevor wir den Rest der Funktionalitäten unter uns aufteilen.
Ich habe die Erfahrung gemacht, dass Java-Anwendungen (auch .NET), die die Datenbank zuletzt berücksichtigen, mit hoher Wahrscheinlichkeit schlecht funktionieren, wenn sie in einer Unternehmensumgebung platziert werden. Sie müssen wirklich über Ihr Publikum nachdenken. Du hast nicht gesagt, ob es eine Web-App war oder nicht. In beiden Fällen ist die Infrastruktur, die Sie implementieren, wichtig, wenn Sie überlegen, wie Sie mit Ihren Daten umgehen.
Ganz gleich, welche Methode Sie in Betracht ziehen, wie Sie Ihre Daten erhalten und speichern, und deren Auswirkungen auf die Leistung sollten als eine Ihrer Prioritäten auf Platz 1 ganz oben stehen.
Ich würde vorschlagen, darüber nachzudenken, wie diese Anwendung verwendet wird. Wie werden zukünftige Benutzer damit arbeiten? Ich bin mir sicher, dass Sie zumindest ein paar Dinge darüber wissen, was diese Anwendung zu handhaben hat, aber mein erster Rat lautet: "Denken Sie an den Benutzer und was er oder sie braucht".
Zeichnen Sie es auf Normalpapier und überlegen Sie, wo Sie den Code abtrennen können. Denken Sie daran, Logik nicht mit GUI-Code zu mischen (allgemeiner Fehler). Auf diese Weise können Sie die Reichweite Ihrer Anwendungen in Zukunft auf Servlets und / oder Applets oder andere Plattformen erweitern. Abschnitt in Ebenen, damit Sie schneller auf große Änderungen reagieren können, ohne alles neu zu erstellen. Ebenen sollten keine anderen Ebenen als ihre nächsten benachbarten Ebenen sehen.
Beginnen Sie mit der wahren Kernfunktionalität. All diese zeitraubende Flaum (das wird Ihr Projekt 4 Wochen zu spät), ist nicht wichtig für die Mehrheit der Benutzer. Es kann später hinzugefügt werden, sobald Sie sicher sind, dass Sie pünktlich liefern können.
Übrigens. Auch wenn das nichts mit Design zu tun hat, möchte ich nur sagen, dass Sie nicht pünktlich liefern werden. Machen Sie eine realistische Schätzung des Zeitverbrauchs und verdoppeln Sie sie dann :-) Ich gehe hier davon aus, dass Sie nicht alleine in diesem Projekt sein werden und dass die Leute kommen und gehen werden, während das Projekt voranschreitet. Sie müssen vielleicht mitten im Projekt Leute schulen, Leute machen Urlaub / brauchen eine Operation usw.
Teilen Sie das große System in kleinere Teile auf. Und denken Sie nicht, dass es so komplex ist, weil es normalerweise nicht so ist. Wenn Sie zu komplex denken, ruinieren Sie nur Ihre Gedanken und schließlich das Design. Irgendwann merkt man einfach, dass man das Gleiche leichter machen kann, und dann gestaltet man es neu.
Das war zumindest mein großer Fehler beim Entwerfen.
Halten Sie es einfach!
Ich habe sehr aufschlussreiche Ideen zum Start eines neuen großen Projekts gefunden, basierend auf
in dem Buch Wachsende objektorientierte Software, geführt von Tests .
Es ist noch in der Entwicklung, aber die ersten drei Kapitel könnten das sein, was Sie suchen und IMHO, die es wert sind, gelesen zu werden.
Tags und Links java architecture design oop