Frage Was sind gemeinsame Java-Web-Entwicklungspraktiken? [geschlossen]


Ich würde gerne mehr über Java-Webentwicklungspraktiken von Entwicklergruppen mit mindestens zwei Teams lernen - Webdesigner und Webkomponentenentwickler. Insbesondere interessiere ich mich für Dinge wie:

  1. Unter der Annahme, dass ein Code-Repository vorhanden ist, checken alle Teams eine lokale Kopie aus alle Code? Wenn ja, warum sollte ein Web-Designer Zugriff auf Back-End-Code haben / benötigen, und warum sollte ein Web-Komponenten-Entwickler Zugriff auf Front-End-Code benötigen?

  2. Wie testet jeder Teammitglied, unabhängig vom Team, seinen Code? Veröffentlichen sie den Code auf ihrer lokalen Workstation, einer einzelnen Instanz auf einer Entwicklungsumgebung oder einer konsolidierten Entwicklungsumgebung?

  3. Wie werden Integration und Tests durchgeführt? Angenommen, ein Webdesigner erstellt eine Anmeldeseitenseite und der Webkomponentenentwickler erstellt den Back-End-Code zum Verarbeiten und Einfügen der Daten in die Datenbank - wie würde der Front-End- und Back-End-Code integriert werden und getestet?

Jegliche zusätzliche Information, die sich auf Java-Web-Entwicklungspraktiken von Entwicklungsgruppen bezieht, die ich nicht speziell angefragt habe, aber relevant ist, teile bitte.

BEARBEITEN (FOLLOW-UP): Ich schätze die Antworten, sie haben die meisten konzeptionellen Lücken gefüllt, die ich über Java-Web-Entwicklung hatte. Allerdings habe ich ein paar Follow-up-Fragen -

  1. Tests, insbesondere automatisierte Tests, sind eindeutig wichtige Bestandteile der Java-Webentwicklung. aber was macht einen guten "Test" aus? Angenommen, ein Java-Back-End-Entwickler erstellt einfach Code, der Formulardaten akzeptiert, validiert und dann in eine Datenbank einfügt / aktualisiert. Was wäre ein guter Test in diesem Szenario? Wie könnte dies außerdem "automatisiert" werden?

  2. Kann jemand eine Kontinuitätsintegration erklären - d. H. Ist es sein Zweck, nur den gesamten Projektcode zu kompilieren? Oder hilft es beim automatisierten Testen? Von dem, was ich verstehe, überwachen Integrationen Server Repositories für Commits und beim Commit den neu modifizierten Code aus und kompilieren den ganz Projekt; Bei erfolgreicher / fehlgeschlagener Kompilierung werden die Benutzer benachrichtigt.


7
2017-10-21 15:13


Ursprung


Antworten:


  1. Wir checken immer den Quellcode aus, den wir bekommen können. Quellcode für externe Bibliotheken, Backend-Systeme und die Werke. Das Lesen von Code von Backend-Systemen erleichtert es den Frontend-Entwicklern zu verstehen, was vor sich geht. Backend-Entwickler lesen manchmal Frontend-Code, um zu sehen, wie die Dinge tatsächlich genutzt werden. Mehr Code ist ein gute Sache. Maven unterstützt auch das automatische Herunterladen von Quellcode, was großartig ist.

  2. Wir verwenden Maven, und ich empfehle es wirklich in einer Teamumgebung. Wir implementieren lokal, auf Team zentralisierten Testservern und gemeinsamen Akzeptanzumgebungen. Je näher man "Zuhause" kommt, desto günstiger können die Dinge getestet werden.

  3. Wir verwenden Selen für viele Tests, die es ermöglichen, "von vorne" einer richtig eingesetzten Webapp zu testen. Darüber hinaus werden die meisten Integrationstests, die Teile des Stacks ausführen, als reguläre Junit-Tests in einem Maven-Profil ausgeführt.


4
2017-10-21 15:20



