In Zukunft von einem Einzelprojekt zu einem Teamprojekt wechseln. Was soll ich jetzt in Vorbereitung machen und was kann warten?

Um das zu erläutern, bin ich daran interessiert zu wissen, was die Leute denken, dass Sie in einem Ein-Mann-Projekt implementieren müssen (Team-Quellcodeverwaltung, Dokumentation, Builds usw.) und welche Dinge erst zu dem Zeitpunkt erledigt werden müssen, zu dem die zweite Person kommt auf das Projekt.

Jeder, der Erfahrung mit diesem Szenario hat, wird seine Einsichten zu schätzen wissen.

Was ich gelernt habe (Ich habe eine andere Reihenfolge versucht. Ich habe mich geirrt. In dieser Reihenfolge werden die Dinge relevant.)

1. Alles in die Quellcodeverwaltung stecken. Verwenden Sie etwas, auf das jeder Zugriff hat, und beginnen Sie sofort . Keine Ausnahmen. Keine Verspätungen. Keine Ausreden.

2. Erstellen Sie einen QS / Test-Bereich, der völlig unabhängig von Ihrer persönlichen "Arbeits" - oder "Entwicklungs" -Umgebung ist. Mindestens eine separate Benutzer-ID. Idealerweise auf einer separaten VM.
   Völlig getrennt. Keine möglichen Überschneidungen mit Ihrer aktuellen Arbeitsumgebung.

3. Hören Sie auf, über den Unit-Test hinaus in Ihrer eigenen Arbeitsumgebung zu testen. Code und Unit Test machen Sie "wie Sie". Alle anderen Tests (Integration, Leistung usw.) werden auf der separaten VM durchgeführt. Niemals als Sie selbst testen. Testen Sie immer als separater QS-Benutzer. Idealerweise auf einer separaten VM.

   "Funktioniert für mich" ist eine schlechte Sache, die Sie Ihren Teammitgliedern sagen müssen. Sehr schlecht. Sie müssen herausfinden, was sie falsch machen. Mehrmals am Tag.

4. Planen Sie, alles aufzuschreiben. Verwenden Sie ein Nur-Text-Markup-Tool (RST oder Markdown oder so), damit die gesamte Dokumentation im Versionskontroll-Repository nur aus Text besteht. Mit einem Tool können HTML-Seiten (z. B. Docutils für RST) oder PDF-Dateien erstellt werden. Verwenden Sie keine proprietären Dokumentformate (zB MS-Word). Sie können mit einigen Quellcode-Kontrollsystemen nicht gut funktionieren.

5. Die ersten Dinge, die Sie aufschreiben müssen, sind die folgenden.

   • So erstellen Sie eine funktionierende Entwicklungsumgebung. Erstellen Sie im Zweifelsfall eine virtuelle Maschine und führen Sie den gesamten Vorgang auf dieser virtuellen Maschine aus. Stellen Sie sicher, dass die Schritte wirklich funktionieren und die Dokumentation klar ist . Tatsächliche Zeilen, die in der tatsächlichen Befehlszeile eingegeben wurden.

   • So führen Sie die Unit-Testsuite aus. Nochmal. Stellen Sie sicher, dass die Anweisungen funktionieren und kein Nachdenken erforderlich ist. "Tippe dies:" "Bestätige das:" Art von Zeug. Es ist nicht so, dass deine Teammitglieder dumm sind. Es ist so, dass Sie sich nicht daran erinnern, was Sie annehmen, es sei denn, Sie schreiben alles auf.

   • Ausführen der Integrationstestsuite

   Verschwenden Sie nicht viel Zeit damit, die Architektur oder die Designprinzipien zu beschreiben. Sie müssen zuerst jemanden zum Laufen bringen. Du kannst das später erklären.

6. Die nächsten zu dokumentierenden Dinge sind die User Stories. Und die Testfälle, die diese Geschichten unterstützen. Und die Daten, die für die Testfälle benötigt werden, die diese User Stories unterstützen.

   Sie werden dies teilen. Es geht unter Quellcodeverwaltung.

