Nombre de lignes de code dans une vie [fermé]

StackOverflow https://stackoverflow.com/questions/276657

  •  07-07-2019
  •  | 
  •  

Question

Une des entreprises a demandé à son futur employé de donner le nombre de lignes de code écrites au cours de la vie dans un langage de programmation tel que Java ou C #. Étant donné que la plupart d'entre nous avons plusieurs années d'expérience dans différents projets dans plusieurs langues et que nous n'en gardons aucune trace, quelle serait la meilleure approche pour calculer ces paramètres. Je suis sûr que les membres intelligents de stackoverlow.com auront des idées.

C’est une entreprise très respectée dans son domaine et je suis sûr qu’elles ont de très bonnes raisons de poser cette question. Mais il est également difficile de répondre au type de code à prendre en compte. Devrais-je inclure uniquement l’algorithme difficile que j’ai mis en œuvre ou tout code que j’ai écrit pour exemple? un POJO ayant 300 propriétés et dont les getters / setters ont été générés à l'aide d'IDE!

Était-ce utile?

La solution

Cela semble être l’une de ces questions telles que "Combien de balles de ping-pong pourrais-tu mettre dans un Boeing 747?" Dans ce cas, le questionneur souhaite vous voir démontrer davantage vos compétences en résolution de problèmes que le nombre de lignes de code que vous avez réellement écrites. Je ferais attention à ne pas critiquer la question et à essayer de résoudre le problème honnêtement; )

Autres conseils

La meilleure réponse à une telle question est l’une des suivantes:

  • Pourquoi voulez-vous savoir?
  • Quelle signification attribueriez-vous à un tel nombre?
  • Est-ce que je peux me lever et partir maintenant?

Je mettrais sérieusement en doute les motivations de quiconque posant une telle question, qu'il s'agisse d'employés actuels ou potentiels. C’est très probablement le même type d’entreprise qui commencerait à réviser le code en fonction du nombre de lignes de code que vous tapez.

Maintenant, s’ils prétendent que le nombre de lignes de code est une mesure de l’expérience d’un programmeur, je quitterai certainement l’entretien à ce moment-là.

Des solutions simples peuvent être trouvées pour des problèmes complexes, et sont généralement meilleures que simplement jeter suffisamment de lignes de code sur le problème et le problème sera résolu . Étant donné que le nombre de bogues générés varie linéairement et au-dessus du nombre de déclarations, je dirais que l'inverse est probablement meilleur, combiné au nombre de problèmes résolus.

En guise de test-réponse, je demanderais ceci:

  

Si, dans un programme, je suis capable de résoudre les problèmes A, B et C en 1000 lignes de code, un autre programmeur résout les mêmes problèmes en 500 lignes de code. Lequel d'entre nous est le meilleur (et la réponse serait: pas assez d'informations pour juger)

Maintenant, si vous voulez toujours estimer le nombre de lignes, je commence simplement par réfléchir aux projets que la personne a écrits et je compare leur taille à une quantité connue. Par exemple, j'ai une bibliothèque de classes qui contient actuellement environ 130 000 lignes de code, et j'ai écrit des choses similaires dans Delphi et d'autres langages, ainsi que des projets d'application assez importants. Je pense donc que j'ai 10 millions de lignes de code. au moins moi-même. Le nombre est-il significatif? Pas le moins du monde.

On dirait que c’est le questionnaire de D E Shaw?

Consultez ohloh . Le site affiche les métriques de projets open source.

Le site estime que 107 187 lignes de code correspondent à un effort de 27 années-personnes (4 000 lignes de code par an).

Un exemple de la stupidité d’une telle mesure est qu’il s’agit d’un projet auquel je participe depuis 2 ans.

Il existe fondamentalement trois façons de traiter des demandes ridicules de métriques sans signification.

  1. Refusez de répondre, interrogez l'interlocuteur pour ses raisons et expliquez pourquoi ces raisons sont stupides.

  2. Passez du temps à rassembler toutes les informations possibles et à calculer au maximum votre réponse.

  3. Élaborer une réponse plausible et avancer avec le moins possible d'implication émotionnelle dans la stupidité possible.

Les premières réponses que je vois semblent prendre la première ligne. Pensez si vous voulez toujours le travail malgré la stupidité de leurs exigences. Si la réponse est toujours Oui, évitez le numéro 1.

La deuxième méthode consiste à examiner vos anciens référentiels de code d'anciens projets.

Dans ce cas, je choisirais la troisième voie.

Multipliez le nombre d'années de travail sur une langue par 200 jours de travail par an, par 20 lignes de code par jour, et utilisez-le.

Si vous parlez plus d'une langue par an, répartissez-la entre elles.

Si vous avez davantage travaillé sur l'analyse, la conception ou la gestion, réduisez ce chiffre de trois quarts.

Si vous avez travaillé dans un environnement de haute cérémonie (défense, médecine), laissez tomber ce chiffre par ordre de grandeur.

Si vous travaillez dans un environnement où la cérémonie est particulièrement basse, augmentez-le d'un ordre de grandeur.

Ensuite, mettez la stupidité derrière vous et poursuivez votre vie le plus rapidement possible

