Comment vérifiez-vous la qualité du code d'un employeur potentiel avant de prendre position? [fermé]

D'après mon expérience, avant de commencer à travailler pour une entreprise, vous n'avez pas la possibilité de consulter la base de code (j'ai demandé et pour des raisons de confidentialité, tout le monde a toujours dit non, je pense que c'est juste), donc pendant le processus d'entrevue, pensez-vous que ce sont les questions les plus importantes à poser pour savoir dans quel état se trouve le code (après tout, si c'est un chien, alors vous allez faire partie des pauvres malheureux qui doivent le marcher tous les jours)?

MISE À JOUR:

Une liste de contrôle: demandez;

• Ce qu'ils pensent de la base de code. Et lorsque vous le faites, portez une attention particulière aux expressions faciales et au temps qu'il leur faut pour réagir. [Anon]
• Quel est le niveau CMM de l'entreprise [DPD] (et si vous entendez le niveau 5 fonctionner dans l'autre sens [Doug T])
• Quel cycle de vie ils utilisent [DPD] (Et si vous entendez "Agile", c'est là que vous commencez à poser des questions pénétrantes pour essayer de comprendre si par "Agile" ils veulent dire "Agile ou" codage cowboy "[Carson63000])
• Quels outils utilisent-ils pour évaluer la qualité du code? [DPD]
• Quels outils utilisent-ils pour le développement? [DPD] (Rechercher des outils de refactoring et des serveurs de construction continue)
• Quel système de code source (contrôle de version) ils utilisent, et un bon suivi est de demander pourquoi ils l'utilisent. [Zachary K].
• À quoi ressemblent leurs procédures de test? [Karl Bielefeldt] (Recherchez en particulier les équipes qui utilisent des frameworks de simulation et mettez l'accent sur des tests unitaires automatisés approfondis via des frameworks établis comme NUnit / JUnit; ne soyez pas rebutés par les équipes qui n'utilisent pas le développement piloté par les tests TDD, mais soyez méfiez-vous s'ils ne considèrent pas les tests comme partie intégrante et comme pierre angulaire d'un développement logiciel solide. Recherchez des équipes avec des testeurs dédiés.)
• Quels types de missions sont attribués aux nouveaux développeurs? Aux développeurs expérimentés? [Karl Bielefeldt]
• Combien de personnes travaillent sur un projet? [Karl Bielefeldt]
• La refactorisation est-elle autorisée? Encouragé? [Karl Bielefeldt]
• Quels changements de processus ou d'architecture liés à la qualité sont à l'étude ou ont été effectués récemment? [Karl Bielefeldt]
• Quelle est l'autonomie des individus sur leurs modules? [Karl Bielefeldt]
• Allez-vous développer de nouveaux projets (développement de nouveaux sites) ou d'anciens projets (développement de sites contaminés)? (Le développement Greenfield est généralement plus amusant et a moins de problèmes car vous ne nettoyez pas les erreurs de quelqu'un d'autre).
• Le taux de roulement des employés est-il élevé dans l'organisation ou l'équipe? (Cela indique souvent une qualité de code inférieure) [M.Sameer]
• Certains problèmes de programmation de votre choix; mais évitez de ressembler à un imbécile. [Sparky]
• Comment les développeurs collaborent-ils et comment les connaissances sont-elles partagées au sein de l'équipe? (Cela devrait correspondre à votre personnalité; je dirais qu'un mélange de travail en solo et en binôme est probablement le meilleur, avec un rapport correspondant à vos besoins sociaux)
• À quel point leur base de données est-elle proche de la 3e forme normale (3NF), et si elle s'écarte où et pourquoi? (S'ils disent "3NF ???", partez. Sinon, et il pourrait y avoir de bonnes raisons pour cela, alors découvrez ce qu'ils sont).

NOTE: J'ai accepté la réponse d'Anon parce qu'après environ une semaine, la communauté pense que c'est la meilleure - je pense que cela suggère que c'est juste quelque chose pour lequel vous devez en quelque sorte développer un sixième sens. Mais je pense que tout le monde a quelque chose de précieux à dire.

