Est-il possible qu'un bon programmeur n'ait jamais utilisé le contrôle de version? [fermé]

73

Je cherche un programmeur expert pour aider à résoudre une situation difficile.

Les entrevues jusqu’à présent ont été étonnamment décevantes. Le meilleur candidat à ce jour est un programmeur très expérimenté qui n’a jamais utilisé de logiciel de contrôle de version.

Le problème en lui-même n’est peut-être pas trop grave car c’est quelque chose qui peut être appris en peu de temps.

Mais il y a un aspect plus profond qui m'inquiète:

Comment est-il possible de développer activement des logiciels pendant 10 à 15 ans sans jamais avoir besoin de contrôle de version?

Le fait de ne pas rechercher une solution au problème du suivi des modifications est-il un signe d'une mauvaise attitude à l'égard de la programmation?

lortabac
la source
25
Qui a dit qu'il n'avait pas besoin de contrôle de version? Il en avait besoin, et je suppose qu'il l'a fait manuellement. Cela dit, un programmeur qui fait cela semble être très réticent à apprendre quelque chose de nouveau - préparez-vous à cela.
Doc Brown
6
@ e-MEE dépend, vous pouvez apprendre à mettre à jour / résoudre / commettre en 30 à 60 minutes mais personne ne saura comment un vcs fonctionne en une heure. La plupart des personnes qui l'utilisent depuis des années ne l'obtiennent toujours pas.
atamanroman
3
@ConradFrix Gâteau aux carottes :)
Chad Harrison
7
Il est possible qu'un bon programmeur n'ait jamais utilisé le contrôle de version, si le calendrier indique qu'il s'agit bien de 1981.
Kaz
7
Cela ressemble à un cas classique de quelqu'un qui n'a pas 10 ans d'expérience, mais plutôt 1 année d'expérience répétée 10 fois.
Jeanne Pindar

Réponses:

90

J'ai travaillé pendant environ 11 ans dans des entreprises qui n'utilisaient pas le contrôle de source. Nous avons réussi (principalement en commentant les modifications et en conservant le code sur un serveur central qui pourrait être récupéré à n'importe quelle date). Nous n'avons jamais vraiment demandé s'il y avait une meilleure façon. Cela dit, c’était aussi à l’époque où j’avais toute la bibliothèque MSDN sous forme de livre sur mon bureau.

Oui, il y avait une programmation avant Internet.

J'ai du mal à comprendre comment vous pouvez passer plus de 10 ans dans le secteur sans vous être heurté au contrôle de source. Mais j'aurais de la sympathie, je penserais que c'était possible et je ne rejetterais pas le candidat sur ce seul détail. Je voudrais sonder et découvrir comment le candidat a géré cela.

Alternativement, je pourrais me demander si le processus de mon entretien était le problème. De quelle manière était-il le meilleur candidat? Y a-t-il d'autres techniques de programmation modernes qu'il n'a pas pour lesquelles je ne pose pas les bonnes questions? Si je posais les bonnes questions, un autre candidat brillerait-il?

Comme note finale cependant, n’ayez pas peur de rejeter tous les candidats si vous avez des préoccupations. Il faut beaucoup de temps pour recommencer, mais embaucher la mauvaise personne prend plus de temps.

pdr
la source
17
+1, c'est une réponse intéressante. Cependant, je ne suis pas tout à fait d'accord avec "à cette époque, le contrôle à la source coûtait très cher" . RCS existe depuis 30 ans, CVS - 21 ans; Les deux sont open source.
vartec
8
+1: Je travaille toujours ici . Nous obtenons enfin un contrôle des sources géré cette année (en grande partie grâce à moi). Je ne pense pas que nous soyons tous des développeurs terribles parce que nous ne l'avions pas jusqu'à présent, mais je suis vraiment trop content que ça arrive
oliver-clare
3
Si le candidat comprend les principes du contrôle de source, je ne vois aucun problème. Un développeur expérimenté devrait être capable de comprendre la "syntaxe" du système que vous utilisez assez rapidement. Une question que je voudrais poser - est-ce que toute cette expérience est sur un site? Si c'est le cas, il n'avait peut-être pas le pouvoir de mettre en place un système. Si son expérience a été avec différentes entreprises, je creuserais un peu plus loin. Le nombre d'entreprises, avec des équipes de développement, qui n'utilisent pas le contrôle de source doit être minime aujourd'hui.
BIDeveloper
4
+1 pour le point de poser les bonnes questions. Je me demandais ce qui faisait de lui le meilleur candidat aussi.
shambulator
3
@Ramhound: et vous pensez que lorsque vous effectuez un contrôle de source manuellement, vous avez besoin de moins de matériel et de moins de temps pour les sauvegardes? D'après mon expérience, l'inverse est tout à fait vrai.
Doc Brown
49

Je pense que cela dépend de son attitude. S'il est un programmeur très expérimenté et un bon programmeur, je pense qu'il serait capable de se procurer rapidement un système de contrôle de version. Il peut en parler de deux manières:

  • Bien

    Je n'ai jamais utilisé le contrôle de version, mais je suis très heureux d'apprendre et il semble que cela contribuerait réellement à rendre le développement plus efficace. Je n'en ai pas eu autant besoin parce que j'ai travaillé seul sur des projets.

  • Mauvais

    Le contrôle de version est juste un mot à la mode qui meurt lentement dans l'industrie. Je suis au-dessus du contrôle de version.

Pilules d'explosion
la source
17
Je conviendrais que cela aurait pu être valable il y a 10 ans, mais aujourd'hui? Je le dirais pas "bon / mauvais" mais "mauvais / horrible"
vartec
24
Même si vous travaillez seul, l'utilisation d'un VCS est extrêmement utile. Après avoir passé un projet de "ça marche presque" à ne plus le faire fonctionner correctement et n'avoir aucun moyen de revenir à la version "presque fonctionnant", je me suis promis de tout mettre dans un VCS, aussi petit que soit le projet. .
alroc
11
"Je suis très heureux d'apprendre", - Ce n'est pas un produit commercial coûteux comme Coherence. Le contrôle de source est une chose que tout le monde peut connaître. Si vous lisez des blogs sur le développement de logiciels, vous devriez en être conscient.
Andy Boot
7
+1 pour cette réponse. Ce n'est pas la marque d'un bon programmeur qu'il / elle a toutes les compétences. C'est qu'il / elle peut acquérir n'importe quelle compétence requise.
Steven
2
@ Steven: Non, pas du tout. Selon cette logique, un enfant de 8 ans pourrait être embauché parce qu'il pourrait suivre des cours. OMI, des compétences de base sont nécessaires pour être considéré comme un programmeur. La maîtrise d'un langage de programmation en est un, la connaissance et l'utilisation de n'importe quel VCS en est un autre. Il y en a plus.
Steven Evers
34

Permettez-moi de vous donner une perspective de la réalisation de logiciels sous DOS et Windows depuis plus de 20 ans.

Les logiciels de contrôle de version dans le monde Windows / PC étaient souvent peu fiables au début des années 90. Visual Sourcesafe (VSS) était à peu près le meilleur système basé sur Windows, mais il pouvait être bizarre et beaucoup de programmeurs le détestaient. Certaines équipes n'auraient tout simplement pas envisagé leur utilisation après avoir fait face à cette situation.

La plupart des autres options VCS à l'époque n'étaient pas basées sur Windows et étaient donc rarement utilisées par les équipes de développement Windows. Certaines de ces solutions étaient coûteuses et les solutions open source n'étaient pas acceptées aussi facilement qu'aujourd'hui.

Dans de nombreux cas, à la fin des années 90 et au début des années 2000, si une équipe Windows n'utilisait pas VSS, elle n'utilisait rien pour le contrôle de source en dehors des conventions internes. Un certain nombre d'entre eux n'utilisent toujours pas de VCS malgré la sophistication de Team Foundation Server (TFS) et d'excellentes options gratuites telles que git et SVN.

Il est possible qu'une personne ayant travaillé pendant des années dans une petite équipe de développement Windows sans avoir utilisé de VCS. J'ai interviewé et même travaillé à contrat dans des endroits qui ne les utilisaient pas ou qui étaient très aléatoires à propos de leur utilisation.

Donc, je ne pense pas que le manque d'expérience de votre candidat dans ce domaine soit un «non» définitif, mais vous voudrez probablement approfondir davantage sa situation professionnelle antérieure pour savoir pourquoi cela manque à son expérience. Vous voudrez également explorer leur attitude à l'égard du contrôle de version. Pense-t-il que c'est une bonne idée mais ils n'ont pas été autorisés à le poursuivre à leur poste précédent ou pensent-ils que c'est une perte de temps?

jfrankcarr
la source
18
VSS n'était pas "bizarre" - c'était tout simplement mauvais. Les référentiels corrompus et les pertes de données étaient courants, mais vous pourriez ne pas le découvrir avant des semaines ou des mois après le problème, sauf si vous exécutiez un contrôle d'intégrité quotidien (et que la chance s'en remette même à ce moment-là). Le verrouillage et le partage de fichiers étaient atroces. Les programmeurs détestaient cela parce que cela leur rendait la vie plus difficile - tout le contraire de ce qu'un VCS devrait faire.
alroc
@ alroc - Croyez-le ou non, il en existait d'autres moins fiables et plus insolites. J'ai eu la malchance d'en utiliser une vers 1995. Je n'ai jamais eu de problème sérieux avec la fiabilité VSS, mais j'ai entendu des récits de malheur de la part d'autres personnes. Je connais certaines organisations qui ont cessé d'utiliser un VCS après de mauvaises expériences avec VSS.
Jfrankcarr
UGGH, nous avons essayé le contrôle de code source de Powerbuilder dans la journée. Cela nous a activement fait perdre du code source. PB se bloquerait, et tout pbl extrait deviendrait inaccessible à tous les autres. Quelle plaisanterie c'était.
GrandmasterB
J'ai travaillé pendant un an et demi dans un magasin utilisant Visual Source Safe. L'un des meilleurs programmeurs gâcherait le référentiel à chaque fois qu'il tenterait de vérifier son code par téléphone (oui, c'était il y a quelque temps). Un de mes systèmes VCS les moins préférés.
GlenPeterson
Nous avons utilisé tlib ( burtonsys.com/index.html ) pour un travail dans un environnement DOS. Certes, c'était en 2005, mais il semblait qu'ils l'utilisaient depuis un moment.
Doug T.
29