7. Schließlich können Sie die anderen 4 Ansichten dokumentieren.

   • Die logische Sicht ist hilfreich, um Dinge zu dokumentieren. Bilder sind hier akzeptabel. Dies kann sich schnell entwickeln, nehmen Sie sich also keine Zeit, um die Altdaten zu erfassen. Erarbeiten Sie einen Weg, um mit Ihren Teammitgliedern zusammenzuarbeiten.

   • Prozesssicht ist oft hilfreich. Wie wichtig dies ist, hängt von der Gesamtanwendung ab.

   • Die Entwicklungsansicht - Module, Bibliotheken, Frameworks usw. - wird häufig informell beschrieben. Ein Bild mag helfen, aber es ist bekanntermaßen schwierig, es so vollständig zu machen, dass jemand ein Dokument aufheben und Kopf oder Zahl daraus machen kann. Sogar lange etablierte, sehr öffentliche Projekte haben Bibliotheksdokumentationen, die einfach ignoriert werden. (Dies führt zu vielen Fragen zum Stapelüberlauf.)

     Dies ist nicht nur akzeptabel, um informell zu sein, sondern ändert sich auch schnell.

   • Bereitstellungsinformationen. Server. IP-Adressen. Datenbankanmeldeinformationen. All das Zeug muss aufgeschrieben werden. Schließlich.

Tools und Methodik

Was ist notwendig, um erfolgreich zusammenzuarbeiten und produktiv zu sein?

• Identifizieren Sie Teile / Komponenten Ihres Projekts: Unterscheiden Sie klar zwischen verschiedenen Teilen (Datenbank, Datenzugriffsebene, Website, Service, API, Testprojekten, Build-Skripten usw.) und Umgebungen (Entwicklung, Staging, Produktion) und benennen Sie diese hat durchweg Einfluss auf Ihre mündliche und schriftliche Kommunikation (Dokumentation, Projektnamen, ...)
• Verwenden Sie ein Quellcode-Verwaltungssystem (nur für den Fall, dass Sie es noch nicht tun). Überlegen Sie, wie Sie die Verzweigung für Ihr Projekt und Setup verwenden können.
• Automatisieren Sie Ihre Builds - machen Sie es so einfach wie möglich, eine Umgebung aus Ihrem Quell-Repository heraus einzurichten.
• Testprojekte sind ein Muss für große Projekte, zumindest für komplexere Projekte.
• Verwenden Staging-Umgebungen, in denen Ihr Projekt zur Verwendung bereit ist. Erstellen und verwalten Sie außerdem Beispieldaten für ein automatisiertes Staging-Setup.
• Benutze einen Fehlerverfolgungssystem, mit dessen Hilfe Sie die Entwicklung priorisieren und planen können, und das auch als Speicher für frühere Fehler und deren Behebung dient.
• Dokumentieren Sie jeden Teil Ihres Projekts, manche mehr als andere. Ich persönlich mag: Übersicht - Architektur - Abhängigkeiten - Konfiguration - Häufige Probleme (von hier ). Manchmal ist weniger mehr - um nicht zuzulassen, dass Ihre Dokumentation veraltet ist, ist es besser, präzise zu sein und die Dokumentation zu einem Teil Ihrer täglichen Aktivitäten zu machen.

Management / Teamarbeit

... oder irgendetwas anderes auf der zwischenmenschlichen Ebene

