Frage:
Während automatischer Prozesse konzentriert bleiben: "Es wird kompiliert"
Daniël van den Berg
2016-06-20 14:09:29 UTC
view on stackexchange narkive permalink

Ich bin kürzlich in eine ziemlich ironische Situation geraten. Nachdem ich einen kleinen Teil in einem Code geändert und meinem Computer gesagt hatte, er solle mit dem Kompilieren beginnen, wechselte ich zu einer Website und stieß auf Folgendes:

The #1 programmer excuse for legitimately slacking off: my code's compiling. From xkcd 303 by Randall Munroe per https://creativecommons.org/licenses/by-nc/2.5/

[xkcd comic 303 von Randall Munroe]

In meiner Firma arbeiten sie mit einem Tool, das beim Kompilieren von Programmen notorisch langsam ist. Es wurde ausgewählt, um die Implementierung von Programmen zu vereinfachen. Sie sind es gewohnt, mit dieser Sprache zu arbeiten.

Ich drücke oft auf die Schaltfläche zum Kompilieren und warte entweder etwa 30 Sekunden oder werde abgelenkt. 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 warten ist nicht allzu schrecklich, aber es ungefähr 15 mal pro Stunde tun zu müssen, ist mühsam. Nach diesen 30 Sekunden wieder an die Arbeit zu gehen, wird von Tag zu Tag schwieriger.

Wie kann ich produktiv bleiben?

Bearbeiten:

Anscheinend war die Art der Fehler, auf die ich stoße, nicht klar. Ich spreche nicht von Fehlern, die vom Compiler abgefangen wurden. Es sind meistens Fehler, die ich erst sehe, wenn das Programm ausgeführt wird und für das es kompiliert werden muss. Zum Beispiel das Vertauschen von zwei (schlecht dokumentierten) IDs. Die Fehler sind aus dem Code schwer zu erkennen, aber aus dem Verhalten leicht zu erkennen.

Update:

Ich habe viele davon übernommen vorgeschlagene Antworten, und keine von ihnen ist "die richtige", da sie alle unterschiedliche Ideen und Meinungen bieten. Einige sind großartige Möglichkeiten, um das Kompilieren zu beschleunigen, aber leider trifft keine davon auf mich zu. Ich arbeite an einem schnellen System mit 2 SSDs, aber der Flaschenhals ist, dass ich an Android arbeite, das über USB hochgeladen werden muss. Da das Kompilieren nicht beschleunigt werden kann, muss ich meinen Workflow anders gestalten.

@ Coteyrs Antwort ist großartig, aber leider ist dies so ziemlich mein einziges Projekt. Dadurch kann ich mich besser auf dieses Projekt konzentrieren, aber da ich nicht zu viel andere Arbeit habe, um dies zu tun, kann ich diese Antwort nicht auf mich selbst anwenden. Ich hoffe, andere finden es nützlich.

Dennis ' und Иво Недев's haben mir sehr geholfen. Ich habe angefangen, meinen Code während des Kompilierens durchzugehen und bei Bedarf Kommentare hinzuzufügen. Es ist jedoch schwierig, damit anzufangen, denn die Idee "meh, jeder, der das liest, sollte wissen, was es bedeutet". Das Vorgeben, dass Leute, die meinen Code lesen, dumm sind, hat viel dazu beigetragen, die richtige Dokumentation hinzuzufügen.

Was meiner Meinung nach die größte Änderung hatte, wird in diesem Thread jedoch nicht erwähnt, da ich die spezifischen Details nicht angegeben habe für eine Antwort wie diese zu kommen. Als ich meinen Prozess noch einmal durchging und die Kompilierungszeit (1 Minute 15) festlegte, stellte ich fest, dass das größte Problem darin bestand, dass ich während des Kompilierens eigentlich nichts tun konnte. Visual Studio hat die böse Angewohnheit, Ihre Dateien zu sperren ... Also dank https://stackoverflow.com/questions/3123624/visual-studio-locking-files-while-debugging habe ich es geschafft Um das zu ändern, und ich kann sagen, es hilft sehr, Ihren Code während der Ausführung berühren zu können.

Ein großes Dankeschön an alle, die geantwortet haben, es wurde für mich einfach viel einfacher Behalten Sie meinen Fokus 8 Stunden am Tag bei.

(Wenn Sie weitere Vorschläge haben, können Sie diese gerne als Antworten hinzufügen. Sie können für zukünftige Passanten sehr hilfreich sein.)

