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

183

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?

CaptainCodeman
quelle
54
Entweder das, oder meine Gewohnheiten werden von Menschen mit unterschiedlichen Gewohnheiten als schlechte Gewohnheiten bezeichnet.
CaptainCodeman
9
@DocBrown Der Vergleich ist gültig, wenn das Endziel ein korrektes Produkt ist. Ein Programm, das "läuft", ist nicht besser als ein Programm, das falsch läuft. Sie können nicht erwarten, dass die Kompilierung Ihren Code mehr auf Sie überprüft als eine Rechtschreibprüfung, um Ihre Grammatikfehler zu beheben.
CaptainCodeman
7
Ob das Kompilieren Ihren Workflow stört, ist sehr subjektiv und hängt von der Sprache, der Build-Umgebung, der Größe / Komplexität des Projekts usw. ab. IMO ist eher ein Problem bei großen Legacy-Projekten.
pjc50
64
Ich stimme dem OP voll und ganz zu. Ich kann nicht verstehen, wie jemand seine Arbeitsgewohnheiten beurteilen kann, z. B. wenn er / sie den Compiler startet. Das einzige, was zählt, ist das Ergebnis der Bemühungen. Ist es richtig? Ist es wartbar? Läuft es im erwarteten Zeitrahmen? Wie lange hat die Implementierung gedauert? Das sind die interessanten Fragen. Alles andere ist willkürliche BS. Wenn der Befragte 2 Stunden perfekten Code schreibt, der beim ersten Versuch kompiliert wird, wo liegt das Problem? Nur weil der Interviewer es anders macht? Mein Gott.
JensG
9
Es sollte auch erwähnt werden, dass die IDE für bestimmte Sprachen und IDEs (Java / [Eclipse | NetBeans | etc], C # / Visual Studio, ...) bereits alles im Hintergrund in Echtzeit kompiliert, während Sie es eingeben Sie erhalten sofort eine Rückmeldung, ob Sie einen Fehler gemacht haben. Man würde hoffen, dass die IDE-Entwickler einige Nachforschungen angestellt haben, die diesen Ansatz unterstützen.
Ogre Psalm33

Antworten:

223

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.

Oded
quelle
72
Tatsächlich kompilieren und rekompilieren moderne IDEs bei solchen syntaktischen Fehlern die ganze Zeit, um die Rückkopplungsschleife so kurz wie möglich zu halten, und es ist unangemessen hilfreich, um kleinere Fehler zu erkennen.
Phoshi
12
@CaptainCodeman - Ich würde sagen, dass es einige Kompilierungsfehler gibt, bei denen Sie eine Menge Code durchsuchen müssen. Dies gilt vor allem für größere Codebasen und größere Änderungsmengen.
Oded
29
Manchmal gibt Ihnen der Compiler ein Rätsel anstelle eines Hinweises, wie z. B. gcc-Vorlagenfehler.
pjc50
14
@ pjc50: absolut (was einfacher zu handhaben ist, wenn nicht zu viele Dinge auf einmal vor der nächsten Kompilierung geändert werden, sodass Sie genau wissen, was Sie zuletzt geändert haben).
Doc Brown
21
Die Idee ist nicht nur zufällig zu kompilieren. Es ist notwendig, bei jedem wichtigen Schritt zu kompilieren, um zu kompilieren, wenn Sie erwarten, dass es immer noch richtig funktioniert. Ich werde beispielsweise kompilieren, um zu testen, ob Objekte ordnungsgemäß erstellt / gelöscht werden, oder um sicherzustellen, dass Ereignisse ordnungsgemäß für eine von mir erstellte neue Klasse ausgelöst werden. Wenn ich eine Klasse erstelle und sie auf irgendeine Weise in mein Programm einbinde, möchte ich sicherstellen, dass ich sie korrekt ausgeführt habe, bevor ich weitere Elemente in meine App einbinde. Bei kleinen Apps weniger wichtig, bei großen unabdingbar.
Thebluefish
108

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.

pjc50
quelle
25
Wenn Sie Ihre Lochkarten zum Laden zu den Sysops bringen, stellen Sie sicher, dass Sie sie niemals fallen lassen, da es ein echtes Problem ist, sie wieder in die richtige Reihenfolge zu bringen! Ah, für die Tage, als ein wesentliches Debugging-Tool ein Gummiband war.
Gbjbaanb
3
Als ich anfing zu programmieren, maß ich meinen Fortschritt daran, wie viel Code ich schreiben konnte, ohne zu kompilieren - im Wesentlichen an der Qualität meines mentalen Compilers. Zuerst waren es ein paar Zeichen, dann ein paar Zeilen. Jetzt ist es mir egal. Ich kompiliere viel für kleine Änderungen, ich möchte nur die Auswirkungen von sehen, ich kompiliere sehr wenig, wenn ich das strukturelle Layout des Projekts mache.
Phil
Hmm. Ich möchte nur sagen, dass eine gut geschriebene C ++ - Datei für die Kompilierung nicht länger als ein paar Sekunden dauern sollte. Wenn es länger ist, riecht es nach schlechtem Code. Und wenn es so groß ist, dass make Probleme hat, würde ich argumentieren, dass die Anwendung zu monolithisch ist. "Mein" make hatte nie Probleme, und das auch nicht beim Kompilieren von Linux.
Phresnel
2
Es war 1,5 Millionen LOC, als ich ging. Beachten Sie, dass Linux C und nicht C ++ ist. Vorlagen scheinen in gcc langsam zu sein, und wenn Sie etwas Kluges und Nützliches getan haben, das sich nur langsam kompilieren lässt, gibt es keine einfache Möglichkeit, dem Compiler ein Profil zu geben, um herauszufinden, was es war.
pjc50
21
@gbjbaanb Ich denke, es wäre besser zu sagen, "die Tage, an denen die Quellcodeverwaltung ein Gummiband war." ;)
JasonMärcher
35

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

