Ein langer Build lähmt den gesamten Softwareentwicklungsprozess. Sie sollten dies nicht als Tatsache hinnehmen, ohne vorher Schritte zur Verkürzung der Bauzeit zu unternehmen. Hier sind einige Möglichkeiten, wie Sie das tun können:

1. Kaufen Sie eine SSD .
2. Fügen Sie mehr RAM hinzu.
3. Wenn Sie eine Web-App entwickeln: Verwenden Sie Browserify , um Ihren clientseitigen Code im laufenden Betrieb neu zu laden.
4. Erstellen Sie während der Entwicklung nur die Teile der Codebasis, die sich ändern.
5. Untersuchen Sie den Buildcode und schließen Sie den Build auf Ihrem lokalen Computer kurz, sodass nur die Teile der Codebasis erstellt werden, die sich ändern.
6. Erwägen Sie, automatisierte Komponententests nur vor dem Einchecken auszuführen.
7. Arbeiten Sie mit Teammitgliedern und Managern zusammen, um die Build-Zeit dauerhaft zu verkürzen.

Mehr zu #1 und #2: Diese sind besonders effektiv. Sie sollten dies auch tun, wenn Sie Geld aus Ihrer eigenen Tasche ausgeben müssen, da dies Ihre allgemeine Zufriedenheit am Arbeitsplatz erhöht. Ein guter Schreiner würde keine stumpfe Säge vertragen, und Sie sollten keine langsame Festplatte oder eine Workstation mit zu wenig RAM vertragen. Sie möchten abends zu Hause sein, mit Ihrer Familie zu Abend essen oder Netflix schauen. Sie möchten keinen elenden "Tod durch tausend Schnitte" erleiden, indem Sie auf langsame Builds warten.

BEARBEITEN:

1. An die Leute, die sagten, dass ich die Frage des OP nicht beantwortet habe: Bitte beachten Sie diese Meta-Antwort .
2. Ein langsamer Aufbau kann den Arbeitsplatz lahmlegen. Es ist sehr wichtig, alle Optionen zu prüfen, bevor Sie die Tatsache akzeptieren, dass der Build langsam ist.

Ein Schwertkampf ist eine großartige Übung. Benutze es.

Um ehrlich zu sein, kann man beim Kompilieren nicht viel mit dem Code machen. Sie können versuchen, die Kompilierzeit zu verkürzen, aber manchmal ist das einfach nicht möglich. Sie können versuchen, die Anzahl der Kompilierungen zu reduzieren, aber manchmal ist es einfach scheiße.

Also ... um die Produktivität zu verbessern, müssen Sie nur besser werden als ein Stuhl- und Schwertkampf. Ich würde vorschlagen:

• E-Mails beantworten
• Dokumententickets
• Bewerbung dokumentieren
• Verpflichten Sie sich zu SCM, wenn Sie können
• Machen Sie eine legitime Pause.
• Behandeln Sie andere nicht verwandte Codeaufgaben
• Meetings mit Teammitgliedern haben
• ein Nickerchen machen

Ehrlich gesagt ist das einer der Gründe, warum ich die Sprachen mag, die ich mag. Keine Kompilierzeit. Wenn Sie eine so lange Kompilierzeit haben, müssen Sie sich damit befassen, vorausgesetzt, Sie können es nicht ansprechen.

Beispielsweise könnten Sie in .NET große Logikblöcke in DLLs aufteilen. Dann müssen Sie nur noch häufig Codeabschnitte kompilieren.

Sie können sich auch die Compileroptionen ansehen und Optionen auswählen, die "nach dem ersten Fehler abbrechen".

Hinweis Ich habe gerade bemerkt, dass Ihre Bauzeit 30 Sekunden beträgt. Das ist keine lange Bauzeit. Wenn Sie in dieser Zeit etwas tun möchten, dann machen Sie Fingerübungen oder stehen Sie auf und atmen Sie tief durch. Lange Bauzeiten sind 10 Minuten. oder mehr.

Etwas aus eigener Erfahrung:

Versuchen Sie, mehrere Fehler gleichzeitig zu beheben.

Sicher, es ist sehr schnell, zwei Spalten zu vertauschen, nachdem Sie bemerkt haben, dass sie vertauscht sind. Stellen Sie jedoch sicher, dass Sie nicht mit der Überprüfung aufhören, nachdem Sie einen Fehler gefunden haben.

Beispielsweise könnten Sie die Anzahl der Zyklen reduzieren, indem Sie andere Dinge überprüfen:

• Sind die Spalten zumindest richtig formatiert?
• Enthalten alle anderen Spalten, was sie sollten?
• ...

Dies ist besonders wichtig in den ersten 1 oder 2 Zyklen und könnte Ihnen helfen, von 15 auf 5 Verzögerungen von 30 Sekunden zurückzugehen (und wahrscheinlich auch ein besseres Ergebnis).