Ne pouvez-vous pas avoir le contrôle de version sans logiciel de contrôle de version? Demandez comment ils ont géré leur code. Peut-être y avait-il déjà un système développé chez nous.

Vouloir faire les choses manuellement, réinventer la roue et résister au changement ne sont pas nouveaux en programmation. Allez-vous baver devant un candidat qui utilise Visual Source Safe et "uniquement" VSS?

Lorsque vous essayez de trouver du talent, vous devez être capable de faire la différence: ne pouvez pas, n'avez pas et ne voulez pas.

JeffO
la source
Avant de découvrir le contrôle de version et son utilité (après 2 ans de programmation amateur non professionnelle), il n’était pas rare que je dispose de cinq dossiers avec des «sauvegardes» de jalons de projet - un VCS primitif.
Orlp
"Ne peut pas, n'a pas, ne veut pas et n'a pas été autorisé à"? J'ai entendu parler d'endroits qui n'accepteraient pas le contrôle de code source parce qu'ils aimaient la jungle qui constituait leur lecteur réseau.
Philip
19

Il n'y a aucune excuse pour ne pas utiliser le contrôle de version, même pour un petit projet développé par un seul développeur. La mise en place d'un contrôle de version local va au-delà de la simple trivialité et présente d'énormes avantages. Tout développeur ne sachant pas qui ne peut être considéré comme bon ni expérimenté.

Quant aux entreprises qui perçoivent le contrôle de version comme une "nouveauté", qu’elles ne sont pas disposées à introduire:

  • SCCS a été publié en 1972 ( il y a 40 ans )
  • RCS est sorti en 1982 ( il y a 30 ans ) et est complètement open source et gratuit.
  • CVS est sorti en 1990 ( il y a 21 ans ), également complètement open source et gratuit
