Wie zu Überzeugen-Team Gehen zu Lassen, die Alten Weisen?

https://stackoverflow.com/questions/493460

20-08-2019
|

Frage

Dies ist eher ein business-orientierte Programmierung Frage, die ich kann nicht scheinen, um herauszufinden, wie Sie zu beheben.Ich arbeite mit einem team von Programmierern, die mit gearbeitet haben BASIC für über 20 Jahre.Ich wurde gebracht in zu helfen das gleiche schreiben software .NETTO, nur mit updates und modernen Praktiken.Das problem ist, dass ich kann nicht scheinen, um eine der anderen 3 Teams(alle BASIC-Programmierer, aber man tut .NET jetzt auch), um zu verstehen, wie man richtig tun, eine relationale Datenbank.Hier ist die Sache, die Sie nicht verstehen:

Wir haben im Grunde eine Transaktion, die hält track von Kunden, ein tag-Informationen.Wir müssen in der Lage sein zu verfolgen aktuelle Bewegungen und vergangene Transaktionen.Im alten system, eine Flatfile-Datenbank verwendet wurde, hatte eine Tabelle aus, die Datensätze mit den grundlegenden aktuellen Transaktion des Kunden, und eine andere Transaktion, die alle vorherigen Transaktionen des Kunden zusammen mit den wichtigsten Geld-Informationen.Um zu verhindern, dass Redundanz, würden Sie überschreiben die aktuelle Transaktion mit der Geschichte von Transaktionen(die Geschichte Datei wurde aktualisiert ersten, dann der aktuelle.) Es ist völlig unnötig, da müssen Sie nur eine Transaktion Tisch, aber mein Vorgesetzter oder meine anderen zwei co-Arbeiter kann nicht scheinen, dies zu verstehen.Wie genau kann ich Sie davon überzeugen, das Licht zu sehen, damit wir nicht zu tun haben lächerliche Beträge von Arbeit und am Ende schlagen die datatabse too many times?Vielen Dank für den input!

Lösung

Erstens muss ich zugeben, es ist nicht ganz klar, um mich von Ihrer Beschreibung, was die Daten-Strukturen und Logik fließt in die bestehenden Strukturen tatsächlich sind.Dies bedeutet für mich, dass du vielleicht nicht machen Sie sich klar zu Ihrer co-Arbeiter, also zu einem der Schwerpunkte muss in der Lage sein zu erklären, sei es mündlich oder vorzugsweise schriftlich und Diagramme, die aktuelle situation und die vorgeschlagene Ersatz.Bitte nehmen Sie dies als eine Beobachtung, die sich eher als Kritik an deiner Frage.

Zweitens finde ich es durchaus bemerkenswert, dass Programmierer mit 20 Jahren Erfahrung nicht verstehen, relationale Datenbanken und Transaktionen.Flat-file-coding ging aus dem mainstream eine sehr lange Zeit - habe ich zuerst behandelt relationale Datenbanken in ein kommerziellen Einstellung im Jahr 1988-und Sie waren ziemlich alltäglich durch die Mitte der 90er Jahre.Was ist Sektor-und Produkt-Typ sind Sie mit der Arbeit auf?Es klingt mir möglich, die Sie vielleicht zu tun haben mit irgendeiner Art von embedded-oder sonst 'ungewöhnliche' - system, in welchem Fall Sie tun müssen, um sicherzustellen, dass Sie nicht über irgendeine Art von Kommunikation-Problem und Sie sind mit Blick auf einen großen Elefanten, die noch nicht darauf hingewiesen worden - Sie wäre nicht die erste "Berater" brachte in ein team, das eingerichtet wurde, in irgendeiner Weise durch nicht gefüttert werden die entsprechenden Informationen ein., Dass sagte, diese archaischen shops haben noch existieren - eines meiner aktuellen Kunden-Systeme Schnittstellen zu einer flat-file-basiertes system codiert, die in COBOL, und ja, es ist die Hölle zu verwalten ;-)

Endlich, wenn Sie absolut sicher sind, dass von Ihrem Boden, und Sie sind konfrontiert mit einem team, das nicht an Bord nehmen Ihre Empfehlungen - und Demo-code ist eine gute Idee, wenn Sie können die Zeit -dann werden Sie wahrscheinlich haben, um diese Entscheidung zu akzeptieren anmutig und bewegen ein.Selbst in dieser position würde ich versuchen, zu abstrahieren, sich die Frage - können die Datenbank-updates werden verschoben in gespeicherte Prozeduren, zum Beispiel so, dass der code zu aktualisieren beiden Tabellen in der SP und kann geändert werden zu einem späteren Zeitpunkt zu verschieben, um das schema ohne eine entsprechende Applikation ändern?Stellen Sie sicher, dass Ihre Argumente sind gut dokumentiert und aufgezeichnet, so dass Sie kann überarbeiten Sie später sollte sich die Gelegenheit ergeben.

Sie werden nicht die ersten coder, der zur Implementierung einer sub-optimalen Lösung, da der office-Politik - verwenden Sie es als eine Lernerfahrung für Ihre eigene persönliche Entwicklung über den Umgang mit solchen Situationen und bemitleiden sich selbst mit dem Gedanken, dass Sie bezahlt werden, für die zusätzliche Arbeit.Oft der entscheidende Faktor in der solche Argumente nicht die Logik, sondern das Gewicht der Ruf' Sie selbst an den Tisch bringen - es klingt wie eingebracht, die Sie nicht haben viel von dieser Art von Hebelwirkung, die Sie mit Ihrem team, so können Sie zu arbeiten haben, um auf einen Ruf von exceling an der Umsetzung, was Sie tun, einverstanden zu tun, bevor Sie genügend Ruf in den nachfolgenden Fällen - Sie müssen modded zuerst!