Plutôt que de demander à voir leur code, demandez ce qu'ils pensent de la base de code. Et lorsque vous le faites, faites très attention aux expressions faciales et au temps qu'il leur faut pour réagir.

Appliquez ensuite vos connaissances des gestes non verbaux de votre culture pour interpréter ce qu'ils disent vraiment. Pour une entreprise nord-américaine, les éléments suivants doivent être exacts:

• Un petit haussement d'épaules, et une réponse rapide "ça pourrait être mieux": c'est probablement assez bon.
• Une longue pause, une respiration haletante, peut-être un petit rire: ce n'est pas agréable, et les personnes que vous interviewez ne se sentent pas à l'aise de vous le dire.
• Yeux roulés, réponse rapide de "ça craint": peut-être bien, peut-être mal, mais il y a des jeux politiques en cours. À moins que vous ne soyez prêt à jouer à ce jeu ou à être une personne silencieuse, restez à l'écart.
• Sourcils levés ou contractés: ils ne comprennent pas la question, et la base de code est presque certainement putride.

Bien sûr, si vous avez des problèmes avec la communication interpersonnelle, cela pourrait ne pas fonctionner pour vous.

Je suis surpris que vous ayez même demandé. Aucune entreprise ne vous montrera le code avant votre inscription. Pas même aux consultants appelés pour le processus, sauf s'ils ont signé un accord de confidentialité.

Voici ce que vous pouvez demander pour le savoir.

• Quel est le niveau CMM de l'entreprise (idéalement 5)
• Quel est le processus qui est suivi dans votre projet potentiel (BTW, demander c'est bien parce que cela montre que vous êtes intéressé par "ce" travail et pas n'importe quel travail)
• Quel cycle de vie utilisent-ils (ne portez pas de jugement si vous n'entendez pas «Agile». Ils peuvent avoir une raison valable d'utiliser les anciens modèles scolaires)
• Demandez-leur s'ils utilisent des outils et des mesures pour vérifier la qualité du code. Et si oui lequel (s'ils utilisent au moins un outil pour les métriques et un autre pour la qualité c'est un bon signe.)
• Notez également quels outils ils utilisent. S'il s'agit d'un outil coûteux tel que Resharper au lieu d'un outil gratuit, ils sont très sérieux quant à la qualité.

1. Demandez-leur s'ils utilisent le contrôle de code source.
   • Pas de contrôle de source? -> code le plus probablement merdique