vartec
la source
20
Pas sûr que SVN soit le meilleur exemple pour une configuration "au-delà de triviale". Certains de ces fichiers que vous devez éditer, directement dans le référentiel, peuvent être fastidieux. La mise en place d’un DVCS local n’est pas une mince affaire. Et la configuration d'un compte BitBucket / GitHub et le clonage des pensions à partir de ce compte n'est pas bien plus compliqué
pdr
9
@vartec: Ce qui est au-delà de trivial, c'est git init. La page liée pourrait me faire fuir car cela me semble assez compliqué.
Maaartinus
7
@vartec: Je dirais que git et hg sont plus faciles à comprendre par un débutant en VCS que ceux qui utilisent un VCS centralisé depuis des années et plus faciles que CVCS pour les débutants. Il suffit de regarder la section Disposition du référentiel sur cette page comme si vous ne la compreniez pas déjà. Ensuite, pensez "J'ai un référentiel ici, je veux le cloner ici."
pdr
8
@vartec: Hmm. Je ne peux pas être d'accord J'aime pouvoir créer des branches et cloner même lorsque je travaille seul. Parfois j'ai des idées. Et parfois, ils sont mauvais :).
pdr
4
J'ai travaillé dans des entreprises où la direction refusait le contrôle de la version. Ce n'était pas une option. Et nous avons fait des projets intéressants et complexes. Je ne pense pas que je suis un pire développeur à cause de cela. À la maison, je ne l'utilise pas non plus, jusqu'à présent, bien que j'avoue que je l'ai envisagé.
Picarus
14

Un programmeur qui n'a jamais utilisé le contrôle de version n'a probablement jamais coopéré avec d'autres programmeurs. Je n’envisagerais probablement jamais d’engager un tel programmeur, quelles que soient les autres informations d’identité.

JesperE
la source
34
Je ne suis pas d'accord. Ne pas utiliser le contrôle de source nécessiterait un niveau de coopération beaucoup plus élevé que d’habitude avec d'autres programmeurs. Je pourrais même aller jusqu'à dire que si vous venez d'un environnement où il n'y a pas de contrôle de source, alors vous connaissez vraiment l'importance de la coopération
oliver-clare
12
C'est une déclaration glorieusement radicale et manifestement fausse.
Murph
3
Je ne voudrais tout simplement pas embaucher un programmeur qui ne sait pas utiliser les outils modernes. Il / elle sait peut-être écrire un code incroyablement agréable, mais j’aimerais considérer au moins les connaissances de base du contrôle de version comme une exigence absolue.
JesperE
6
Beaucoup de gens ici semblent confus de ne pas avoir été exposés à VCS et refusent activement de l'utiliser dans leur nouvel emploi. Que se passe-t-il si cela ne leur est tout simplement jamais arrivé sur leur lieu de travail précédent ou si la direction l’a verboté? Cela dit, ce serait un problème critique si je faisais l'embauche, et leur volonté d'apprendre serait une exigence difficile pour moi.
György Andrasek
5
Effrayant de voir autant de gens ici trouve en réalité que le manque de contrôle de la source est quelque chose de normal ou d’acceptable.
JesperE
12

On dirait bien un drapeau rouge, mais creusez plus profondément pour savoir pourquoi il ne l'a pas utilisé. Je m'attendrais toujours à ce qu'un développeur solo utilise le contrôle de version, surtout dans dix ans, mais je le pardonnerais plus que s'il travaillait en équipe et qu'il n'essayait même pas d'introduire un contrôle de version.

Eoin Carroll
la source
6
+1: Je serais horrifié si j'étais inemployable simplement parce que mon directeur actuel ne voyait pas l'importance du contrôle à la source. Au moins, j'utilise le contrôle de code source pour tous mes projets personnels, je ne serais donc pas complètement foutu par cette situation ...
oliver-clare
2
@ LordScree - Il peut être difficile de travailler seul sur un site Web à volume élevé, mais vous pouvez toujours apprendre à utiliser le contrôle de source en dehors de votre travail.
JeffO
9

Je ne serais pas religieux sur le manque d'expérience de contrôle de version. Ce n'est qu'un outil. À la fin, vous pouvez reprendre les bases de svn ou de git en un jour ou deux. Le reste, vous allez chercher avec le temps. Et je ne peux pas croire qu'un candidat malhonnête ne pourrait pas s'intégrer s'il travaillait dans un environnement utilisant le contrôle de source.

L'utilisation du contrôle de source est plus une habitude qu'une compétence. Quelqu'un qui ne l'a jamais utilisé peut exagérer les efforts requis et sous-estimer les avantages acquis. Après tout, il s'en est bien sorti jusqu'à maintenant. Ce n’est qu’après avoir utilisé le contrôle de la source qu’il va l’apprécier.

La question que vous devriez poser est la suivante: comment s’est-il comporté en l’absence de contrôle à la source? Cela pourrait vous dire quelque chose sur lui et sur la manière dont il gère son travail.

scrwtp
la source
4
Il faut
absolument
4

Vous laissez beaucoup d'informations sur son expérience.

En gros, je dirais qu’il est très possible qu’un programmeur ait 10 à 15 ans d’expérience sans avoir à connaître le contrôle de version. Coder pendant 10 ans ne signifie pas apprendre constamment de nouvelles techniques de programmation pendant 10 ans.

Je suis très jeune et j'ai vu des ingénieurs en logiciel vieux et "expérimentés" dont je ne voudrais jamais toucher au code. Cela dit, il a peut-être beaucoup de talent, mais je suppose que, compte tenu du peu d’information, il ne l’est pas.

Bonne chance.

cubsink
la source
4

Personnellement, ce qui me préoccupe le plus, c’est que le candidat n’a jamais rencontré les systèmes de contrôle de versions en tant que concept ou qu’il a décidé qu’il ne valait pas la peine d’être utilisé. Je trouve le premier scénario hautement improbable, mais si tel est le cas, cela me laisse supposer que le candidat a été considérablement isolé pendant toute la durée de sa carrière, ce qui jetterait un doute sérieux sur sa valeur en tant que membre d’une équipe. En particulier, ils peuvent avoir des concepts très bizarres sur la façon de faire certaines choses et ne pas connaître la "bonne" façon de faire les choses.

Si c'est le deuxième cas, où ils se sont activement prononcés contre le contrôle de version, cela me laisse supposer qu'ils n'ont jamais travaillé sur quoi que ce soit d'importance ou qu'ils soient extrêmement arrogants. Ou, au mieux, ils ont des moyens vraiment terribles de maintenir du code, comme commenter des blocs et attribuer chaque ligne de code à un auteur, à une date et à un numéro de bogue.