Kommentare sind nicht für eine ausführliche Diskussion gedacht. Dieses Gespräch wurde [in den Chat verschoben] (http://chat.stackexchange.com/rooms/41499/discussion-on-question-by-daniel-van-den-berg-staying-focused-during-automatic-p) .
Die Frage wurde geschützt, sodass ich keine neue Antwort hinzufügen kann, aber ich denke, es gibt eine bessere Antwort als die bereits gegebenen: Verwenden Sie Unit-Tests besser. Sie können die Klasse erstellen und ihr Verhalten in Komponententests testen, die Sie in Ihrer IDE ausführen können. Es wird Ihnen wahrscheinlich auch ermöglichen, einen bestimmten Komponententest durchzuführen, um zu überprüfen, ob Ihre Änderungen ihn behoben haben. Auf diese Weise müssen Sie es weniger häufig bereitstellen.
Amüsanterweise - ich bin hierher gekommen, während mein Latexdokument kompiliert wurde ...
`... Aber der Flaschenhals ist, dass ich an Android arbeite, das über USB hochgeladen werden muss. Da das Kompilieren nicht beschleunigt werden kann ... `- Dann ist Ihr Engpass * nicht * der Kompilierungsschritt. Es ist der Schritt * Hochladen *.
Vierzehn antworten:
#1
+121
Jim G.
2016-06-20 16:19:20 UTC
view on stackexchange narkive permalink

Ein langer Build lähmt den gesamten Softwareentwicklungsprozess. Sie sollten dies nicht als eine Tatsache des Lebens akzeptieren, ohne vorher Schritte zu unternehmen, um die Bauzeit zu verkürzen. Hier sind einige Möglichkeiten, wie Sie dies tun können:

  1. Kaufen Sie eine SSD.
  2. Fügen Sie mehr RAM hinzu.
  3. Wenn Sie Entwickeln Sie eine Web-App: 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 Build-Code und schließen Sie den Build auf Ihrem lokalen Computer kurz, sodass nur die Teile der Codebasis erstellt werden, die sich ändern.
  6. Führen Sie automatisierte Komponententests erst vor der Überprüfung durch -ins.
  7. Arbeiten Sie mit Teammitgliedern und Managern zusammen, um die Erstellungszeit dauerhaft zu verkürzen.
  8. ol>

    Weitere Informationen zu Nr. 1 und Nr. 2: Diese sind besonders effektiv. Sie sollten dies auch dann 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 eine stumpfe Säge nicht tolerieren, und Sie sollten keine langsame Festplatte oder eine Workstation mit unzureichendem RAM tolerieren. Sie möchten nachts 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 diejenigen Personen, die sagten, dass ich die Frage des OP nicht beantwortet habe: Bitte beachten Sie diese Meta-Antwort.
    2. Ein langsamer Build kann den Arbeitsplatz lahm legen. Es ist sehr wichtig, alle Optionen zu prüfen, bevor Sie akzeptieren, dass der Build langsam ist.
    3. ol>
Kommentare sind nicht für eine ausführliche Diskussion gedacht. Diese Konversation wurde [in den Chat verschoben] (http://chat.stackexchange.com/rooms/41500/discussion-on-answer-by-jim-g-staying-focused-during-automatic-processes-its).
Ich würde auch hinzufügen, wenn ich mir andere Tools anschaue. Ich erinnere mich, dass ich mit Sharepoint arbeiten musste und es 15 Minuten dauerte, um eine JavaScript-Änderung bereitzustellen und zu testen! Am Ende habe ich Fiddler verwendet, um Aufrufe von JS-Dateien an lokal gespeicherte umzuleiten, die ich schnell ändern konnte.
Kann bestätigen. Hatte ein altes Rig für eine ziemlich lange Zeit und es war wirklich erschwerend. Nach einem mit mehr RAM war die Arbeit viel besser als zuvor.
Vergleichen Sie auch Ihren Virenprüfer und sehen Sie, wie viel den Build verlangsamt. Ändern Sie bei Bedarf die Virenprüfung.
Nur um # 1 und # 2 zu erweitern, wenn Sie genug RAM dafür haben, sollten Sie Ihre gesamte Entwicklung auf einer [RAM-Disk] (https://en.wikipedia.org/wiki/RAM_drive) (viele Ressourcen) speichern Stellen Sie einfach sicher, dass Sie alle paar Minuten eine Sicherungskopie auf Ihrem System haben, falls ein Stromausfall, ein unerwartetes Herunterfahren usw. auftreten. Ich habe dies selbst sehr effektiv genutzt, indem ich meine gesamte Entwicklungsumgebung eingerichtet habe darin (Java-Instanz, Ameise, Eclipse, Quellcode usw.)
#2
+49
coteyr
2016-06-20 19:26:57 UTC
view on stackexchange narkive permalink

Ein Schwertkampf ist eine großartige Übung. Verwenden Sie es.

Um ehrlich zu sein, können Sie beim Kompilieren nicht viel mit dem Code tun. Sie können versuchen, die Kompilierungszeit zu verkürzen, aber manchmal ist dies einfach nicht möglich. Sie können versuchen, die Anzahl der Kompilierungen zu reduzieren, aber manchmal ist es einfach nur zum Kotzen.

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

  • E-Mails beantworten
  • Dokumententickets
  • Dokumentanwendung
  • Bei SCM festschreiben, wenn Sie können
  • Machen Sie eine echte Pause.
  • Andere nicht verwandte Code-Aufgaben erledigen
  • Treffen mit Teammitgliedern haben
  • ein Nickerchen machen

Ehrlich gesagt ist es eine der Gründe, warum ich die Sprachen mag, die ich mag. Keine Kompilierungszeit. Wenn Sie eine lange Kompilierungszeit haben, müssen Sie sich nur darum kümmern, vorausgesetzt, Sie können sie nicht adressieren.

In .NET können Sie beispielsweise große Logikblöcke von DLLs trennen. 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 Erstellungszeit 30 Sekunden beträgt. Das ist keine lange Bauzeit. Wenn Sie in dieser Zeit etwas tun möchten, machen Sie Fingerübungen oder stehen Sie auf und atmen Sie tief durch. Lange Bauzeiten betragen 10 Minuten. oder mehr.

Sie sollten lesen, wie schlecht es ist, Aufgaben immer wieder zu wechseln, um die Produktivität zu steigern. Solche Dinge funktionieren nicht wirklich. Er wird noch mehr an Produktivität verlieren und mehr Stress bekommen
Nun, als ich die Frage zum ersten Mal las, nahm ich an, dass 30 Minuten bis eine Stunde ein langer Aufbau waren. Wenn Sie eine halbe Stunde Zeit haben, um zu töten, während Sie auf den Compiler warten, füllen Sie ihn am besten mit mindestens halbbezogenen Aufgaben. Wenn Sie über 30 Sekunden sprechen ... Nun, es ist so gut wie jeder andere Zeitpunkt, um eine Art Augen- oder Fingerbelastungsübung durchzuführen. Dort einfach und schnell und EXTREM wichtig.
Nun, dem stimme ich dann zu.
Erwägen Sie das Hinzufügen eines Aufzählungspunkts: "Check * StackExchange Hot Network Questions * list" ;-)
@DigitalTrauma Das muss einer der schlechtesten Produktivitätstipps aller Zeiten sein;) Fast so schlecht wie "einen Wikipedia-Artikel lesen und versuchen, keinen Links zu folgen" (funktioniert nie so).
Dank des Overheads des Kontextwechsels und des begrenzten Platzes im mentalen Stapel ist der Versuch, nicht verwandte Arbeiten während dieser Wartezeiten zu blockieren, wahrscheinlich weniger produktiv als das Anstarren an die Decke.
@NathanCooper Fingerübungen oder Übungen zur Überanstrengung der Augen erfordern nicht viel geistige Leistungsfähigkeit. Besonders wenn Sie es sich zur Gewohnheit machen. "F5" 1-2-3-4-5 1-2-3-4-5 Build prüfen. Code Code Code. "F5" 1-2-3-4-5 1-2-3-4-5 Build prüfen. Und es ist weit weniger Overhead als Augenbelastung oder RSI.
Ich lese das, während die Dinge installiert werden, aber sie wurden vor Minuten erledigt :)
Ich denke, eine Microsoft-Studie hat ergeben, dass das Beantworten von E-Mails 30 Minuten Produktivität kostet. Diese Antwort ist ein aktiv schädlicher Rat. Ich weiß nicht, warum 14 Personen den Kommentar, der dies vorschlägt, positiv bewertet haben, aber die Antwort nicht abgelehnt haben.
30 Sekunden sind genau im schlechten Tal. Zu lange, um konzentriert zu bleiben, wenn Sie sehr oft bauen müssen, aber zu kurz, um zu etwas anderem zu wechseln.
"Commit to SCM, wenn Sie können", bevor ein Build abgeschlossen ist?
@StuperUser Vielleicht hängt es von der Sprache, SCM und Ihren Ignoranten ab. Sie checken die binären Objekte nicht ein. Warum also nicht festschreiben? Wenn Sie in einem Feature-Zweig alle gewünschten Fehler begehen, stammen einige der besten Ideen aus Fehlern. Sie werden zusammenführen / quetschen, bevor Sie mit dem Haupt- / Hauptzweig zusammenführen, oder? Punkt ist, jedes Setup ist anders. Es gibt keinen Grund, warum Sie sich beim Erstellen nicht festlegen können, wenn Sie sich in einer Umgebung befinden, die dies unterstützt.
#3
+45
Dennis Jaheruddin
2016-06-20 19:10:08 UTC
view on stackexchange narkive permalink