Versuchen Sie, ein Skript zu erstellen, das das tut, was Sie tun müssen, und dann ein hörbares Ding-Geräusch und/oder ein Popup erzeugt. Wenn Sie also Ihren Fokus ablenken möchten, brauchen Sie sich keine Gedanken darüber zu machen, ob Sie komplett abschalten und vergessen, zu überprüfen, ob Sie fertig sind. Für mich ist es in Ordnung, sich "ablenken" zu lassen, indem man sich andere Dinge wie anderen Code ansieht, aber das Problem ist, wenn man "zu weit in den Kaninchenbau geht" und vergisst zu überprüfen, ob der Prozess abgeschlossen ist.

Ich werde mich nicht darum kümmern, einen Vorschlag zu machen, wie dies zu tun ist, da dies je nach Betriebssystem, Kompilierungsmethode und anderen Faktoren variieren wird. Ich würde einfach so etwas wie "Sound und Popup in (Betriebssystem hier einfügen) machen, wenn der Befehl ausgeführt wird" oder ähnliches googeln.

Update: Wie in einigen Kommentaren angemerkt wurde, gibt es möglicherweise Möglichkeiten, dies in bestimmten Programmen mit GUIs zu tun, nicht nur über die Befehlszeile. Wie zuvor werde ich hier nicht die Mühe machen, Vorschläge zu machen, da es sehr unterschiedlich sein wird, um welches Programm es sich handelt und was eine Weile dauert.

Meine Antwort hängt vom Compiler ab, aber versuchen Sie Folgendes:

Wenn der Compiler es Ihnen ermöglicht, den Code anzuzeigen und im Hintergrund kompiliert wird, können Sie Ihre eigene Version von RDD ausführen . Während der Compiler seine Arbeit erledigt, gehen Sie einfach den Code durch, den Sie gerade geschrieben haben, kompilieren Sie ihn in Ihrem Kopf, überprüfen Sie ihn und versuchen Sie, Fehler zu finden.

Du wirst:

1. Lassen Sie sich nicht ablenken und verlieren Sie den Fokus.
2. Wenn ein Fehler auftritt, dauert es nicht zwei Minuten, ihn zu beheben und erneut zu kompilieren, sondern viel weniger.

Zum Beispiel das Austauschen von zwei (schlecht dokumentierten) Ausweisen.

Ich habe dieses Problem in vielen Programmen gesehen, die Intoder Stringfür jede einzelne ID verwenden; In diesem Fall ist es leicht, versehentlich eine ID anstelle einer anderen zu übergeben und es lange Zeit nicht zu bemerken.

Wenn Sie eine Hühner-ID an den Getränkeautomaten weitergeben können, hat Ihr Code ein Problem (*).

Der Trick besteht also darin, IDs zu markieren . Da Sie von langen Kompilierzeiten sprechen, gehe ich davon aus, dass Sie über eine statisch typisierte Sprache verfügen, in diesem Fall sollten Sie diese Typen nutzen. A ChickenIdist nicht gleich a DrinkId. A DrinkIdist nicht gleich a FuelId.

Machen Sie sie zu unterschiedlichen Typen, und der Compiler zeigt Ihnen gerne Ihre Fehler, was die Fix-Compile-Test-Schleife beschleunigt (indem der Test-Schritt ausgelassen und der Compile-Schritt unterbrochen wird).

Dies ist die statisch typisierte Version des Fail-Fast - Prinzips: Es geht kaum schneller, als wenn der Compiler (oder sogar die IDE, wenn sie im Hintergrund kompiliert) Fehler anzeigt.

Als Bonus können Sie sogar eine Validierung in dasselbe System einführen. In meinem Teil der Welt sind zum Beispiel nur wenige IDs jemals negativ ... oder wenn Sie eine Stringhaben, ist eine ID von 2 KB gelinde gesagt überraschend.

(*) Was weiß ich, es sei denn, das Trinken von Hühnerblut ist bei Ihnen Standardpraxis?

Der offensichtliche Weg, dies zu mildern, besteht darin, von vornherein damit aufzuhören, zahlreiche kleine Fehler zu machen. Hier würde ich sowieso ansetzen.

Wenn der Compiler 30 Sekunden benötigt, dauert der Compiler 30 Sekunden. Wir alle machen Fehler, aber 15 Mal pro Stunde wäre für mich ein Signal, um eine robustere Fehlerprüfmethode zu haben.

Es gibt wahrscheinlich so viele Möglichkeiten, dies zu tun, wie es ihre Mitarbeiterprogrammierung gibt. Was auch immer für dich funktioniert. Beheben Sie das Problem an seiner Quelle.

Ich bin kein Programmierer, also muss ich ziemlich viel herumspielen, damit die Dinge manchmal funktionieren. Ich bleibe produktiv durch Multitasking, wenn eine Sache nicht bearbeitet werden kann, arbeite ich an etwas anderem.

