Y a-t-il un avantage à compiler votre code au fur et à mesure?

J'ai récemment eu un entretien d'embauche dans lequel ils m'ont donné une heure pour écrire du code réel. Ce n'était pas énorme, probablement moins de 100 lignes. Après environ 45 minutes, je l'ai compilé, exécuté et mis au travail. J'ai peut-être passé 5 à 10 minutes à résoudre des erreurs de compilation et quelques bugs mineurs, mais dans l'ensemble, tout s'est très bien passé. (Incidemment, j'ai reçu une offre de leur part.)

Cependant, ce qui m'a intriguée, c'est qu'après avoir remis le code complet, l'intervieweur m'a dit que la seule chose que j'avais mal fait était de "ne pas compiler au fur et à mesure". Je lui ai demandé quelle était la différence et il m'a répondu "qu'aurais-tu fait si tu avais fini le code et qu'il ne compilait pas à temps".

A mon sens, cet argument est invalide, car "obtenir du code à compiler" pour une longueur de code donnée implique généralement de réparer un nombre constant d'erreurs de compilation et prend un laps de temps relativement constant, qui devrait être identique si vous le faites après terminez d’écrire le code ou si vous l’entrelacez avec votre temps de codage. Au contraire, interrompre votre codage pour rechercher les points-virgules manquants serait probablement préjudiciable à votre efficacité. Sauf dans des circonstances extrêmes, lorsque j'expérimente des obscurités autour de cas tels que des fonctions virtuelles dans des classes dérivées, etc., il semble raisonnable de s'attendre à ce qu'un code écrit par un développeur expérimenté compilera, moins les erreurs de frappe occasionnelles, et même si ce n'est pas le cas

Dans un autre incident similaire, on m'a donné une base de code incomplète lors d'une interview et on m'a demandé de le terminer et d'apporter les modifications nécessaires pour le faire fonctionner. J'ai commencé par lire le code existant, puis après quelques minutes (avant même d'avoir fini de le lire), l'intervieweur m'a dit que c'était suffisant. Quand je lui ai demandé ce qu'il aurait fait (c'est-à-dire "qu'est-ce que j'ai fait de mal"), il m'a répondu qu'il aurait commencé par obtenir immédiatement le code à compiler.

Pourquoi est-ce même pertinent? À mon avis et selon mon expérience, la compilation d'un code est essentiellement aléatoire, impliquant par exemple la disparition de points-virgules et ayant peu à voir avec la justesse du programme sous-jacent. (Pour moi, se concentrer sur la compilation revient à faire passer un article par un correcteur orthographique sans relecture pour vérifier la grammaire.)

Si vous me donnez un morceau de code incomplet, la première chose que je ferai sera de le lire. Je ne vais même pas essayer de le compiler avant de savoir ce que fait le code et de savoir que l'algorithme est correct.

Quoi qu'il en soit, il ne s'agit que de quelques incidents récents, mais en général, j'ai entendu de nombreux développeurs parler de la compilation de leur code au fur et à mesure, mais personne n'a été en mesure de me dire l'avantage de le faire. Je comprends les avantages de tester votre code au fur et à mesure, mais pourquoi compiler?

Ma question est donc la suivante: y a-t-il quelque chose qui m'a échappé? Y a-t-il un avantage à compiler au fur et à mesure? Ou est-ce une sorte de mythe propagé par la communauté des logiciels selon lequel vous devez compiler votre code fréquemment?

Y a-t-il un avantage à compiler au fur et à mesure?

Il y a. Cela vous donne une boucle de retour d'information plus courte - ce qui est généralement une bonne chose lors de la conception (interface utilisateur, logiciel d'écriture, conception visuelle, etc.).

Une courte boucle de rétroaction signifie que vous pouvez corriger rapidement les erreurs, avant qu'elles ne deviennent plus coûteuses.

Pour emprunter votre exemple, supposons que vous codiez dans une langue semblable à C et que vous ayez oublié }quelque part au milieu du programme.

Si vous compilez juste après avoir fini d'écrire la déclaration, vous pouvez être certain que vous venez d'introduire l'erreur de compilation et que vous pouvez la corriger sur place, puis en quelques secondes.

