Gibt es einen Vorteil beim Kompilieren Ihres Codes, während Sie fortfahren?

Ich hatte kürzlich ein Vorstellungsgespräch, in dem sie mir eine Stunde Zeit gaben, um richtigen Code zu schreiben. Es war keine große Menge, wahrscheinlich weniger als 100 Zeilen. Nach ungefähr 45 Minuten kompilierte ich, ließ es laufen und brachte es zum Laufen. Ich habe vielleicht 5-10 Minuten damit verbracht, Kompilierungsfehler und ein paar kleinere Fehler zu beheben, aber insgesamt war es sehr reibungslos. (Ich habe übrigens ein Angebot von ihnen bekommen.)

Was mich jedoch verwunderte, war, dass der Interviewer mir sagte, nachdem ich den vollständigen Code übergeben hatte, dass das einzige, was ich falsch gemacht habe, "nicht kompilieren, während ich mitmache". Ich fragte ihn, was der Unterschied sei, und er sagte: "Was hätten Sie getan, wenn Sie den Code fertiggestellt hätten und er nicht rechtzeitig kompiliert worden wäre?"

Meines Erachtens ist dies ein ungültiges Argument, da das "Kompilieren von Code" für eine bestimmte Codelänge im Allgemeinen das Beheben einer konstanten Anzahl von Kompilierungsfehlern und eine relativ konstante Zeit in Anspruch nimmt Schreibe den Code fertig oder verschränke ihn mit deiner Codierungszeit. Wenn Sie die Codierung unterbrechen, um nach fehlenden Semikolons zu suchen, wirkt sich dies möglicherweise nachteilig auf Ihre Effizienz aus. Außer unter extremen Umständen, wenn ich mit Unklarheiten in Bezug auf Randfälle experimentiere, etwa bei virtuellen Funktionen in abgeleiteten Klassen usw., ist zu erwarten, dass von einem erfahrenen Entwickler geschriebener Code kompiliert wird, abzüglich gelegentlicher Tippfehler und sogar wenn nicht, dann '

Bei einem ähnlichen Vorfall erhielt ich in einem Interview eine unvollständige Codebasis und wurde gebeten, diese zu beenden und die erforderlichen Änderungen vorzunehmen, um sie zum Laufen zu bringen. Ich begann damit, den vorhandenen Code zu lesen, und nach ein paar Minuten (noch bevor ich den Code durchgesehen hatte) sagte mir der Interviewer, das sei genug. Als ich ihn fragte, was er getan hätte (dh "was habe ich falsch gemacht"), sagte er mir, dass er damit begonnen hätte, den Code sofort zum Kompilieren zu bringen.

Warum ist das überhaupt relevant? Meiner Meinung nach und nach hat die Tatsache, ob ein Teil des Codes im Wesentlichen zufällig kompiliert wird oder nicht, wenig mit der Korrektheit des zugrunde liegenden Programms zu tun. (Für mich bedeutet das Fokussieren auf das Kompilieren, einen Artikel einer Rechtschreibprüfung zu unterziehen, ohne die Grammatik zu überprüfen.)

Wenn Sie mir einen unvollständigen Code geben, werde ich ihn zuerst lesen. Ich werde nicht einmal versuchen, es zu kompilieren, bis ich weiß, was der Code tut und der Algorithmus korrekt ist.

Wie dem auch sei, es waren nur ein paar Zwischenfälle in der letzten Zeit, aber im Allgemeinen habe ich viele Entwickler darüber sprechen hören, wie sie ihren Code im Laufe der Zeit kompilieren, und dennoch konnte mir niemand sagen, welchen Nutzen dies hat. Ich verstehe die Vorteile des Testens Ihres Codes, aber warum kompilieren?

Meine Frage lautet also: Gibt es etwas, das ich verpasst habe? Hat das Kompilieren tatsächlich einen Vorteil für Sie? Oder ist dies eine Art Mythos, der von der Software-Community verbreitet wird und den Sie häufig kompilieren müssen?

Hat das Kompilieren tatsächlich einen Vorteil für Sie?

Es gibt. Es gibt Ihnen eine kürzere Rückkopplungsschleife - was im Allgemeinen beim Entwerfen (Benutzeroberfläche, Schreiben von Software, visuelles Design usw.) eine gute Sache ist.

Durch eine kurze Rückkopplungsschleife können Sie Fehler frühzeitig beheben, bevor ihre Behebung teurer wird.