Etwas aus meiner eigenen Erfahrung:

Versuchen Sie, mehrere Fehler gleichzeitig zu beheben.

Sicher, es ist sehr schnell, zwei Spalten auszutauschen, nachdem Sie festgestellt haben, dass sie vertauscht sind. Stellen Sie jedoch sicher, dass Sie die Überprüfung nicht beenden, nachdem Sie einen Fehler gefunden haben.

Sie können beispielsweise die Anzahl der Zyklen verringern, indem Sie andere Dinge überprüfen:

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

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

Oh Mann, das ist so kritisch. Wir konzentrieren uns so sehr auf die Reduzierung der Zykluszeit ... Gesamtzeit = Zykluszeit * Anzahl der Zyklen. Das Reduzieren der Anzahl der Zyklen ist genauso wichtig wie das Reduzieren der Zykluszeit !!
Ich denke, dies übersieht die Kosten für die Behebung zu vieler Dinge in einem einzigen Zyklus - dies macht es sehr schwierig, die Auswirkungen einzelner Änderungen zu isolieren. Aus diesem Grund liegt der Schwerpunkt auf der Zykluszeit. Die Reduzierung der Anzahl der Zyklen führt zu weiteren nachteiligen Auswirkungen
@Dancrumb Es muss nicht sein, wenn Sie verwalten, was behoben werden soll, insbesondere in der Phase, in der alles "gebaut" ist und Sie testen. Erstellen Sie während des Testens eine gute Liste aller Probleme, die Sie beheben müssen. Versuchen Sie herauszufinden, was Sie beheben müssen, damit Sie später keinen Versuch und Irrtum benötigen. Testen Sie so viele neue / feste Funktionen wie möglich. Beenden Sie dann das Programm, gehen Sie in Ihre IDE und beheben Sie diese alle. Markieren Sie in der Liste, welche Sie behoben haben. Dann machen Sie Ihren Build und testen Sie alle Ihre Korrekturen - schlagen Sie durch, wenn Sie fertig sind. Auf diese Weise können Sie problemlos Zyklen mit jeweils 10 bis 20 Korrekturen durchführen, bevor Sie sie neu erstellen müssen.
Das ist was ich mache. Insbesondere versuche ich, an zwei unabhängigen Themen gleichzeitig zu arbeiten. Ich werde an Aufgabe 1 arbeiten, auf Kompilieren klicken, zu Aufgabe 2 wechseln, bei der es sich um E-Mail oder eine andere Codebasis handelt. Wechseln Sie dann zurück zu Aufgabe 1, testen Sie und wiederholen Sie den Vorgang.
Bei einer Bauzeit von 30 Sekunden ist das eigentlich keine große Sache. Im schlimmsten Fall beginnen Sie mit dem Kompilieren und überprüfen den Code in der Zwischenzeit. Wenn Sie nichts gefunden haben, haben Sie 30 Sekunden gespart. Jedenfalls lohnt es sich nicht, 30 Sekunden lang zu viel über den Code nachzudenken.
Sie müssen immer testen, was Sie tun. Andernfalls können Sie Fehler oder andere Störungen erstellen, die möglicherweise schwer zu beheben sind, da Sie nicht wissen, welche Ihrer Änderungen diesen Fehler verursacht haben
Habe das verpasst. Es ist nicht so gut, wie die Kompilierungszeit tatsächlich zu reduzieren, aber für diejenigen, die nicht in der Lage sind, die Kompilierungszeit zu reduzieren, ist es eine hervorragende Nutzung der eigenen kognitiven Fähigkeiten - da Sie alles auf einmal tun.
Ich habe nicht gezählt, wie viele Programmierer ich getroffen habe, um nur den ersten Fehler zu debuggen und zu beheben, ohne den Rest der Änderungen zu testen. Dies ist eine ausgezeichnete Antwort.
Relevant: https://blog.codinghorror.com/boyds-law-of-iteration/
#4
+40
Captain Man
2016-06-20 19:53:21 UTC
view on stackexchange narkive permalink