En fonction de leur réponse, je ne pense pas que ce soit une mauvaise question. Par exemple, si un candidat ajoute du code JavaScript à son CV, je souhaite savoir combien de code JavaScript il a réellement écrit. Je peux demander, par exemple, le nombre de lignes du plus grand projet JavaScript écrit. Mais je cherche seulement un sens de l'échelle, pas un nombre réel. S'agit-il de 10, 100, 1000 ou 10 000 lignes?

Quand je le demanderai, je vous dirai très clairement que je cherche simplement un chiffre brut pour jauger la taille du projet. J'espère que l'employeur dans le cas du questionneur est après le même.

C’est une métrique intéressante à demander, étant donné que vous pourriez écrire de nombreuses lignes de mauvais code au lieu d’en écrire quelques-unes intelligentes.

Je ne peux que supposer qu'ils considèrent que plus de lignes sont meilleures que moins. Serait-il préférable de ne pas planifier du tout et de commencer à écrire du code, ce serait un excellent moyen d'écrire plus de lignes de code, car au moins si je le fais, je finis généralement par tout écrire au moins deux fois.

Les superflus de pile intelligents éviteraient généralement les organisations qui posent ce genre de question. Sauf si la réponse correcte est "hein, wtf?"

Pourquoi se préoccuper de calculer cette métrique sans raison valable? Et une entreprise aléatoire qui demande la métrique vraiment n'est pas une bonne raison.

Si la question de la société est réellement sérieuse et que vous pensez que l'entrevue pourrait déboucher sur quelque chose d'intéressant, je choisirais simplement un nombre aléatoire afin de voir où cela mènerait: -)

Ha, me rappelle quand j'ai repris un framework de test basé sur C, qui a commencé comme 20K + lignes que j'ai fini par s'effondrer dans 1K LOC en tenant compte d'un sous-programme à la place des 20 lignes de code de diarrhée écrites à l'origine par l'auteur original. Malheureusement, Je me suis fait fesser plus fort pour des erreurs dans le code car mon KLOC écrit est allé réellement Négatif ... Je réfléchirais longuement à la réduction de la base de code dans une organisation basée sur des métriques ....

Si vous deviez être vraiment honnête, vous diriez que vous ne le savez pas car vous ne l'avez jamais considéré comme une métrique valide. Si l’enquêteur est une personne raisonnable / rationnelle, c’est la réponse qu’ils recherchent.

La seule autre option pour dire que vous ne savez pas, est de deviner, et cela ne démontre pas vraiment vos compétences en résolution de problèmes.

Même si je suis d’accord avec la majorité des gens pour dire que ce n’est pas un très bon indicateur, s’il s’agit d’une entreprise sérieuse, comme vous le dites, ils auront peut-être des raisons de demander cela. C’est probablement ce que je ferais:

Prenez l’un de vos projets existants, obtenez le nombre de lignes et divisez-le par le temps qu’il vous a fallu pour le coder. Cela vous donnera une sorte de lignes par heure métrique. Ensuite, essayez d’estimer combien de fois vous avez travaillé avec cette langue spécifique et multipliez-la avec votre métrique déjà calculée. Honnêtement, je ne pense pas que ce soit un bon moyen… mais honnêtement, ce n'est pas une bonne question non plus. Je dirais également à la société la stratégie que j'ai utilisée pour proposer ce chiffre… peut-être, PEUT-ÊTRE, voici ce que ils veulent .. connaître votre opinion sur cette question et comment vous y répondriez? : p

Ou, ils veulent juste savoir si vous avez des expériences .. alors, devinez un nombre impressionnant et notez-le: D

  

"C’est une entreprise très respectée dans son domaine et je suis sûr qu’ils ont de très bonnes raisons de poser cette question"

Et je suis tout à fait sûr que ce n’est pas le cas, car "être respecté" ne veut pas dire "ils font tout bien", parce que ce n'est certainement pas correct, ou si c'est le cas, c'est du moins stupide à mon avis.

Qu'est-ce qui compte comme "Lignes de code"? J’estime avoir écrit environ 250 000 lignes de code C #, voire beaucoup plus. Le problème? 95% étaient du code jetable, et tout n'était pas destiné à l'apprentissage. Je me retrouve encore à écrire un petit programme de 3 lignes pour la dixième fois simplement parce qu'il est plus facile d'écrire ces trois lignes (et de modifier un paramètre) que de rechercher celles qui existent déjà.

De plus, les lignes de code signifient rien . J'ai donc deux gars, l'un a écrit 20% de lignes de plus que l'autre, mais ces 20% de plus étaient des lignes inutiles et compliquées, "déroulant en boucle". et sinon des choses inutiles qui auraient pu être refactorées.

Désolé, entreprise respectée ou non: demander des lignes de code est un signe certain qu’ils n’ont aucune idée de la mesure de l’efficacité de leurs programmeurs, ce qui signifie qu’ils doivent s’appuyer sur des techniques de l’âge de la pierre, telles que la mesure de la LdC. à peu près aussi précis que les calendriers à l'âge de pierre. Ce qui signifie que c’est peut-être un bon endroit où travailler si vous aimez vous détendre et gonfler vos chiffres de temps en temps.

D'accord, c'était plus une diatribe qu'une réponse, mais je ne vois vraiment aucune raison de justifier ce chiffre.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top