Dans le cas contraire, vous devrez passer beaucoup de temps à lire le code, à rechercher la position exacte }et à vous assurer que, une fois l'erreur trouvée, le correctif correspond bien à votre intention. Cela se produirait un certain temps après que vous ayez quitté ce morceau de code. Ce ne serait pas aussi limpide qu'au moment où vous l'avez écrit.

Maintenant, oui, le résultat final est le même, mais vous avez perdu beaucoup de temps sur les problèmes de syntaxe pour lesquels le compilateur est là pour vous aider - un temps qui pourrait être considérablement plus court si vous compiliez au fur et à mesure.

La compilation est une forme de test, en particulier dans les langues qui utilisent beaucoup de types tels que Haskell ou ML . Dans d'autres langues, c'est une analyse syntaxique qui vous en dit peu.

Cela dit, "compiler au fur et à mesure" me semble une habitude très situationnelle. Vous pourriez aussi bien être considéré comme étant "sournois" pour avoir compilé plus souvent que le préjugé personnel de l'intervieweur. Cela ressemble à du nitpicking; personne n'aime admettre qu'une personne interrogée a réussi le test; il fait pencher la balance de la négociation salariale.

Tous les systèmes de construction ne sont pas rapides. J'ai travaillé sur un projet (C ++) dans lequel Make passerait 30 secondes à tout déclarer pour déterminer s'il était nécessaire de construire ou non, et la plupart des fichiers prendraient quelques minutes à créer si vous aviez apporté des modifications. Nous hésitions à le faire plus souvent que toutes les 10-15 minutes. Quelqu'un racontera sans doute une anecdote lors de la compilation en prenant votre paquet de cartes perforées et en le transportant dans un autre bâtiment ...

Compilez lorsque vous sentez que vous avez créé une unité conceptuelle complète dans votre tête et que vous êtes prêt à la faire valider. Une fois par minute ou une fois par semaine, en fonction du flux de travail.

Ma question est donc la suivante: y a-t-il quelque chose qui m'a échappé?

Oui: votre esprit n'est pas un compilateur. Bien qu'un compilateur puisse effectuer n changements de contexte par seconde, votre esprit ne le peut pas. Le nombre de changements de contexte que votre esprit peut créer au cours d’une journée dépend de nombreux facteurs tels que l’expérience / la familiarité avec la base de code, votre immersion mentale dans le code, la propreté du code, la complexité du problème que vous abordez, à quel point vous êtes fatigué, si vous êtes fréquemment interrompu ou dans un environnement bruyant, etc.

Compiler une base de code (tous en même temps), pour la première fois (pensez "projet avec 20 fichiers") vous obligera à changer de contexte par rapport à ce que vous pensez (par exemple, "cette valeur est définie sur 5 ici, puis dans la boucle for blablabla, et l'algorithme complexe donne la valeur correcte au retour ") à un problème de compilation qui n'a aucun rapport avec ce à quoi vous pensez (fichier / module / fonction / conditions / syntaxe / noms de variable, conditions préalables, etc. ).

Plus vous compilez de code en une fois, plus votre esprit doit changer de contexte. Ce n'est pas un problème pour une base de code réduite, lorsque tout le code que vous avez écrit correspond à celui que vous avez écrit en une heure. Cependant, c'est un gros problème lorsque vous travaillez dans une base de code existante, avec des interdépendances multiples (et souvent non documentées).

Y a-t-il un avantage à compiler au fur et à mesure?

Vous minimisez les changements de contexte que votre esprit doit faire, ce qui vous permet de vous concentrer davantage sur l’impact et les effets secondaires des changements que vous apportez. Cela vous rend également moins fatigué (et moins sujet aux erreurs) et augmente la qualité de votre sortie (vous pouvez ainsi garantir des effets secondaires minimisés plus facilement lorsque vous modifiez et compilez un fichier à la fois, plutôt que lorsque vous en compilez et en modifiez dix).

Si vous compilez de très courtes itérations (cela suppose que le processus de compilation est optimisé pour prendre un peu de temps), il est possible de corriger les erreurs de compilation sans sortir de "la zone".

Ou est-ce une sorte de mythe propagé par la communauté des logiciels selon lequel vous devez compiler votre code fréquemment?

La communauté des logiciels le propage également, mais elle a de bonnes raisons.

A mon sens, cet argument est invalide, car "obtenir du code à compiler" pour une longueur de code donnée implique généralement de réparer un nombre constant d'erreurs de compilation et prend un laps de temps relativement constant.

