Y a-t-il un avantage à compiler votre code au fur et à mesure?
J'ai récemment eu un entretien d'embauche au cours duquel ils m'ont donné une heure pour écrire du vrai code. Ce n'était pas énorme, probablement moins de 100 lignes. Après environ 45 minutes, j'ai compilé, l'ai exécuté et l'ai fait fonctionner. J'ai peut-être passé 5 à 10 minutes à résoudre des erreurs de compilation et quelques bugs mineurs, mais dans l'ensemble, c'était très fluide. (Soit dit en passant, j'ai reçu une offre de leur part.)
Cependant, ce qui m'a intrigué, c'est qu'après avoir remis le code complet, l'intervieweur m'a dit que la seule chose que j'avais mal faite était de "ne pas compiler au fur et à mesure". Je lui ai demandé quelle était la différence, et il a répondu "qu'auriez-vous fait si vous aviez terminé le code et qu'il ne s'est pas compilé à temps".
À ma connaissance, c'est un argument invalide, car "obtenir du code à compiler" pour une longueur de code donnée implique généralement de corriger un nombre constant d'erreurs de compilation et prend un temps assez constant, qui devrait être le même si vous le faites après vous finissez d'écrire le code, ou si vous l'entrelacez avec votre temps de codage. Si quoi que ce soit, interrompre votre codage pour rechercher les points-virgules manquants serait probablement préjudiciable à votre efficacité. Sauf dans des circonstances extrêmes où j'expérimente des obscurités autour des cas Edge sur des choses comme les fonctions virtuelles dans les classes dérivées, etc., il semble raisonnable de s'attendre à ce que le code écrit par un développeur expérimenté se compile, moins l'erreur de frappe occasionnelle, et même si ce n'est pas le cas, ce n'est pas comme si je devais réécrire une partie du code afin de corriger l'erreur de compilation.
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 regarder le code), 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 dit qu'il aurait commencé par obtenir immédiatement le code à compiler.
Pourquoi est-ce même pertinent? À mon avis et selon mon expérience, le fait qu'un morceau de code soit compilé ou non est essentiellement aléatoire, impliquant des choses comme le fait que des points-virgules soient manquants ou non, et a peu à voir avec l'exactitude du programme sous-jacent. (Pour moi, se concentrer sur la compilation, c'est comme faire passer un article par une vérification 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 n'essaierai même pas de le compiler jusqu'à ce que je sache ce que fait le code et que je sache que l'algorithme est correct.
Quoi qu'il en soit, ce ne sont que 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, et pourtant personne n'a pu me dire l'avantage de le faire. Je comprends les avantages de testing votre code au fur et à mesure, mais pourquoi compiler?
Ma question est donc la suivante: y a-t-il quelque chose que j'ai manqué? Y a-t-il réellement 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 réellement un avantage à compiler au fur et à mesure?
Il y a. Cela vous donne une boucle de rétroaction plus courte - ce qui en général, lors de la conception (interface utilisateur, logiciel d'écriture, conception visuelle, etc.) est une bonne chose.
Une courte boucle de rétroaction signifie que vous pouvez corriger rapidement les erreurs au début, avant qu'elles ne deviennent plus coûteuses à corriger.
Pour emprunter votre exemple, supposons que vous codiez dans un langage de type C et que vous avez oublié un } quelque part au milieu du programme.
Si vous compilez juste après avoir fini d'écrire l'instruction, vous pouvez être certain que vous venez d'introduire l'erreur de compilation et pouvez la corriger ici et là, en quelques secondes.
Si vous ne le faites pas, cependant, vous devrez passer beaucoup de temps à lire le code, à chercher la position exacte que le } est et assurez-vous, une fois que vous avez localisé l'erreur que le correctif est bien ce qui était prévu. Cela se produirait un certain temps après que vous ayez laissé ce bout de code. Ce ne serait pas aussi clair que pendant le 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 syntaxiques avec lesquels le compilateur est là pour vous aider - un temps qui pourrait être considérablement plus court si vous compilé au fur et à mesure.
La compilation est une forme de test, en particulier dans les langues qui utilisent largement des 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 tout aussi bien être accusé d'être "nerveux" pour avoir compilé plus fréquemment que les préjugés personnels de l'intervieweur. Cela ressemble à une piqûre; 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++) où Make passerait 30 secondes juste stat 'tout pour déterminer s'il avait besoin de construire ou non, et la plupart des fichiers prendraient quelques de minutes à construire si vous avez apporté des modifications. Nous étions réticents à le faire plus fréquemment que toutes les 10 à 15 minutes. Quelqu'un vous fournira sans doute une anecdote lors de la compilation qui impliquait de prendre votre jeu de cartes perforées et de les transporter dans un autre bâtiment ...
Compilez lorsque vous sentez que vous avez fait une unité conceptuelle complète dans votre tête et êtes prêt à la valider. Une fois par minute ou une fois par semaine selon le flux de travail.
Ma question est donc la suivante: y a-t-il quelque chose que j'ai manqué?
Oui: votre esprit n'est pas un compilateur. Alors qu'un compilateur peut effectuer n changements de contexte par seconde, votre esprit ne le peut pas. Le nombre de changements de contexte que votre esprit peut faire en une journée dépend d'un certain nombre de facteurs tels que l'expérience/la familiarité avec la base de code, la façon dont vous êtes immergé mentalement dans le code, la propreté du code, la complexité est le problème auquel vous vous attaquez, à quel point vous êtes fatigué, si vous êtes fréquemment interrompu ou dans un environnement bruyant, etc.
La compilation d'une base de code (tout en même temps), pour la première fois (pensez "projet avec 20 fichiers") vous obligera à changer le contexte de ce à quoi 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 rien à voir avec ce à quoi vous pensez (fichier/module/fonction/conditions préalables/syntaxe/noms de variables différents, conditions préalables, etc.) ).
Plus vous compilez de code à la fois, plus votre contexte doit changer de contexte. Ce n'est pas un problème pour une petite base de code, lorsque tout le code que vous avez écrit est ce que vous avez écrit en une heure. C'est un gros problème cependant, lorsque vous travaillez dans une base de code existante, avec plusieurs interdépendances (et plusieurs fois non documentées).
Y a-t-il réellement un avantage à compiler au fur et à mesure?
Vous minimisez les changements de contexte que votre esprit doit effectuer, vous permettant 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 (c'est-à-dire que vous pouvez garantir des effets secondaires minimisés plus facilement lorsque vous modifiez et compilez un fichier à la fois, que lorsque vous en compilez et modifiez dix).
Si vous compilez en 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?
Il est également propagé par la communauté des logiciels, mais il a de bonnes raisons derrière cela.
À ma connaissance, cet argument n'est pas valide, car "obtenir du code à compiler" pour une longueur de code donnée implique généralement de corriger un nombre constant d'erreurs de compilation et prend un temps assez constant
Il me semble que vous avez peu (voire aucune) expérience dans la maintenance de bases de code héritées moyennes à grandes (des centaines ou des milliers de fichiers source). C'est là que cette attitude (c'est-à-dire "compiler au fur et à mesure") vous aidera le plus, et c'est là que vous prenez ce genre d'habitude.
J'imagine que les personnes qui vous ont interviewé ont tiré une conclusion similaire ("vous avez peu ou pas d'expérience dans les grandes bases de code").
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, alors vous n'avez jamais travaillé avec quelque chose d'aussi compliqué - allez acquérir plus d'expérience et revenez quand vous aurez appris à travailler exactement comme nous."
Mais il y a évidemment un autre aspect à cela. Certains projets prennent un certain temps à compiler. J'ai travaillé avec des frameworks qui prennent 30 minutes ou plus à compiler après des modifications même mineures. Heaven vous aide si vous avez besoin d'éditer 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 détecter vos erreurs, il existe encore de rares erreurs qui ne seront pas détectées lors d'une génération partielle. Vous ne recompilez simplement pas toutes les 5 minutes dans ces conditions - sauf si vous vous sentez 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 à compiler en vaille la peine. Bien sûr, vous ferez la faute de frappe occasionnelle, mais je vais supposer que vous pouvez à la fois taper et lire. Si vous avez la liberté de choisir, utilisez un style de codage qui fait bon usage de la mise en page pour mettre en évidence visuellement les erreurs et vous ne laisserez plus jamais tomber une accolade, un support ou un 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 pendant quelques heures à la fois, dans un éditeur de texte brut, 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 que j'ai eu une erreur qui aurait été plus facile à corriger en conséquence.
Si vous n'êtes pas fan de recompilation constante, vous êtes en bonne compagnie. Voici Donald Knuth:
Quant à votre vraie question, l’idée d’une compilation immédiate et de "tests unitaires" ne m’intéresse que rarement, lorsque je me sens dans un environnement totalement inconnu et que j’ai besoin de retours sur ce qui fonctionne et ce qui ne fonctionne pas. Sinon, beaucoup de temps est perdu pour des activités que je n'ai tout simplement jamais besoin d'exécuter ou même de penser.
Tout cela étant dit ... si vous travaillez dans un contexte où la compilation est une action gratuite, pourquoi pas toi? À 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 IDE qui exécute constamment le code via le front-end du compilateur pour fournir une mise en évidence des 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 que rester sur la tâche est une stratégie de codage OK.
L'avantage le plus significatif de la compilation incrémentielle est la mentalité que beaucoup obtiennent s'ils attendent la fin pour compiler et tester: à la fin, nous sommes plus préoccupés par l'exécution du code qu'autre chose. point. Nous disons "Oh, il suffit d'ajouter cette parenthèse pour que le compilateur cesse de se plaindre" ou "oh il suffit de mettre cela en majuscule" sans penser 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é la signification d'une variable et, par conséquent, changé son nom. Le changement de nom génère une erreur de syntaxe plus tard dans le code mais si je me contente de complaire en corrigeant le nom, j'ai ignoré pourquoi cette erreur est survenue à l'existence.
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 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 (devrait échouer), de code d'écriture, de recompilation, de run-test, de correction de bogues, de recompilation, de refactorisation, de compilation -encore, run-test, et ainsi de suite ...
Donc tout le monde ne fait pas TDD, du moins pas toujours (moi aussi, je l'avoue). Avec votre stratégie actuelle, vous n'aurez même jamais la chance d'essayer TDD. Mais même lorsque vous ne faites pas TDD, il est extrêmement utile à mon humble avis de tester votre code plus régulièrement - ce qui n'est pas possible lorsque 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 l'algorithme de Nice que vous avez écrit quelques minutes auparavant ne se comporte pas aussi bien que vous le pensiez). Et plus vous écrivez de code sans compilation, plus vous écrivez de code sans test, donc plus il est probable que vous rencontriez un cas où vous ne pouvez pas prédis que le temps pour résoudre le problème est "O (1)", comme vous l'avez écrit.
Je suis en fait d'accord avec vous que les erreurs de compilation ne devraient pas être un problème pour un développeur expérimenté. Je ne pense pas que le coût de leur réparation augmente suffisamment au fil du temps pour s'inquiéter. S'il était possible de reporter la correction de toutes les erreurs du compilateur juste avant un Push, je le ferais, car cela présenterait une interruption beaucoup plus petite et plus consolidée.
Malheureusement, trouver des erreurs de compilation n'est pas la seule chose que les compilateurs font. Au risque d'indiquer l'évidence, la compilation est nécessaire pour exécuter votre programme, et l'exécution de votre programme est nécessaire pour trouver tous les bogues d'exécution plus complexes, subtils et intéressants que même les développeurs expérimentés créent. Et ces types de bogues sont plus difficiles et donc plus coûteux à corriger plus vous retardez leur débogage, car ils peuvent s'appuyer ou se masquer.
Cependant, je ne marquerais pas nécessairement quelqu'un dans un exercice d'entrevue pour avoir reporté la compilation jusqu'à la fin. Les exercices d'entrevue ont tendance à être très simples et les développeurs expérimentés connaissent généralement leurs limites. Plus vous êtes sûr de ce que vous avez écrit, plus vous passerez de temps entre les compilations. C'est juste la nature humaine.
Pour ne pas vous démarquer, la confiance devrait cependant être justifiée. Si vous aviez passé 45 minutes à écrire quelque chose sans compiler, puis qu'il vous fallait encore 45 minutes pour le déboguer, j'aurais pesé lourdement contre vous.
La seule chose importante à propos de la compilation, qui manque dans les autres réponses pour autant que je puisse voir, est la suivante: si vous compilez rarement et obtenez un grand nombre d'erreurs de compilation, la plupart d'entre elles n'ont aucun sens, car elles sont générées par la première erreur. Cela peut être dû au fait que le type, la faute de frappe ou la syntaxe est incorrecte, ce qui rend une déclaration non valide.
Vous pouvez toujours simplement corriger le premier, recompiler, corriger le suivant, etc., mais avec une grande base de code, cela peut être lent. Mais si vous essayez de parcourir la longue liste d'erreurs du compilateur et d'erreurs ponctuelles qui sont indépendantes, vous passez beaucoup de temps à lire des messages non pertinents ou à parcourir le code du point d'erreur secondaire à la cause réelle.
Une autre chose pour les builds réguliers est que rien ne vous empêche de commencer à compiler dès que vous avez écrit un bloc complet de code, qui devrait compiler. Vous pouvez ensuite continuer à écrire plus de code pendant la compilation, tant que vous ne sauvegardez pas les nouvelles modifications jusqu'à la fin de la compilation. Il n'y a 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 devez alors attendre la compilation sans rien faire. Il s'agit essentiellement de la version manuelle de ce que les IDE modernes peuvent faire automatiquement en arrière-plan.
Non, il n'est pas déraisonnable de suspendre la compilation jusqu'à ce que vous ayez fait une quantité suffisante de code (et une "quantité suffisante" dépend du codeur et du code en cours d'écriture).
Par exemple, si vous êtes un codeur génial qui prend son temps pour bien faire les choses et que vous n'écrivez pas des quantités massives ou du code alambiqué, alors compiler régulièrement est un gaspillage, et probablement aussi une distraction. Si vous ne l'êtes pas, la compilation de chaque fonction peut être une bonne chose. Cela dépend de la personne.
À titre de contre-exemple, imaginez que vous écrivez du code JavaScript - il n'y a pas de compilateur. Au lieu de cela (étant donné la nature de la plupart du code JavaScript), vous exécutez le programme (ou actualisez 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 avoir du 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 bonne réponse 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 y a des facteurs beaucoup plus importants sur le codage que votre tendance à frapper F7 régulièrement (ou non) n'a absolument aucune conséquence.
Pour un programmeur suffisamment expérimenté, la compilation de code n'est jamais le goulot d'étranglement.
Une fois que vous connaissez assez bien un langage (c'est-à-dire lorsque vous n'avez plus à penser à la syntaxe et au lieu de simplement coder pour la fonctionnalité), vous n'avez pas tendance à faire de simples erreurs syntaxiques. Ceux que vous faites sont généralement des fautes de frappe ou des copier-coller, et ils peuvent être nettoyés rapidement en quelques étapes de compilation.
J'écris régulièrement du code toute la journée sans compiler, puis je compile et corrige juste les erreurs de syntaxe et les avertissements signalés par le compilateur avant de valider mon code (avec une note qui dit "doit être testé!" =). Je n'ai aucun problème à nettoyer plus de 1000 lignes de code C ou C++ en quelques minutes.
Le débogage et les tests, en revanche, prennent du temps. Des erreurs logiques surviennent pour toutes sortes de raisons et je n'ai pas encore rencontré de compilateur qui me parlera du sous-programme que j'ai totalement oublié d'écrire, ou remarquera que mon arbre binaire ne fonctionne pas parce que j'ai collé node->left quand il aurait dû être node->right.
Bien que je pense qu'il est généralement imprudent de se battre avec un intervieweur, je dirais que si vous pensiez que votre style valait la peine d'être défendu, vous auriez dû souligner que vous vous êtes laissé suffisamment de temps pour déboguer le code que vous aviez écrit . C'est la chose qu'aucun bon programmeur ne néglige jamais.
p.s. - Si je vous avais regardé réviser le code en le lisant, je vous aurais engagé sur place. C'est ce que fait un pro à chaque fois.
Avec un bon environnement de développement, je vois peu de raisons de compiler, sauf si vous prévoyez de tester du code. Les outils de vérification de la syntaxe d'arrière-plan capturent presque tout ce dont l'intervieweur semble parler, bien que j'admette qu'il existe encore quelques cas (impliquant des modifications qui se propagent dans les fichiers) qui ne sont pas toujours entièrement identifiés.
Cela étant dit, je vais essayer de compiler et d'exécuter à peu près la plus petite unité de code qui puisse réellement produire un résultat. Il y a une demi-heure, je créais un moyen d'imprimer certains résultats de recherche et j'ai fait une demi-douzaine de tests d'impression (en .pdf, pas sur papier) en apportant des modifications au résultat pour le rendre plus joli - un taux d'environ 1 compilation pour 10 lignes.
L'avantage de "compiler au fur et à mesure" est que vous obtenez un feedback constant et que vous n'aurez pas la possibilité de vous tromper avant d'être poussé dans la bonne direction. Pour un programmeur compétent comme vous, ce n'est pas une considération énorme, mais pour beaucoup d'autres c'est le cas. Autrement dit, "compiler au fur et à mesure" est une façon de "minimiser la perte maximale", même s'il y a des pertes d'efficacité potentielles dans votre cas.
De nos jours, les entreprises ne sont pas seulement intéressées par un produit fini. Ils veulent savoir que c'était "sous contrôle" depuis le début. Pour eux, "y arriver est la moitié du plaisir".
À mon avis et selon mon expérience, le fait qu'un morceau de code soit compilé ou non est essentiellement aléatoire, impliquant des choses comme le fait que des points-virgules soient manquants ou non, et a peu à voir avec l'exactitude du programme sous-jacent. (Pour moi, se concentrer sur la compilation, c'est comme faire passer un article par une vérification orthographique sans relecture pour vérifier la grammaire.)
Mon expérience est très différente: moins de 5% des erreurs de compilation que j'obtiens sont de l'ordre de syntaxe. Je connais bien la langue, quand je reçois des erreurs, c'est surtout des erreurs de type, me disant que les sémantique ne sont pas corrects.
C'est pourquoi je suis heureux de bénéficier au plus vite des retours de mon compilateur. Avez-vous déjà utilisé un IDE qui souligne les erreurs de compilation en temps réel? 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 n'essaierai même pas de le compiler jusqu'à ce que je sache ce que fait le code et que je sache 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 faible couplage et devrait vous permettre de raisonner indépendamment 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 de corriger un nombre constant d'erreurs de compilation et prend un temps assez constant, qui devrait être le même si vous le faites après avoir fini d'écrire le code, ou si vous entrelacez avec votre temps de codage.
Le changement de contexte est coûteux pour votre cerveau, donc corriger de petites erreurs dès que vous les écrivez peut être plus efficace.
EDIT: Je peux également 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 permet d'éviter d'avoir beaucoup de douleur à la fin lorsque vous devez fusionner et tout trier.
Vous dites que vous désactivez des choses comme des lignes rouges sous votre texte. Le faites-vous également lorsque vous tapez un e-mail 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 quasi-compiler à tout moment, vous pouvez bénéficier de nombreuses fonctionnalités sémantiques IDE (renommage sûr, refactoring, trouver les usages d'un symbole ...).
Si vous voulez avoir une meilleure compréhension de la façon dont ces fonctionnalités vous aident, vous pouvez essayer de les activer et de vous exercer pour en faire l'expérience vous-même. Vous pouvez également essayer de faire de la programmation en binôme avec quiconque est habitué à eux et voir comment ils en bénéficient.
Les autres réponses ici montent une bonne défense pour compiler fréquemment sur le tas, mais comme votre question est centrée sur interviews, j'aimerais aborder cet angle.
Dans mes entretiens, je fais exactement le contraire: les candidats ne peuvent pas utiliser de compilateur. Ils écrivent de courts programmes sur le tableau blanc, puis nous en discutons. J'ai trouvé que trop de développeurs utilisent le compilateur (ou l'interpréteur) comme béquille, et c'est une perte de temps beaucoup plus importante que de compiler trop rarement. Si je vous offre beaucoup d'argent et que vous ne pouvez même pas écrire correctement FizzBuzz sans compilateur, vous n'allez jamais le couper à long terme, en travaillant sur des problèmes 100 fois plus difficiles que les exercices de jouets 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 mutuelle du candidat et de l'entreprise. Une bonne question d'entrevue devrait énoncer les objectifs de la question et comment la personne interrogée sera évaluée. Poser une question piège à l'interviewé, puis 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 âgés - ne sont pas formés pour interviewer d'autres programmeurs, ils se contentent donc de clichés et posent les mêmes types de questions qui leur ont été posées lors de leur interview, sans trop se demander si ce sont des techniques efficaces pour évaluer les candidats. ou pas.
Je ne prétends pas que mon approche est la "seule vraie voie", mais elle m'a très bien servi. Comme tant 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.
J'ai réfléchi un peu plus longtemps à cela, car je sentais qu'il y avait quelque chose de très, très mal avec l'intervieweur et je ne pouvais pas exactement préciser 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 exploitable en code qui compile 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 un enquêteur 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 externes qui doivent être utilisés, à la création d'une conception globale qui conduira à un code correct et maintenable au lieu de pirater le code ensemble, et à trouver des algorithmes cela conduira au code de travail au lieu du code qui est corrigé ensemble jusqu'à ce qu'il fonctionne (code qui n'a évidemment aucune erreur vs code qui n'a pas d'erreurs évidentes).
Viennent ensuite une petite quantité de temps à écrire du code qui se compile.
Vient ensuite une plus grande quantité de temps 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 se fait en écrivant des tests unitaires, en parcourant 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. Qui représentent 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.
Concernant la deuxième interview, un avantage de la compilation est que vous pouvez observer, en quelques secondes, ce que les programmes font (ou ne font pas). 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.
La lecture d'une base de code inconnue comme celle-ci du début à la fin peut être assez improductive (vous n'êtes pas un compilateur), tandis que la compilation/l'exécution de l'application vous donnera rapidement une image plus grande.
Dans les projets plus importants, avec plusieurs sous-programmes, vous souhaitez tester ces parties, avant de les utiliser dans le 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 petits morceaux, 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.