• Definieren Sie Ihre Erwartungen an den anderen Entwickler. Seien Sie vernünftig, niemand wird wahrscheinlich das gleiche Engagement und die gleiche Leidenschaft mitbringen wie Sie - zumindest nicht von Anfang an. Kommunizieren Sie, was Sie erwarten und was nicht, definieren Sie Ihre und die der anderen Verantwortlichkeiten. Nicht jeder ist Ingenieur, Architekt, Entwickler, dba und sysadmin, aber wenn Sie danach suchen, wählen Sie die richtige Person, oder Sie werden enttäuscht sein.
• Zunächst , definieren Aufgaben genau und überprüfen und die Ergebnisse diskutieren. Beginnen Sie mit der Zeit immer weniger mit dem Mikromanagement. Die Idee ist, Vertrauen aufzubauen und Verantwortung zu erhöhen.
• Planen Sie Ihr Projekt , setzen Sie sich Ziele für Ihr Projekt und für Ihr Team für das nächste Jahr. Schreiben Sie es auf und überprüfen Sie es später, dies gibt Perspektive . Diese Ziele können oder auch nicht zu anderen mitgeteilt werden (so lange , wie sie sind Ziele Sie erreichen müssen, nicht um andere). Dies kann einfach Ihre eigene Checkliste sein.
• Nehmen Sie sich einen Tag Zeit, um den ersten Monat (oder zwei bis drei Monate) Ihres neuen Entwicklers vorzubereiten und zu planen . Ich finde es sehr motivierend, mit gut vorbereiteten Leuten zu arbeiten. Niemand sollte den Eindruck bekommen, dass seine / ihre Zeit verschwendet wird.
• Lassen Sie los . Es ist dein Baby, es sollte auch jemand anderem gehören. Erlauben Sie dem anderen, zumindest in einigen Teilen des Projekts ein Experte zu werden, der besser ist als Sie. Das heißt, Sie haben es tatsächlich geschafft.
• Hör mal zu - wenn Sie sie engagiert haben, hat sie etwas zu sagen. Seien Sie bereit zu lernen.
• Seien Sie bereit, Ihr Wissen und Ihre Erfahrung zu teilen (und daher Zeit - seien Sie geduldig).
• Fehler werden gemacht, es ist, wie sie gehandhabt werden und was jeder über sie erfährt, was zählt.
• Nehmen Sie sich Zeit zum Lernen und Experimentieren

Buchreferenzen

Ich werde einige der allgemein erwähnten Bücher auflisten, die ich tatsächlich gelesen habe und die es meiner Meinung nach wert sind, gelesen zu werden. Für eine detailliertere Beschreibung oder für weitere Bücher möchten Sie vielleicht einige der Fragen zu SO lesen, die genau danach fragen, wie dies oder diese Frage.

Diese Bücher sind in Bezug auf Teams, Organisationen und Programmierprojekte wirklich lesenswert:

• Peopleware
• Monat des mythischen Mannes
• Software-Schätzung, Entmystifizierung der schwarzen Kunst

Keines davon ist ein praktischer Leitfaden für die Implementierung der Methode X (mit Ausnahme der Softwareschätzung hilft Ihnen dieses Handbuch bei der Auswahl eines geeigneten Schätzprozesses). Natürlich sind auch Bücher, die sich mehr auf das Programmieren konzentrieren, wie Code Complete, sehr bereichernd.

Ich werde aus der Erfahrung sprechen, aber denken Sie daran, dass jeder anders ist. Diese Dinge sind nicht universell.

Eine Sache ist, es persönlich gehen zu lassen. Mit diesem Projekt haben Sie 18 Monate lang zusammengelebt - Sie möchten natürlich, dass jede Veränderung so ist, wie Sie es tun würden. Geben Sie einem Kollegen einen Puffer, um Fehler zu machen und zu lernen. Schaffen Sie einen Raum, in dem sie nützlich sein können. Und denken Sie daran, es könnte nicht sofort passieren. Es wäre auch großartig, wenn es etwas gäbe, einen Teil des Codes, von dem sie glauben, dass er es schafft, ihn zu verbessern oder zu erstellen, der sich nach Erfolg in kurzer Zeit anfühlt. Geduld und Toleranz zahlen sich hier aus. Versuchen Sie nicht, Mikromanagement zu betreiben, und wenn Sie kritisieren wollen, "Sie liegen falsch" zu sagen, stellen Sie sicher, dass Sie ein Verdienst haben, Sie können es beweisen, es ist kein "religiöser" Kampf.