Ich ertappe mich oft dabei, wie ich auf den Compiler-Button drücke und entweder etwa 30 Sekunden warte oder abgelenkt werde. Nach diesen 30 Sekunden mache ich mich wieder an die Arbeit, nur um festzustellen, dass ich einen kleinen Fehler gemacht habe, und muss innerhalb von zwei Minuten erneut auf Kompilieren klicken.

Einmal 30 Sekunden zu warten ist nicht allzu schrecklich, aber es ungefähr 15 Mal pro Stunde tun zu müssen, ist mühsam.

Wenn Sie 15 Mal pro Stunde neu kompilieren müssen, weil Sie so viele kleine Fehler gemacht haben, dann ist Ablenkung offensichtlich nicht Ihr Problem - Sie sind einfach nicht vorsichtig genug.

Und wenn Sie kleine Fehler machen, die vom Compiler abgefangen werden, ist das wahrscheinlich ein Zeichen dafür, dass Sie auch logische Fehler machen, die nicht abgefangen werden.

Bemühen Sie sich, sich Ihres Codes bewusster zu sein, bevor Sie ihn kompilieren.

Schau es dir an, schreibe ein paar Kommentare, schau es dir noch einmal an. Dann kompilieren.

Wenn Sie feststellen, dass Sie immer wieder dieselben kleinen Fehler machen, müssen Sie vielleicht mehr Zeit damit verbringen, Ihre Programmiersprache zu verstehen. Eine kleine Investition in das Lernen kann sich langfristig auszahlen.

Investiere die Zeit in dich selbst.

10 Sekunden frei: Liegestütze machen.
60 Sekunden kostenlos: Stack Exchange Hot Network Questions durchsuchen.
120 Sekunden gratis: Steh auf und trink etwas Wasser.

Ich bin gerade von 20 Liegestützen aufgestanden, während ich darauf gewartet habe, dass ein Kollege mir auf Slack antwortet. Jedes Mal, wenn ich sehe, dass ich 10 < seconds < 120auf etwas warten muss, nutze ich die Zeit, um mich zu verbessern . Seit ich vor ein paar Wochen damit angefangen habe, fühle ich mich gesünder, energiegeladener und weniger müde. Ich sehe, dass meine Produktivität in die Höhe geschossen ist. Und ich fühle mich großartig.

Seien Sie vorsichtiger / Holen Sie sich bessere Software

Ist das eigentliche Problem, dass Sie warten müssen, bis der Build abgeschlossen ist, um zu wissen, ob Sie einen Fehler gemacht haben, oder dass Sie genügend kleine Fehler durchgehen lassen, sodass die sehr kurze Build-Zeit (30 Sekunden!) zu einem Problem wurde?

Nicht alle Probleme werden sofort offensichtlich sein; Aus diesem Grund ist versehentliches Programmieren eine schreckliche Idee, und es klingt nach dem, worauf Sie sich einlassen.

Ihre Bearbeitung schlägt vor, dass Sie dies tun, weil die von Ihnen verwendete Software keine Dokumentation enthält. Das ist ein Problem mit der Software und sollte behoben werden. Dokumentation ist kein nettes Extra, sondern Kernfunktionalität. Wenn Sie genug Zeit damit verbracht haben, über die API zu raten, um diese Frage zu stellen, ist es wahrscheinlich an der Zeit zu diskutieren, ob diese Software zu einer Belastung geworden ist.

Nutzen Sie die Zeit für kleine einmalige Aufgaben

30 Sekunden scheinen die perfekte Zeit zu sein, um mehrere kleine Aufgaben zu erledigen, die Sie wahrscheinlich nicht ganz ablenken werden. Die besten Beispiele, die mir einfallen, sind das Abspielen/Ändern eines Musiktitels und das Abrufen Ihrer offiziellen E-Mail. Während der zweite Sie ablenken könnte , ist das an sich vielleicht keine schlechte Sache.

Multitasking

Wie in meinem Kommentar zu der Frage angegeben, bin ich an Builds gewöhnt, die viel länger als 30 Sekunden dauern. Wenn Ihre Builds länger dauern, sollten Sie sicherstellen, dass Sie während dieser Zeit immer eine zweite Aufgabe haben, zu der Sie wechseln können.

Ich versuche, eine Aufgabe A und eine Aufgabe B zu haben – Aufgabe B hat nichts mit kompilierten Programmen zu tun, an denen ich arbeiten kann, während Aufgabe A fast alle meine Festplatten-E / A erstellt und aufsaugt.

Implementieren Sie einen Continuous Integration/Build Server und automatisierte Tests.

Sobald Sie einen Commit durchführen, sollte Ihr Build-Server dies bemerken und einen automatisierten Build starten. Dadurch können Sie sofort weiterarbeiten.

