it-swarm.com.de

Wie gehe ich mit einer noch nicht implementierten Methode um, die von einem Co-Programmierer durchgeführt wird?

Dies ist eine Frage zur Arbeit in Teams.

Kürzlich habe ich mit einem Team von 6 Personen an meinem ersten größeren Programmierprojekt (~ 80 Klassen, Java) gearbeitet, obwohl nur 4 von uns kontinuierlich am Code gearbeitet haben. Wir haben die zu erledigende Arbeit frühzeitig verteilt und irgendwann musste ich eine Methode aufrufen, die noch nicht von einem meiner Co-Programmierer implementiert wurde. Wie ist der empfohlene Weg, um damit umzugehen?

Optionen, die ich gesehen habe, obwohl ich keine wirklich mag:

  1. Schreibe mir ein //TODO und überprüfen Sie diese Codezeile später erneut, um zu überprüfen, ob die Methode in der Zwischenzeit implementiert wurde.

  2. Bitten Sie das entsprechende Teammitglied, das jetzt zu implementieren .

  3. Auslösen einer benutzerdefinierten runtimeException mit einer klaren Beschreibung dessen, was noch nicht implementiert ist. (Zumindest müssen wir nicht lange suchen, um herauszufinden, was fehlt)

  4. Hinzufügen der erforderlichen Methode zu ihrer Klasse und Schreiben eines //TODO Senden Sie ihnen im Nachrichtentext möglicherweise auch eine kurze Nachricht über diese Änderung. (Jetzt ist es nicht mehr mein Problem, aber dies kann zu lästigen Zusammenführungskonflikten führen, wenn sie in der Zwischenzeit an dieser Methode gearbeitet haben.)

  5. Definieren Sie abstrakte Klassen oder Schnittstellen für alles, bevor Sie den Code schreiben, der die Arbeit erledigt. (Hat nicht gut funktioniert, da diese Schnittstellen oft geändert wurden)

45
lucidbrot

Es ist eine interessante Frage und die Antwort könnte einfacher sein als Sie denken.

Schreiben Sie einfach Tests, die Ihre Annahmen bestätigen. Es spielt keine Rolle, ob Sie die Implementierung durchführen oder Ihre Programmierkollegen

Die lange Antwort.

Alle Optionen, die Sie auflisten, sind etwas passiv und erfordern , dass Sie früher oder später zurückkehren und den Code (falls vorhanden) erneut aufrufen.

  • Kommentare müssen von Ihrem für die Implementierung verantwortlichen Gegenüber gelesen und behandelt werden. Ihr Code kann in der Zwischenzeit nicht kompiliert werden. Wenn Sie einen solchen Status in einem Code-Repository überprüfen, funktioniert Ihre Pipeline für die kontinuierliche Integration nicht und es ist sowieso eine schlechte Praxis ... Checken Sie niemals fehlerhaften Code ein
  • Laufzeitausnahmen scheinen besser zu sein, sind aber immer noch giftig, da Ihr Programmiererkollege davon ausgehen könnte, dass die Implementierung bereits ohne Überprüfung durchgeführt wurde, wodurch das System ebenfalls in einem instabilen Zustand bleibt. Wenn die Methode nicht so oft ausgelöst wird, kann dies zu einem fehlerhaften Produktionscode führen ... auch schlechte Praktiken ... checken Sie niemals "nicht implementierte" Ausnahmen ein
  • Warten auf Ihre Programmierkollegen auf die Implementierung der Methoden oder eines Stubs ist ebenfalls entmutigend. Es unterbricht Ihren Workflow und den Workflow Ihrer Programmierkollegen. Was passiert, wenn sie krank sind, in einer Besprechung in der Kaffeepause, möchten Sie Ihre Zeit mit Warten verbringen? ... warte nicht auf jemanden, wenn du nicht musst
  • implementiere die fehlenden Methoden definitiv der beste Weg, um vorwärts zu kommen. Aber was passiert, wenn Ihre Implementierung nicht den gesamten Anwendungsfall erfüllt und Ihre Programmierkollegen sie ändern oder ergänzen müssen? Wie stellen Sie und sie sicher, dass es noch mit Ihrem beabsichtigten kompatibel ist? Die Antwort ist wieder einfach. Schreiben Sie Tests, die Ihre Absichten bestätigen, beschreiben und dokumentieren. Wenn die Tests abbrechen, ist es leicht zu bemerken. Wenn Änderungen an dieser Methode vorgenommen werden müssen, die Ihre Funktion beeinträchtigen, wird sie sofort angezeigt. Sie haben beide einen Grund zu kommunizieren und zu entscheiden, was zu tun ist. Funktionalität aufteilen? Ändern Sie Ihre Implementierung usw. checken Sie niemals Code ein, der durch Tests nicht ausreichend dokumentiert ist