brianmearns
la source
4

Je vois ici des réponses plutôt subjectives qui ne tiennent pas compte de la personne jugée.

Personnellement, je trouve que le logiciel de contrôle de version est un outil précieux. Cependant, nous n'avons pas tous le choix ni le contrôle sur les outils et les processus utilisés dans nos environnements de travail. Je travaille dans le développement Windows depuis 1990. Comme le signalent d’autres personnes, VCS n’était guère disponible à cette époque dans Windows. Nous n'allions pas faire appel à des serveurs UNIX uniquement pour obtenir un VCS. Est-ce que ça fait de moi un mauvais programmeur? Plus tard dans ma carrière, j'ai travaillé pour une société proposant un produit commercial du marché vertical dans lequel le contrôle de version était un processus et non un outil. Est-ce que ça fait de moi un mauvais programmeur? Mes trois derniers emplois ont tous été fortement tributaires des outils VCS. Est-ce que cela fait de moi un bon programmeur?

Ce serait bien si nous utilisions tous les outils, les langages et les technologies les plus récents et les plus performants. Mais la profession de développement de logiciels ne fonctionne pas toujours de cette façon. C'est un peu idéaliste de dire "je quitterais le travail immédiatement, s'ils ne le faisaient pas ..." ou "je ne prendrais jamais un travail qui n'utilisait pas ..." ou "je les obligerais à utiliser. .. ". Nous ne sommes pas tous entourés d’un nombre infini de possibilités d’emploi où tout fonctionne exactement comme nous le souhaitons. Nous avons des factures à payer et avons besoin d'un travail, alors nous nous occupons de ce qui nous entoure.

En fin de compte, la réponse à votre question est la suivante: Jugez ce programmeur par ses compétences, ses philosophies et ses décisions, et non par les décisions (éventuellement erronées) prises par les responsables de ses précédents emplois.

cdkMoose
la source
4
Si vous avez seulement travaillé avec des idiots pendant 15 ans et n’avez pas fait d’open source intelligente, cela se répercutera probablement sur vos compétences et votre attitude. Les gens sont façonnés par leur environnement. Si ce n'était pas le cas, pourquoi devrions-nous même examiner l'historique d'emploi de quelqu'un?
Kaz
@Kaz Nous regardons leurs antécédents professionnels non pas pour les commentaires de leurs collègues, mais pour les leurs. Je ne peux pas juger quelqu'un dans la région dans laquelle il a grandi, sinon nous pourrions aussi interroger des voisins.
James Khoury
Formés par nos environnements, oui, mais nous ne sommes pas définis par nos environnements. Je suggère simplement que OP prenne une vue complète du programmeur et ne porte pas un jugement sévère basé sur un critère.
cdkMoose
4

Je ne me suis jamais considéré comme un "programmeur" avant de commencer à gagner de l'argent en le faisant de manière professionnelle.

J'ai gagné pas mal d'argent en créant des systèmes qui rapportent encore plus aux clients. Que je sois ou non un "bon" développeur est subjectif.

Je peux rapidement utiliser GSD (Get Something Done), ce qui pour le développement Web a généralement plu à mes clients. Ils peuvent ne pas voir un code laid dans les coulisses, un manque de commentaires, etc.

Je n'avais pas utilisé Git et je n'avais pas encore de profil Github avant cette année, ce qui, à mon avis, est "en retard" en termes de standards de programmation modernes. Je viens aussi de commencer à faire des projets Rails et Django après seulement avoir utilisé PHP, Flash et iOS dans le passé. Depuis que j'ai décroché des contrats pour développer des sites pour les clients et pour moi, il n'a pas été trop pénible d'apprendre quelque chose de nouveau à 30 ans et quelques années grâce à la programmation.

De nos jours, la société moderne se concentre trop sur le fait de suivre le discours des Jones et de se préoccuper de ce que les autres pensent. Si vous parvenez à rompre ces chaînes et à réfléchir à ce dont vous avez besoin pour votre développement logiciel (rapidité / délai de mise sur le marché, gestion optimisée des ressources, code bien documenté, évolutivité, etc.), alors cela peut être beaucoup plus important que de savoir si quelqu'un connaît Mercurial, SVN , Git ou tout autre système de contrôle de version.

Je préfère demander aux candidats développeurs de quoi ils sont passionnés, quel est le système le plus cool qu'ils aient conçu à leur propre opinion et dans lequel ils passent leur temps libre à développer leurs compétences. Si les gens ne font pas progresser leurs compétences à leur rythme, cela me fait plus peur que d’autres choses, mais ne veut pas dire que cela doit vous faire peur.

Je pense que les personnes ici présentes ont déjà trouvé d'excellentes réponses à cette question, ce qui devrait vous aider à prendre votre propre décision en toute connaissance de cause, en fonction de vos besoins.

ljs.dev
la source
2

Je trouve incroyable qu'un professionnel du logiciel n'ait jamais utilisé le contrôle de source, et je serais très inquiet de l'embaucher.

Quelle expérience a-t-il. Je me demande ce qu'il ne sait pas d'autre que vous n'avez pas encore découvert.

Quelle est votre expérience de développement logiciel vous-même? Êtes-vous en mesure de lui poser des questions sur l'architecture, les modèles de conception, les problèmes courants de développement de logiciels, les questions relatives à la performance du système, la sécurité du système, etc.?

S'il se montrait fort sur ce genre de choses, je pourrais peut-être oublier le manque de connaissances sur le contrôle des sources.

ozz
la source
2

Est-il possible qu'un bon programmeur n'ait jamais utilisé le contrôle de version?

Oui. Beaucoup de petites entreprises avec des programmeurs autodidactes ne l'utilisent pas.

Comment est-il possible de développer activement des logiciels pendant 10 à 15 ans sans jamais avoir besoin de contrôle de version?