Wenn der Build abgeschlossen ist, sollte Ihr Server einige automatisierte Tests ausführen, um allgemeine Probleme wie die von Ihnen beschriebenen (gemischte Spalten usw.) zu erkennen. Der Server sollte Ihnen eine E-Mail senden, wenn er Kompilierungs- und/oder Testfehler findet.

Der Vorteil dieses Workflows ist, dass Sie nie aus dem Fokus geraten. Sie arbeiten weiter an Ihrer aktuellen Aufgabe und erhalten asynchron Feedback zum Build. Auf diese Weise können Sie einen Gedanken vervollständigen und dann zurückgehen, um Fehler zu beheben, ohne ständig hin und her zu springen, was zu vielen Kontextwechseln führt.

(Dies ist eine Antwort auf die Bearbeitung der ursprünglichen Frage, die besagt, dass es sich bei den fraglichen Fehlern nicht um Kompilierungsfehler handelt, sondern um solche, die Sie erst erkennen, wenn das Programm ausgeführt wird.)

Die Zeit, die mit Verhaltens- oder Laufzeitproblemen verbracht wird, kann durch das Schreiben von Komponententests drastisch reduziert oder eliminiert werden. Sie sparen nicht nur Zeit, da Sie nicht nach jeder Iteration dieselben Schritte manuell ausführen müssen (lassen Sie die Maschine die niedere Arbeit für Sie erledigen), sondern das Schreiben von Code, um sicherzustellen, dass Sie ihn überhaupt testen können, hilft Ihnen beim Durchdenken Ihren Code besser und zwingen Sie, über den Datenfluss nachzudenken und Grenzfälle zu berücksichtigen.

Da es sich bei den Fehlern hier nicht um schlechte Codierung, sondern um schlechte Dokumentation handelt, ist es möglich, (1) viele IDs in einem Kompilierlauf abzufangen, anstatt sie einzeln zu beheben, dann können Sie möglicherweise produktiver arbeiten, wenn Sie Ihr Build-System verwenden, oder (2 ) verschieben Sie die IDs, mit denen Sie ein Problem haben, in eine Textdatei, die zur Laufzeit gelesen werden kann. Dann werden Sie in Ordnung kompilieren und Ihre Zeit in einer Run-Edit-Run-Schleife verbringen, die in Ihrem Fall möglicherweise schneller ist.

Bessere Hardware

Bevor Sie irgendetwas ändern , haben Sie versucht, mehr/bessere Hardware auf das Problem zu werfen? Eine aufgerüstete Workstation ist nicht nur ein nettes Extra, sondern spart dem Unternehmen sogar Geld. Jedes Mal, wenn Sie abgelenkt werden, verliert das Unternehmen Geld (für die Zeit, die Sie damit verbringen, sich wieder zu konzentrieren).

Besserer Bauprozess

Wenn mehr/bessere Hardware das Problem nicht löst, versuchen Sie, den Build-Prozess zu rationalisieren, um schneller zu sein, oder ändern Sie sogar die Toolchain für eine schnellere.

Besser selbst

Der Grund, warum ich diese beiden Ansätze zuerst vorschlage, ist, dass dies die Ablenkungszeit für alle Entwickler in Ihrem Unternehmen und nicht nur für Sie verringert. Wenn beide Ansätze das Problem nicht beseitigen, dann bleibt tatsächlich nur eine Variable übrig, und das sind Sie.

Wenn ich an einem Problem arbeite, plane ich, wie ich etwas in mehreren Schritten lösen kann. Ein Beispiel wäre die Implementierung einer Anmeldeschaltfläche. Dies ist ein mehrstufiger Prozess.

- Find the appropriate button icon and place it in the index.html file.
- Make the button call something on the backend, usually an API
- Make the API call the appropriate service.
- Let the service call the appropriate DataAccess methods
- Create tests for valid and invalid logins (backend)
- Create tests for valid and invalid logins (integration)
- Add these tests to automated test repo
- Commit code
- proceed to next task

Beachten Sie, dass alle Aufgaben in einer logischen Reihenfolge sind (zumindest für mich), aber sie sind nicht in dem Sinne abhängig, dass die Änderung des Codes an verschiedenen Stellen stattfinden würde. Auf diese Weise kann ich meine nächste Aufgabe planen , während meine aktuelle Aufgabe darin besteht, Tests zu kompilieren und/oder auszuführen.

Dieser Ansatz erfordert jedoch, dass Ihre Fähigkeit zum Kontextwechsel zwischen zwei Aufgaben auf dem neuesten Stand ist. Ist dies nicht der Fall, ist dieser Ansatz für Sie nicht geeignet. Andere Ansätze (oben erwähnt) wie Stretching, Fingerübungen könnten ebenfalls funktionieren.