Vor ungefähr einem Monat habe ich begonnen, für einen meiner Kollegen ein Programm in Java zu entwickeln. Ich bin der einzige, der daran arbeitet, und dies ist mein erstes ernsthaftes Projekt (was bedeutet, dass es von jemandem verwendet wird, nicht nur zum Spaß oder in der Schule).
Mein Kollege nimmt Informationen über das Programm von einer anderen Person außerhalb des Unternehmens (nennen wir ihn Bob) und gibt sie an mich weiter (Bob wird derjenige sein, der das Produkt verwendet, also erstelle ich das Programm eigentlich für ihn). einige Missverständnisse manchmal, aber nichts zu großes, alles ist absolut reparabel.
Das Problem ist, dass er mir manchmal sagt, ich solle einige Features implementieren, für die ich viele Codezeilen ändern muss. Am Anfang, als ich ungefähr 100 Zeilen geschrieben habe, war das keine große Sache, aber jetzt ist es definitiv zeit- und arbeitsaufwändig (da ich bei ungefähr 500 Zeilen bin und an diesem Punkt ungefähr 60 ändern und ungefähr 500 hinzufügen muss ). Ich weiß, dass es kein Problem gegeben hätte, wenn er von Anfang an klar gewesen wäre (und vielleicht ein Treffen mit Bob arrangiert hätte).
Meine Frage ist: Soll ich ihm davon erzählen und eine bessere und endliche Vorstellung davon bekommen, was ich tun muss, bevor ich wieder arbeite?
Dinge, die man beachten muss:
Ja, Sie sollten auf jeden Fall versuchen, so schnell wie möglich die bestmöglichen Informationen zu erhalten, wenn Sie mit der Entwicklung beginnen. Auch wenn Sie irgendwelche Hindernisse haben, die Ihrer Meinung nach Ihre Produktivität beeinträchtigen, sollten Sie versuchen, diese zu beheben. Es ist ein Zeichen von Professionalität, sich Hilfe zu holen, wenn man sich selbst nicht helfen kann!
In der Programmierwelt gibt es ein Sprichwort:
Wochenlanges Programmieren kann Ihnen Stunden der Planung ersparen!
Das ist also durchaus üblich. Es ist auch üblich, dass Sie nicht alle Informationen erhalten können und mit etwas anfangen müssen. Aber versuchen Sie Ihr Bestes und besprechen Sie dies mit Ihrem Kollegen!
Perfekte Anforderungen gibt es nicht. Sie verändern sich in allen Projekten im Laufe der Zeit. Es wird immer notwendig sein, Dinge nachzuarbeiten, die fertig waren. Das gehört zum Beruf und man sollte sich daran gewöhnen.
Anforderungen werden auch oft durch einen Filter von einer oder häufiger mehreren Personen geleitet, da es Entwicklern im Allgemeinen nicht erlaubt ist, direkt mit den Personen zu sprechen, die die Anforderungen erstellen, insbesondere nicht mit Junior-Entwicklern.
Sie können Änderungen jedoch durch gute Anforderungen und durch Zurückdrängen minimieren, anstatt Annahmen zu treffen, wenn Sie eine Anforderung nicht vollständig verstehen.
Dies ist einer der Gründe, warum es so wichtig ist, ein gutes Verständnis für die Geschäftsdomäne aufzubauen, in der Sie arbeiten. Es hilft Ihnen zu erkennen, wenn etwas in den Projektanforderungen fehlt oder falsch ist. Je mehr Klärungsbedarf Sie erkennen, bevor Sie mit dem Codieren beginnen, desto schneller geht die Codierung und desto weniger Dinge müssen nachgearbeitet werden (aber niemals keine, da einige Benutzer die Ergebnisse nicht gut visualisieren können und nicht wissen, dass etwas nicht funktioniert für sie, bis sie es sehen).
Was Sie bei jeder Anforderung tun sollten, die Sie erhalten, ist, nach Löchern darin zu suchen. Gibt es Orte, an denen es Entscheidungspunkte gibt, die Ihnen aber nur sagen, was Sie für einen möglichen Weg tun sollen? Gibt es Stellen, an denen Ihnen nicht klar ist, was gemeint ist? Welche Annahmen treffen Sie? Löschen Sie alle Annahmen als richtig, bevor Sie mit dem Codieren beginnen.
Gibt es Dinge, die fehlen, wie z. B. eine Beschreibung, was zu melden ist, nachdem die Daten in die Datenbank eingegeben wurden, oder eine Beschreibung, welche Datensicherheit vorhanden sein muss, wenn Sie personenbezogene Daten in eine Datenbank eingeben? Haben sie die erforderlichen Leistungsstufen erwähnt?
Verwendet die Anforderung Wörter, mit denen Sie nicht vertraut sind (schlagen Sie sie zuerst nach)? Wenn die Definition im Kontext keinen Sinn ergibt, bitten Sie um Klärung. Oft gibt es geschäftsbereichsspezifische Wörter, die für jeden, der mit der Domäne vertraut ist, eine unausgesprochene Bedeutung haben können. Indem Sie fragen, was sie meinten, können Sie einige Dinge herausfinden, von denen sie annahmen, dass sie alle wüssten. Die meisten der schlimmsten Unterbrechungen in Anforderungen, die ich gesehen habe, sind darauf zurückzuführen, dass der Benutzer Annahmen über Dinge trifft, die "jeder" weiß, aber der Entwickler nicht wusste.
Sie können Ihrem Kollegen vorschlagen, Sie in seine Interaktion mit Bob im Zusammenhang mit der Software einzubeziehen, indem Sie Sie entweder in den E-Mail-Austausch per CC setzen oder Sie zu den Besprechungen einladen. Denken Sie daran, dass es einen Grund geben könnte, warum er dies nicht tut, also lassen Sie Ihren Kollegen wissen, dass Sie dadurch Fehlinterpretationen in Bezug auf Bobs Anforderungen vermeiden können.
Sie sollten auf jeden Fall immer so viele Informationen wie möglich zu den Anforderungen einholen. Vereinbaren Sie sogar einmal pro Woche oder alle zwei Wochen ein Treffen mit Ihrem Kollegen und Bob, um direkte Informationen zu erhalten und das aktuelle Produkt vorzuführen!
Eine dünne, die ich vorschlagen würde, ist Clean Code von Robert C Martin. Wenn Sie Ihre Funktionalität in verschiedene Klassen und Methoden extrahiert haben, müssen Sie statt 60 Codezeilen nur wenige auf einmal ändern. Als Entwickler würde ich vorschlagen, sich von einer Klasse mit 500 Zeilen fernzuhalten und zu versuchen, Klassen nur eine Sache tun zu lassen, die Ihre Zeilen beispielsweise auf unter 200 begrenzt.
cdkMoose
Daniel
Laurent S.