Um Ihr Beispiel auszuleihen, sagen Sie, Sie haben in einer C-ähnlichen Sprache codiert und }irgendwo in der Mitte des Programms eine vergessen .

Wenn Sie erst kompilieren, nachdem Sie die Anweisung fertig geschrieben haben, können Sie sich sicher sein, dass Sie den Kompilierungsfehler soeben eingeführt haben, und ihn innerhalb von Sekunden dort und dann beheben.

Wenn Sie dies jedoch nicht tun, müssen Sie viel Zeit damit verbringen, den Code zu lesen, nach der genauen Position zu suchen }und sicherzustellen, dass der Fehler tatsächlich das ist, was beabsichtigt war, sobald Sie den Fehler gefunden haben. Dies würde eine Weile dauern, nachdem Sie das Code-Bit verlassen haben. Es wäre nicht so kristallklar wie in dem Moment, als Sie es geschrieben haben.

Nun ja, das Endergebnis ist dasselbe, aber Sie haben eine Menge Zeit mit syntaktischen Problemen verschwendet, bei denen der Compiler Ihnen helfen kann - eine Zeit, die erheblich kürzer sein könnte, wenn Sie im Laufe der Zeit kompiliert haben.

Das Kompilieren ist eine Form des Tests, insbesondere in Sprachen, in denen häufig Typen wie Haskell oder ML verwendet werden . In anderen Sprachen ist es ein syntaktischer Scan, der wenig aussagt.

Trotzdem scheint mir "compile as you go" eine sehr situative Angewohnheit zu sein. Sie könnten genauso gut als "nervös" eingestuft werden, wenn Sie häufiger kompilieren als das persönliche Vorurteil des Interviewers. Es klingt wie Nitpicking; niemand mag zugeben , dass ein Befragter hat aced den Test; Es gibt den Ausschlag für die Gehaltsverhandlung.

Nicht alle Build-Systeme sind schnell. Ich arbeitete an einem (C ++) Projekt , bei dem Fabrikat 30 Sekunden nur ausgeben würde stat ‚ting alles , um zu bestimmen , ob es erforderlich zu bauen oder nicht, und die meisten Dateien würden ein paar Minuten in Anspruch nehmen zu bauen , wenn Sie Änderungen vorgenommen hatten. Wir zögerten, dies öfter als alle 10-15 Minuten zu tun. Jemand wird ohne Zweifel eine Anekdote darüber liefern, wie Sie Ihre Lochkartenstapel zusammenstellen und zu einem anderen Gebäude bringen ...

Kompilieren Sie, wenn Sie das Gefühl haben, eine komplette konzeptionelle Einheit in Ihrem Kopf erstellt zu haben und bereit sind, sie validieren zu lassen. Einmal pro Minute oder einmal pro Woche, je nach Arbeitsablauf.

Meine Frage lautet also: Gibt es etwas, das ich verpasst habe?

Ja, dein Verstand ist kein Compiler. Ein Compiler kann zwar n Kontextwechsel pro Sekunde durchführen, Ihr Verstand jedoch nicht. Die Anzahl der Kontextwechsel, die Sie an einem Tag vornehmen können, hängt von einer Reihe von Faktoren ab, wie Erfahrung / Vertrautheit mit der Codebasis, wie tief Sie im Code verstrickt sind, wie sauber der Code ist, wie komplex das Problem ist, das Sie angehen. wie müde Sie sind, wenn Sie häufig unterbrochen werden oder in einer lauten Umgebung und so weiter.

Durch das erstmalige Kompilieren einer Codebasis (alle gleichzeitig) (denken Sie an "Projekt mit 20 Dateien") werden Sie gezwungen, den Kontext von dem zu wechseln, über den Sie nachdenken (z. B. "dieser Wert wird hier auf 5 gesetzt, dann in") Die for - Schleife blablabla und der komplexe Algorithmus ergeben den korrekten Wert bei der Rückkehr ") zu einem Kompilierungsproblem, das völlig unabhängig von Ihren Überlegungen ist (andere Datei / Modul / Funktion / Vorbedingungen / Syntax / Variablennamen, Vorbedingungen usw ).

Je mehr Code Sie auf einmal kompilieren, desto mehr Kontextwechsel müssen Sie vornehmen. Dies ist kein Problem für eine kleine Codebasis, wenn der gesamte von Ihnen geschriebene Code dem entspricht, was Sie in einer Stunde geschrieben haben. Es ist jedoch ein großes Problem, wenn in einer vorhandenen Codebasis mit mehreren (und oftmals nicht dokumentierten) Abhängigkeiten gearbeitet wird.

