Frage Wie arbeiten Programmierer zusammen an einem Projekt?


Ich habe immer alleine programmiert, ich bin immer noch Student, also habe ich nie mit jemand anderem programmiert, ich habe noch nie ein Versionskontrollsystem benutzt.

Ich arbeite jetzt an einem Projekt, das Kenntnisse darüber erfordert, wie Programmierer zusammen an einer Software in einem Unternehmen arbeiten.

Wie wird die Software zusammengestellt? Ist es aus dem Versionskontrollsystem? Ist es von einzelnen Programmierern? Ist es periodisch? Ist es, wenn jemand beschließt, etwas zu bauen? Gibt es irgendwelche Tests, um sicherzustellen, dass es "funktioniert"?

Alles wird tun.


75
2018-06-08 18:33


Ursprung


Antworten:


Tatsächlich gibt es so viele Variationen in diesen Prozessen, wie es viele Firmen gibt. Bedeutung: Jedes Unternehmen hat ein wenig andere Konventionen als andere, aber es gibt einige gängige Best Practices, die an den meisten Orten verwendet werden.

Best Practices, die immer nützlich sind

  • Alle Der Quellcode des Projekts und alles, was benötigt wird, um es zu erstellen, ist unter Versionskontrolle (auch Quellcodeverwaltung genannt). Jemand sollte in der Lage sein, das gesamte Projekt mit einem Klick zu erstellen.
    Außerdem sollten unnötige Dateien (Objektdateien oder kompilierte Binärdateien) nicht dem Repository hinzugefügt werden, da sie relativ einfach regeneriert werden können und nur Platz im Repo verschwenden würden.
  • Jeder Entwickler sollte aktualisieren und verpflichten zur Versionskontrolle ein paar Mal pro Tag. Meistens, wenn sie die Aufgabe erledigt haben, arbeiten sie daran und testen sie genug, damit sie wissen, dass sie keine kleinen Fehler enthält.
  • Nochmal: jemand sollte in der Lage sein, das Projekt mit einem einzigen Klick zu erstellen. Dies ist wichtig und macht es einfach für jedermann zu testen. Ein großer Vorteil, wenn auch Nicht-Programmierer (zB der Chef) dazu in der Lage sind. (Sie fühlen sich in der Lage zu sehen, woran das Team genau arbeitet.)
  • Jeder Entwickler sollte testen die neue Funktion oder die Fehlerbehebung, die sie hinzufügen Vor Sie verpflichten diese zum Repository.
  • Richten Sie einen Server ein, der sich regelmäßig (in vorgegebenen Intervallen) selbst aus dem Repository aktualisiert und versucht, ihn zu erstellen alles in dem gesamtes Projekt. Wenn es fehlschlägt, sendet es E-Mails an das Team zusammen mit den letzten Commits an die Versionskontrolle (seit welchem ​​Commit konnte es nicht bauen), um das Problem zu beheben.
    Diese Praxis wird genannt kontinuierliche Integration und die Builds werden auch genannt nächtliche baut.
    (Dies bedeutet nicht, dass Entwickler den Code nicht auf ihren eigenen Maschinen erstellen und testen sollten. Wie oben erwähnt, sollten sie das tun.)
  • Offensichtlich, jeder sollte mit dem grundlegenden Design / Architektur des Projekts vertraut sein, wenn also etwas benötigt wird, müssen verschiedene Mitglieder des Teams das Rad nicht neu erfinden. Das Schreiben von wiederverwendbarem Code ist eine gute Sache.
  • Eine Art von Kommunikationwird zwischen den Teammitgliedern benötigt. Jeder sollte sich bewusst sein, was die anderen tun, zumindest ein bisschen. Je mehr desto besser. Dies ist der Grund, warum täglicher Standup ist nützlich in SCRUM-Teams.
  • Komponententest ist eine sehr gute Übung, die das Testen der grundlegenden Funktionalität Ihres Codes automatisch macht.
  • EIN Fehler-Tracking-Software (manchmal genannt Zeiterfassungssoftware) ist ein sehr gutes Mittel, um zu verfolgen, welche Fehler vorhanden sind und welche Aufgaben die verschiedenen Teammitglieder haben. Es ist auch gut zum Testen: Die Alpha- / Beta-Tester Ihres Projekts könnten so mit dem Entwicklungsteam kommunizieren.