Il me semble que vous n’avez que peu (voire aucune) d’expérience dans la maintenance de bases de code héritées de moyenne à grande taille (des centaines ou des milliers de fichiers sources). C’est là que cette attitude (c’est-à-dire "compiler au fur et à mesure") aidera le plus, et c’est là que vous formez ce genre d’habitude.

J'imagine que les personnes qui vous ont interrogé ont tiré une conclusion similaire ("vous avez peu ou pas d'expérience dans les bases de code volumineuses").

Je pense qu'il y a plus qu'un petit snobisme professionnel ici. L'implication semble être "si vous n'avez jamais eu besoin de compiler régulièrement, vous n'avez jamais travaillé avec quelque chose d'aussi compliqué - allez acquérir un peu plus d'expérience et revenez quand vous aurez appris à travailler exactement comme nous."

Mais évidemment, il y a un autre côté à cela. Certains projets prennent un âge pour compiler. J'ai travaillé avec des frameworks dont la compilation nécessite 30 minutes ou plus, même après des modifications mineures. Heaven vous aidera si vous avez besoin de modifier un fichier d'en-tête. Les recompilations complètes sont généralement effectuées du jour au lendemain, et si vous comptez sur le compilateur pour corriger vos erreurs, il existe encore de rares erreurs qui ne seront pas détectées lors d'une construction partielle. Ne recompilez pas toutes les 5 minutes dans ces conditions, à moins que vous ne vous sentiez paresseux .

Le compilateur ne peut pas vous aider avec les erreurs logiques ou sémantiques et les erreurs de syntaxe ne sont vraiment pas si difficiles à éviter que passer la moitié de votre journée de compilation en vaut la peine. Bien sûr, vous ferez de temps en temps une faute de frappe, mais je vais supposer que vous pouvez à la fois toucher et lire. Si vous avez la liberté de choisir, utilisez un style de codage qui utilise bien la disposition pour mettre en évidence les erreurs et vous ne perdrez plus jamais d'accolade, de crochet ou de point-virgule. Cela demande un peu de pratique et un peu plus de discipline que la plupart des gens, mais c'est possible. Je peux écrire du code plusieurs heures à la fois dans un éditeur de texte en clair et le compiler une première fois mieux que neuf fois sur dix. Bien sûr, je pourrais compiler plus souvent, mais je ne me souviens pas de la dernière fois où j'ai eu une erreur qui aurait été plus facile à corriger.

Si vous n'êtes pas fan de la recompilation constante, vous êtes en bonne compagnie. Voici Donald Knuth:

En ce qui concerne votre vraie question, l’idée d’une compilation immédiate et de «tests unitaires» ne m’intéresse que rarement, alors que je me sens dans un environnement totalement inconnu et que j’ai besoin d’un retour d’information sur ce qui fonctionne ou non. Sinon, beaucoup de temps est perdu pour des activités que je n'ai jamais besoin de réaliser ni même de penser.

Tout cela étant dit ... si vous travaillez dans un contexte où la compilation est une action libre, pourquoi pas vous? À la maison, sur des projets personnels, j'appuie sur ctrl-S environ une fois toutes les 30 secondes et le raccourci "compiler" presque aussi souvent, dans un environnement de développement intégré qui exécute constamment le code via le front-end du compilateur afin de mettre en évidence les erreurs en temps réel. Pourquoi laisser passer un déjeuner gratuit?

Il y a des avantages à compiler au fur et à mesure. Mais je suis tout à fait d’accord pour dire que rester sur la tâche est une stratégie de codage acceptable.

L'avantage le plus important de la compilation incrémentale est la mentalité de beaucoup d'entre eux s'ils attendent la fin de la compilation et du test : nous sommes plus préoccupés par le fait de faire exécuter le code que toute autre chose à ce stade. Nous disons "Oh, juste besoin d'ajouter ce support pour que le compilateur arrête de se plaindre" ou "Oh juste besoin de le capitaliser" sans se demander s'il y a une erreur sémantique sous-jacente que cette erreur de syntaxe cache. Je trouve vraiment que les erreurs syntaxiques se nichent souvent dans des erreurs sémantiques (l'inverse n'est pas vrai).