J'ai personnellement introduit le contrôle de version dans deux petites entreprises, j'ai mis à niveau une entreprise de taille moyenne en passant à SVN (la meilleure option à l'époque) et travaillé dans une autre petite entreprise qui ne disposait que de VC, qui a écrit sa propre solution de VC pour du code et eu beaucoup de code tout simplement pas dans aucun VC.

Le fait de ne pas rechercher une solution au problème du suivi des modifications est-il un signe d'une mauvaise attitude à l'égard de la programmation?

Eh bien, ce n'est pas un échec instantané, mais je poserais certainement beaucoup de questions de suivi. Des choses comme:

Avez-vous déjà essayé un logiciel VC? Quelle? Qu'en as-tu pensé? Y a-t-il une raison pour laquelle vous ne l'utiliseriez pas? Qu'avez-vous utilisé auparavant pour gérer le code? Avez-vous déjà travaillé avec quelqu'un sur la même base de code et quelles méthodes avez-vous utilisées pour éviter les conflits?

James
la source
1
Rien de nouveau dans cette réponse.
pdr
1
Les programmeurs autodidactes et intelligents connaissent tous aujourd'hui le contrôle de version et l'utilisent. Les autres ont la tête coincée quelque part.
Kaz
@Kaz Pas d'accord. Je pense que c'est ce que nous aimons penser, mais j'ai rencontré des programmeurs que je qualifierais d'intelligent, comme le dit mon expérience personnelle. Ne pas utiliser le contrôle de version est un gros signe d'avertissement qu'ils pourraient avoir la tête coincée quelque part [phrase charmante :-)] mais ce n'est pas toujours le cas.
James
2

Je voudrais être d'accord avec les pilules d'explosion (mais mon représentant est trop bas, atm ...) ... l'attitude est beaucoup plus importante.

Il y a quelques éléments à rechercher qui, selon moi, contribuent à l'excellence de la programmation:

  1. la communication
  2. La créativité
  3. Compassion (dites quoi?)

Et, souvent, plus qu'un peu de TOC.

Vous connaissez le type ... ceux qui sont assis là à marteler un problème, se perdant complètement dans leur code alors qu'ils explorent les options. Ce sont eux qui prennent des notes au fur et à mesure, laissent des commentaires dans leur code pour s’assurer qu’ils comprennent leur propre chemin logique (et pour éclairer la voie pour eux-mêmes ou pour d’autres programmeurs qui pourraient avoir à traiter le code à l’avenir. .. ainsi, "compassion" dans ma liste ci-dessus!), et transmettent rapidement et clairement des idées complexes aux décideurs de haut en bas de la chaîne afin que les problèmes puissent être traités efficacement.

Un excellent programmeur est peut-être resté bloqué pendant des années dans un environnement qui n’a pas adhéré à l’idée de VCS, mais qui a eu de mauvaises expériences avec VCS (à la VSS), ce qui les a incités à craindre les essais de nouveaux systèmes, mais je garantirais que un excellent programmeur dans cette situation aurait quand même mis en place une sorte de routine pour se protéger de la perte de tout son travail au profit de quelques mauvaises itérations de conception.

Par conséquent, le type de programmeur à prendre en compte est celui qui affirme n'avoir jamais eu besoin de VCS, ni d'aucune mesure de protection contre les inévitables bêtises. Leur attitude est celle de "bien, je l'ai construite, donc elle ne peut pas se tromper." Celles-ci sont celles que je crains plus que tout noviciat sortant de l’université, car un novice peut apprendre à apprécier les points forts de VCS car il réalise à quel point il en sait très peu.

Jason M. Batchelor
la source
2

Comment est-il possible de développer activement des logiciels pendant 10 à 15 ans sans jamais avoir besoin de contrôle de version?

S'il vient d'anciennes équipes d'école où de petits projets sont gérés par une seule personne, c'est très possible. Il peut avoir 10 ans d’expérience dans le même ensemble technologique sans apprendre ni s’améliorer.

Le fait de ne pas rechercher une solution au problème du suivi des modifications est-il un signe d'une mauvaise attitude à l'égard de la programmation?

Si votre candidat a été dans un environnement de développement en équipe (au moins 4 programmeurs ou plus), la question est triviale. Cependant, il peut exister une division de travail entre les programmeurs, travaillant sur les modules qui leur sont uniquement affectés, ce qui peut réduire le besoin de contrôler le code à la source.

Cependant, ne pas être entendu sur le contrôle des sources à l'ère d'Internet est une situation vraiment surprenante. Ainsi, je verrais sa volonté d'apprendre de nouvelles choses (concernant votre environnement de développement) et son ouverture à un environnement de travail dynamique.

ElYusubov
la source
Tout le monde ne lit pas les blogs de programmation / etc. En particulier, une personne dont la carrière repose entièrement sur une plate-forme héritée ne va pas en tirer une valeur immédiate. Combien de blogs de logiciels Mainframe / COBOL / RPG (pas de jeux) connaissez-vous? La programmation de ces plates-formes n'a pas beaucoup changé au cours des 30 dernières années, et bon nombre des meilleures sources d'informations qui leur sont destinées sont presque certainement encore au format arbre mort. Si la programmation est votre travail, par rapport à ce que vous vivez, lorsque vous travaillez dans ces domaines, la lecture de blogs techniques, etc., n'aura pas beaucoup de retour sur investissement.
Dan Neely
1
Même sur un projet à une personne, vous bénéficiez du contrôle de version. Si un bogue est détecté, vous pouvez indiquer "introduit dans la version 3.13", ce qui affecte les utilisateurs de 3.13 et ultérieurs. Vous pouvez également créer facilement un correctif pour différentes versions, pour les personnes qui ne souhaitent pas migrer vers la dernière version. Si vous pouvez effectuer ces opérations sans contrôle de version, vous effectuez un contrôle de version de facto et ad hoc. Vous attendez de vos utilisateurs qu'ils utilisent votre logiciel pour éliminer le travail manuel laborieux et sujet aux erreurs, mais vous, le programmeur, ne le faites pas vous-même! LOL.
Kaz
2

L’expérience compte et vous avez raison de dire que les mécanismes d’utilisation des outils de contrôle de source peuvent être appris très rapidement. Mais vous avez raison de voir un drapeau rouge.

  • Votre candidat est-il isolé de la profession et de ses tendances?
  • Les nombreux autres aspects du travail en équipe doivent-ils également être appris?