2. Demandez-leur à quelle fréquence les revues de code.
   • Pas de révision de code? -> le code peut être suspect (mais pas nécessairement, surtout s'il s'agit d'une petite équipe composée de développeurs décents.)
3. Demandez-leur si elles testent et déploient avant de passer en production?
   • Aucun environnement de test? Déploiement direct en production? -> code très probablement merdique.
4. Demandez-leur s'ils effectuent une intégration continue (.ie. Exécution de builds avec Hudson)
   • Pas d'intégration continue? -> le code peut être suspect, mais pas nécessairement.
5. (Lié à # 3), demandez-leur si leur environnement de test est distinct de votre environnement de développement?
   • Le test est dev? -> pas bon signe, à moins qu'ils ne soient vraiment à court d'argent, mais combien coûterait une boîte supplémentaire?
6. Demandez-leur s'ils examinent une liste d'actions avant le déploiement en production.
   • Pas de revue des actions avant le déploiement en production? -> Bad juju.
7. Demandez-leur combien d'étapes faut-il pour faire une construction.
   • Plus de 3? -> généralement mauvais juju.
8. Prennent-ils (ou estiment-ils) des métriques de code telles que la complexité cyclomatique ou LCOM (une mesure de cohésion de classe).
   • Oui? -> probablement (mais pas certainement) un bon signe concernant la qualité de leur code.
   • Non, mais ils comprennent les concepts (au moins la complexité cyclomatique)? -> difficile à dire
   • Ils pensent que la complexité cyclomatique est un plat exotique ou un aphrodisiaque de Tombouctou (en d'autres termes, ils ne savent pas ce que c'est)? -> possible mauvais juju.
   • Ils pensent que c'est de la merde hors de propos (ou un autre comportement du genre)? -> fuyez.
9. Demandez-leur comment ils suivent les bogues.
   • Ils suivent # de bogues par rapport à certaines mesures (.ie. Par projet, nombre de modules modifiés, ou nombre de demandes d'exigence / changement, quelque chose!)? -> bon signe sur leur code (et leur processus logiciel).
   • Ils font celui ci - dessus et tentent de prédire le nombre de bogues potentiels qu'ils pourraient rencontrer dans un projet futur (ou en cours) en fonction d'une métrique attendue (nombre de demandes de changement, taille du projet, etc.)? -> très bon signe.
   • Ils gardent une trace des bogues uniquement pour la résolution des bogues? -> difficile à dire
   • Pas de suivi cohérent? -> fuyez.

Ce serait du haut de ma tête. Vous remarquerez que certaines de mes questions concernent le processus de développement de logiciels, et pas seulement le codage. La qualité de ce dernier est une fonction directe de la qualité du premier.

Cela dit, lorsque vous posez ces questions, procédez avec prudence. Étudiez-les et sélectionnez-en quelques-uns lors d'une entrevue.

Quelques choses que vous devez garder à l'esprit. Une bonne équipe de développement sera heureuse d'entendre une personne interviewée poser ces questions ... à condition qu'elles soient posées avec tact. Faites-le mal et vous donnerez à l'intervieweur une impression d'arrogance et de perfectionnisme. Peu importe la qualité d'une équipe de développement, aucun groupe n'est parfait et ils ont tous des problèmes à résoudre, des compromis de qualité, etc. Ils veulent un joueur d'équipe avec un penchant pour la qualité, pas un perfectionniste perturbateur. Donc sois prudent.

En outre, il peut y avoir des cas où vous avez une équipe de bonnes personnes qui, par des circonstances externes, doivent travailler dans un code de qualité inférieure à la normale (il peut s'agir de développeurs débutants, ou ils ont simplement hérité d'une pile de conneries sur laquelle ils doivent maintenant travailler avec un nombre limité ressources consacrées à l'amélioration de la qualité.) Vous pouvez travailler avec du code merdique tout en ayant une bonne expérience de travail si les personnes qui vous entourent sont également de bonnes personnes (à la fois personnellement et professionnellement). Donnez-leur la mauvaise impression lorsque vous posez les questions, et ils pourraient simplement éviter de vous embaucher complètement (vous voler l'opportunité de travailler avec de bonnes personnes dans une situation très difficile et difficile).

• btw, je crois de tout coeur que c'est un must pour un développeur de logiciel d'avoir travaillé au moins une fois avec un type de code au-delà de l'espoir (ou presque au-delà de l'espoir). Vous survivez à cela et faites un bon travail, c'est une leçon précieuse.

Vous pourriez également rencontrer un groupe de développement de merde avec des gens de merde. De toute évidence, leur code sera de la merde et ils échoueront à toutes ces questions. Ils peuvent vous mépriser pour leur avoir posé des questions difficiles (et donc vous rendre service), ou ils vous embaucheront parce qu'ils ont besoin de vous (même s'ils sont / seront incapables de travailler avec vous.)

Lorsque cela se produit, vous devez vous demander si vous avez si mal besoin de ce travail. Parfois, vous le faites, et vous devez plonger dans un tas de merde de spaghetti. Parfois, vous ne le faites pas (ce qui signifie que vous pouvez vous permettre de ne pas le faire.)

Ce sont les choses que vous devez prendre en considération lorsque / si vous avez choisi de demander à un intervieweur la qualité de son code et de ses processus logiciels.

Au lieu de la qualité réelle du code, je préfère chercher une entreprise où l'importance de la qualité du code est bien comprise.

Par exemple, disons que la société A a des gestionnaires qui croient que "la planification est une perte de temps" et "nous pouvons résoudre les problèmes de conception plus tard (par exemple, quand l'enfer gèle. Nous aurons alors le temps)". Même si cette entreprise avait maintenant une bonne base de code, elle ne l'aura pas longtemps. Et c'est vous qui serez (forcé) d'aggraver les choses.