Ein weiteres wichtiges Anliegen ist es, die richtige Person für Sie zu finden. Im Idealfall ist es besser, jemanden zu finden, der klüger ist als Sie. Es ist subjektiv und relativ, aber wenn Sie das Gefühl haben, dass eine Person über etwas Wissen und Fähigkeiten verfügt, über das Sie nicht verfügen, ist es das Beste. Es wird eine für beide Seiten lohnende Zusammenarbeit.

Es gibt zwei Möglichkeiten: Der Kollege ist ein Hindernis, und Sie werden das, was er oder sie getan hat, am Ende wiederholen, oder die Fähigkeiten von zwei von Ihnen werden sich vervielfachen, nicht nur addieren, und Sie werden es wirklich zu schätzen wissen, zusammenzuarbeiten.

Zu einem Thema "Sauberer, schneller, wiederverwendbarer Code" - Ich schlage vor, in einem Interview einen kleinen Mikrokernel / Service Manager und / oder Job Executor zu schreiben. Sehen Sie, wie steckbare Komponenten angegeben und konfiguriert werden. Muss nicht fertig sein, es ist ein Gedanke, der zählt. Und außerdem lernst du schnell Leute, die wissen, wie man es macht ;-) Viel Glück!

Meine Einstellung: Beginnen Sie damit, die Architektur Ihres internen Projekts für jemanden zu dokumentieren, der sich dessen nicht bewusst ist. Versuchen Sie zu erklären, welche Annahmen vorhanden sind und wann / wo Sie von den üblichen Praktiken abgewichen sind und warum.

Build-Automatisierung: Tolle Idee, kann ich eine Konfigurationsautomatisierung für einen Dev-Rechner hinzufügen? Je einfacher das Erstellen ist, desto mehr wird es sein (also mehr / schnellere Testbereitstellung).

Eine weitere Idee (die mir einmal sehr geholfen hat): Bitten Sie den neuen Entwickler, einige kleinere Bereinigungsaufgaben in verschiedenen Bereichen Ihrer Codebasis auszuführen, damit er sich an die Layout-Tools usw. gewöhnt. Eine gute Idee ist, sie zu entfernen Obskure Bereiche, die später Verwirrung stiften könnten (Beispiel: Wenn Sie emmm python für zwei Zeilen eines Shell-Skripts irgendwo verwendet haben und Ihr Projekt auf Java basiert, bitten Sie die Entwickler, diese beiden Zeilen in Java umzuschreiben, damit # 3 dies muss weniger wissen, um zu arbeiten)

Ich würde mich darauf konzentrieren, alles zu automatisieren, was manuelle Arbeit erfordert und daher von einer unerfahrenen Person vermasselt werden kann . Was, basierend auf Ihrem kurzen Kommentar oben, Folgendes beinhaltet:

• Installieren Sie die Versionskontrolle und ersetzen Sie die manuellen Sicherungen durch automatisierte.
• Richten Sie die automatische Bereitstellung so weit wie möglich ein (schreiben Sie mindestens ein Skript, das über FTP bereitgestellt werden soll, anstatt es manuell auszuführen).

Wenn Sie dies nicht tun, werden Sie entweder angekettet, um diese Aufgaben für immer zu erledigen, oder (ein Teil von) der neuen Person (en) wird irgendetwas früher oder später unvermeidlich vermasseln.

Die andere wichtige Aufgabe ist, wie @dimitris feststellte, die Dokumentation. @S. Lott hat viel mehr Details hinzugefügt, also nur +1 für ihn anstatt zu wiederholen :-)

Hier einige Gedanken, die teilweise auf persönlichen Erfahrungen beruhen:

• Dokumentieren Sie Ihr Projekt. Konstruktionsspezifikationen, Diagramme, Handbücher und Kommentare helfen dem neuen Mitarbeiter, sich auf den neuesten Stand zu bringen. Ein komplexes System nur mündlich zu erklären, kann sich als langsam und frustrierend erweisen. Bei Ein-Mann-Projekten wird die Dokumentation häufig vernachlässigt. Stellen Sie sicher, dass Ihre Ausnahme ist.