Pour moi, le problème du contrôle de version est davantage un symptôme que la maladie. La cause peut varier et être plutôt bénigne. Beaucoup de programmeurs ad-hoc ont juste commencé à faire ce qui leur paraissait logique, à commencer par quelques livres sur la programmation, et n’ont pas fait d’étude systématique du développement de logiciels. Parfois, plus souvent encore, les majors en informatique obtenaient leur diplôme sans avoir jamais utilisé de système de contrôle de source, car tous leurs projets étaient des projets individuels et ils allaient dans des entreprises dotées de processus logiciels extrêmement immatures.

Quoi qu'il en soit, s'il est un loup solitaire depuis une décennie ou plus, il peut être difficile de vivre avec des gens.

Il pourrait être utile de demander à votre candidat quelques questions plus approfondies.

  • Parlez-moi d'une fois où vous avez travaillé en équipe?
  • Parlez-moi d'un moment où une équipe sur laquelle vous avez travaillé a eu un conflit entre ses membres?
  • Parlez-moi d'une fois où vous avez reçu du code d'un autre développeur et que vous avez poursuivi son projet?
  • Dites-moi comment vous et les autres membres de votre équipe vous êtes tenus à l'écart des autres lorsque vous créez du code ensemble?
  • Parlez-moi d'un problème signalé par un client lié à une fonctionnalité qui fonctionnait auparavant, mais ne fonctionnait pas dans une version ultérieure? Comment l'avez-vous résolu?
  • Qu'aimez-vous dans le travail en équipe?

Il peut également être habitué à avoir un contrôle presque complet sur ses méthodes, ses processus et à jouer un rôle dans lequel il est le seul expert en logiciels. Vous voudrez quelqu'un qui sera ouvert à une nouvelle façon de faire les choses. Plus de questions:

  • Parlez-moi d'une fois où vous avez utilisé ou aidé à créer une norme de codage?
  • Quel genre de choses voulez-vous voir dans une norme de codage?
  • Que pensez-vous de la réécriture du code de quelqu'un d'autre?
  • Parlez-moi d'une fois où vous avez participé à des examens par des pairs de logiciels ou de documentation?
  • Pouvez-vous me parler d'une proposition ou d'un contrat de développement logiciel que vous avez écrit?
  • Parlez-moi de votre gestionnaire de logiciel ou superviseur préféré?
  • Parlez-moi de votre collègue ou subordonné préféré?
DeveloperDon
la source
2

En 2012, le fait de ne pas avoir utilisé le contrôle de version est un indicateur rouge pour les 15 ans d'expérience dans le secteur. Ce pourrait ne pas être un drapeau rouge si l'année était 1982, ou même 1992. Mais aujourd'hui, il y aurait lieu de donner une excellente explication à cette lacune troublante dans le contexte de ce développeur.

Les situations extraordinaires nécessitent des explications extraordinaires.

Cela ressemble un peu à un mécanicien automobile qui prétend avoir réparé des voitures pendant 15 ans, sans jamais avoir autant de graisse que de graisse.

Bien sûr, vous enduire de graisse ne corrigera pas une transmission, et aucune des étapes du manuel de réparation n’exige une telle chose, mais ce n’est pas le problème. Le fait est qu’être parfaitement propre est totalement incompatible avec l’apparence réelle des mécaniciens d’automobiles lorsqu’ils travaillent. Dans ce travail, vous obtenez de la graisse sur vous-même.

Si vous interviewez une personne expérimentée qui admet n'avoir aucune expérience en contrôle de version, il exagère probablement ou fabrique une partie de son expérience (et ne sait même pas que le contrôle de version est une chose largement utilisée et importante, et quelque chose sur laquelle il devrait également mentir! )

Il est possible de voir toutes sortes de jokers lors d'entretiens. J'ai vu des personnes qui ne peuvent pas dessiner un diagramme d'une liste chaînée ou écrire une fonction qui insère un nœud en tête d'une liste chaînée. Pourtant, ils ont 20 ans d’expérience professionnelle.

Même les nouveaux diplômés en informatique peuvent s'attendre à être familiarisés de manière passive avec le contrôle de version, même s'ils ne l'ont pas encore beaucoup utilisé.

Kaz
la source
Le mieux que vous puissiez toujours espérer des nouveaux diplômés est "Oh, j'en ai entendu parler". Nous avons eu une introduction d'une semaine à ce que c'était, basé sur Subversion, mais nous n'avons jamais utilisé le contrôle de version pour quoi que ce soit.
Izkata
Oui, et comme ils sont nouveaux diplômés, nous "achetons" cela et passons à autre chose.
Kaz
"familiarité passagère" (ce que je pense que vous vouliez dire dans la réponse) implique qu'ils l' utilisent à un moment donné; Je souligne que vous ne pouvez même pas vous attendre à ça.
Izkata
Je dirais que si les diplômés CS n’ont pas utilisé le contrôle de version, leur service administratif n’a pas réussi à mettre en place un cours de génie logiciel adéquat et obligatoire dans le cadre duquel les étudiants de premier cycle en apprennent non seulement sur les concepts du logiciel, contrôle et tout). J'aimerais avoir un mot ou deux avec le responsable de ce département.
Kaz
Je programme professionnellement depuis près de 20 ans. Je sais ce qu'est une liste chaînée et pourquoi elle serait utilisée. Je n’en ai jamais utilisé et j’aurais probablement du mal à bien écrire votre fonction. Je pense que juste parce que vous utilisez des techniques vieilles de 30 ans, dire que tout le monde devrait le faire est un peu injuste.
DefenestrationDay
1

Je trouverais cela étrange, mais pas impossible pour un programme expérimenté de ne jamais avoir utilisé de contrôle de source dédié. Dans une entreprise avec laquelle je travaillais, ils utilisaient fréquemment le contrôle de source pour leurs codes C # et VB traditionnels. Toutefois, le code de base de données pur (procédures et scripts stockés ainsi que les définitions de table) ne faisait pas partie du contrôle de code source malgré le fait que deux développeurs SQL professionnels aient pour tâche principale d'écrire, de maintenir et d'exécuter du code de base de données pur. Je me suis fait le champion du contrôle de source pour les entités de la base de données et je n’ai que partiellement réussi.