Hat das Kompilieren tatsächlich einen Vorteil für Sie?

Sie minimieren die Kontextänderungen, die Sie vornehmen müssen, und können sich so stärker auf die Auswirkungen und Nebenwirkungen der vorgenommenen Änderungen konzentrieren. Es macht Sie auch weniger müde (und weniger fehleranfällig) und erhöht die Qualität Ihrer Ausgabe (dh Sie können minimierte Nebenwirkungen leichter garantieren, wenn Sie eine Datei gleichzeitig ändern und kompilieren, als wenn Sie zehn Dateien kompilieren und ändern).

Wenn Sie in sehr kurzen Iterationen kompilieren (dies setzt voraus, dass der Kompilierungsprozess für kurze Zeit optimiert ist), können Kompilierungsfehler behoben werden, ohne dass Sie die Zone verlassen müssen.

Oder ist dies eine Art Mythos, der von der Software-Community verbreitet wird und den Sie häufig kompilieren müssen?

Es wird auch von der Software-Community propagiert, hat aber gute Gründe.

Meines Erachtens ist dies ein ungültiges Argument, da das "Kompilieren von Code" für eine bestimmte Codelänge im Allgemeinen das Beheben einer konstanten Anzahl von Kompilierungsfehlern und einen relativ konstanten Zeitaufwand erfordert

Es hört sich für mich so an, als ob Sie nur wenig (bis gar keine) Erfahrung in der Pflege mittlerer bis großer älterer Codebasen (Hunderte oder Tausende von Quelldateien) haben. Dies ist der Punkt, an dem diese Einstellung (dh "Compile as you go") am meisten hilft, und hier bilden Sie diese Art von Gewohnheit.

Ich würde mir vorstellen, dass die Leute, die Sie interviewt haben, eine ähnliche Schlussfolgerung gezogen haben ("Sie haben wenig bis keine Erfahrung mit großen Codebasen").

Ich denke, es gibt hier mehr als einen kleinen professionellen Snobismus. Die Implikation scheint zu sein: "Wenn Sie noch nie das Bedürfnis hatten, regelmäßig zu kompilieren, haben Sie noch nie mit so komplizierten Dingen gearbeitet. Holen Sie sich mehr Erfahrung und kehren Sie zurück, wenn Sie gelernt haben, genau so zu arbeiten, wie wir es tun."

Aber offensichtlich hat dies eine andere Seite. Das Kompilieren einiger Projekte kann einige Zeit in Anspruch nehmen. Ich habe mit Frameworks gearbeitet, deren Kompilierung nach nur geringfügigen Änderungen mindestens 30 Minuten dauert. Der Himmel hilft Ihnen, wenn Sie jemals eine Header-Datei bearbeiten müssen. Vollständige Neukompilierungen werden in der Regel über Nacht durchgeführt. Wenn Sie sich darauf verlassen, dass der Compiler Ihre Fehler abfängt, gibt es immer noch seltene Fehler, die während einer Teilerstellung nicht erkannt werden. Unter diesen Bedingungen kompilieren Sie nicht alle 5 Minuten neu - es sei denn, Sie fühlen sich faul .

Der Compiler kann Ihnen bei logischen oder semantischen Fehlern nicht helfen, und Syntaxfehler sind nicht so schwer zu vermeiden, dass es sich lohnt, den halben Tag mit dem Kompilieren zu verbringen. Natürlich werden Sie gelegentlich Tippfehler machen, aber ich gehe davon aus, dass Sie sowohl tippen als auch lesen können. Wenn Sie die Freiheit haben zu wählen, verwenden Sie einen Codierungsstil, der das Layout gut nutzt, um Fehler optisch hervorzuheben, und Sie werden nie wieder eine Klammer, eine Klammer oder ein Semikolon fallen lassen. Es braucht etwas Übung und Disziplin, als die meisten es gewohnt sind, aber es ist möglich. Ich kann in einem einfachen Texteditor mehrere Stunden lang Code schreiben und ihn das erste Mal besser kompilieren als neun von zehn. Sicher, ich könnte öfter kompilieren, aber ich kann mich nicht erinnern, wann ich das letzte Mal einen Fehler hatte, der dadurch leichter zu korrigieren gewesen wäre.

Wenn Sie kein Fan ständiger Neukompilierung sind, sind Sie in guter Gesellschaft. Hier ist Donald Knuth:

Was Ihre eigentliche Frage betrifft, finde ich die Idee der sofortigen Zusammenstellung und der "Komponententests" nur selten interessant, wenn ich mich in einer völlig unbekannten Umgebung zurechtfinde und Feedback darüber benötige, was funktioniert und was nicht. Andernfalls wird viel Zeit für Aktivitäten verschwendet, an die ich einfach nie denken oder arbeiten muss.

Das alles wird gesagt ... wenn Sie in einem Kontext arbeiten, in dem das Kompilieren eine kostenlose Aktion ist, warum würden Sie das nicht tun? Zu Hause drücke ich bei persönlichen Projekten etwa alle 30 Sekunden Strg-S und die Verknüpfung "Kompilieren" fast genauso oft in einer IDE, die den Code ständig über das Front-End des Compilers ausführt, um Fehler in Echtzeit hervorzuheben. Warum auf ein kostenloses Mittagessen verzichten?

Das Kompilieren ist von Vorteil, wenn Sie fortfahren. Aber ich stimme sehr zu, dass es eine gute Codierungsstrategie ist, bei der Arbeit zu bleiben.

Der wichtigste Vorteil des inkrementellen Kompilierens ist die Mentalität, in die viele geraten, wenn sie auf das Ende des Kompilierens und Testens warten : Am Ende geht es uns mehr darum, den Code zum Laufen zu bringen, als um irgendetwas anderes zu diesem Zeitpunkt. Wir sagen "Oh, muss nur diese Klammer hinzufügen, damit der Compiler aufhört sich zu beschweren" oder "oh, muss dies nur groß schreiben", ohne zu überlegen, ob es einen zugrunde liegenden semantischen Fehler gibt, den dieser Syntaxfehler verbirgt. Ich finde wirklich, dass syntaktische Fehler sich oft in semantischen Fehlern verschachteln (das Gegenteil ist nicht wahr).

Nehmen wir zum Beispiel an, ich hätte die Bedeutung einer Variablen geändert und infolgedessen ihren Namen geändert. Die Namensänderung erzeugt später im Code einen Syntaxfehler, aber wenn ich dem Komplizen durch Korrigieren des Namens nur recht mache, habe ich ignoriert, warum dieser Fehler aufgetreten ist .

Ich verstehe die Vorteile des Testens Ihres Codes, aber warum kompilieren?

Aber wie werden Sie Ihren Code testen, wenn Sie nicht entsprechend kompilieren?

Der Extremfall ist die testgetriebene Entwicklung (TDD). Es ist offensichtlich, dass TDD nicht mit Ihrer Strategie funktioniert, da TDD extrem kurze Zyklen von Schreiben, Kompilieren (sollte fehlschlagen), Schreiben von Code, erneutem Kompilieren, Ausführen von Tests, Beheben von Fehlern, erneutem Kompilieren, Umgestalten und Kompilieren bedeutet -wieder, Run-Test und so weiter ...

Also nicht jeder macht TDD, zumindest nicht immer (ich auch, gebe ich zu). Mit Ihrer aktuellen Strategie haben Sie nie die Möglichkeit, TDD einmal auszuprobieren. Aber auch wenn Sie kein TDD durchführen, ist es meiner Meinung nach äußerst hilfreich, Ihren Code regelmäßiger zu testen - was nicht möglich ist, wenn Sie ihn nicht regelmäßig kompilieren. Und wenn Ihr Test fehlschlägt, müssen Sie ihn debuggen (was Ihnen helfen kann zu verstehen, warum sich der gut aussehende Algorithmus, den Sie einige Minuten zuvor geschrieben haben, nicht so gut verhält, wie Sie gedacht hatten). Und je mehr Code Sie schreiben, ohne zu kompilieren, desto mehr Code schreiben Sie, ohne zu testen, und desto wahrscheinlicher ist es, dass Sie auf einen Fall stoßen, in dem Sie nicht vorhersagen können , dass die Zeit zur Behebung des Problems "O (1)" ist Sie schrieben.

Ich stimme Ihnen sogar zu, dass Compiler-Fehler für einen erfahrenen Entwickler keine große Sache sein sollten. Ich glaube nicht, dass die Kosten für die Reparatur mit der Zeit erheblich genug steigen, um sich Sorgen zu machen. Wenn es möglich wäre, die Behebung aller Compiler-Fehler bis kurz vor einem Push zu verschieben, würde ich dies tun, da dies eine viel kleinere und konsolidiertere Unterbrechung darstellen würde.