Par exemple, disons que j'ai changé le sens d'une variable et que, par conséquent, son nom a été changé. Le changement de nom génère une erreur de syntaxe plus tard dans le code, mais si je me contente de plaire au compliant en corrigeant le nom, j'ai ignoré la raison de cette erreur.

Je comprends les avantages de tester votre code au fur et à mesure, mais pourquoi compiler?

Mais comment allez-vous tester votre code au fur et à mesure que vous ne compilez pas en conséquence?

Le cas extrême est le développement piloté par les tests (TDD). Il est évident que TDD ne fonctionne pas avec votre stratégie, car TDD signifie des cycles extrêmement courts de test d'écriture, de compilation (en cas d'échec), d'écriture de code, de nouvelle compilation, de test d'exécution, de correction de bogues, de nouvelle compilation, de refactorisation, de compilation. -again, run-test, et ainsi de suite ...

Donc, tout le monde ne pratique pas le TDD, du moins pas toujours (moi aussi, je l’avoue). Avec votre stratégie actuelle, vous n'aurez jamais la possibilité d'essayer TDD. Mais même lorsque vous ne faites pas de TDD, il est extrêmement utile à mon humble avis de tester votre code plus régulièrement - ce qui n’est pas possible si vous ne le compilez pas régulièrement. Et lorsque votre test échoue, vous devez le déboguer (ce qui peut vous aider à comprendre pourquoi le bel algorithme que vous avez écrit quelques minutes auparavant ne se comporte pas aussi bien que vous le pensiez). Et donc plus il est probable que cela se produira que vous exécutez dans un cas où vous le code plus vous écrivez sans compiler, plus de code que vous écrivez sans test, ne peut pas prédire que le temps de résoudre le problème est « O (1) », comme tu as écrit.

En fait, je suis d’accord avec vous pour dire que les erreurs de compilation ne devraient pas poser de problèmes importants aux développeurs expérimentés. Je ne pense pas que le coût de leur réparation augmente suffisamment avec le temps pour s'inquiéter. S'il était possible de différer la correction de toutes les erreurs du compilateur jusqu'à un moment propice, je le ferais, car cela présenterait une interruption beaucoup plus petite et plus consolidée.

Malheureusement, la recherche des erreurs du compilateur n'est pas la seule chose à faire par les compilateurs. Au risque d'exposer l'évidence, la compilation est nécessaire pour exécuter votre programme, qui doit rechercher tous les bogues d'exécution les plus complexes, subtils et intéressants créés par des développeurs expérimentés. Et ces types de bogues sont plus difficiles et donc plus coûteux à réparer plus vous retardez leur débogage, car ils peuvent se construire ou se masquer les uns les autres.

Cependant, je ne noterais pas nécessairement quelqu'un dans un exercice d'interview pour avoir différé la compilation jusqu'à la fin. Les exercices d'entretien ont tendance à être très simples et les développeurs expérimentés connaissent généralement leurs limites. Plus vous êtes confiant dans ce que vous avez écrit, plus vous allez passer de temps en temps entre les compilations. C'est juste la nature humaine.

Afin de ne pas vous fâcher, la confiance devrait cependant être justifiée. Si vous aviez passé 45 minutes à écrire quelque chose sans compiler, puis qu’il vous a fallu 45 minutes supplémentaires pour le déboguer, j’aurais pesé cela très lourdement contre vous.

La seule chose importante à propos de la compilation, qui manque souvent à d’autres réponses, est la suivante: si vous compilez rarement et obtenez un grand nombre d’erreurs de compilation, la plupart d’entre elles n’ont aucune signification, car elles sont générées par la première erreur. Cela peut être dû au fait que vous avez un type incorrect, une faute de frappe ou une erreur de syntaxe simple qui rend une déclaration invalide.

Vous pouvez toujours corriger le premier, recompiler, corriger le suivant, etc., mais avec une base de code volumineuse, cela peut être lent. Mais si vous essayez de parcourir la longue liste d'erreurs de compilateur et d'erreurs de tache indépendantes, vous passez alors beaucoup de temps à lire des messages non pertinents ou à parcourir le code du lieu d'erreur secondaire à la cause réelle.