Versuchen Sie, ein Skript zu erstellen, das genau das tut, wofür Sie es benötigen. macht dann ein hörbares Klingeln und / oder ein Popup. Auf diese Weise müssen Sie Ihren Fokus nicht ablenken Sorgen Sie sich darum, die Zonen vollständig zu schließen und zu vergessen, ob Sie fertig sind. Für mich ist es in Ordnung, sich durch andere Dinge wie anderen Code "ablenken" zu lassen, aber das Problem ist, wenn Sie "zu weit in das Kaninchenloch gehen" und vergessen, zu überprüfen, ob der Vorgang abgeschlossen ist.

I. Sie werden sich nicht die Mühe machen, einen Vorschlag dazu zu machen, da dies je nach Betriebssystem, Kompilierungsmethode und anderen Faktoren unterschiedlich ist. Ich würde einfach so etwas wie "Sound erzeugen und Popup einfügen (Betriebssystem hier einfügen), wenn der Befehl ausgeführt wird" oder ähnliches.


Update: as In einigen Kommentaren wurde darauf hingewiesen, dass es in bestimmten Programmen mit GUIs möglicherweise Möglichkeiten gibt, dies zu tun, nicht nur über die Befehlszeile. Nach wie vor werde ich hier keine Vorschläge machen, da dies je nach Programm und Dauer sehr unterschiedlich sein wird.