Leider ist das Auffinden von Compilerfehlern nicht das einzige, was Compiler tun. Um Ihr Programm ausführen zu können, ist das Kompilieren erforderlich, und das Ausführen Ihres Programms ist erforderlich, um alle komplexeren, subtileren und interessanteren Laufzeitfehler zu finden, die selbst erfahrene Entwickler verursachen. Und diese Arten von Fehlern sind umso schwieriger und daher umso teurer zu beheben, je länger Sie das Debuggen verschieben, da sie aufeinander aufbauen oder sich gegenseitig maskieren können.

Ich würde jedoch nicht unbedingt jemanden in einer Interviewübung für die Verschiebung des Kompilierens bis zum Ende markieren. Interviewübungen sind in der Regel sehr unkompliziert, und erfahrene Entwickler kennen normalerweise ihre Grenzen. Je sicherer Sie sind, was Sie geschrieben haben, desto länger werden Sie zwischen den Kompilierungen verweilen. Das ist nur die menschliche Natur.

Um Sie nicht dafür zu kritisieren, müsste das Vertrauen jedoch gerechtfertigt sein. Wenn Sie 45 Minuten damit verbracht hätten, etwas zu schreiben, ohne es zu kompilieren, und dann weitere 45 Minuten zum Debuggen benötigt hätten, hätte ich das schwer gegen Sie abgewogen.

Das Wichtigste beim Kompilieren ist, soweit ich sehe, dass es häufig in anderen Antworten fehlt: Wenn Sie selten kompilieren und eine große Anzahl von Compilerfehlern erhalten, sind die meisten dieser Fehler bedeutungslos, da sie durch den ersten Fehler generiert werden. Dies kann daran liegen, dass Sie einen falschen Typ oder Tippfehler oder einen einfachen Syntaxfehler hatten, der eine Deklaration ungültig macht.

Sie können immer nur das erste Problem beheben, es erneut kompilieren, das nächste verbleibende Problem beheben usw. Bei einer großen Codebasis kann dies jedoch langsam sein. Wenn Sie jedoch versuchen, die lange Liste von Compilerfehlern und Fehlerquellen zu durchsuchen, die unabhängig sind, verbringen Sie viel Zeit damit, irrelevante Nachrichten zu lesen oder den Code von der sekundären Fehlerquelle zur eigentlichen Ursache zu navigieren.

Eine andere Sache, die für reguläre Builds gilt, ist, dass nichts Sie davon abhält, mit dem Kompilieren zu beginnen, sobald Sie einen vollständigen Codeblock geschrieben haben, der kompiliert werden sollte. Sie können dann während der Kompilierung weiteren Code schreiben, solange Sie die neuen Änderungen nicht speichern, bis die Kompilierung abgeschlossen ist. Es wird also praktisch keine Zeit damit verschwendet, auf den Bau zu warten. Wenn Sie warten, bis Sie alles geschrieben haben, was Sie zu diesem Zeitpunkt schreiben werden, müssen Sie auf die Kompilierung warten, ohne etwas zu tun. Dies ist im Grunde die manuelle Version dessen, was moderne IDEs im Hintergrund automatisch tun können.

Für einen ausreichend erfahrenen Programmierer ist das Kompilieren von Code niemals der Engpass.

Wenn Sie eine Sprache gut genug kennen (dh wenn Sie nicht mehr über die Syntax nachdenken müssen und stattdessen nur Code für die Funktionalität verwenden), neigen Sie dazu, keine einfachen syntaktischen Fehler zu machen. Bei den von Ihnen erstellten Fehlern handelt es sich in der Regel um Tipp- oder Kopierfehler, die mit wenigen Kompilierungsdurchläufen in kurzer Zeit behoben werden können.

Ich schreibe regelmäßig den ganzen Tag Code, ohne ihn zu kompilieren. Dann kompiliere ich und behebe die Syntaxfehler und Warnungen, die der Compiler ausgibt, bevor ich meinen Code festschreibe (mit dem Hinweis "Muss getestet werden!" ). Ich habe kein Problem damit, über 1.000 Zeilen C- oder C ++ - Code in nur wenigen Minuten zu bereinigen.

Dagegen dauert das Debuggen und Testen eine Weile. Logikfehler treten aus den unterschiedlichsten Gründen auf, und ich muss mich noch mit einem Compiler auseinandersetzen, der mir die Subroutine beschreibt, die ich völlig vergessen habe, oder der feststellt, dass mein Binärbaum nicht funktioniert, weil ich ihn eingefügt habe, node->leftals er hätte sein sollen node->right.