utnapistim
quelle
1
"compile and change ten" - viele Situationen, in denen dies die kleinste sinnvolle Einheit ist, die es zu versuchen gilt; B. Hinzufügen eines neuen Parameters zu einer Funktion und allen ihren Aufrufstellen.
pjc50
7
Kontext wechselt. Du machst Witze oder? Wenn wir über die automatische Hintergrundkompilierung sprechen, um auf syntaktische Fehler in Ihrem Code hinzuweisen, ist das in Ordnung. Die schnellste Kontextumschaltung kann Ihnen jedoch nicht sagen, ob die Algorithmuslogik korrekt implementiert ist oder ob der Algorithmus überhaupt geeignet ist. Aber das ist es, was eine funktionierende Lösung von ordentlich organisiertem, fehlerfrei kompiliertem und blitzschnellem, aber völlig falschem Code unterscheidet.
JensG
5
@ JenS, nein, ich mache keine Witze. Wenn Sie den gesamten Code überspringen müssen, um Kompilierungsfehler zu beheben, denken Sie nicht mehr an das Problem, das Sie gerade lösen (Sie verlassen die Zone). Wenn Sie stattdessen beim Schreiben des Codes kompilieren können, können Sie den Algorithmus und nicht die Syntax überprüfen. Die schnellste Möglichkeit, mit Kontextwechseln umzugehen, besteht darin, sicherzustellen, dass Sie sie nicht benötigen. Mein Beitrag geht jedoch von einer idealen Welt aus (mit einer schnellen C ++ - Kompilierung großer Codebasen und minimierten Abhängigkeiten).
Dienstag,
1
@JensG das scheint ein logischer Trugschluss zu sein: Hier geht es nicht um die Wahl zwischen kompiliertem Code und beschissenem Code, sondern um mögliche Vorteile des mehrmaligen Kompilierens.
Jörg
1
Ich bezweifle, dass die Behauptung, die Konzentration für eine kurze Zeitspanne Dutzende Male zu brechen, um einzelne syntaktische Fehler zu beheben, schneller ist, als sie einmal zu brechen und ein Dutzend syntaktischer Fehler auf einmal zu beheben (nachdem Sie sich um Ihren tatsächlichen Algorithmus gekümmert haben). So funktionieren Kontextwechsel beim Computing sicher nicht (wir versuchen hier doch, den Durchsatz zu optimieren). Und ich habe an einem Projekt mit ca. 500.000 C ++ - Code gearbeitet, das sich in mehr als einem Jahrzehnt entwickelt hat, also hoffe ich, dass wir die Unerfahrenheitskarte noch nicht zeichnen?
Voo
26

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?