Une autre chose à faire pour les constructions régulières est que rien ne vous empêche de commencer à compiler dès que vous avez écrit un bloc complet de code, qui devrait être compilé. Vous pouvez ensuite continuer à écrire plus de code pendant la compilation, à condition de ne pas enregistrer les nouvelles modifications jusqu'à la fin de la compilation. Il n’ya donc pratiquement pas de temps perdu à attendre la construction. Si vous attendez d'avoir écrit tout ce que vous allez écrire à ce moment-là, vous devrez alors attendre la compilation sans rien faire. Ceci est fondamentalement la version manuelle de ce que les IDE modernes peuvent faire automatiquement en tâche de fond.

Pour un programmeur suffisamment expérimenté, la compilation de code n'est jamais le goulot d'étranglement.

Une fois que vous connaissez suffisamment la langue (par exemple, lorsque vous n'avez plus besoin de penser à la syntaxe mais plutôt au code pour la fonctionnalité), vous ne commettez pas d'erreurs syntaxiques simples. Ceux que vous faites sont généralement des fautes de frappe ou des bogues de copier-coller, et ils peuvent être nettoyés rapidement en quelques passes de compilation.

J'écris régulièrement du code toute la journée sans compiler, puis je compile et corrige les erreurs de syntaxe et les avertissements signalés par le compilateur avant de valider mon code (avec une note disant "doit être testé!" ). Je n'ai aucun problème à nettoyer plus de 1 000 lignes de code C ou C ++ en quelques minutes seulement.

Le débogage et les tests, en revanche, prennent du temps. Les erreurs de logique surviennent pour toutes sortes de raisons et je n'ai pas encore rencontré de compilateur qui me parle du sous-programme que j'ai totalement oublié d'écrire, ou je remarque que mon arbre binaire ne fonctionne pas car j'ai collé node->leftquand il aurait dû l'être node->right.

Bien que je pense qu'il soit généralement peu judicieux de se battre avec un interviewer, je dirais que si vous estimiez que votre style valait la peine d'être défendu, vous auriez dû indiquer que vous aviez laissé assez de temps pour déboguer le code que vous aviez écrit. C'est la chose qu'aucun bon programmeur ne néglige jamais.

ps - Si j'avais regardé votre code en le lisant, je vous aurais embauché sur place. C'est ce que fait un professionnel à chaque fois.

Non, il n'est pas déraisonnable de retarder la compilation tant que vous n'avez pas créé une quantité de code suffisante (et une "quantité suffisante" dépend du codeur et du code en cours d'écriture).

Par exemple, si vous êtes un excellent codeur qui prend son temps pour bien faire les choses, et que vous n'écrivez pas des quantités énormes ou du code compliqué, alors compiler régulièrement est un gaspillage, et probablement aussi une distraction. Si vous ne l'êtes pas, alors compiler chaque fonction peut être une bonne chose. Cela dépend de la personne.

En guise de contre-exemple, imaginez que vous écrivez du code JavaScript - il n’existe pas de compilateur. Au lieu de cela (étant donné la nature de la plupart du code JavaScript), vous devez exécuter le programme (ou actualiser la page) pour voir les résultats de votre codage. Maintenant, vous ne pouvez pas faire cela tant que vous n'avez pas écrit suffisamment de code pour donner un sens. En conséquence, les développeurs JavaScript ont tendance à "compiler" aussi souvent qu'ils le peuvent, ce qui n'est pas nécessairement très souvent.

En bref, il n'y a pas de réponse correcte ici - l'intervieweur n'a pas tort, mais vous non plus. Faites ce qui vous rend productif et oubliez ce que quelqu'un vous dit que vous êtes censé faire. Il existe des facteurs beaucoup plus importants concernant le codage que votre tendance à frapper F7régulièrement (ou non) n’a absolument aucune conséquence.

Avec un bon environnement de développement, je ne vois aucune raison de compiler, sauf si vous envisagez réellement de tester le code. Les outils de vérification de la syntaxe en arrière-plan couvrent presque tout ce dont l’intervieweur semble parler, bien que je reconnaisse qu’il existe encore quelques cas (impliquant des modifications qui se propagent d’un fichier à l’autre) qui ne sont pas toujours bien identifiés.

Cela étant dit, je vais essayer de compiler et d’exécuter à peu près la plus petite unité de code pouvant réellement produire un résultat. Il y a une demi-heure, je créais un moyen d’imprimer des résultats de recherche et j’ai effectué une demi-douzaine d’impressions test (au format .pdf, et non au papier) en apportant des modifications au résultat pour l’améliorer - un taux d’environ 1 compilation par 10 lignes.

À mon avis et selon mon expérience, la compilation d'un code est essentiellement aléatoire, impliquant par exemple la disparition de points-virgules et ayant peu à voir avec la justesse du programme sous-jacent. (Pour moi, se concentrer sur la compilation revient à faire passer un article par un correcteur orthographique sans relecture pour vérifier la grammaire.)

Mon expérience est très différente: moins de 5% des erreurs de compilation que je reçois concernent la syntaxe . Je connais bien la langue, quand je reçois des erreurs, ce sont surtout des erreurs de type, qui me disent que la sémantique n'est pas correcte.

C'est pourquoi je suis heureux de bénéficier aussi rapidement que possible des retours de mon compilateur. Avez-vous déjà utilisé un IDE qui souligne les erreurs de compilation en temps réel? Avoir une boucle de rétroaction plus courte peut être très utile.

Si vous me donnez un morceau de code incomplet, la première chose que je ferai sera de le lire. Je ne vais même pas essayer de le compiler avant de savoir ce que fait le code et de savoir que l'algorithme est correct.

Si vous devez travailler sur du code écrit par quelqu'un d'autre, vous n'avez pas toujours le temps de tout lire. La bonne nouvelle est que le code bien écrit a un couplage faible et devrait vous permettre de raisonner de manière indépendante sur la partie du code dont vous avez besoin.

Dans ces cas, vous devez supposer que le code que vous n'avez pas encore lu est correct et enquêter paresseusement en cas de problème.

"obtenir du code à compiler" pour une longueur de code donnée implique généralement la correction d'un nombre constant d'erreurs de compilation et prend un laps de temps relativement constant, qui devrait être identique si vous le faites après avoir fini d'écrire le code ou si vous l'entrelacez avec votre temps de codage.

La commutation de contexte est coûteuse pour votre cerveau. Il est donc plus efficace de corriger les petites erreurs dès que vous les écrivez.

EDIT: Je peux aussi faire une analogie avec le contrôle de source, quand toute une équipe travaille sur les mêmes sources. Compiler au fur et à mesure, c'est comme faire des commits fréquents, cela aide à éviter d'avoir beaucoup de douleur à la fin lorsque vous devez tout fusionner et tout trier.

Vous dites que vous désactivez des choses comme des lignes rouges sous votre texte. Faites-vous cela également lorsque vous tapez un email ou rédigez un document technique? Ensuite, vous devez relire toutes les pages au lieu de corriger les erreurs au fur et à mesure.

Un autre avantage est que, lorsque vous travaillez sur votre code, si vous continuez à le compiler ou à le compiler à tout moment, vous pouvez bénéficier de nombreuses fonctionnalités de l'EDI basées sur la sémantique (renommage sécurisé, refactoring, recherche des utilisations d'un symbole ...). .

Si vous souhaitez mieux comprendre l’aide apportée par ces fonctionnalités, vous pouvez essayer de les activer et de les mettre en pratique, afin de faire l'expérience de leurs avantages. Vous pouvez également essayer de programmer en binôme avec ceux qui y sont habitués et voir comment ils en tirent profit.

J'ai réfléchi un peu plus longtemps à ce sujet, car j’ai eu l’impression que l’intervieweur avait quelque chose de très erroné et je ne pouvais pas dire exactement ce que c’était. Voici le problème: pour tout code que j'ai écrit au cours des vingt dernières années, le temps nécessaire pour transformer un algorithme utilisable en code compilant a été minime. Tout gain d'efficacité dans ce domaine a si peu d'impact sur le temps de développement total qu'il est totalement négligeable, et l'intervieweur qui rejette un candidat pour des inefficacités perçues dans ce domaine n'a aucune idée de ce qui fait un bon développeur.

La plupart du temps devrait être consacré à la collecte d'informations sur ce que le code est censé faire, la collecte d'informations et de spécifications sur les services extérieurs devant être utilisés, la création d'une conception globale qui aboutira à un code correct et maintenable au lieu d'un code piraté, et à la recherche d'algorithmes cela conduira au code de travail au lieu du code qui est corrigé ensemble jusqu'à ce qu'il fonctionne (code qui ne comporte évidemment aucune erreur, par opposition au code qui ne comporte aucune erreur évidente).

Vient ensuite une petite quantité de temps à écrire du code qui compile.

Vient ensuite un temps plus long passé pour s’assurer que le code fonctionne et pour s’assurer que nous savons que le code fonctionne et continuera de fonctionner. Ce qui est fait en écrivant des tests unitaires, en passant par le code, et dans une large mesure en ayant un code bien conçu en premier lieu.

Cet intervieweur s'est concentré sur quelque chose qui est couvert par dix mots dans ma réponse. Ce qui représente 10% ou moins du temps de travail réel. Et n'a presque aucune influence sur la capacité de ce développeur à produire du code fiable et fonctionnel.

L'avantage de "compiler au fur et à mesure" est que vous obtenez un retour constant et que vous n'aurez aucune chance de vous tromper avant d'être poussé dans la bonne direction. Pour un programmeur compétent comme vous, ce n'est pas un facteur important, mais pour de nombreux autres. En d'autres termes, "compiler au fur et à mesure" est un moyen de "minimiser la perte maximale", même s'il existe des pertes d'efficacité potentielles dans votre cas.

Les entreprises de nos jours ne sont pas seulement intéressées par un produit fini. Ils veulent savoir qu'il était "sous contrôle" depuis le début. Pour eux, "s'y rendre est la moitié du plaisir".

Les autres réponses ici constituent une bonne défense pour la compilation fréquente au travail , mais comme votre question est centrée sur les entretiens , je voudrais aborder cet aspect-là.

Dans mes entretiens, je fais exactement le contraire: les candidats ne peuvent pas utiliser un compilateur. Ils écrivent des programmes courts sur le tableau blanc, puis nous en discutons. J'ai constaté que trop de développeurs utilisent le compilateur (ou l'interpréteur) comme une béquille, ce qui représente une perte de temps bien plus importante que la compilation trop peu fréquente. Si je vous offre beaucoup d'argent et que vous ne pouvez même pas écrire FizzBuzz correctement sans compilateur, vous ne le réduirez jamais à long terme, vous travaillez sur des problèmes 100 fois plus difficiles que les exercices simples. dans l'interview. Et pourtant, ces exercices simples éliminent plus de candidats que toute autre partie de l'entretien.