Obwohl ich denke, dass es im Allgemeinen unklug ist, mit einem Interviewer zu kämpfen, würde ich sagen, wenn Sie der Meinung sind, dass es sich lohnt, Ihren Stil zu verteidigen, hätten Sie darauf hinweisen müssen, dass Sie genug Zeit gelassen haben, um den von Ihnen geschriebenen Code zu debuggen . Das ist das, was kein guter Programmierer vernachlässigt.

ps - Wenn ich beobachtet hätte, wie Sie Code durchgelesen haben, hätte ich Sie sofort eingestellt. Das macht ein Profi jedes Mal.

Nein, es ist nicht unvernünftig, das Kompilieren zu unterbrechen, bis Sie eine ausreichende Menge an Code erstellt haben (und eine ausreichende Menge hängt vom Codierer und dem Code ab, der geschrieben wird).

Wenn Sie beispielsweise ein großartiger Programmierer sind, der sich die Zeit nimmt, es richtig zu machen, und Sie keine großen Mengen oder verschlungenen Codes schreiben, ist das regelmäßige Kompilieren eine Verschwendung und wahrscheinlich auch eine Ablenkung. Wenn nicht, kann das Kompilieren jeder Funktion eine gute Sache sein. Es kommt auf die Person an.

Stellen Sie sich als Gegenbeispiel vor, Sie schreiben JavaScript-Code - es gibt keinen Compiler. Stattdessen würden Sie (aufgrund der Art des meisten JavaScript-Codes) das Programm ausführen (oder die Seite aktualisieren), um die Ergebnisse Ihrer Codierung anzuzeigen. Jetzt können Sie das erst tun, wenn Sie genug Code geschrieben haben, um einen Sinn zu ergeben. Daher "kompilieren" JavaScript-Entwickler in der Regel so oft sie können, was nicht unbedingt sehr oft der Fall ist.

Kurz gesagt, hier gibt es keine richtige Antwort - der Interviewer liegt nicht falsch, aber Sie auch nicht. Tun Sie, was Sie produktiv macht, und vergessen Sie, was Ihnen jemand sagt, was Sie tun sollen. Es gibt viel wichtigere Faktoren bei der Kodierung, als dass Ihre Tendenz, F7regelmäßig zu schlagen (oder nicht), absolut ohne Bedeutung ist.

Mit einer guten Entwicklungsumgebung sehe ich wenig Grund zum Kompilieren, es sei denn, Sie planen tatsächlich, Code zu testen. Die Tools zur Überprüfung der Hintergrundsyntax erfassen fast alles, worüber der Interviewer zu sprechen scheint, obwohl ich zugeben werde, dass es immer noch einige Fälle gibt (Änderungen, die sich über Dateien verbreiten), die nicht immer vollständig identifiziert werden.

Abgesehen davon werde ich versuchen, so ziemlich die kleinste Codeeinheit zu kompilieren und auszuführen, die tatsächlich zu einem Ergebnis führen kann. Vor einer halben Stunde habe ich ein Mittel zum Drucken einiger Suchergebnisse entwickelt und ein halbes Dutzend Testdrucke (auf PDF, nicht auf Papier) durchgeführt, um das Ergebnis zu verbessern - eine Rate von etwa 1 Kompilierung pro 10 Linien.

Meiner Meinung nach und nach hat die Tatsache, ob ein Teil des Codes im Wesentlichen zufällig kompiliert wird oder nicht, wenig mit der Korrektheit des zugrunde liegenden Programms zu tun. (Für mich bedeutet das Fokussieren auf das Kompilieren, einen Artikel einer Rechtschreibprüfung zu unterziehen, ohne die Grammatik zu überprüfen.)

Meine Erfahrung ist sehr unterschiedlich: Weniger als 5% der Kompilierungsfehler betreffen die Syntax . Ich kenne die Sprache gut, wenn ich Fehler erhalte, sind es meistens Tippfehler, die mir sagen, dass die Semantik nicht korrekt ist.

Deshalb freue ich mich, möglichst schnell von den Rückmeldungen meines Compilers zu profitieren. Haben Sie jemals Erfahrung mit einer IDE, die Kompilierungsfehler in Echtzeit unterstreicht? Eine kürzere Rückkopplungsschleife kann sehr wertvoll sein.