Slack-Integrationen oder ähnliches funktionieren hierfür gut
+1; Verzögerungen treten auf, und wenn Sie sich nicht genügend Platz auf dem Monitor geben, um die Ergebnisse beim Multitasking zu verfolgen, können Sie das menschliche Äquivalent von "Polling" am besten vermeiden. Es kann auch einfach sein, den Compiler-Befehl zu verpacken, damit eine Nachricht angezeigt wird. Ich verwende ein sehr kurzes "notify" -Shell-Skript, das kurz "$ @" ist. notify-send "$ 1 ist fertig." `([docs] (https://wiki.archlinux.org/index.php/Desktop_notifications))
Tangential im Zusammenhang mit dem Thema langer Prozesse können einige SQL-Clients, wenn Sie routinemäßig lang laufende SQL-Abfragen ausführen, auch nach Abschluss einen Sound liefern.
#5
+28
Иво Недев
2016-06-20 14:24:28 UTC
view on stackexchange narkive permalink

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

Wenn der Compiler es Ihnen ermöglicht, den Code anzuzeigen und er 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.

Sie werden:

  • Lassen Sie sich nicht ablenken und verlieren Sie den Fokus.
  • Wenn ein Fehler auftritt, dauert das Beheben und erneute Kompilieren nicht zwei Minuten, sondern viel weniger.
  • ol>
    #6
    +10
    Matthieu M.
    2016-06-20 18:58:07 UTC
    view on stackexchange narkive permalink

    Zum Beispiel zwei (schlecht dokumentierte) IDs austauschen.

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

    Wenn Sie eine Hühnchen-ID an die Getränkemaschine übergeben können, hat Ihr Code eine Problem (*).

    Der Trick besteht also darin, IDs zu markieren. Da es sich um lange Kompilierungszeiten handelt, gehe ich davon aus, dass Ihnen eine statisch typisierte Sprache zur Verfügung steht. In diesem Fall sollten Sie diese Typen nutzen. Eine ChickenId ist nicht dasselbe wie eine DrinkId . Eine DrinkId ist nicht dasselbe wie eine FuelId .

    Machen Sie sie zu verschiedenen Typen, und der Compiler zeigt Ihnen gerne Ihre Fehler an, was die Geschwindigkeit beschleunigt Erhöhen Sie die Fix-Compile-Test-Schleife (indem Sie den Testschritt ausschneiden und den Kompilierungsschritt unterbrechen).

    Dies ist die statisch typisierte Version des Fail Fast -Prinzips: dort ist kaum schneller, als wenn der Compiler (oder sogar die IDE, wenn sie im Hintergrund kompiliert wird) Fehler auf Sie hinweist.

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

    ( *) Was weiß ich, wenn es bei Ihnen nicht üblich ist, Hühnerblut zu trinken ...

    Obwohl es die Frage des OP möglicherweise nicht direkt anspricht, ist dies kein schlechter Rat. Vergleichen Sie [Falschen Code falsch aussehen lassen] (http://www.joelonsoftware.com/articles/Wrong.html) mit Joel on Software oder [Wie lässt man falschen Code falsch aussehen? Welche Muster verwenden Sie, um semantische Fehler zu vermeiden?] (Https://stackoverflow.com/q/26086/486504) auf [so].
    @MichaelKjörling: In der Tat; Es ist keine neue Idee :) Folgt auch dem Prinzip von Daniel J. Bernstein, Fehler * Klassen * anstelle von Fehlern * Vorkommen * auszurotten.
    Ich verstehe den Geist dieser Antwort, aber ich verstehe nicht, wie Sie das tatsächlich auf so etwas wie eine ID anwenden können. Es gibt nur so viele statische Typen zur Auswahl, und viele sind austauschbar. Wenn Sie beispielsweise eine ID "long" erstellt haben, können Sie dennoch versehentlich ein "int" eingeben. Außerdem wäre dies in der Praxis einfach verrückt.
    @ChrisPratt Einige Sprachen machen solche Dinge Ludricusly einfach (F # und OCaml zum Beispiel). Die Idee ist, dass selbst wenn zwei IDs der gleiche primitive Typ sind (z. B. "int"), Sie für jeden ID-Typ (ChickenID, DrinkID) einen Typ um "int" haben. Obwohl die Funktionalität gleich ist, bedeutet die Semantik des Typsystems, dass Sie sie nicht falsch herum verstehen können. Wenn Code Vergleiche und dergleichen für die ID durchführen muss, können die entsprechenden Methoden entweder pro Typ implementiert werden, oder der typspezifische Code kann sie zerlegen, wenn nichts schief gehen kann.
    @ChrisPratt: Um den Kommentar von VisualMelon zu erweitern, wäre die Verwendung verschiedener integrierter Typen eine schreckliche Idee, da viele Sprachen ohnehin eine implizite Konvertierung haben, sodass nichts gewonnen wird. Stattdessen benötigen Sie für jede * Geschäftseinheit * einen * Geschäftstyp * mit der entsprechenden Funktionalität. Neben der Vermeidung, eine Entität mit einer anderen zu verwechseln, vermeiden Sie auch das Aufrufen unsinniger Funktionen (selbst wenn eine ID numerisch, 2 + ID, 2 * ID usw. ist, macht dies einfach keinen Sinn!).
    #7
    +9
    Kilisi
    2016-06-20 15:21:36 UTC
    view on stackexchange narkive permalink

    Der offensichtliche Weg, dies zu mildern, besteht darin, zunächst keine kleinen Fehler mehr zu machen. Hier würde ich sowieso anfangen.

    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 Flag, um eine robustere Fehlerprüfungsmethode zu haben.

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

    Ich bin kein Programmierer, daher muss ich einiges herumspielen, damit die Dinge manchmal funktionieren. Wie ich produktiv bleibe, ist Multitasking. Wenn an einer Sache nicht gearbeitet werden kann, arbeite ich an etwas anderem.

    Kommentare sind nicht für eine ausführliche Diskussion gedacht. Diese Konversation wurde [in den Chat verschoben] (http://chat.stackexchange.com/rooms/41501/discussion-on-answer-by-kilisi-staying-focused-during-automatic-processes-its).
    #8
    +8
    Joe Strazzere
    2016-06-20 15:02:12 UTC
    view on stackexchange narkive permalink

    Ich drücke oft auf die Schaltfläche zum Kompilieren und warte entweder etwa 30 Sekunden oder werde abgelenkt. 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 warten ist nicht allzu schrecklich, aber Es ist mühsam, es ungefähr 15 Mal pro Stunde tun zu müssen.

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

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

    Bemühen Sie sich Um sich Ihres Codes vor dem Kompilieren bewusster zu werden.

    Sehen Sie sich das an, schreiben Sie einige Kommentare und schauen Sie es sich noch einmal an. Kompilieren Sie dann.

    Wenn Sie wiederholt denselben kleinen Fehler machen, müssen Sie möglicherweise mehr Zeit damit verbringen, Ihre Programmiersprache zu verstehen. Eine kleine Investition in das Lernen könnte sich langfristig auszahlen.

    Entschuldigung für die Unregelmäßigkeit, ich spreche nicht von Fehlern, die vom Compiler abgefangen wurden. Es sind meistens Fehler, die ich erst sehe, wenn das Programm ausgeführt wird und für das es kompiliert werden muss. Zum Beispiel den Austausch von zwei (schlecht dokumentierten) IDs. Die Fehler sind im Code schwer zu erkennen, aber am Verhalten leicht zu erkennen.
    @DaniëlvandenBerg Wenn diese Situation häufig auftritt, können Sie auch TDD (Test Driven Development) einbeziehen.
    @Brandin TDD ist * stark * auf kurze Zyklen angewiesen und kompiliert sehr, sehr häufig. Während TDD nett ist, wird es sein Problem sicherlich * schlimmer * machen.
    Und TDD ist eine gute Praxis. Es ist so, dass Dinge getan werden sollen. "Konzentrieren Sie sich mehr und machen Sie weniger Fehler" ist Wunschdenken von Menschen, die die Art des Jobs ignorieren. Wie das OP sagte, ist es weitaus mehr (wie zehnfach oder mehr) Mühe, einen Fehler im Code zu erkennen als bei der Ausführung. Und viele Fehler werden Sie sowieso nie sehen.
    @nvoigt: Nein, da eine sehr häufige Neukompilierung den Umfang möglicher Gründe für einen Fehler bei der Kompilierung (und beim automatisierten Test während der Erstellung) einschränkt. Wenn Sie zwischen den Builds nur kleine Änderungen vornehmen und dennoch feststellen, dass Sie 15 Versuche benötigen, um das Problem zu beheben, macht der Programmierer (ungeachtet der Abstimmungen) einfach zu viele Fehler (wird sich aber hoffentlich mit der Zeit verbessern, wenn er Erfahrungen sammelt). . In jedem Fall begrenzt TDD den verursachten Schaden.
    @LightnessRacesinOrbit Der "verursachte Schaden" ist die verlorene Zeit, da das Neukompilieren unangemessen lange dauert. Das mit TDD zu beantworten und "nur öfter neu zu kompilieren", ist für mich unverständlich. Wenn etwas lange dauert und ich das nicht ändern kann, muss ich die Notwendigkeit minimieren, es zu tun. TDD macht sehr viele Dinge, aber es minimiert nicht die Notwendigkeit einer Neukompilierung. Das Neukompilieren in kleinen, häufigen Schritten ist das Herzstück von TDD.
    @nvoigt: Wenn Sie 50 wesentliche Codeänderungen vornehmen, bevor Sie eine Kompilierung versuchen, müssen Sie mehr korrigieren und müssen erneut kompiliert werden, bevor Sie Ihr Ziel erreichen. Jede Korrektur / Änderung kann sich auf die 49 von Ihnen vorgenommenen Änderungen auswirken. Wenn Sie stattdessen eine wesentliche Codeänderung vornehmen, testen Sie diese sofort und stellen Sie fest, dass Sie fehlgeschlagen sind. Der durch diesen Fehler verursachte Schaden ist wahrscheinlich weitaus geringer. Um ehrlich zu sein, finde ich das Ganze umstritten, da das OP sagt, dass die Kompilierung nur 30 Sekunden dauert, was nichts ist! : D.
    #9
    +8
    dotancohen
    2016-06-22 19:02:26 UTC
    view on stackexchange narkive permalink

    Investieren Sie die Zeit in sich selbst.

    10 Sekunden frei: Liegestütze machen.
    60 Sekunden frei: Durchsuchen Sie die Fragen zum Stack Exchange Hot Network
    120 Sekunden frei: Steh auf und trink etwas Wasser.

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

    #10
    +7
    user38933
    2016-06-20 20:28:47 UTC
    view on stackexchange narkive permalink

    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 genug kleine Fehler dadurch zulassen Sehr kurze Bauzeit (30 Sekunden!) wurde zum Problem?

    Nicht alle Probleme werden sofort offensichtlich sein. Aus diesem Grund ist versehentliches Programmieren eine schreckliche Idee, und es klingt so, als würden Sie sich damit beschäftigen.

    Ihre Bearbeitung deutet darauf hin, dass Sie dies tun, da die von Ihnen verwendete Software keine Dokumentation enthält. Das ist ein Problem mit der Software und sollte behoben werden. Dokumentation ist kein schönes 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 zur Haftung geworden ist.

    Verwenden 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 ablenken. Die besten Beispiele, die ich mir vorstellen kann, sind das Abspielen / Ändern eines Musiktitels und das Abrufen Ihrer offiziellen E-Mails. Während das zweite Sie ablenken könnte, ist dies von Natur aus keine schlechte Sache.

    Multitasking

    Wie in meinem Kommentar zu der Frage angegeben, bin ich es gewohnt Builds, die viel länger als 30 Sekunden dauern. Wenn Ihre Builds länger dauern, möchten Sie möglicherweise sicherstellen, dass Sie 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 damit zu tun kompilierte Programme, an denen ich arbeiten kann, während Aufgabe A fast alle meine Festplatten-E / A erstellt und aufsaugt.

    Dies ist ein normaler Ablauf für TDD, ein bisschen Test, ein bisschen Code. Nicht versehentlich programmieren. Wenn Sie versehentlich programmieren, kümmern Sie sich nicht um Ihre Tests
    #11
    +7
    SnakeDoc
    2016-06-20 21:35:14 UTC
    view on stackexchange narkive permalink

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

    Sobald Sie einen Commit durchgeführt haben, sollte Ihr Build Server einen automatisierten Build bemerken und starten. Dadurch können Sie sofort weiterarbeiten.

    Nach Abschluss des Builds sollte Ihr Server einige automatisierte Tests ausführen, um häufig auftretende Probleme wie die von Ihnen beschriebenen (gemischte Spalten usw.) zu erkennen. Der Server sollte Ihnen eine E-Mail senden, wenn Kompilierungs- und / oder Testfehler festgestellt werden.

    Der Vorteil dieses Workflows besteht darin, 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.

    Bitte verwenden Sie den Build-Server nicht als Compiler. Ihre Mitarbeiter werden schnell lernen, Sie zu hassen.
    Dies ist zwar ein guter Rat, aber falsch. Sie sollten Unit-Tests lokal kompilieren und ausführen, bevor Sie sie festschreiben. CI-Server geben Ihnen die Garantie nur für faule oder weniger erfahrene Mitarbeiter, die sich verpflichten, ohne diese Dinge zu tun. Außerdem ist Ihre Argumentation fehlerhaft, wenn Sie sagen, dass Sie mit dieser Methode weiter an Ihrer Aufgabe arbeiten können, da Sie an Ihrer Aufgabe weiterarbeiten können, wenn Sie auch lokal erstellen.
    #12
    +5
    babelchips
    2016-06-20 18:26:01 UTC
    view on stackexchange narkive permalink

    (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.)

    Zeitaufwand für Verhalten oder Laufzeitprobleme können durch Schreiben von Komponententests drastisch reduziert oder beseitigt werden. Sie sparen nicht nur Zeit, indem Sie nicht nach jeder Iteration manuell dieselben Schritte ausführen müssen (lassen Sie die Maschine die grundlegende 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 Randfälle zu berücksichtigen.

    #13
    +2
    kevin worley
    2016-06-20 18:00:13 UTC
    view on stackexchange narkive permalink

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

    #14
    +2
    kolsyra
    2016-06-21 14:30:01 UTC
    view on stackexchange narkive permalink

    Bessere Hardware

    Haben Sie vor dem Ändern von irgendetwas versucht, mehr / bessere Hardware auf das Problem zu werfen? Eine aktualisierte Workstation ist nicht nur eine schöne Sache, sondern spart dem Unternehmen auch Geld. Jedes Mal, wenn Sie abgelenkt werden, verliert das Unternehmen Geld (für die Zeit, die Sie damit verbringen, sich wieder zu konzentrieren).

    Besserer Erstellungsprozess

    Wenn mehr / bessere Hardware das Problem nicht gelöst hat, sollten Sie den Erstellungsprozess rationalisieren, um schneller zu sein, oder sogar die Toolchain gegen einen schnelleren austauschen.

    Besser Sie 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 diese beiden Ansätze das Problem nicht lösen, ist tatsächlich nur noch 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.

      - Suchen Sie das entsprechende Schaltflächensymbol und platzieren Sie es in der Datei index.html. - Rufen Sie die Schaltfläche im Backend auf, normalerweise eine API. Erstellen Sie die API Rufen Sie den entsprechenden Dienst auf. - Lassen Sie den Dienst die entsprechenden DataAccess-Methoden aufrufen. - Erstellen Sie Tests für gültige und ungültige Anmeldungen (Backend). - Erstellen Sie Tests für gültige und ungültige Anmeldungen (Integration). - Fügen Sie diese Tests zum automatisierten Test-Repo hinzu nächste Aufgabe  

    Beachten Sie, dass alle Aufgaben in einer logischen Reihenfolge sind (zumindest für mich), aber nicht in dem Sinne abhängig sind, dass die Änderung des Codes an verschiedenen Orten erfolgen würde. Auf diese Weise kann ich meine nächste Aufgabe planen , während meine aktuelle Aufgabe Tests kompiliert und / oder ausführt.

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



    Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
    Loading...