Diese einfachen Dinge sorgen dafür, dass das Projekt nicht außer Kontrolle gerät und alle an der gleichen Version des Codes arbeiten. Der kontinuierliche Integrationsprozess hilft, wenn etwas schrecklich schlecht läuft.

Es verhindert auch, dass Personen Inhalte übertragen, die nicht zum Haupt-Repository gehören.
Wenn Sie ein neues Feature hinzufügen möchten, das Tage dauern würde, um es zu implementieren, und andere Personen daran hindern würde, das Projekt zu erstellen (und zu testen), verwenden Sie das Geäst Feature Ihrer Versionskontrolle.

Wenn das nicht genug ist, können Sie es auch für automatisierte Tests einrichten, wenn dies mit dem betreffenden Projekt möglich ist.

Noch ein paar Gedanken

Die obige Liste kann auf den ersten Blick sehr schwer sein. Ich empfehle, dass Sie es auf einem folgen wie benötigt Basis: Beginne mit einer Versionskontrolle und einem Bug Tracker, dann richte später den Continuous Integration Server ein, falls du es brauchst. (Wenn es ein großes Projekt ist, werden Sie es sehr bald brauchen.) Beginnen Sie mit Komponententests für die wichtigsten Teile. Wenn es nicht genug ist, dann schreibe mehr von ihnen.

Einige nützliche Links:
Kontinuierliche Integration, Tägliche Builds sind deine Freunde, Versionskontrolle, Komponententest

Beispiele:

Für Versionskontrolle neige ich dazu zu verwenden Git für meine persönlichen Projekte heutzutage. Subversion ist auch beliebt, und zum Beispiel VisuelleSVN ist sehr einfach einzurichten, wenn Sie einen Windows-Server verwenden. Für den Kunden, SchildkröteSVN funktioniert am besten für viele Menschen. Hier ist ein Vergleich zwischen Git und SVN.

Für Bug-Tracking-Software, Jira und Bugzilla sind sehr beliebt. Wir haben auch gebraucht Gottesanbeterin an einem früheren Arbeitsplatz.

Für kontinuierliche Integration Software gibt es Teamstadt für einen (auch Tempomat und sein .NET-Gegenstück sind nicht in der Lage).

Beantworten Sie Ihre Frage "Wer entscheidet über den Hauptentwurf des Projekts?"

Das wäre natürlich der Hauptentwickler.
In Unternehmen ist der Hauptentwickler die Person, die mit den Finanz- / Marketingmitarbeitern des Projekts spricht und die Arcithecture entsprechend der finanziellen Leistungsfähigkeit des Unternehmens, der geplanten Funktionen, den Anforderungen der Benutzer und der zur Verfügung stehenden Zeit entscheidet.

Es ist eine komplexe Aufgabe, und normalerweise sind mehr als ein Mensch beteiligt. Manchmal werden Mitglieder des Teams auch gebeten, an der Gestaltung des gesamten Projekts oder bestimmter Teile mitzuwirken.


54
2018-06-08 19:00



Ich bin auch ein Student, der kürzlich einen Software Engineering Kurs absolviert hat, bei dem das gesamte Semester aus einem riesigen Gruppenprojekt bestand. Lassen Sie mich zunächst damit beginnen, dass wir mit 3 Leuten hätten machen können, was wir 12 von uns das ganze Semester gebraucht haben. Mit Menschen zu arbeiten ist eine schwierige Sache. Kommunikation ist der Schlüssel.