DeveloperInDevelopment
quelle
Ich bin nicht einverstanden, dass das Kompilieren kostenlos ist, Ablenkungen sind teuer! Aber ansonsten gute Antwort, danke :)
CaptainCodeman
Vielleicht hätte ich das kühne, kursiv geschriebene "if" zu einem "iff" machen sollen ... Ich denke, je nach Projekt, Compiler und Umgebung kann es ziemlich nahe an einer freien Aktion liegen. Wenn Sie ein zweites Fenster oder einen zweiten Bildschirm für die Compiler-Ausgabe haben, können Sie fast so oft kompilieren, wie Sie aufhören zu atmen. Wenn Sie wirklich hardcore wären (ich nicht), müssten Sie nicht einmal von Ihrem Code wegschauen - vorausgesetzt, der Compiler hat ausführlich genug Fehler erzeugt, um sich auf Ihrer peripheren Vision zu registrieren. Dies ist wiederum der Fall , wenn die Kompilierung relativ schnell ist, ansonsten siehe oben.
DeveloperInDevelopment
2
I hit ctrl-S about once every 30 seconds. Ich spare wahrscheinlich doppelt so oft lol. Es ist eine wirklich schlechte Angewohnheit. Manchmal speichere ich in der Mitte einer Codezeile und am Ende wieder. Immer wenn ich eine Sekunde nachdenke und nicht tippe, spare ich.
Cruncher
21

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 .

Lan
quelle
5
+1 für die Hervorhebung der Verbindung zwischen semantischen und sytaktischen Fehlern
Doc Brown
15

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.

Doc Brown
quelle
1
Ich stimme Ihnen zu, aber ich denke, es gibt einen Unterschied zwischen dem Kompilieren eines Programms, weil Sie es ausführen möchten, und dem Kompilieren, wenn es nichts Sinnvolles zum Testen (oder zum Beheben von Kompilierungsfehlern) gibt.
CaptainCodeman
@CaptainCodeman: Ich denke, wenn man 100 Zeilen Code schreibt, sollte es fast immer viele kleine Teile geben, die einzeln für sich getestet werden können. 100 Codezeilen bedeuten normalerweise 4 bis 15 Funktionen (oder> 20, wenn Sie im Bob-Martin-Stil codieren).
Doc Brown
5
@CaptainCodeman: In TDD gibt es nie "nichts Sinnvolles" zum Testen. Das klassische Beispiel ist, dass Sie eine neue Klasse schreiben möchten (nennen wir sie Foo). Als Erstes müssen Sie einen Komponententest erstellen und schreiben, new Foo();der offensichtlich nicht kompiliert werden kann, da Sie die Klassendefinition nicht geschrieben haben. In TDD ist dies ein triftiger Grund, einen Compiler auszuführen - es zeigt, dass Ihr Komponententest funktioniert (durch Fehlschlagen).
Slebetman
@slebetman: danke für diesen hilfreichen Kommentar. Ich möchte hinzufügen, dass dies meiner Meinung nach nicht auf TDD beschränkt ist. Wenn Sie 100 Codezeilen schreiben, gibt es immer etwas Sinnvolles, um dazwischen zu testen, ob Sie TDD ausführen oder nicht.
Doc Brown
14

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.

Karl Bielefeldt
quelle
8

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.

hyde
quelle
Interessanterweise ist dies ein guter Grund, regelmäßig zu kompilieren, auch wenn die Kompilierung langsam ist . Guter Punkt.
sleske
3

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.

Par
quelle
4
"Ich habe noch keinen Compiler getroffen, der mir von der Subroutine erzählt, die ich völlig vergessen habe, zu schreiben." Ich verlasse mich voll und ganz auf den Compiler, der mir mitteilt, wenn ich keine weitreichenden Änderungen vorgenommen habe. Manchmal benenne ich eine Variable sogar um, um eine erfolgreiche Kompilierung zu verhindern, bis ich jede Instanz ihrer Verwendung überprüft und ihnen den neuen Namen gegeben habe. Ich verstehe nicht, wie Sie sagen können, dass Sie keinen Compiler gefunden haben, der Sie nicht warnt, wenn etwas fehlt. Es sei denn, Sie schreiben leere Platzhalter-Unterprogramme und vergessen sie dann. In diesem Fall hilft Ihnen der Himmel.
Ian Goldby
@par Danke für deine Antwort; Es ist gut zu wissen, dass ich nicht der einzige bin, der so codiert!
CaptainCodeman
3
@CaptainCodeman Mir ist klar, dass Logikfehler schleichender sind als Compilerfehler. Aber es war seine Behauptung, dass ein Compiler nicht in der Lage sei, Sie über fehlenden Code zu informieren, den ich bestreiten wollte. Es sei denn, Sie schreiben absichtlich falschen (oder unvollständigen) Code, der… kompiliert, aber dies beseitigt eher das Argument, dass Fehler, die der Compiler nicht abfangen kann, das eigentliche Problem sind, IMO. Ich benutze sogar den Compiler, um das Caret in die Zeile zu verschieben, in der ich als nächstes Code schreiben muss. Aber vielleicht bin ich sehr faul.
Ian Goldby
1
@IanGoldby: Sie haben den Punkt völlig verpasst und ich würde sogar sagen, dass Sie sich dafür entschieden haben, meine Worte zu verdrehen. Der Compiler kann Sie nicht vor fehlendem Code warnen, so wie ich Ihnen morgen nicht sagen kann, was Sie zum Frühstück essen werden. Das absichtliche Einführen von Syntaxfehlern, damit der Compiler Sie an etwas erinnert, das eine Programmiertechnik ist; es qualifiziert nicht als Fehler oder gibt dem Compiler psychische Superkräfte.
Par
1
@par Ich entschuldige mich für die Straftat, die ich offensichtlich durch meinen Kommentar verursacht habe - es war nicht beabsichtigt und ich wollte mit Sicherheit nicht falsch darstellen, was Sie gesagt haben. Ich sehe jetzt, dass Sie, wenn Sie unvollständigen Code schreiben, der trotzdem kompiliert wird, sicherstellen, dass er nicht vergessen wird, indem Sie #warning oder TODO hinzufügen. Das ist eine legitime Technik. Das Wichtige, worüber wir uns beide einig sind, ist, dass Code, der kompiliert, aber nicht funktioniert, weitaus gefährlicher ist als Code, der nicht kompiliert.
Ian Goldby
3

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.