Andere Tipps

Manchmal kann man nicht.

Wenn Sie einige XP Bücher lesen, sagen sie oft, dass einer Ihrer größten Hürden Ihr Team werden zu überzeugen, aufzugeben, was sie immer getan haben.

Im Allgemeinen werden sie empfehlen die Menschen im Stich gelassen, die in andere Projekte nicht anpassen können gehen (Oder einfach lassen sie gehen).

Code-Reviews könnte in Ihrem Fall helfen. Mandatory Code-Reviews jeder Zeile des Codes ist nicht unbekannt.

Einige Zeit das beste Argument ist ein Beispiel. Ich würde einen Prototyp (oder einen Ersatz, wenn nicht zu viel Arbeit) schreiben. Mit einem Beispiel zu prüfen, es leichter sein wird, die Vor- und Nachteile einer relationalen Datenbank zu sehen.

Als Neben Flat-File-Datenbanken haben ihre Plätze, da sie so viel leichter zu „verwalten“ als eine echte relationale Datenbank sind. Seien Sie offen. ; -)

Ich denke, man kann mit gutem Beispiel voran haben - wenn die Leute sehen, dass die „neue“ Art und Weise weniger Arbeit ist, werden sie es annehmen (solange Sie nicht die Nase reiben)

Ich würde dich auch fragen, ob das alte Design ist tatsächlich ein Problem verursacht, oder ob es nur ästhetisch störend ist. Es ist wichtig, Ihre Schlachten zu holen - wenn das alte Design ist nicht ein Leistungsproblem oder das System wird schwer zu pflegen, wodurch Sie das alte Design in Ruhe lassen sollen.

Schließlich, wenn Sie das alte Design in Ort tun lassen, versuchen und abstrakt die Schnittstelle zwischen den neuen Code und der alten Datenbank so, wenn Sie Ihre Mitarbeiter tun überzeugen, um den Entwurf zu verbessern später können Sie das neue Schema fallen in ohne mit auf etwas anderes zu ändern.

Es ist schwierig, eine ganze Menge außer allgemeiner Frustration aus der ursprünglichen Frage zu extrahieren.

Ja, es gibt viele Techniken und Gewohnheiten Langzeitgeber im Laufe der Zeit ansammeln, die angesichts der technologischen Veränderungen nutzlos und sogar kostspielig sein können. Einige Dinge, die Sinn macht, wenn Rechenleistung, Speicher und sogar Scheibe war teuer kann jetzt töricht Versuche Optimierung sein. Es ist auch sehr sehr der Fall, dass die Menschen schlechte Gewohnheiten und schlechte Programmierung Muster im Laufe der Zeit ansammeln.

Man muss aber vorsichtig.

Manchmal gibt es gute Gründe für die Dinge, die alten Zeiten zu tun. Leider können sie nicht einmal in der Lage sein, das „Warum“ verbalisieren -. Wenn sie einmal, warum mehr wissen

Ich sehe eine Menge von dieser Art von Frustration, wenn Neulinge in einen Enterprise-Software-Entwicklung Laden kommen. Es kann schlecht sein, auch wenn die Umgebung all ziemlich moderne Technik und Werkzeuge ist. Wenn die meisten Ihrer Erfahrung sind viel kleine Community Desktop und Web-Anwendungen in dem Schreiben, was Sie „wissen“ kann falsch sein.

Oft gibt es Anforderungen für die Transaktion auf einem Niveau Journaling über das, was Sie DBMS tun kann. Nicht selten kann es notwendig sein, über DB Transaktionssemantik zu gehen, um Zeitfolgerichtigkeit, einmal und nur einmal zu aktualisieren, resiliancy, und Nachweisbarkeit.

Und das nicht einmal ansatz der Probleme in Unternehmen oder zwischen Unternehmen Skalierbarkeit beteiligt zu adressieren. Wenn Sie beginnen täglich eine halbe Million komplexe Transaktionen nähern werden Sie feststellen, dass RDBMS-Technologie Sie schlägt fehl. Da relationale Datenbanken nicht zu handhaben hohe Transaktionsvolumen ausgelegt müssen Sie häufig mit Standard-Paradigmen für die Normalisierung und die Aktualisierung durchbrechen. Herkömmliche RDBMS Verriegelungstechniken können Skalierbarkeit zerstören, egal wie viel Hardware Sie auf das Problem werfen.

Es ist einfach alles als Schwerfälligkeit oder allgemeine falsch Innigkeit zu entlassen - auch Inkompetenz. Aber seien Sie vorsichtig, da dies nicht immer der Fall ist.

Und übrigens: Es gibt andere Modelle außer dem RDBMS, und die Alternative zu einem RDBMS ist nicht unbedingt „Flat Files“ - im Gegensatz zu den Erfahrungen der meisten Programmierer heute. Es gibt Transaktions hierarchisches DBMS, die viel höheren Durchsatz als ein RDBMS verarbeiten kann. IMS ist immer noch sehr lebendig in großen IBM Geschäften, zum Beispiel. Andere Anbieter bieten ähnliche Software für verschiedene Plattformen.

Natürlich in einem 4-Mann-Shop vielleicht nichts davon gilt.

Melden Sie sie für ein paar anständige Trainings und dann ist es an Ihnen, sie zu überzeugen, dass mit neuen Technologien viel mehr möglich ist (oder zumindest einfacher!).

Aber ich denke, das Wichtigste dabei ist, dass professionelle, zertifizierte Trainer sie zuerst die Grundlagen beibringen. Sie werden mehr beeindruckt, dass statt nur eines ihrer Kollegen sagen ihnen: „hey, warum nicht diese verwenden“