Wenn Sie mir einen unvollständigen Code geben, werde ich ihn zuerst lesen. Ich werde nicht einmal versuchen, es zu kompilieren, bis ich weiß, was der Code tut und der Algorithmus korrekt ist.

Wenn von Ihnen erwartet wird, dass Sie an Code arbeiten, der von einer anderen Person geschrieben wurde, haben Sie nicht immer Zeit, alles zu lesen. Die gute Nachricht ist: Gut geschriebener Code hat eine geringe Kopplung und sollte es Ihnen ermöglichen, unabhängig über den Teil des Codes zu urteilen, den Sie benötigen.

In diesen Fällen müssen Sie davon ausgehen, dass der Code, den Sie noch nicht gelesen haben, korrekt ist, und Sie müssen träge nachforschen, wenn ein Problem vorliegt.

Das "Kompilieren von Code" für eine bestimmte Codelänge umfasst im Allgemeinen das Beheben einer konstanten Anzahl von Kompilierungsfehlern und benötigt eine relativ konstante Zeit. Dies sollte gleich sein, ob Sie dies nach dem Schreiben des Codes tun oder ob Sie verschachteln es mit Ihrer Codierungszeit.

Das Wechseln des Kontexts ist für Ihr Gehirn kostspielig. Daher kann es effizienter sein, kleine Fehler zu beheben, sobald Sie sie schreiben.

EDIT: Ich kann auch eine Analogie zur Quellcodeverwaltung ziehen, wenn ein ganzes Team an denselben Quellen arbeitet. Kompilieren ist wie häufiges Festschreiben. Es hilft, zu vermeiden, dass Sie am Ende große Schmerzen haben, wenn Sie alles zusammenführen und sortieren müssen.

Sie sagen, dass Sie Dinge wie rote Linien unter Ihrem Text deaktivieren. Tun Sie das auch, wenn Sie eine E-Mail schreiben oder ein technisches Dokument schreiben? Dann müssen Sie alle Seiten noch einmal durchlesen, anstatt die Fehler zu beheben.

Ein weiterer Vorteil ist, dass Sie bei der Arbeit an Ihrem Code, wenn Sie ihn immer kompilieren oder nahezu kompilieren, von vielen semantikbasierten IDE-Funktionen profitieren können (sicheres Umbenennen, Refactoring, Auffinden der Verwendung eines Symbols ...). .

Wenn Sie besser verstehen möchten, wie diese Funktionen helfen, können Sie versuchen, sie zu aktivieren und zu üben, um ihre Vorteile selbst zu erleben. Sie können auch versuchen, mit jedem, der an sie gewöhnt ist, eine Paarprogrammierung durchzuführen, um zu sehen, wie er von ihnen profitiert.

Ich habe ein bisschen länger darüber nachgedacht, weil ich das Gefühl hatte, dass mit dem Interviewer etwas sehr, sehr falsch ist und ich konnte nicht genau sagen, was es ist. Hier ist das Problem: Für jeden Code, den ich in den letzten zwanzig Jahren geschrieben habe, war die Zeit, die benötigt wurde, um einen funktionsfähigen Algorithmus in kompilierbaren Code umzuwandeln, minimal. Jeder Effizienzgewinn in diesem Bereich hat einen so geringen Einfluss auf die gesamte Entwicklungszeit, dass er vernachlässigbar ist, und ein Interviewer, der einen Kandidaten für wahrgenommene Ineffizienzen in diesem Bereich ablehnt, hat keine Ahnung, was einen guten Entwickler ausmacht.

Die meiste Zeit sollte darauf verwendet werden, Informationen zu sammeln, was der Code tun soll, Informationen und Spezifikationen zu externen Diensten zu sammeln, die verwendet werden müssen, ein globales Design zu erstellen, das zu korrektem und wartbarem Code anstelle von gehacktem Code führt, und Algorithmen zu finden Das führt zu funktionierendem Code anstelle von Code, der so lange gepatcht wird, bis er funktioniert (Code, der offensichtlich keine Fehler aufweist, im Vergleich zu Code, der keine offensichtlichen Fehler aufweist).

Dann kommt ein winziger Zeitaufwand für das Schreiben von Code, der kompiliert wird.

Dann muss mehr Zeit aufgewendet werden, um sicherzustellen, dass der Code funktioniert, und um sicherzustellen, dass wir wissen, dass der Code funktioniert und weiterhin funktioniert. Dies geschieht durch Schreiben von Komponententests, schrittweises Durchlaufen von Code und größtenteils dadurch, dass in erster Linie gut gestalteter Code vorhanden ist.