Le but d'un entretien est d'évaluer l'adéquation entre le candidat et l'entreprise. Une bonne question d’entrevue devrait préciser les objectifs de la question et la façon dont l’interviewé sera évalué. Poser une question piège sur l'interviewé et ensuite le pénaliser pour ne pas connaître la réponse cachée n'aide pas l'intervieweur ou l'interviewé. Malheureusement, la plupart des programmeurs, même les plus expérimentés, ne sont pas formés pour interroger d'autres programmeurs. Ils se basent donc uniquement sur des clichés et posent le même type de questions qu'auparavant, sans trop savoir toutefois s'il s'agit de techniques efficaces d'évaluation des candidats. ou pas.

Je ne prétends pas que mon approche est la "seule vraie manière", mais cela m’a très bien servi. Comme beaucoup de méthodologies logicielles qui commencent par une majuscule, il existe un nombre égal de "mandats" pour les entretiens. Ils sont tous superposés. Vous devez faire ce qui fonctionne pour vous et votre entreprise.

Dans les projets plus importants, avec plusieurs sous-routines, vous souhaitez tester ces parties avant de les utiliser dans un schéma plus large, car il est beaucoup plus facile de déboguer si vous savez que certaines parties fonctionnent déjà.

Afin de tester ces petites pièces, vous devez compiler.

Il se peut que l'intervieweur confonde cette situation avec un petit programme qui n'est pas conçu de cette manière.

En ce qui concerne la deuxième interview, l’un des avantages de la compilation est que vous pouvez observer, en quelques secondes à peine, ce que les programmes font (ou ne font pas). À partir de là, il est plus facile de lire le code et de concentrer vos efforts sur les parties pertinentes. C'est peut-être ce à quoi l'intervieweur s'attendait.

Lire une base de code inconnue comme celle-ci du début à la fin peut être assez improductif (vous n'êtes pas un compilateur), tandis que la compilation / l'exécution de l'application vous donnera rapidement une image plus grande.