Wie wir es in unserem Team machen:

  1. Ja. Jedes Mitglied checkt den gesamten Code aus, obwohl Sie nicht alle Teile bearbeiten. Sie müssen die Anwendung auf Ihrem lokalen Computer ausführen, während Sie daran arbeiten, die von Ihnen vorgenommenen Änderungen schnell anzuzeigen. Die Frontend-Leute müssen den Backend-Code ausführen, um die Front-End-Effekte zu sehen.

  2. Während der Codierung führt jedes Mitglied den Code auf seiner eigenen Maschine aus. Wenn es eingecheckt ist, wird es als Ganzes auf einem speziell dafür vorgesehenen Server getestet.

  3. Tests sollten so weit wie möglich automatisiert werden. Jedes Teammitglied schreibt Testcode für seinen Teil des Codes, der ebenfalls eingecheckt wird. Sie können einen Continuous Integration Server verwenden, um diese Tests automatisch auszuführen. Aber der erste Test wird tatsächlich auf dem lokalen Rechner durchgeführt. Wenn ich den Code auschecke, dann ändere ich eine Backend-Klasse, ich führe den Code aus und stelle sicher, dass er auf meinem Rechner funktioniert, aktualisiere alle Tests, die aktualisiert werden müssen und setze meine Änderungen fest. Die automatisierten Tests laufen auf dem Server, um sicherzustellen, dass die verschiedenen Commits alle gut zusammenarbeiten.

Ich kann nicht sagen, ob das das Beste der besten Praxis ist, aber es ist eine praktische Übung für unser sehr kleines Team von nur 4 Entwicklern.


4
2017-10-21 15:22



  1. Das hängt von Ihrer Projektstruktur ab. Normalerweise halten sich java webapp-Projekte an die Maven-Projektkonvention. Wenn Sie ein Projekt für Web- und Backend-Funktionen haben, müssen alle Team-Mitarbeiter Quellen auschecken. Wenn die Struktur in Web- und Backend-Projekt aufgeteilt wird, kann jedes Team nur ihre Projekte auschecken.
  2. Wenn Sie Maven verwenden, können Sie die Anwendung natürlich bereitstellen. Sehr empfehlenswert ist die Verwendung von CI (Continuous Integration) Server wie Hudson. Antoher sehr wichtiger Aspekt ist die Verwendung geeigneter Plugins (Maven oder Hudson) wie Selentests oder ein anderes Web-Test-Framework.
  3. Integrationstest werden von Maven / Hudson natürlich mit ein wenig Hilfe von Plugins gemacht :). Ich habe es erwähnt Selen, das könnte sein Canoo WebTest oder ein anderes Test-Framework, das manchmal für Framework oder Technologie geeignet ist, die Sie für die Entwicklung auswählen.

Zusammenfassend folge dem Maven-Weg.


3
2017-10-21 17:18



Bei der ersten Frage sollten Sie in der Regel den Quellcode für jede einzelne Zeile in einer Stack-Trace anzeigen können (dies bedeutet auch, dass Sie JDKs für die Entwicklung verwenden, wenn Eclipse die src.zip-Datei automatisch an die Laufzeitbibliotheken anhängt) Es liegt außerhalb Ihres eigenen Fachgebiets.

Also, schau dir alles an, was du kannst. Es wird Ihnen eines Tages helfen - auch Programmierer neigen dazu, besseren Code zu schreiben und besser zu dokumentieren, wenn sie wissen, dass das ganze Team es immer sehen wird.

Für Entwicklung und Bereitstellung. Sie können alles tun, was Sie möchten, um Ihren Code zu entwickeln und zu testen, aber jeder Code, der in der Produktion oder außerhalb des Teams läuft, MUSS von einer Maschine erstellt worden sein (dies gewährleistet die Reproduzierbarkeit). Wir benutzen Hudson dafür, aber das ist nur ein Zufall. Die neuesten Starter-Team-Lizenzen für Atlassian Bamboo könnten bedeuten, dass wir das auch nutzen.


2
2017-10-21 17:17