gbjbaanb
quelle
Ihr zweiter Absatz ist unklar. Vielleicht möchten Sie es bearbeiten, um festzustellen, ob der "awesome coder" regelmäßig kompiliert werden soll oder nicht. (Haben Sie ein "t" hinzugefügt und "no" in "not"
geändert
@DougM - ta viel.
Gbjbaanb
Sehr oft wird Scripting-Code "live" entwickelt, das heißt, er wird in der REPL-Umgebung ausgeführt. Die "Kompilierung" geschieht also die ganze Zeit, der meiste Code, der in die Quelldatei geschrieben wird, wurde auch einmal ausgeführt. Nicht alle Schreib Script - Code auf diese Weise, aber ich würde jemand sagen pflegte und gern die relative „Sicherheit“ von statisch typisierten Sprachen und Compiler - Fehler von fehlerhaftem Code angegeben, sie sollten in Skriptsprachen auf diese Weise arbeiten.
Hyde
2

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.

Loren Pechtel
quelle
1

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.

Eldritch Conundrum
quelle
1
Normalerweise deaktiviere ich nervige "Compiler-Funktionen" wie automatische Formatierung, Zeichnen roter Linien unter Ihrem Text usw., da ich finde, dass ich ohne diese verworrenen Funktionen produktiver bin.
CaptainCodeman
1

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.

gnasher729
quelle
Das macht sehr viel Sinn. Meiner Meinung nach sollte ein guter Entwickler in der Lage sein, den ganzen Tag Code auf Papier zu schreiben und ihn am Ende des Tages einzutippen.
CaptainCodeman
1

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ß."

Tom Au
quelle
dies scheint nicht alles zu bieten erhebliche über das, was in früheren 16 Antworten gepostet
gnat
2
Danke, aber von was für einem Verlust sprechen wir? Ohne drastische Maßnahmen wie das versehentliche Schreiben in der falschen Sprache müssten Sie sicher keinen Code einfach aufgrund von Kompilierungsfehlern neu schreiben.
CaptainCodeman
@CaptainCodeman: Dadurch fühlen sich Unternehmen besser und es handelt sich um eine Art "Versicherung". Das ist etwas, das Geld kostet, aber die meisten Menschen (einschließlich der Manager) dazu bringt, "nachts besser zu schlafen".
Tom Au
@gnat: Der Punkt, den ich anstrebte, war, dass die meisten Vorteile Vorteile auf "Unternehmensebene" waren, und das sollte der Programmierer tun, weil der Chef es ihm sagte, und nicht, weil der Programmierer glaubt, es sei richtig oder falsch.
Tom Au
Gute Punkte für eine "kürzere Rückkopplungsschleife" wurden bereits in der ersten Antwort an dieser Stelle gemacht und gut erklärt. Ich sehe ehrlich gesagt nicht , wie Füllung über „Unternehmen in diesen Tagen“ raten nackten fügt etwas wert über das, was bereits gesagt wurde
gnat
1

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.

Mark E. Haase
quelle
0

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.

Per Alexandersson
quelle
0

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.

laurent
quelle
dies scheint nicht alles zu bieten erhebliche über das, was in früheren 15 Antworten gepostet
gnat