D'un autre côté, disons que la société B a une mauvaise base de code, mais la direction comprend que la qualité du code est à l'origine de tous ces bogues et retards, ils voient le besoin de changement et ils sont prêts à faire quelque chose (par exemple à grande échelle refactoring ou même réécriture). Cette entreprise améliorera sa base de code, et vous pouvez les aider à y arriver.

Je sais où je voudrais travailler.

Il y a 99,9% de chances que vous ne puissiez pas voir le code avant de commencer. (À moins qu'ils ne mettent bien sûr des logiciels libres à disposition)

Alors, que pouvez-vous faire, je voudrais poser des questions sur le processus, en général, un bon processus produira un bon code. Je commencerais par le test Joel et poserais des questions sur la méthode de développement. Dépassez également les bases. Par exemple, je demande toujours quel système de code source ils utilisent, donc un bon suivi est de demander pourquoi ils l'utilisent.

L'endroit où j'ai travaillé avec du code de très haute qualité n'a pas permis aux deux tiers des développeurs de toucher au code. Les autres ont plutôt écrit des scripts de test de boîte noire automatisés. Si vous vous êtes montré digne de changer le code actuel, les exigences étaient si extrêmement sur-spécifiées que ce n'était rien de plus qu'une transcription en code source. Les scripts de test étaient en fait plus amusants à écrire.

Les endroits où j'ai vu le code de qualité la plus basse étaient exactement l'inverse: seuls des programmeurs relativement peu formés ou non-menteurs ont touché le code, généralement parce que c'était un outil qui n'était pas directement lié au produit de l'entreprise, ou jugé expérimental.

Les lieux de travail les plus agréables ont un équilibre. Les nouveaux développeurs reçoivent de véritables missions, mais sont encadrés. Il existe un bon service AQ et un processus d'examen par les pairs pour détecter vos erreurs. Vous n'êtes pas puni pour avoir commis des erreurs, mais vous êtes censé les corriger et en tirer des leçons. Parfois, un module mal écrit passe à travers les mailles du filet, mais vous n'êtes pas critiqué pour passer du temps à améliorer la qualité du code lorsque vous les rencontrez. L'entreprise dans son ensemble s'efforce continuellement de trouver de nouvelles façons d'améliorer le code.

Par conséquent, les questions que je voudrais poser pour évaluer la qualité du code sont les suivantes:

• À quoi ressemblent vos procédures de test?
• Quels types de missions sont attribués aux nouveaux développeurs? Aux développeurs expérimentés?
• Combien de personnes travaillent sur un projet?
• La refactorisation est-elle autorisée? Encouragé?
• Quels changements de processus ou d'architecture liés à la qualité sont à l'étude ou ont été effectués récemment?
• Quelle est l'autonomie des individus sur leurs modules?

Comme l'ont dit @DPD et @Zachary, le processus et SDLC sont des facteurs très importants mais je veux ajouter quelques autres facteurs qui, selon mon expérience, ont un impact significatif sur la qualité du code:

• Demandez si vous allez travailler au développement dans un projet relativement récent ou au maintien d'une application héritée. Les applications héritées ont tendance à être moins propres que les nouveaux projets.
• Essayez de savoir si le taux de roulement de l'employé est élevé dans l'organisation ou dans l'équipe. Cela réduira également la qualité du code.

Notez qu'un processus aide beaucoup mais il ne donnera pas une immunité totale contre les facteurs ci-dessus. Lorsque de nombreux développeurs transmettent un projet, chacun vient avec un état d'esprit différent. L'architecte et le développeur ne suivront pas exactement la façon dont leurs prédécesseurs l'ont fait, ce qui entraînera des incohérences.

Mon attitude est la suivante, le code est le code, s'il est mauvais, eh bien c'est un défi de l'améliorer. Si c'est bon, c'est un défi encore plus difficile à améliorer!

Le plus important pour moi est de savoir si je veux travailler pour l'entreprise et les personnes avec qui j'ai la possibilité d'interagir. Le code peut être changé, les gens ne peuvent pas ...

Je plaisante un peu, dis-je, interview avec moi .

J'utilise normalement un bug réel (déjà corrigé) dans notre base de code comme test d'interview, donc vous voyez du code réel. Code généralement légèrement compliqué et contenant un bogue.

J'encourage tout le monde à utiliser cette technique, car vous savez déjà que le bogue est réel, le problème est réel et vous savez combien de temps il a fallu pour le trouver et le corriger.

La grande chose est que vous pouvez avoir un problème mesurablement difficile.

J'ai utilisé un problème très difficile comme dernière question d'entrevue pour séparer les experts des assez bons.

La pertinence de la question du PO est que tous ceux qui se rendent à un entretien physique voient un code. (Rien avec du contenu confidentiel de l'entreprise)

Si vous ne pouviez pas utiliser cette technique, à cause des jurons dans la base de code, alors le test fonctionne, car les employés potentiels demanderont "puis-je voir le code" et la réponse serait "oh, vous ne pouvez pas c'est plein de grossièretés ".

Bien sûr, la réponse standard "c'est tout un secret d'entreprise" est le cheval-puckey total.
Ma preuve: chez mon ancien employeur, une partie non confidentielle d'un produit militaire était l'échantillon de code pour la question d'entrevue. [Heureusement non classé]

Je laisse le problème de déterminer la qualité des designs classifiés avant de travailler là-bas à quelqu'un de plus intelligent que moi. Je pense qu'il peut être courant que la classification soit synonyme de sans surveillance.

Il est douteux qu'ils vous laisseront voir leur code, mais vous pourrez peut-être vous faire une idée de ce que cela pourrait être si vous leur confiez une tâche de programmation. De nombreux endroits offrent aux personnes interrogées une mission de programmation à emporter qu'ils peuvent utiliser pour vous évaluer. Renvoyez la faveur - attendez-vous à l'un d'eux afin que vous puissiez mieux évaluer dans quoi vous pourriez vous embarquer.

Demandez ce qui est requis pour que le code entre dans la version de production. Si vous obtenez "euh ... le développeur le commet ..." alors c'est presque certainement une ordure.

Il y a un certain nombre de choses qui ont tendance à augmenter la qualité du code (évidemment, il n'y a aucune garantie).

• Analyse statique (dans .NET, ce sont des choses comme fxcop / stylecop)
• Un sous-ensemble (ou un ensemble complet) de la suite de tests - unité / intégration / régression / manuel, etc.
• Compilation (un autre développeur de l'équipe construit les modifications pour voir s'il y a des problèmes dépendants de la machine / de l'utilisateur - exécutant parfois aussi une raison rapide)
• Révision du code

Celles-ci peuvent aider à améliorer non seulement la force du code, mais la qualité du code.

Demandez-leur des tests unitaires. S'ils le prennent au sérieux, l'intervieweur aura probablement des opinions précises sur le sujet et sera heureux de les partager. Si les réponses sont vagues, c'est un gros signe d'avertissement.

S'il s'agit d'une boutique Java, demandez-leur quelle bibliothèque ORM ils utilisent. S'ils ont roulé le leur, alors ça pourrait aller dans les deux sens - ça pourrait être nul, ou ça pourrait aller. S'ils n'en utilisent pas, courez immédiatement vers la porte.

C'est une tâche difficile car il y a tellement de mauvaises pratiques de codage différentes que vous ne pourrez jamais les prédire toutes.

Vous ne pouvez malheureusement pas. Aucune entreprise ne vous laissera voir son code (mais elle vous demandera de voir VOTRE code ...), et il y a de fortes chances que si vous leur posez des questions sur l'environnement, vous serez soit complètement menti ("Contrôle de version? Bien sûr .. nous utilisons .. euh .. en pensant à Sub .. Sous-quelque chose ") ou induit en erreur sur la qualité (" Nous utilisons le dernier et le meilleur .NET 4 "uniquement pour découvrir que pendant qu'ils utilisent .NET 4, ils ' le réécrire comme .NET 1.1).

J'en ai été brûlé plusieurs fois dans le passé, et je n'ai pas encore trouvé un bon moyen d'évaluer la qualité. Habituellement, la meilleure façon est d'utiliser votre propre jugement et si cela se résume à cela, partez immédiatement si c'est pire que vous ne le pensiez; vous pourriez finir par une trémie d'emploi, mais vous garderez votre raison.