In unserem Team ...

  1. Es ist unsere Praxis, eine neue Kategorie im Repository für neue Entwicklungen zu erstellen und sie dann in den zu etikettierenden Stamm zu verschmelzen, wenn sie bereit sind, in der Produktion eingesetzt zu werden. Also checken wir die gesamte Branche aus, an der wir arbeiten. Mit SVN können auch mehrere Coder an der gleichen Datei wie SVN arbeiten. Die Datei wird nicht gesperrt und Sie können sie später zusammenführen, aber das ist ein seltener Fall. Die automatische Zusammenführung funktioniert nicht immer und Sie müssen einige manuelle Zusammenführungen durchführen.

  2. Die ersten Tests werden lokal durchgeführt und dann in einer Entwicklungsumgebung und dann in einer Akzeptanzumgebung durchgeführt. Der in der DEV und Acceptance Umgebung getestete Code wird von Luntbuild / ANT erstellt und in unserem ApplicationServer über Jythons-Skripte bereitgestellt. Wir implementieren oder erstellen niemals manuell außerhalb der lokalen Umgebung. Wenn möglich, bitten wir andere Teammitglieder, diese Einsätze zu testen.

  3. Mit der Cactus-API können Sie den jUnit-Test für Servlets / Struts / Web-App "aufrüsten". Wir machen einen Stresstest mit JMeter und Selenium (nettes Firefox-Plugin) für einige andere Tests. Sie können auch Coverage-Tools (wie EMMA) ausführen, die Sie darüber informieren, welcher Prozentsatz des Codes von Ihren jUnit / Cactus-Tests abgedeckt wird.


1
2017-10-21 15:53



Angenommen, es gibt ein Code-Repository, überprüfen alle Teams eine lokale Kopie des gesamten Codes? Wenn ja, warum sollte ein Web-Designer Zugriff auf Back-End-Code haben / benötigen, und warum sollte ein Web-Komponenten-Entwickler Zugriff auf Front-End-Code benötigen?

Dies hängt davon ab, wie groß und wie modular Ihr Projekt / Build ist. Bei großen Projekten mit großer Codebasis ist ein modularer Ansatz und binäre Abhängigkeiten ein Muss. Dies wird die lokale Buildzeit drastisch verbessern. Wenn ich an Modul A arbeite (das von B abhängt), möchte ich B nicht während der Entwicklungszyklen kompilieren. Das würde mich verlangsamen, das ist nervig. Ich bevorzuge eine binäre Abhängigkeit von B (und wenn es nötig ist, kann ich B noch auschecken und lokal kompilieren).

Wie testet jeder Teammitglied, unabhängig vom Team, seinen Code? Veröffentlichen sie den Code auf ihrer lokalen Workstation, einer einzelnen Instanz auf einer Entwicklungsumgebung oder einer konsolidierten Entwicklungsumgebung?

Verwenden Sie dedizierte Umgebungen pro Entwickler für Web-Server, Anwendungsserver, Datenbankinstanzen (siehe Verwenden Sie eine Datenbankinstanz pro Entwickler). Teammitglieder sollten in der Lage sein, neu zu starten, wann immer sie wollen, ohne andere zu stören (auch wenn ich befürworte, die während der Entwicklung "im Container verbrachte Zeit" zu minimieren, d. H. Komponententests isoliert zu bevorzugen). Ziehen Sie daher die lokale Workstation für alles vor, was neu gestartet werden muss: Webserver, Anwendungsserver usw. Die lokale Bereitstellung ist oft auch einfacher. Für die Datenbank ist eine entfernte Datenbankinstanz im Allgemeinen in Ordnung (und möglicherweise besser, wenn Sie beispielsweise einen großen Oracle-Server haben). Verwenden Sie eine konsolidierte Entwicklungsbox für den kontinuierlichen Integrationsprozess.

Wie werden Integration und Tests durchgeführt? Angenommen, ein Webdesigner erstellt eine Anmeldeseitenseite und der Webkomponentenentwickler erstellt den Back-End-Code zum Verarbeiten und Einfügen der Daten in die Datenbank - wie würde der Front-End- und Back-End-Code integriert werden und getestet?

Teste sie zuerst separat. Mock / Stub das Back-End bei Bedarf. Dann teste das Ganze. Bei der Durchführung von Integrations- oder Funktionstests, die mit der Datenbank interagieren, empfiehlt es sich, die Datenbank immer in einen bekannten Status zu versetzen, bevor Sie den Test ausführen (siehe Gutes Setup muss nicht aufgeräumt werden!). DBUnit kann dabei helfen. Kaktus ist ein weiteres gutes Werkzeug für das serverseitige Testen, z. Integrationstest. Um Funktionstests, also End-to-End-Tests, durchzuführen, Selen oder Webtreiber sind gute Kandidaten. Für Akzeptanztests (oder BBD) untersuche ich gerade Gurke und ich mag es.


1
2017-10-23 16:05