• Konzentrieren Sie sich zunächst auf den Code auf API- / Core-Ebene, und geben Sie dem neuen Mitarbeiter einige "Application Layer" -Aufgaben oder Fehlerbehebungen, um ihn schrittweise mit dem Code vertraut zu machen. Im Allgemeinen beginnt mit einfacher , aber dennoch sinnvoll und damit belohnen Aufgaben .

• Kommunikation ist wichtig. Reagieren Sie auf die Fragen, Kommentare und Ideen der neuen Mitarbeiter. Erklären Sie, warum Sie denken, dass eine Idee nicht gut ist, wenn Sie dies tun. Ein frisches Paar Augen kann überraschend gut Verbesserungspotential erkennen. Wenn Ihr neuer Mitarbeiter ein anständiger Mitarbeiter ist, kann er Ihren Code einer Peer-Review unterziehen und schließlich an Architekturentscheidungen teilnehmen. Diskutieren, Ideen austauschen. Dies ist einer der größten Vorteile, wenn Sie einen Mitarbeiter für Ihr Projekt haben.

• Definieren Sie Verantwortlichkeiten klar , sobald Sie wissen, welche Aufgaben Ihr neues Teammitglied erledigt. Richten Sie Dokumentationsmethoden und Kodierungskonventionen ein , um reibungslose Abläufe zu gewährleisten.

• Verwenden Sie ein Revisionskontrollsystem . Pflegen Sie ein logisches Quelldatei-Layout und bauen Sie Disziplin auf .

Was das Interview betrifft, ich bin kein großer Fan von künstlichen Codierungstests oder Trickfragen, es sei denn, Sie möchten die Belastbarkeit des Kandidaten testen. Selbst die klügsten Problemlöser können sich in einer solchen Situation einschließen. Die Eigenschaften, nach denen Sie suchen, sind unter anderem: Ehrlichkeit , Fachkompetenz , technologische Kenntnisse / Einsicht , Begeisterung und gegenseitige Kompatibilität . Arbeitsklima kann viel bedeuten; Es ist nicht ratsam, einen Teamkollegen auszuwählen, den Sie nicht mögen. Stellen Sie Ihre Fragen richtig und führen Sie eine informelle Diskussion, um sich ein gutes Bild von Ihrem Kandidaten zu machen. Viel Glück!

Technologie

Wenn Sie jemanden als Entwickler mit einbeziehen, gibt es drei wichtige Dinge, die ich empfehlen würde, bevor sie gestartet werden.

1. Quellcodeverwaltung
2. Fehlersuche
3. Kontinuierliche Integration

Wenn diese drei Dinge richtig funktionieren, beseitigen Sie 75% des allgemeinen Problems, das auftritt, wenn Sie ein neues Teammitglied einstellen. Der Sinn dieser Technologie ist es, eine Menge dessen, was nur in Ihrem Kopf passiert, zu erfassen und herauszufinden, wo Ihr Teammitglied damit interagieren kann.

Die Quellcodeverwaltung stellt sicher, dass Sie beide an der gleichen Sache arbeiten. Mit Issue Tracking behalten Sie beide den Überblick über die zu erledigenden Aufgaben und können leichter erkennen, woran sie arbeiten und was sie leisten. Kontinuierliche Integration und Tests stellen sicher, dass Sie einen wiederholbaren Erstellungsprozess haben und dass neue Verbesserungen andere Teile des Codes nicht beschädigen.

Pragmatic Programmer hat einige ziemlich gute Bücher dazu. Hier sind ein paar, die ich empfehlen würde. Sie haben ähnliche Titel, je nachdem, welche Programmiersprache Sie verwenden oder welche Versionskontrolle Sie verwenden möchten:

http://www.pragprog.com/titles/tpp/the-pragmatic-programmer http://www.pragprog.com/titles/tsgit/pragmatic-version-control-using-git http: //www.pragprog. com / title / auto / pragmatic-project-automation