Dieser Interviewer konzentrierte sich auf etwas, das in meiner Antwort aus zehn Wörtern besteht. Die 10 Prozent oder weniger der tatsächlichen Arbeitszeit darstellen. Und hat fast keinen Einfluss auf die Fähigkeit dieses Entwicklers, zuverlässigen und funktionierenden Code zu erstellen.

Der Vorteil des "Kompilierens" besteht darin, dass Sie ein ständiges Feedback erhalten und keine Chance haben, weit daneben zu gehen, bevor Sie in die richtige Richtung gelenkt werden. Für einen kompetenten Programmierer wie Sie ist das keine große Überlegung, für viele andere jedoch schon. Anders ausgedrückt: "Kompilieren, während Sie fortfahren" ist ein Weg, "den maximalen Verlust zu minimieren", obwohl in Ihrem Fall einige potenzielle Effizienzverluste auftreten können.

Unternehmen interessieren sich heutzutage nicht nur für ein fertiges Produkt. Sie wollen wissen, dass es die ganze Zeit "unter Kontrolle" war. Für sie ist "dorthin zu kommen der halbe Spaß."

Die anderen Antworten hier sind eine gute Verteidigung für das häufige Kompilieren im Job , aber da sich Ihre Frage auf Interviews konzentriert , möchte ich diesen Aspekt angehen.

In meinen Interviews mache ich genau das Gegenteil: Kandidaten können keinen Compiler verwenden. Sie schreiben kurze Programme an die Tafel und dann diskutieren wir sie. Ich habe festgestellt, dass zu viele Entwickler den Compiler (oder Interpreter) als Krücke verwenden, und das ist eine weitaus größere Zeitverschwendung als zu seltenes Kompilieren. Wenn ich Ihnen eine Menge Geld anbiete und Sie FizzBuzz ohne einen Compiler nicht einmal richtig schreiben können, werden Sie es niemals langfristig schneiden und an Problemen arbeiten, die 100-mal schwieriger sind als die Spielzeugübungen im interview. Und doch haben diese einfachen Übungen mehr Kandidaten ausgesondert als jeder andere Teil des Interviews.

Ziel eines Interviews ist es, die gegenseitige Übereinstimmung von Kandidat und Unternehmen zu bewerten. Eine gute Interviewfrage sollte die Ziele der Frage angeben und wie der Befragte bewertet wird. Dem Befragten eine Trickfrage zu stellen und ihn dann dafür zu bestrafen, dass er die versteckte Antwort nicht kennt, hilft weder dem Befragten noch dem Befragten. Leider sind die meisten Programmierer - auch ältere - nicht dazu ausgebildet, andere Programmierer zu interviewen. Daher verlassen sie sich nur auf Klischees und stellen die gleichen Fragen, die ihnen bei den Interviews gestellt wurden, ohne viel darüber nachzudenken, ob dies wirksame Techniken zur Bewertung von Kandidaten sind oder nicht.

Ich behaupte nicht, dass mein Ansatz der "einzig wahre Weg" ist, aber er hat mir sehr gute Dienste geleistet. Wie so viele Software-Methoden, die mit einem Großbuchstaben beginnen, gibt es auch für Interviews die gleiche Anzahl von "Mandaten". Sie sind alle Etagenbetten. Sie müssen das tun, was für Sie und Ihr Unternehmen funktioniert.

In größeren Projekten mit mehreren Unterroutinen möchten Sie diese Teile testen, bevor Sie sie im größeren Schema verwenden, da das Debuggen einfacher ist, wenn Sie wissen, dass bestimmte Teile bereits funktionieren.

Um diese kleineren Teile zu testen, müssen Sie kompilieren.

Es kann sein, dass der Interviewer diese Situation mit einem kleinen Programm verwechselt, das nicht auf diese Weise entworfen wurde.

In Bezug auf das zweite Interview besteht ein Vorteil des Kompilierens darin, dass Sie innerhalb weniger Sekunden beobachten können, was die Programme tun (oder nicht tun). Von dort aus ist es einfacher, den Code zu lesen und sich auf die relevanten Teile zu konzentrieren. Vielleicht hat der Interviewer das erwartet.

Das Lesen einer unbekannten Codebasis wie dieser von Anfang bis Ende kann recht unproduktiv sein (Sie sind kein Compiler), während das Kompilieren / Ausführen der Anwendung Ihnen schnell ein größeres Bild vermittelt.