Dans une autre société, l’équipe de développement était petite (un magasin pendant longtemps, puis deux). Le contrôle source du développeur précédent consistait à disposer de plusieurs copies des fichiers source avec une date ajoutée à la fin. En plus de ne pas avoir un meilleur système de contrôle de source, mon prédécesseur était définitivement compétent et intelligent.

Avant de devenir professionnel, j'étais un amateur et je n'utilisais aucun contrôle de source, je savais vaguement de quoi il s'agissait mais je ne me dérangeais pas.

En bref, je trouve étrange qu’un professionnel ne le connaisse pas très bien, mais surtout s’il est habitué à de très petites équipes, il est certainement possible d’être compétent sans cela. En embauchant, je ne lui en voudrais pas. Je serais absolument réticent à apprendre et commencerais à l'utiliser au travail contre lui cependant ...

TimothyAWiseman
la source
demandez au DBA de générer des scripts SQL à partir de la base de données, puis il peut les placer dans le contrôle de source.
linquize
@ Linquize Oh d'accord. C’est l’une des meilleures façons de le faire (bien que pas tout à fait la seule). Je signale simplement que j’ai rencontré de nombreux professionnels compétents et un amateur expérimenté qui n’avait aucune expérience du contrôle à la source, en particulier du côté DBA. En embauchant, je serais réticent à apprendre le contrôle des sources face à une nouvelle recrue potentielle, mais je ne serais pas trop surpris de ne pas l'avoir utilisé auparavant, surtout s'ils étaient habitués à une petite équipe et étaient principalement du côté de la base de données.
TimothyAWiseman
1

Mon propre 2c est que cela dépend de la façon dont il a réagi à la question de VC. Les réactions possibles pourraient être:

  1. Hein? Qu'est-ce que c'est
  2. Non, nous l'avons fait à la place
  3. Pas de mélange gêné , la direction ne nous le permettrait pas
  4. Pas de mélange embarrassé , mais j'ai enquêté un peu moi-même et j'ai pensé que cela ressemblait à quelque chose que nous devrions faire.

Dans le cas de 4, le gars obtiendrait un laissez-passer de ma part, il a la bonne attitude et le prendra probablement bien. Dans le cas de 3, il a le mérite de comprendre que c'est quelque chose qui devrait être fait, mais pas autant que 4. S'il a été capable de citer quelques faits à propos de VC (listez quelques paquets de VC), je ' Je prendrais cela comme une preuve de curiosité et risquait de le dépasser.

S'il répondait 1 ou 2, c'est-à-dire s'il savait et ne se souciait pas de VC, je remettrais sérieusement en cause le jugement du candidat. Il devra également travailler avec d'autres outils (suivi des bogues, métriques de qualité, automatisation de la construction, etc.) et vous constaterez probablement que vous avez une bataille ardue sur toutes ces questions s'il n'est pas disposé à essayer de nouvelles solutions. approches.

Comme la plupart des gens ici, je pense qu'il serait injuste de désavantager le candidat simplement parce que son employeur n'était pas à la hauteur; pour moi, tout dépend de la façon dont ils ont réagi.

PhilDin
la source
1

Ecrire ce qui a changé est bon quand on regarde en arrière. Cela m'a permis de gagner beaucoup de temps lorsque j'ai compris ce qui n'allait pas et que beaucoup de problèmes ont été résolus rapidement parce que je l'avais écrit. À mon avis, il est bon de tenir un journal. Surtout si vous programmez avec plus de personnes que vous.

Si vous écrivez une application Web, vous pouvez continuer à ajouter des fonctionnalités sans contrôle de version, car vous ajoutez simplement de nouvelles choses à celle-ci. Mais peut-être écrirez-vous un journal ou un article avec les nouveautés.

Tout dépend de ce que vous programmez.

Jason Stackhouse
la source
0

J'ai travaillé dans des endroits où le processus d'approbation du logiciel était de 12 à 18 mois. S'il ne figurait pas déjà sur la liste des logiciels approuvés, il n'y avait aucun moyen de le télécharger sur les machines. Les lecteurs de CD / DVD étaient verrouillés et les machines n'étaient pas connectées à Internet.

Le premier endroit où j'ai rencontré le contrôle de code source de la solution a été de demander à un développeur d'écrire son propre projet, au moment où il était prêt à tester le projet pluriannuel en voie de disparition. Ils ont parié que l'écriture à partir de zéro était plus rapide que le processus d'approbation.

La deuxième place que j'ai rencontrée dans ce problème utilisait le contrôle de source pendant les premiers mois, mais le client souhaitait ensuite que tout le développement soit effectué sur son réseau interne. Ils ont à nouveau tout verrouillé, de sorte que les dossiers compressés étaient de nouveau nombreux.

Je connais des développeurs qui n'ont travaillé que dans ces conditions. Ils veulent utiliser ces outils, ils adoreraient utiliser ces outils, mais ils ne sont pas autorisés à utiliser ces outils.

Recherchez pourquoi ils ne les ont pas utilisés. Ne pas comprendre les procédures à cause d'une expérience nulle est très différent du rejet des outils.

mhoran_psprep
la source
Rien de nouveau dans cette réponse.
pdr
0

Je me développe depuis 15 ans. Utilisé le contrôle de version seulement quelques fois. J'utilise toujours mes propres scripts et programmes planifiés pour sauvegarder tous les dossiers de développement de manière incrémentielle. Je ne sais pas quoi dire si quelqu'un me demande si j'utilise le contrôle de version. Je n'ai jamais eu besoin d'un système de contrôle de version, j'ai toujours travaillé sur de petits projets. Je veux dire que je ne suis pas le meilleur programmeur, mais je suis sûr que je ne suis pas le pire. La plupart du temps, je suis gêné de dire aux gens que je n'utilise pas régulièrement le système de contrôle de version, mais c'est comme ça pour moi.