persönlich

Oftmals sind die Schwierigkeiten, denen Sie gegenüberstehen, weniger auf der technischen Seite der Dinge als vielmehr auf dem Lernen, loszulassen. Es kann schwierig sein, jemand anderem die Kontrolle über bestimmte Aspekte des Projekts zu geben - insbesondere, wenn Sie es gewohnt sind, alles selbst zu tun und jede einzelne Entscheidung zu treffen. Sie werden sich etwas Kummer ersparen, wenn Sie einen Bereich finden, in dem die neue Person zu Beginn mit einem angemessenen Maß an Freiheit arbeiten kann, damit Sie eine Vertrauensbasis aufbauen können. Wenn Sie eine gute Person einstellen, lernen Sie wahrscheinlich vor allem, wie Sie der anderen Person vertrauen können, dass sie gute Arbeit leistet, auch wenn ihre individuellen Entscheidungen nicht mit den Entscheidungen übereinstimmen, die Sie getroffen hätten.

Sie möchten Ihrem neuen Mitarbeiter die Freiheit geben, Probleme so zu lösen, wie es für ihn funktioniert, und gleichzeitig die Sicherheitsvorkehrungen einhalten, damit Sie Probleme frühzeitig erkennen können.

Diese Punkte sind meiner Meinung nach am wichtigsten:

1. Lesen Sie wichtige Teile Ihres Codes durch und vergewissern Sie sich, dass sie leicht zu verstehen sind. Verwenden Sie Kommentare oder intuitive Funktions- und Variablennamen.
2. Machen Sie es der neuen Person einfach, Code einzureichen.
3. Wenn es nicht trivial ist, erstellen Sie eine README-Datei, die dem neuen Entwickler alle erforderlichen Schritte zum Einrichten der Entwicklungsumgebung erklärt. Alternativ können Sie eng mit der Einrichtung dieser Umgebung zusammenarbeiten.
4. Geben Sie dem neuen Entwickler sehr klar definierte Aufgaben, wenn Sie an diesem neuen Projekt arbeiten. Meiner Meinung nach sollten diese Aufgaben neue, aber einfache Funktionen beinhalten. Bereinigungsaufgaben machen meiner Meinung nach wenig Sinn, da sich der neue Entwickler erst an Ihren Codierungsstil und die darin enthaltenen Gewohnheiten gewöhnen muss, auch wenn sie schlecht sind. Bereinigen oder sogar Umgestalten sind Aufgaben, die von Personen ausgeführt werden müssen, die den Code kennen.
5. Stellen Sie klar, wie der Code eingereicht wird. (ZB nur kompiliertes Material einreichen.) Aber seien Sie nicht zu streng, dies kann am Anfang frustrierend sein.
6. Halten Sie ein Dokument mit Codierungskonventionen bereit. Es kann sehr frustrierend sein, die anderen Kodierungskonventionen zu erraten.
7. Wenn die App komplex ist, halten Sie eine Dokumentation bereit, in der die Architektur erläutert wird. Oder erklären Sie der neuen Person die Architektur anhand von Flussdiagrammen oder Ähnlichem. Sie möchten nicht, dass der neue Entwickler zu viel Zeit für das Reverse Engineering Ihres Projekts verschwendet.
8. Wenn der neue Entwickler Bereitstellungen selbst durchführen soll, halten Sie eine geordnete Checkliste bereit, in der alle für die Bereitstellung erforderlichen Schritte erläutert werden.

Und zu guter Letzt: Holen Sie sich ein Versionskontrollsystem. Subversion ist in Ordnung. Fügen Sie jedoch keine Eclipse-Dateien (oder was auch immer) hinzu, die benutzerspezifisch sind und daher ständig geändert werden. Sie bringen Sie dazu, Stunden zu verschwenden. Zögern Sie nicht, bei Stackoverflow nachzufragen, wenn Sie Probleme damit haben.