Um ein ausreichendes Testniveau zu erreichen, würde ich vorschlagen, dass Sie sich zwei Disziplinen ansehen.

  1. TDD - testgetriebene Entwicklung - dies stellt sicher, dass Sie Ihre Absicht beschreiben und ausreichend testen. Es gibt Ihnen auch die Möglichkeit, Methoden und Klassen (auch mithilfe von Schnittstellen) zu verspotten oder zu fälschen, die noch nicht implementiert sind. Der Code und die Tests werden weiterhin kompiliert und ermöglichen es Ihnen, Ihren eigenen Code isoliert vom Code Ihrer Programmierkollegen zu testen. (siehe: https://en.wikipedia.org/wiki/Test-driven_development )

  2. ATDD - Akzeptanztest-gesteuerte Entwicklung - Dadurch wird eine äußere Schleife (um die TDD-Schleife herum) erstellt, mit der Sie die Funktion als Ganzes testen können. Diese Tests werden erst grün, wenn die gesamte Funktion implementiert ist. Auf diese Weise erhalten Sie eine automatische Anzeige, wenn Ihre Kollegen ihre Arbeit abgeschlossen haben. Ganz ordentlich, wenn du mich fragst.

Vorsichtsmaßnahme: In Ihrem Fall würde ich nur einfache Abnahmetests schreiben und nicht versuchen, zu viel von der Geschäftsseite einzubeziehen, da dies zunächst zu viel wäre. Schreiben Sie einfache Integrationstests, in denen alle für die Funktion erforderlichen Teile des Systems zusammengefasst sind. Das ist alles was benötigt wird

Auf diese Weise können Sie Ihren Code in eine Pipeline für die kontinuierliche Integration einfügen und eine äußerst zuverlässige Implementierung erstellen.

Wenn Sie in diesem Thema weiter kommen möchten, überprüfen Sie die folgenden Links:

5
Jesko R.

Fragen Sie nach Stubs.

Oder schreiben Sie sie selbst. In jedem Fall müssen Sie und Ihre Mitarbeiter sich auf die Schnittstellen und deren Verwendungszweck einigen. Diese Vereinbarung muss relativ gefestigt sein, damit Sie gegen Stubs entwickeln können - ganz zu schweigen davon, dass Sie Ihre eigenen Mocks für Ihre Unit-Tests erstellen können. .

103
svidgen

In Ihrer Situation würde ich mit dem Teammitglied sprechen, das für diese Funktion verantwortlich ist. Es kann sein, dass sie in der Lage sind, die Entwicklung dieser Funktion zu priorisieren, damit Sie sie früher verwenden können.

Ich würde mich von Ihrer vierten Option fernhalten. Sie haben Ihren gesamten Code geschrieben und betrachten ihn, wie Sie sagen, nicht mehr als Ihr Problem. Ihr Kollege schreibt dann die Implementierung der Funktion und betrachtet sie nicht mehr als ihr Problem. Wer wird eigentlich testen, ob der von Ihnen geschriebene Code korrekt funktioniert?

6
Pete