Ensuite
la source
J'ai eu une expérience opposée: certaines personnes me jettent un regard amusant en disant que j'utilise le contrôle de version sur de petits projets dont je suis le seul développeur. Peut-être moins aujourd'hui, car le contrôle de version est utilisé pour l' hébergement de projets open source et est donc compris comme une méthode de déploiement.
Kaz
2
Vous devriez changer votre attitude et vous pencher sur le contrôle de version car il vous permet de faire beaucoup de choses facilement. Par exemple, le gitsystème de contrôle de version dispose d'un workflow automatisé ( git bisect) pour rechercher un bogue de régression. Ceci effectue la recherche binaire dans l'historique des versions d'un projet pour essayer de trouver l'ensemble de modifications qui a introduit le bogue. Tout ce que vous faites est de reconstruire, d'exécuter votre test et d'indiquer gits'il était bon ou mauvais; il sélectionne et récupère ensuite la ligne de base à tester.
Kaz
Dans gitvous pouvez faire quelques modifications expérimentales et ensuite les mettre dans un fichier stash. Votre travail est rétabli à l'original et les modifications sont enregistrées. Plus tard, vous pourrez explorer votre réserve et réappliquer ces modifications pour continuer à les expérimenter ou les jeter. Et bien sûr, tout système de contrôle de version décent a des branches, avec lesquelles vous pouvez faire des choses comme développer une fonctionnalité, de manière isolée, d’une version stable. Ou bien corrigez un bogue dans une version (pour donner un correctif aux clients) et fusionnez facilement cette modification dans la version de développement actuelle.
Kaz
0

D'après mon expérience en tant que programmeur sur les systèmes IBM MVS: pendant les dix premières années de ma carrière professionnelle, le système d'exploitation avec lequel je travaillais disposait exactement d'un type de fichier versionable à la disposition du programmeur: l'ensemble de données de génération. Il s’agissait essentiellement d’un fichier contenant un nombre fixe de versions, et il fallait se rappeler quelle version était quoi - ce qui était pratiquement inutile pour le contrôle de version moderne. Couplé à un système de fichiers sans répertoires réels, mais avec plus ou moins de qualificatifs (8 caractères), le concept de système de gestion de code source était totalement étranger à toute personne travaillant dans cet environnement.

En réalité, je n'ai pas vu de système de contrôle de code source avant de migrer vers SunOS 3 et d'utiliser RCS. À ce moment-là, j'étais un programmeur de systèmes IBM extrêmement facile, très productif et très bon dans mon travail. Toute la gestion des versions a été gérée en copiant des sauvegardes sur une bande et en enregistrant ce qui se trouvait où.

Si je travaillais encore sur des ordinateurs centraux à ce stade, il est tout à fait possible que je n’aie toujours pas été exposé à un système de contrôle de version formel; Les alternatives spécifiquement supportées sont ClearCase et Rational, aucune d’elles n’est gratuite (et sont en fait assez chères).

Dire que quelqu'un est par définition incompétent parce qu'il n'a jamais utilisé le contrôle de version est un argument spécieux. Il faut creuser et regarder les détails. S'ils prétendent être des développeurs Linux / Unix / Mac OS mais qu'ils n'ont jamais utilisé le contrôle de version, cela leur parle moins bien, et vous devrez peut-être évaluer si leur expérience globale est si satisfaisante que vous seriez prêt à le faire. les former au génie logiciel moderne. Si ce sont eux et les programmeurs centraux de la vieille école - et c'est ce dont vous avez besoin -, concentrez-vous sur s'ils possèdent exactement les compétences de programmation souhaitées, et résignez-vous au fait que vous devrez leur apprendre cela. Comme d'autres l'ont dit, leur réponse au concept sera le facteur décisif dans ce cas.

Joe McMahon
la source
0

Jolie s'il-vous-plaît! L'ensemble de notre communauté ne vit pas dans des communautés sociales très développées où les hangars geek et les événements hacky sont excessivement abondants. Nous ne travaillons pas tous dans des entreprises de développement logiciel et certains d'entre nous ne peuvent même pas trouver de ressources publiées pertinentes ou à jour. dans nos langues maternelles, imprimées ou en ligne, laissez-vous toujours rencontrer un collègue programmeur dans la chair.

Si je comprends bien, s’il est un développeur de logiciel expérimenté, vous avez probablement été un loup solitaire qui travaillait en tant que pigiste pour de petites entreprises.

Filip Dupanović
la source
-1

Il y a peu de raisons pour ne pas utiliser le contrôle de version:

  1. Travailler dans des entreprises dont le développement logiciel n’est pas leur activité principale.
  2. Ou si le développeur a décidé d'utiliser un autre système - valable uniquement pour les expérimentés.
  3. Ou si le développeur n'a pas encore appris le fonctionnement de chaque système
  4. Ou c'est un problème d'attitude par rapport aux outils auxquels ils sont inconnus

Mais vous devriez faire attention lorsque vous rencontrez des gens qui supposent:

  1. Qu'il n'y a qu'un seul moyen de faire quelque chose
  2. Ou que chaque programmeur doit le faire de la même manière
  3. Ou que les pratiques que les gens utilisent sont faciles à changer
tp1
la source
-2

Aussi bien que possible pour un mauvais programmeur d'être un expert en contrôle de version. Mon point est que je ne sais pas ce que le contrôle de version fait pour vos compétences en programmation ou votre capacité à résoudre des problèmes. C'est une question d'expérience. Beaucoup de petits magasins ne l'utilisent pas ou laissent les particuliers (qui travaillent souvent en solo) pour le résoudre eux-mêmes.

Aserwin
la source
-2

Je pense que ce n'est pas tant une question de « Comment est - il possible de développer activement les logiciels de 10-15 ans sans jamais avoir besoin de contrôle de version? », Mais « Comment est - il possible de développer activement des logiciels pour les dernières 10-15 années sans jamais besoin de contrôle de version? ".

Bien sûr, la programmation est possible sans contrôle de version, mais un professionnel doit être familiarisé avec l’état de la technique et savoir choisir les bons outils pour effectuer son travail. Ne pas utiliser le logiciel de gestion de version approprié rend votre travail risqué et peu fiable, et l'une des raisons pour lesquelles vous souhaitez engager un développeur professionnel est qu'il doit être capable de gérer les risques.

Une base de code correctement annotée dans un VCS vaut bien plus que celle qui ne l'est pas. La raison de chaque changement peut être suivie et comprise, ce qui permet aux responsables de la maintenance de mieux comprendre ce qu’ils doivent savoir. Ne pas le faire est peu professionnel et le seul prétexte serait qu'il fût contraint par des gestionnaires médiocres à son poste précédent. Même alors, n'auraient-ils pas dû utiliser le contrôle de version pour leurs projets privés?

Dominic Cronin
la source