Verwenden Sie definitiv ein Repository. Jede Person kann aus der Ferne auf den gesamten Code zugreifen und alles hinzufügen / löschen / ändern. Aber das Beste an Subversion ist, dass Sie, wenn jemand den Code bricht, zu einer früheren Version zurückkehren und abschätzen können, was von da an schief gelaufen ist. Kommunikation ist immer noch der Schlüssel, weiß was deine Teammitglieder tun, damit es keine Konflikte gibt. Setzen Sie sich auch nicht auf Ihren Code, machen Sie schnelle, sinnvolle Commits zum Repository, um am effektivsten zu sein.

** Ich würde auch einen Bugtracker wie Redmine empfehlen. Sie können Accounts für alle einrichten und Personen Aufgaben mit unterschiedlichen Prioritäten zuweisen. Außerdem können Sie verfolgen und sehen, ob sich Personen um bestimmte Probleme gekümmert haben oder ob weitere aufgetreten sind.

Wie bereits erwähnt, wird das Testen von Einheiten sehr hilfreich sein. Viel Glück! Hoffe das hat geholfen :-)


11
2018-06-08 19:41



Die großen Dinge sind:

  • Ein Plan - Wenn die Leute nicht wissen, wohin sie gehen, werden sie nirgendwohin gehen. Der Beginn eines jeden Projekts erfordert daher, dass ein paar Leute (oft die Graubärte des Projekts) in eine Hocke gehen und einen Plan aufstellen; Der Plan muss nicht sehr detailliert sein, aber es ist immer noch erforderlich.
  • Versionskontrollsystem - Ohne dies arbeiten Sie nicht zusammen. Sie brauchen auch die feste Verpflichtung, dass, wenn Dinge nicht begangen werden, sie nicht zählen. "Oh, es ist in einem meiner Sandkästen" ist nur eine lahme Ausrede.
  • Problemverfolgung - Sie können diese Dinge nicht per E-Mail-Ordner verfolgen. Sollte definitiv datenbankgestützt sein.
  • Benachrichtigungssystem - Die Leute müssen wissen, wann Dinge für den von ihnen gepflegten Code begangen werden oder Kommentare zu Bugs gemacht werden, für die sie verantwortlich sind. Email kann arbeite dafür, genauso wie IRC (vorausgesetzt, dass jeder es natürlich nutzt).
  • System erstellen - Es ist nicht wirklich wichtig Wie Dies geschieht, solange Sie mit einer Aktion den aktuellen Zustand der Dinge, sowohl Ihrer Entwicklungs-Sandbox als auch des Haupt-Repository, vollständig erstellen können. Die beste Option hängt davon ab, welche Sprache (n) Sie verwenden.
  • Testsuite - Eine Testsuite hilft Leuten, dumme Fehler zu vermeiden. Es muss so einfach laufen wie der Build (Teil des Builds ist) gut). Beachten Sie, dass Tests nur ein grober Ersatz für die Richtigkeit sind, aber sie sind viel besser als nichts.

Schließlich brauchen Sie die Bereitschaft, gemeinsam an der Erfüllung des Plans zu arbeiten. Das ist allzu oft der schwierige Teil.


8
2018-06-08 20:00



Im Allgemeinen empfiehlt es sich, Build-Artefakte nicht im Repository zu überprüfen. Das Repository enthält den Quellbaum, die Build-Konfiguration usw. - alles, was von einem Menschen geschrieben wurde. Softwareentwickler werden eine Kopie ihres Codes auf ihrem lokalen Dateisystem auschecken und lokal erstellen.

Es ist auch eine gute Übung, Komponententests zu haben, die als Teil des Build-Prozesses ausgeführt werden. Auf diese Weise wird ein Entwickler sofort wissen, ob seine Änderungen einen der Komponententests ungültig gemacht haben, und er wird die Möglichkeit haben, sie zu beheben, bevor er seine Änderungen eincheckt.

Vielleicht möchten Sie in die Dokumentation für ein Versionskontrollsystem (eines von Subversion, CVS, Git, etc.) und für ein Build-System schauen (zB in Java gibt es Ant und Maven).


7
2018-06-08 18:37



wie Programmierer zusammenarbeiten auf a   Stück Software in einer Firma

