Ich bin ein Junior-Entwickler und arbeite seit kurzem in einem sehr kleinen Büro, wo sie viel Eigenentwicklung betreiben. Ich habe noch nie in einem Projekt gearbeitet, an dem mehr als ein Entwickler beteiligt war, oder waren so groß und komplex wie diese.
Das Problem ist, dass sie nicht alle verfügbaren Tools (Versionskontrolle, automatisiertes Bauen, kontinuierliche Integration, etc.) in vollem Umfang nutzen: Hauptsächlich ist ein Projekt ein großes Projekt in eclipse / netbeans mit cvs für Versionskontrolle und Alles eingecheckt (einschließlich Bibliotheksgläser), sie begannen, Branching zum ersten Mal zu verwenden, als ich begann, Zweige für kleine Aufgaben zu machen und sie wieder zusammenzuführen. Wenn die Projekte größer und komplexer werden, entstehen Probleme mit Abhängigkeiten, die Projektstruktur ist an eine IDE gebunden, Bauen kann manchmal eine PITA sein, usw. Es ist bestenfalls hektisch.
Ich möchte eine Entwicklungsumgebung einrichten, in der die meisten dieser Probleme verschwinden und ich Zeit und Mühe sparen kann. Ich möchte Projekte in einer von der Versionsverwaltung unabhängigen Version erstellen (ich lehne mich SVN zu), vermeide Abhängigkeiten und automatisiere so viel wie möglich.
Ich weiß, dass es dafür mehrere Ansätze und Instrumente gibt und ich möchte nicht, dass ein heiliger Krieg beginnt. Ich würde sehr gerne praktische Empfehlungen schätzen, die auf Erfahrungen basieren und was Sie bei ähnlichen Problemen als nützlich empfunden haben. Alle Projekte sind Java-Projekte und reichen von Web-Anwendungen bis hin zu "generischen" Projekten. Ich benutze Eclipse die meiste Zeit, verwende aber auch Netbeans, wenn nötig. Vielen Dank im Voraus.Sie scheinen fast genau an der Stelle zu sein, an der ich gearbeitet habe, als ich vor 1,5 Jahren dort angefangen habe, nur dass Sie angefangen haben, mit Ästen zu spielen, was wir eigentlich immer noch nicht tun bei meiner Arbeit, aber dazu später mehr in dieser Antwort.
Wie auch immer, Sie führen eine sehr gute Auswahl an Werkzeugen auf, die einem kleinen Unternehmen helfen können und die als Unterthemen wirklich gut funktionieren, also ohne weitere Umstände,
Am häufigsten verwenden kleine Unternehmen derzeit CVS oder SVN und es gibt nichts Schlechtes daran, in der Tat würde ich wirklich besorgt sein, wenn überhaupt keine Versionskontrolle wirklich verwendet würde. Allerdings müssen Sie die Versionskontrolle richtig verwenden, damit Sie Ihr Leben nicht einfacher machen. Wir verwenden derzeit CVS und schauen uns Mercurial an, aber wir haben festgestellt, dass das Folgende als gute Konventionen beim Arbeiten funktioniert mit CVS (und ich würde auch SVN vermuten):
Denken Sie immer daran, dass der Quellcode für die Softwarefirma Ihre Einkommensquelle ist und Ihren gesamten Geschäftswert enthält, also behandeln Sie ihn so. Auch, wenn Sie zusätzliche 70 Minuten haben, empfehle ich wirklich, dass Sie dieses Gespräch Linus Thorvalds bei Google über < a href="http://git-scm.com/"> git und (d) VCS im Allgemeinen, es ist wirklich aufschlussreich.
Diese sind ungefähr gleich. Daily Builds ist ein PR-Witz und hat wenig Ähnlichkeit mit dem Zustand der eigentlichen Software jenseits einiger sehr rudimentärer "Kompiliert es " Probleme. Sie können eine Menge schreckliches Code-Rauschen kompilieren, das nichts bewirkt. Die Qualität der Software zu halten, hat nichts damit zu tun, dass der Code kompiliert wird.
Auf der anderen Seite ist Komponententests ein guter Weg, um die Softwarequalität zu erhalten, und ich kann mit ein bisschen persönlichem Stolz sagen, dass rigorose Komponententests sogar den schlimmsten Programmierern helfen, sich zu verbessern und dumme Fehler zu erkennen. In der Tat gab es bisher nur drei Bugs, dass Code, den ich geschrieben habe, Produktionsumgebungen erreicht hat und ich würde sagen, dass das in 18 Monaten eine verdammt gute Leistung ist. In unserem neuen Produktionscode haben wir normalerweise eine Anweisung Codeabdeckung von + 80%, meistens + 90% und in einem speziellen Fall den ganzen Weg bis zu 98% erreichen. Dieser Teil ist sehr lebhaft und man googelt besser für folgende Themen: TDD, BDD, Komponententests, Integrationstests, Abnahmetests, xUnit, Mock-Objekte.
Das ist ein bisschen ein langes Vorwort, ich weiß. Das tatsächliche Fleisch für all das oben genannte ist das: Wenn Sie automatisierte Builds haben wollen, lassen Sie sie jedes Mal auftreten, wenn jemand festlegt, und stellen Sie sicher, dass es eine ständig steigende und sich verbessernde Anzahl von Komponententests für den Produktionscode gibt. Haben Sie das kontinuierliche Integrationssystem Ihrer Wahl (wir verwenden Hudson CI ), führen Sie alle Komponententests aus, die sich auf das Projekt beziehen, und akzeptieren nur Builds, wenn Alle Tests bestehen. Mach keine Kompromisse! Wenn Komponententests zeigen, dass die Software defekt ist, reparieren Sie die Software.
Continuous Integration-Systeme dienen darüber hinaus nicht nur zum Kompilieren von Code, sondern sollten auch zum Verfolgen des Status der Softwareprojektmetriken verwendet werden. Für Hudson CI kann ich all diese Plugins empfehlen:
Dies ist eine kontroverse Frage. Grundsätzlich stimmen alle darin überein, dass eine einheitliche Struktur groß ist, aber da es mehrere Camps mit unterschiedlichen Anforderungen, Gewohnheiten und Ansichten gibt, stimmen sie eher nicht zu. Zum Beispiel glauben Maven-Leute wirklich, dass es nur einen Weg gibt - den Maven-Weg - Dinge zu tun, und das ist es, während
Da wir also nicht die von externen Parteien auferlegte Projektstruktur verwenden, werde ich Ihnen ein wenig darüber erzählen, wie wir in unsere aktuelle Projektstruktur eingegriffen haben.
Am Anfang haben wir einzelne Projekte für die eigentliche Software und die damit verbundenen Tests (normalerweise Produkt und Produkt_TEST genannt) verwendet. Das ist sehr nah an dem, was Sie haben, ein riesiges Verzeichnis für alles mit den Abhängigkeiten als JARs direkt im Verzeichnis enthalten. Wir haben beide Projekte aus CVS ausgecheckt und dann das eigentliche Projekt als Laufzeitabhängigkeit mit dem Testsoftwareprojekt in Eclipse verknüpft. Ein bisschen klobig, aber es hat funktioniert.
Wir haben schnell erkannt, dass diese zusätzlichen Schritte völlig nutzlos sind, da Sie Ant verwenden - Sie können übrigens Ant-Aufgaben aufrufen direkt in Hudson - wir könnten dem JAR / WAR-Erstellungsschritt mitteilen, alles entweder durch den Dateinamen (etwa alles, was mit Test oder TestCase endet) oder durch den Quellordner zu ignorieren. Ziemlich bald haben wir unser Software-Projekt so umgestaltet, dass wir eine einfache Struktur mit zwei Stammordnern, src und test , verwenden. Seitdem haben wir nicht zurückgeblickt. Die einzige Debatte, die wir derzeit haben, ist, ob wir einen dritten Ordner namens spikes in unserer Standard-Projektstruktur zulassen sollten, und das ist keine sehr hitzige Debatte.
Das hat sehr gut funktioniert und erfordert keine zusätzliche Unterstützung oder Plugins von irgendwelchen IDEs da draußen, was ein großes Plus ist - der zweite Grund, warum wir Maven nicht ausgewählt haben, war zu sehen, wie M2Eclipse hat Eclipse übernommen. Und da Sie sich wundern müssen, war der Hauptgrund für die Ablehnung von Maven die Ungeschicklichkeit von Maven selbst, die endlose Menge an langwierigen XML-Deklarationen für die Konfiguration und die damit verbundene Lernkurve wurde als ein zu großer Kostenfaktor angesehen / p>
Interessanterweise hat uns später der Wechsel zu Ivy statt zu Maven eine reibungslose Umstellung ermöglicht, um eine Grails -Entwicklung zu entwickeln, die Ordner und verwendet Klassennamen als Konventionen für fast alles beim Strukturieren der Webanwendung.
Auch eine letzte Notiz über Maven, während es behauptet, Konvention über die Konfiguration zu fördern, wenn du die Dinge nicht genau so machen willst, wie die Maven-Struktur sagt, du solltest Dinge tun, bist du in einer Welt der Schmerzen für die vorgenannte Gründe. Sicher ist das ein erwarteter Nebeneffekt von Konventionen, aber keine Konvention sollte nicht endgültig sein, es muss immer etwas Raum für Änderungen geben, die Regeln verbiegen oder das Passende aus einer bestimmten Menge auswählen.
Kurz gesagt, meine Meinung ist, dass Maven eine Bazooka ist, du arbeitest in einem Haus und dein ultimatives Ziel ist, es frei von Insekten zu haben. Jeder von diesen ist gut für sich und funktioniert, auch wenn Sie zwei von ihnen auswählen, aber die drei zusammen funktionieren einfach nicht.Solange Sie weniger als 10 code-zentrierte Personen haben, haben Sie die nötige Flexibilität, um die wichtigen Entscheidungen zu treffen. Wenn du darüber hinaus gehst, musst du mit allen Entscheidungen leben, die du getroffen hast, egal wie gut oder schlecht sie sind. Glauben Sie nicht einfach Dinge, die Sie im Internet hören, setzen Sie sich hin und testen Sie alles gründlich - ach ja, unser leitender Techniker hat sogar seine Bachelorarbeit über Java-Web-Frameworks geschrieben, nur um herauszufinden, welche wir verwenden sollten - und wirklich herausfinden, was Sie tun wirklich brauchen. Verpflichten Sie sich zu nichts, nur weil Sie einige der Funktionen benötigen, die es in ferner Zukunft bietet, wählen Sie diejenigen Dinge aus, die die geringstmögliche negative Auswirkung auf das gesamte Unternehmen haben. Da ich die 10. Person bin, die an die Firma angeheuert wurde, an der ich arbeite, kann ich alles in diesem Paragraphen mit meinem eigenen Blut unterschreiben, wir haben derzeit 16+ Leute, und das Ändern bestimmter Konventionen wäre an dieser Stelle ein bisschen beängstigend.
Unser Entwicklungsstack (Team von 10+ Entwicklern)
Dieses Setup gilt als Standard für unser Unternehmen, da viele Abteilungen diese Tools verwenden und es viel Erfahrung und Community-Unterstützung für diese gibt.
Sie haben absolut Recht damit, so viel wie möglich zu automatisieren. Wenn Ihre Kollegen beginnen, die Vorteile zu erkennen, wenn Aspekte der Entwicklungsphasen automatisiert werden, werden sie ermutigt, sich selbst zu verbessern. Natürlich ist jedes neue Technologie-Gimmick ("Tool") eine neue Last und muss verwaltet und aufrechterhalten werden. Hier wird die Anstrengung bewegt. Sie sparen Zeit, z.B. Wenn Maven Ihre Veröffentlichungen automatisch ausführt, verschwenden Sie jedoch Zeit mit der Verwaltung von Maven. Meine Erfahrung ist, dass jedes Mal, wenn ich ein neues Werkzeug (eines der oben genannten) einführe, es Zeit braucht, um übernommen und gepflegt zu werden, aber am Ende bringt es Vorteile für das ganze Team, wenn echter Wert erfahren wird - besonders. in Zeiten von Stress, wenn die Werkzeuge einen Großteil der Arbeit übernehmen, müssten Sie manuell tun.
Ein schöner, bewundernswerter Instinkt. Ein großes Lob an Sie.
Ein Teil Ihres Problems wird möglicherweise nicht mithilfe von Tools gelöst. Ich würde sagen, dass das Quellcode-Management etwas Arbeit braucht, weil es nicht nach Verzweigung, Markierung und Zusammenführung klingt. Du brauchst etwas Training und Kommunikation, um das zu lösen.
Ich habe CVS nicht selbst benutzt, daher kann ich nicht sagen, wie gut es diese Praktiken unterstützt. Ich werde darauf hinweisen, dass Subversion und Git bessere Entscheidungen treffen würden. Im schlimmsten Fall sollten Sie das Buch " Red Bean von Subversion lesen, um einen generellen Rat zur Verwaltung des Quellcodes zu erhalten.
Ich persönlich bin kein Maven-Fan. Ich glaube, es ist zu schwer, besonders im Vergleich zu Ant und Ivy. Ich würde sagen, dass mit denen mit Cruise Control die Lösung für viele Ihrer Probleme sein könnte.
Sie haben Unit-Tests nicht erwähnt. Beginnen Sie mit dem Erstellen von TestNG- und Fit-Tests in Ihrem Build-Zyklus.
Schau dir IntelliJ an - ich denke, es ist eine bessere IDE als entweder Eclipse oder NetBeans, aber das bin nur ich.
Viel Glück.
Maven ist großartig, aber es kann ein bisschen eine Lernkurve haben, und es erfordert, dass das Projekt zu einer sehr spezifischen Dateistruktur passt. Wenn Sie ein großes Legacy-Projekt haben, kann es schwierig sein, es zu mavenisieren. In diesem Fall würde Ant + Ivy das gleiche tun, ohne die strengen Anforderungen, die Maven hat.
Für Build-Automatisierung ist Hudson großartig. Ich habe ein paar verschiedene Systeme verwendet, aber das ist zweifellos am einfachsten einzurichten und zu verwalten.
Ich empfehle, Maven zum Erstellen Ihrer Projekte zu verwenden. Maven verwendet den Wert für das Projekt, weil:
Für das Projekt- und Repository-Management verwende ich trac mit Subversion .
Hier ist, was ich gerade benutze, aber ich werde wahrscheinlich ein paar Teile wechseln (siehe das Ende dieses Posts).
Eclipse als IDE mit ein paar Plugins: JADClipse (um dekompilieren .class im laufenden Betrieb, ziemlich nützlich), DBViewer für eine schnelle Zugriff auf die Datenbank über Eclipse, WTP (Web Tools Platform) integriert in Eclipse für die Ausführung von Tomcat 6 als Entwicklungs-Webserver (ziemlich schnell), Mylyn (verlinkt mit JIRA Bug-Tracker).
Ich wundere mich auch über "IDE-unabhängige Projekte", jetzt sind wir alle an Eclipse gebunden - Eclipse-Projektdateien (.project, .classpath, .settings) werden sogar in das CVS-Repository geschrieben (um eine Projekt vollständig fertig, sobald ausgecheckt) - aber mit Netbeans, unterstützt von Sun und läuft mit jedem Release (und jeder neuen JRE-Version) schneller und schneller, ist die Frage nicht geschlossen.
CVS zum Speichern von Projekten, mit fast keinen Zweigen (nur für Patches).
Ich arbeite an der Produktion der Umgebung mit Oracle SGBDR , aber ich verwende HSQLDB auf meinem Entwicklungscomputer den Test- und Build- und Entwicklungsprozess viel schneller machen (mit Hilfe des Open-Source-Tools DDLUtils , um die Datenbankerstellung und Dateninjektionen zu vereinfachen) ). Ansonsten verwende ich SQLWorkbench für schnelle BD-Aufgaben (einschließlich Schemasvergleich) oder das Oracle (kostenlos) SQLDeveloper für einige Oracle-spezifische Aufgaben (wie das Sperren von Sitzungen usw.).
Tests sind nur JUnit -Tests (entweder einfache Unit-Testfälle oder komplexere Testfälle (fast "Integrationen"), die fast immer auf HSQLDB ausgeführt werden, um schneller zu laufen.
Mein Build-System ist Ant (gestartet von Eclipse) für verschiedene kleine Aufgaben (z. B. das Hochladen eines Krieges auf einem Remote-Server) und (hauptsächlich) Maven 2 für:
Das fortlaufende Integrations-Frontend ist Luntbuild und das Frontend für das Maven-Repository ist Archiva .
Das alles funktioniert. Aber ich bin ziemlich enttäuscht von einigen Elementen dieses Ökosystems.
Hauptsächlich Maven, es ist einfach zu zeitaufwendig und ich habe viel Leid im Vergleich zu diesem Tool. Konflikten Abhängigkeiten Auflösung ist ein Witz. Viele XML-Zeilen in jeder POM.xml, redundant in jedem Projekt (auch mit Hilfe einiger POM-Wurzeln). Plugins sind viel zu inkonsistent, fehlerhaft und es ist wirklich schwierig, eine klare Dokumentation zu finden, die erklärt, was zu konfigurieren ist usw.
Ich frage mich also, ob ich von Maven zu ANT + Ivy wechseln sollte. Für das, was ich bisher gesehen habe, scheint es ziemlich cool zu sein (es gibt verschiedene Konflikt-Manager für die Konfliktabhängigkeiten-Auflösungen und Sie können sogar Ihren eigenen Konflikt-Manager schreiben), es muss kein zusätzliches Werkzeug installiert und konfiguriert werden (als ANT läuft nativ unter Eclipse, während Maven ein separates Plugin benötigt - ich habe übrigens die 3 Mavens Plugins ausprobiert und alle drei Buggy gefunden.
Aber Maven 3 ist auf dem Weg, ich werde es versuchen, aber ich erwarte nicht, dass es sich grundlegend von Maven 2 unterscheidet.
Hudson scheint auch eine bessere Wahl zu sein als Luntbuild, aber dieser Teil wird sich für den Augenblick nicht ändern.
Und Subversion wird wahrscheinlich CVS in naher Zukunft ersetzen (auch wenn ich fast keine Probleme mit CVS habe).
Hier gibt es viele gute Ratschläge. Ich habe nur ein paar Ergänzungen:
Ich denke, dass eine IDE im Gegensatz zu den anderen ein persönliches Werkzeug ist und jeder Entwickler sollte die Freiheit haben, diejenige auszuwählen, die am besten für ihn funktioniert. (Zum Beispiel, viele lieben Eclipse, während ich es für NetBeans aufgegeben habe, weil die Maven-Integration in Eclipse problematisch war.)
Ich dachte, ich würde Maven hassen, aber jetzt komme ich ziemlich gut damit klar. Das Hauptproblem, das ich in diesen Tagen habe, ist herauszufinden, wo die Konventionen dokumentiert sind.
Ich würde empfehlen, Werkzeuge einzeln einzuführen. Wenn Sie versuchen, alle Aspekte der Softwareentwicklung in einem Handbetrieb in einem Schlag zu mechanisieren, wird es wahrscheinlich massiven Widerstand geben. Machen Sie Ihren Business Case und stimmen Sie sich mit einem guten, gemeinsamen Tool ab, oder holen Sie sich einfach die Erlaubnis, es für Ihre Zwecke einzurichten, aber auf eine allgemein zugängliche Weise und lassen Sie die Leute sehen, was es für Sie tut. Nach ein paar von diesen werden die Leute die Angewohnheit haben sich zu fragen, wie Aspekt X automatisiert werden könnte, so dass zusätzliche Tools einfacher einzuführen sein sollten.
Das Beste, was Sie tun können, ohne andere Leute und deren Arbeitsweise zu stören, ist, Hudson einzurichten, um das CVS-Repository für jedes Ihrer Projekte anzusehen. Wenn Sie das tun, erhalten Sie einen zentralen Ort, um cvs Commit-Nachrichten zu sehen.
Der nächste Schritt besteht darin, diese Projekte unter Hudson zu kompilieren. Für Eclipse bedeutet dies normalerweise, entweder zu ant zu wechseln oder - wie wir es taten - ant4eclipse zu verwenden, um den bestehenden Eclipse-Build-Prozess zu modellieren. Nicht einfach, aber sehr lohnenswert. Denken Sie daran, Mails zu versenden, wenn der Build bricht - das ist extrem wichtig. Ant4eclipse erfordert Team-Projekt-Sets, die Sie in Ihrem Unternehmen einführen können. Machen Sie Ihre Kollegen glücklich, wenn sie das nächste Mal einen neuen Arbeitsbereich einrichten müssen.
Wenn Sie eine Situation haben, in der Ihre Sachen ordnungsgemäß erstellt werden, wenn jemand Änderungen vornimmt, dann überlegen Sie sich, ob der Code automatisch erstellt wird, um den Code tatsächlich an den Kunden zu senden. Da es auf dem Build-Server und nicht auf einem Entwicklungscomputer erstellt wurde, wissen Sie , dass Sie den Build reproduzieren können. Das ist von unschätzbarem Wert in einer "hey fix diese alte Version" -Situation.
Tags und Links java project-management version-control build-automation