Entwickler arbeiten nie als Team. Teams saugen. Dilbert ist lustig, nicht weil er eine komische Figur wie Goofy ist. Er ist lustig, weil er echt ist und die Leute die Situationen erkennen, in denen er sich befindet.

Comic


5
2018-06-09 12:27



Es gibt keinen Standard für die Dinge, nach denen du fragst. Vielmehr gibt es Konventionen, die stark von der Größe und Reife der Organisation abhängen. Wenn Sie in einer kleinen Organisation sind, sagen ein paar Programmierer, dann werden die Dinge wahrscheinlich etwas informell sein mit den einzelnen Entwicklern, die Codierung, Builds und Tests machen.

In größeren Organisationen kann es einen dedizierten Build-Techniker und Prozess geben. Diese Art von Organisation wird in der Regel regelmäßig, etwa einmal am Tag, formell erstellt, wobei der Quellcode verwendet wird, der eingecheckt wird. Der Prozess wird normalerweise auch BVT (Build Validation Tests) und vielleicht einige Regressionstests beinhalten. Entwickler werden den Code aus dem Repository auschecken, lokal an ihrem eigenen Teil arbeiten und dann einchecken.

In den größten Organisationen, wie Microsoft oder Google, werden sie eine vollständig dedizierte Gruppe und ein vollständiges Labor haben, das auf einer mehr oder weniger kontinuierlichen Basis aufbauen wird, um die Ergebnisse jedes Laufs verfügbar zu machen. Diese Organisationen haben sehr formelle Prozesse und Verfahren, was wann eingecheckt wird, was die Code-Review-Prozesse sind usw.


3
2018-06-08 18:43



Die kurze Antwort - "Es kommt darauf an".

Momentan arbeite ich selbst an einem Projekt, also bin ich derjenige, der VCS baut / benutzt. Ich kenne andere Orte, an denen Sie Teams haben, die gemeinsam an dem Projekt arbeiten schaudern Email. Oder große (+5) Teams, die VCS verwenden.

In diesem Sinne empfehle ich dringend, zumindest einige VCS zu lernen, und Joel Spolsky hat eine großartige Einführung Anleitung für Mercurial. Bazaar (meine persönliche Wahl) ist ähnlich, und dann ist Git der nächste in Bezug auf Ähnlichkeit, aber wahrscheinlich beliebter als jeder (zumindest ATM). Danach haben Sie SVN, die im Vergleich ziemlich schwach ist.

Eigentlich, Joel Gespräche Über die meisten Ihrer Fragen - ich empfehle Ihnen, die 10 Jahre Archiv zu lesen, die er hat - es sind alles sehr nützliche Informationen, und das meiste davon ist relevant für Ihre aktuelle und nahe-zukünftige Situation.


2
2018-06-08 18:45



Es gibt kein Kochbuch für die Arbeit mit Softwareentwicklung, aber im Allgemeinen sollte das Versionskontrollsystem das Herzstück Ihres Build-Systems sein, auch wenn Sie in einem Projekt arbeiten, in dem Sie der einzige Entwickler sind. Selbst in diesem Fall ist es sehr willkommen, Fehler beheben zu können und das Versions-Log lesen zu können. Dies ist nicht das einzige Merkmal eines Versionskontrollsystems, aber dies allein rechtfertigt die Installation, Konfiguration und Wartung eines Versionskontrollsystems.

Der Build kann entweder von jedem Entwickler beim Hinzufügen von neuem Code oder periodisch von einem "Build-Server" durchgeführt werden. Der letzte Ansatz erfordert mehr Setup, hilft aber, Build-Fehler früher zu finden.


2
2018-06-08 22:18



Richtige Programmierung ist eine tiefe Sache, die stark von Erfahrung profitiert. Paar-Programmierung ist wie das Laufen mehrerer Bewusstseins-Prozessoren ... man kann etwas übersehen, das der andere gesehen hat und solange es kommuniziert, kann es zu einem großen Fortschritt führen.


1
2018-06-08 18:35