Est-il possible pour un bon programmeur de n'avoir jamais utilisé le contrôle de version?
Je recherche un programmeur expert pour aider à résoudre une situation difficile.
Jusqu'à présent, les interviews ont été étonnamment décevantes. Le meilleur candidat jusqu'à présent est un programmeur très expérimenté qui n'a jamais utilisé de logiciel de contrôle de version.
Le problème en soi n'est peut-être pas trop grave car c'est quelque chose qui s'apprend 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 chercher lui-même une solution au problème du suivi des changements est-il le signe d'une mauvaise attitude envers la programmation?
J'ai travaillé pendant environ 11 ans dans des entreprises qui n'utilisaient pas le contrôle de code source. Nous avons réussi (principalement en commentant les modifications et en conservant le code sur un serveur central qui pouvait ê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 de la programmation avant Internet.
J'ai du mal à voir comment vous pouvez maintenant passer plus de 10 ans dans l'industrie sans avoir rencontré le contrôle des sources. Mais, j'aurais une certaine sympathie, je croirais que c'était possible et je ne rejetterais pas le candidat sur ce seul détail. Je sonderais et découvrirais comment le candidat a géré cela.
Alternativement, je pourrais me demander si mon processus d'entrevue était le problème. En quoi é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 tout simplement pas les bonnes questions? Si je posais les bonnes questions, un autre candidat brillerait-il?
Enfin, n'ayez pas peur de rejeter tous les candidats si vous avez des inquiétudes. Il faut beaucoup de temps pour recommencer, mais il faut plus de temps pour embaucher la mauvaise personne.
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 en mesure de prendre 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 aiderait vraiment à rendre le développement plus efficace. Je n'en ai pas eu autant besoin car j'ai travaillé seul sur des projets.
Mauvais
Le contrôle de version n'est qu'un mot à la mode qui disparaît lentement dans l'industrie. Je suis au-dessus du contrôle de version.
Permettez-moi de vous donner une perspective de développement de logiciels sous DOS et Windows depuis plus de 20 ans.
Le logiciel de contrôle de version dans le monde Windows/PC était souvent peu fiable au début des années 90. Visual Sourcesafe (VSS) était le meilleur basé sur Windows, mais il pouvait être excentrique et de nombreux programmeurs le détestaient. Certaines équipes refusaient tout simplement d'en profiter après avoir fait face à cette situation.
La plupart des autres options VCS à l'époque n'étaient pas basées sur Windows et, par conséquent, étaient rarement utilisées dans les équipes de développement Windows. Certaines de ces solutions étaient coûteuses et les solutions open source n'étaient pas aussi acceptées qu'elles le sont aujourd'hui.
Dans de nombreux cas, à la fin des années 90, au début des années 00, si une équipe Windows n'utilisait pas VSS, elle n'utilisait rien pour le contrôle des sources 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 comme git et SVN.
Il est possible qu'une personne qui a travaillé pendant des années dans une petite équipe de développement Windows pendant des années n'ait pas utilisé de VCS. J'ai interviewé et même fait du travail à contrat dans certains endroits qui ne les utilisaient pas ou qui étaient très aléatoires quant à leur utilisation.
Donc, je ne pense pas que le manque d'expérience de votre candidat dans ce domaine soit un non catégorique, mais vous voulez probablement approfondir sa situation de travail précédente pour découvrir pourquoi cela manque à son expérience. Vous voudrez également explorer leur attitude envers le contrôle de version. Pensent-ils que c'est une bonne idée mais ils n'étaient pas autorisés à la poursuivre à leur poste précédent ou pensent-ils que c'est une perte de temps?
Vous ne pouvez pas avoir de contrôle de version sans logiciel de contrôle de version? Demandez comment ils ont géré leur code. Peut-être qu'un système local était déjà en place.
Vouloir faire les choses manuellement, réinventer la roue et résister au changement ne sont pas nouveaux pour la programmation. Allez-vous baver sur 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 entre: ne peut pas, n'a pas et ne veut pas.
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 est au-delà de la banalité et présente des avantages considérables. Tout développeur ne sachant pas que cela ne peut pas être considéré comme bon ou 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 est sorti en 1972 (il y a 40 ans)
- RCS est sorti en 1982 (il y a 30 ans), et il est complètement open source et gratuit
- CVS est sorti en 1990 (il y a 21 ans), également complètement open source et gratuit
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, indépendamment de toute autre information d'identification.
On dirait bien un drapeau rouge, mais approfondissez 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 serais plus indulgent envers lui que s'il travaillait en équipe et n'essayait même pas d'apporter le contrôle de version.
Je ne serais pas religieux au sujet du manque d'expérience en contrôle de version. Ce n'est qu'un outil. En fin de compte, vous pouvez reprendre les bases de svn ou git en un jour ou deux. Le reste vous ramasserez avec le temps. Et je ne peux pas croire qu'un candidat à moitié décent ne puisse pas s'intégrer s'il devait travailler dans un environnement qui utilise le contrôle des sources.
Utiliser le contrôle de code source est plus une habitude qu'une compétence. Quelqu'un qui ne l'a jamais utilisé peut exagérer l'effort requis et sous-estimer les avantages obtenus. Après tout, il allait bien jusqu'à présent. Ce n'est qu'après avoir réellement utilisé le contrôle de source qu'il apprendra à l'apprécier.
La question que vous devez vous poser est la suivante: comment a-t-il géré en l'absence de contrôle des sources? Cela pourrait vous dire quelque chose sur lui et comment il gère son travail.
Je ne me suis jamais considéré comme un "programmeur" jusqu'à ce que je commence à gagner de l'argent en le faisant professionnellement.
J'ai gagné pas mal d'argent en créant des systèmes qui ont fait gagner encore plus d'argent aux clients. Que je sois ou non un "bon" développeur est subjectif.
Je peux GSD (Get Something Done) rapidement, ce qui pour le développement web a généralement plu à mes clients. Ils peuvent ne pas voir de code laid dans les coulisses, le manque de commentaires, etc.
Je n'avais pas utilisé Git et je n'avais pas de profil Github avant cette année, ce qui me semble bien "en retard" en termes de normes de programmation modernes. Je viens aussi de commencer à faire des projets Rails et Django après avoir seulement fait PHP, Flash et iOS dans le passé. J'ai depuis décroché des contrats de développement de sites) tant pour les clients que pour moi, cela n'a pas été trop pénible d'apprendre quelque chose de nouveau à 30 ans et à quelques années de la programmation.
Trop dans la société moderne se concentre sur le fait de suivre les Jones et de se soucier de ce que les autres pensent. Si vous pouvez briser ces entraves et considérer 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.), cela peut avoir beaucoup plus d'importance que 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 ce qui les passionne, quel est le système le plus cool qu'ils aient jamais créé à leur avis et dans quoi ils passent leur temps libre à développer leurs compétences. Si les gens ne font pas progresser leurs compétences en leur temps, ça me fait plus peur que d'autres choses, mais ça ne veut pas dire que ça doit vous faire peur.
Je pense que vous avez déjà d'excellentes réponses à cette question de la part des gens ici et cela devrait vous aider à prendre votre propre décision éclairée en fonction de vos besoins.
Vous laissez beaucoup d'informations sur son expérience.
Fondamentalement, je dirais qu'il est très possible qu'un programmeur puisse avoir 10 à 15 ans d'expérience sans avoir à connaître le contrôle de version. Coder pendant 10 ans n'est pas égal à apprendre constamment de nouvelles techniques de programmation pendant 10 ans.
Je suis très jeune et j'ai vu des ingénieurs logiciels anciens et "expérimentés" dont je ne voudrais jamais toucher le code. Cela dit, il est peut-être très talentueux, mais je suppose que d'après le peu d'informations étant donné qu'il ne l'est pas.
Bonne chance.
Personnellement, la chose la plus alarmante pour moi est que le candidat n'a jamais rencontré de systèmes de contrôle de version en tant que concept, ou a décidé que cela ne valait pas la peine d'être utilisé. Je trouve le premier scénario très improbable, mais si tel est le cas, cela m'amène à supposer que le candidat a été significativement isolé pendant la durée de sa carrière, ce qui jetterait un sérieux doute sur sa valeur en tant que membre d'une équipe. Plus précisément, 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 ont activement décidé de ne pas contrôler la version, cela me fait supposer qu'ils n'ont jamais travaillé sur quoi que ce soit d'important ou qu'ils sont extrêmement arrogants. Ou, au mieux, ils ont des moyens vraiment terribles de maintenir le code comme commenter les blocs et attribuer chaque ligne de code à un auteur, une date et un numéro de bogue.
Je vois ici des réponses plutôt critiques qui ne tiennent pas réellement compte de la personne jugée.
Je trouve personnellement que le logiciel de contrôle de version est un outil précieux. Mais, nous n'avons pas tous le choix et le contrôle sur les outils et les processus qui sont utilisés dans nos environnements de travail. Je travaille dans le développement Windows depuis 1990. Comme indiqué par d'autres, à cette époque, il n'y avait pas beaucoup de disponibilité pour VCS dans Windows. Nous n'allions pas apporter de serveurs UNIX juste pour obtenir un VCS. Cela fait-il de moi un mauvais programmeur? Plus tard dans ma carrière, j'ai travaillé pour une entreprise avec un produit commercial à marché vertical où le contrôle de version était un processus et non un outil. Cela fait-il de moi un mauvais programmeur? Mes trois derniers emplois se sont tous largement appuyés sur les outils VCS. Cela fait-il de moi un bon programmeur?
Ce serait formidable si nous pouvions tous utiliser uniquement les outils, les langages et les technologies les plus récents et les plus performants. Mais la profession de développement logiciel 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 forcerais à utiliser. .. ". Nous ne sommes pas tous entourés d'une offre infinie de possibilités d'emploi où tout fonctionne exactement comme nous le souhaitons. Nous avons des factures à payer et avons besoin d'un emploi, alors nous nous occupons de ce qui nous entoure.
En fin de compte, la réponse à votre question est la suivante: jugez ce programmeur en fonction de ses compétences, de ses philosophies et de ses décisions, et non des décisions (éventuellement erronées) prises par les responsables de ses emplois antérieurs.
Je trouve incroyable qu'un professionnel du logiciel n'ait jamais utilisé le contrôle de source, et je serais très nerveux à l'idée de l'embaucher.
Quelle expérience a-t-il. Je me demande ce qu'il ne sait pas d'autre que vous n'avez jusqu'à présent pas 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 de performances du système, les questions de sécurité du système, etc.?
S'il s'est montré fort sur ce genre de choses, alors peut-être je pourrais ignorer le manque de connaissances en contrôle de source.
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'équipes old school où les 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 de technologies sans apprendre et se perfectionner.
Le fait de ne pas chercher lui-même une solution au problème du suivi des changements est-il le signe d'une mauvaise attitude envers la programmation?
Si votre candidat a été dans un environnement de développement d'équipe (au moins 4 programmeurs ou plus), alors c'est une question banale. Cependant, il peut y avoir une division du travail entre les programmeurs, travaillant sur des modules qui leur sont uniquement affectés, ce qui peut réduire le besoin de contrôler le code source.
Cependant, ne pas être entendu sur le contrôle des sources à l'ère d'Internet est une situation vraiment surprenante. Ainsi, je regarderais sa volonté d'apprendre de nouvelles choses (concernant votre environnement de développement) et son ouverture à un environnement de travail dynamique.
Est-il possible pour un bon programmeur de n'avoir jamais utilisé le contrôle de version?
Oui. De nombreuses 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 2 petites entreprises, j'ai mis à niveau 1 entreprise moyenne de quelque chose de terrible à SVN (meilleure option à l'époque) et j'ai travaillé dans une autre petite entreprise qui n'avait que quelques VC, a écrit la leur VC solution pour du code et avait beaucoup de code mais pas dans aucun VC.
Le fait de ne pas chercher lui-même une solution au problème du suivi des changements est-il le signe d'une mauvaise attitude envers 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? Quoi? Qu'en avez-vous 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 travaillé avec quiconque auparavant sur la même base de code, et quelles méthodes avez-vous utilisées pour éviter les conflits?
Je serais d'accord avec Explosion Pills (mais mon représentant est trop bas, atm ...) ... l'attitude est beaucoup plus importante.
Il y a quelques éléments à rechercher qui, je crois, contribuent à l'excellence de la programmation:
- La communication
- La créativité
- Compassion (dites quoi?)
Et, souvent, plus d'un petit 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 leurs propres chemins logiques (et pour éclairer la voie pour eux-mêmes ou d'autres programmeurs qui pourraient avoir à gérer le code à l'avenir. .. donc, "compassion" dans ma liste ci-dessus!), et transmettre rapidement et clairement des idées complexes aux décideurs de la chaîne afin que les problèmes puissent être résolus efficacement.
Un excellent programmeur a peut-être été coincé pendant des années dans un environnement qui n'a pas adhéré à l'idée de VCS, a eu de mauvaises expériences avec VCS (à la VSS), ce qui les a rendus timides pour essayer de nouveaux systèmes, mais je garantirais que un excellent programmeur dans cette situation aurait toujours mis en place une sorte de routine pour se protéger de ne pas perdre tout leur travail à cause de quelques mauvaises itérations de conception.
Le type de programmeur dont il faut se méfier est donc celui qui prétend n'avoir jamais nécessaire VCS, ni aucune mesure de protection contre les vices inévitables. Leur attitude est "bien, je l'ai construit, donc ça ne peut pas être faux". Ce sont ceux que je crains plus que tout noviciat tout droit sorti du collège, car un novice peut apprendre à apprécier les forces du VCS car il se rend compte du peu qu'il sait réellement.
L'expérience compte et vous avez raison de dire que la mécanique de l'utilisation des outils de contrôle de source peut être apprise assez rapidement. Mais vous avez raison de voir un drapeau rouge.
- Votre candidat est-il isolé du métier et de ses tendances?
- Les nombreux autres aspects du travail en équipe devront-ils également être appris?
Pour moi, le problème du contrôle de version est plus un symptôme que la maladie. La cause peut varier et être assez bénigne. Beaucoup de programmeurs ad hoc ont juste commencé à faire ce qu'ils pensaient logique, à commencer par quelques livres sur la programmation, et n'ont pas fait une étude systématique du développement de logiciels. Parfois, plus encore dans le passé, les majors en informatique obtenaient leur diplôme sans jamais avoir utilisé un système de contrôle des sources car tous leurs projets étaient des projets individuels et ils étaient allés dans des entreprises avec un processus logiciel très immature.
Peu importe où il est arrivé, s'il est un loup solitaire depuis une décennie ou plus, il peut être difficile de vivre avec des gens.
Il vaut peut-être la peine de demander à votre candidat quelques questions supplémentaires.
- 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 les membres de l'équipe?
- Parlez-moi d'une fois où vous avez reçu du code d'un autre développeur et avez poursuivi son projet?
- Dites-moi comment vous et les autres membres de votre équipe êtes restés à l'écart lors de la création de code ensemble?
- Parlez-moi d'un problème signalé par un client lié à une fonctionnalité qui fonctionnait auparavant, mais qui 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 et processus et à jouer un rôle où 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?
- Quels types de choses souhaitez-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 les pairs de logiciels ou de documentation?
- Pouvez-vous me parler d'une proposition ou d'un contrat de développement logiciel que vous avez participé à la rédaction?
- Parlez-moi de votre gestionnaire ou superviseur logiciel préféré?
- Parlez-moi de votre collègue ou subordonné préféré?
En 2012, pour quelqu'un avec 15 ans d'expérience dans l'industrie, ne jamais avoir utilisé le contrôle de version est un drapeau rouge. Ce ne serait peut-être pas un tel drapeau rouge si l'année était 1982, ou même 1992. Mais aujourd'hui, il vaut mieux avoir une excellente explication de cet écart déroutant dans les antécédents de ce développeur.
Les situations extraordinaires nécessitent des explications extraordinaires.
C'est un peu comme un mécanicien automobile qui prétend réparer des voitures depuis 15 ans, mais qui n'a jamais eu autant de graisse sur lui-même.
Bien sûr, vous enduire de graisse ne résoudra pas une transmission, et aucune des étapes du manuel de réparation ne l'exige, mais ce n'est pas la question. Le fait est qu'être d'une propreté impeccable est totalement incohérent avec ce à quoi ressemblent les mécaniciens automobiles lorsqu'ils travaillent. Dans ce travail, vous vous graissez.
Si vous interviewez quelqu'un d'expérience qui admet qu'il n'a aucune expérience en matière de contrôle de version, il exagère ou fabrique probablement une partie de son expérience (et ne sait même pas que le contrôle de version est quelque chose de largement utilisé et important, et quelque chose sur lequel il devrait également mentir! )
Il est possible de voir toutes sortes de jokers dans les interviews. J'ai vu des gens 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. Ils revendiquaient pourtant 20 ans d'expérience professionnelle.
Même les nouveaux diplômés de l'informatique peuvent s'attendre à avoir une familiarité passive avec le contrôle de version, même s'ils ne l'ont pas encore largement utilisé.
Je trouverais cela étrange, mais pas impossible pour un programme expérimenté de n'avoir jamais utilisé de contrôle de source dédié. Dans une entreprise avec laquelle je travaillais, ils utilisaient largement le contrôle de code source pour leur C # traditionnel et VB. Mais le code de base de données pur (procédures stockées et scripts ainsi que les définitions de table) n'était pas en contrôle de code source) malgré le fait d'avoir deux développeurs SQL professionnels dont le travail principal était d'écrire, de maintenir et d'exécuter du code de base de données pur.
Dans une autre entreprise, l'équipe de développement était petite (un homme boutique pendant longtemps, puis deux). Le contrôle de code source du développeur précédent avait plusieurs copies des fichiers source avec une date ajoutée à la fin. Mis à part l'absence d'un meilleur système de contrôle des sources, mon prédécesseur était définitivement compétent et intelligent.
Avant de devenir un professionnel, j'étais un amateur et je n'utilisais aucun contrôle de source, je savais vaguement de quoi il s'agissait, mais cela ne me dérangeait pas.
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 lui. En embauchant, je ne lui en tiendrais pas rigueur. Je serais absolument réticent à apprendre et à commencer à l'utiliser contre lui au travail ...
Mon propre 2c est que cela dépend de la façon dont il a réagi aux questions sur VC. Les réactions possibles pourraient être:
- Hein? Qu'est-ce que c'est
- Non, nous l'avons fait à la place
- Non mélange embarrassé, la direction ne nous permettrait pas
- Non 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 moi, il a la bonne attitude et le ramassera probablement très bien. Dans le cas de 3, il obtient le mérite d'avoir compris que c'est quelque chose qui devrait être fait mais pas autant que 4. S'il a pu nommer quelques factoids à propos de VC (énumérer certains des VC packages là-bas) je prendrais cela comme une preuve de curiosité et je pourrais le passer.
S'il répondait 1 ou 2, c'est-à-dire s'il savait et ne se souciait pas de VC, je mettrais sérieusement en doute le jugement du candidat. Il y aura d'autres outils (suivi des bogues, mesures de qualité, automatisation de la construction, etc., etc.) avec lesquels il devra travailler et vous constaterez probablement que vous avez une bataille difficile sur tous ces problèmes s'il n'est pas prêt à essayer de nouveaux 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 au courant; pour moi, tout dépend de la façon dont ils ont réagi.
Écrire ce qui a changé, c'est bien quand on regarde en arrière. Cela m'a fait gagner beaucoup de temps lorsque j'ai compris ce qui n'allait pas et 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 gens que vous.
Si vous écrivez une application Web, vous pouvez continuer à ajouter des fonctionnalités sans contrôle de version, car vous y ajoutez constamment de nouvelles choses. Mais peut-être que vous écrirez un journal ou un article avec les nouveautés.
Tout dépend de ce que vous programmez.
J'ai travaillé dans des endroits où le processus d'approbation des logiciels é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 les obtenir sur les machines. Les lecteurs de CD/DVD étaient verrouillés et les machines n'étaient pas connectées à Internet.
Le premier endroit où je suis tombé sur le contrôle de code source, la solution a été de demander à un développeur d'écrire le sien, au moment où il était prêt à tester le projet pluriannuel qui était en train de se terminer. Ils ont parié que l'écrire à partir de zéro était plus rapide que le processus d'approbation.
Le deuxième endroit où j'ai rencontré ce problème a utilisé le contrôle de code source pendant les premiers mois, mais le client a ensuite souhaité que tout le développement soit effectué sur son réseau interne. Ils ont à nouveau tout verrouillé, donc c'était de retour à de nombreux dossiers zippés.
Je connais des développeurs qui n'ont travaillé que dans ces conditions. Ils veulent utiliser ces outils, ils aimeraient utiliser ces outils, mais ils ne sont pas autorisés à utiliser ces outils.
Cherchez pourquoi ils ne les ont pas utilisés. Ne pas comprendre les procédures en raison d'une expérience nulle, est très différent du rejet des outils.
Je me développe depuis 15 ans. N'a utilisé le contrôle de version que quelques fois. J'utilise toujours mes propres scripts et programmes planifiés pour sauvegarder progressivement tous les dossiers de développement. 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.
Parlant de 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 j'ai travaillé avait exactement un type de fichier versionnable à la disposition du programmeur: l'ensemble de données de génération. Il s'agissait essentiellement d'un fichier avec un nombre fixe de versions, et vous deviez vous rappeler quelle version était quoi - à peu près inutile pour le contrôle de version moderne. Couplé à un système de fichiers qui n'avait pas de répertoires réels, juste plus ou moins de qualificatifs (8 caractères), le concept d'un système de gestion de code source était complètement étranger à toute personne travaillant dans cet environnement.
Je n'ai pas vu de système de contrôle de code source avant de passer à 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. Toutes les versions ont été gérées en copiant les sauvegardes sur bande et en enregistrant où elles se trouvaient.
Si je travaillais encore sur des mainframes à ce stade, il est tout à fait possible que je n'aurais peut-être jamais été exposé à un système de contrôle de version formel; les alternatives spécifiquement prises en charge sont ClearCase et Rational, aucune des deux n'est gratuite (et en fait, elles sont toutes les deux assez chères).
Donc, 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 est nécessaire de creuser et de regarder les détails. S'ils prétendent être un développeur Linux/Unix/Mac OS mais n'ont jamais utilisé le contrôle de version, cela parle moins bien pour eux, et vous devrez peut-être évaluer si leur expérience globale est si adaptée que vous seriez prêt à le faire. les former en génie logiciel moderne. S'ils sont programmeurs mainframe old-school - et c'est ce dont vous avez besoin - alors concentrez-vous sur s'ils ont précisément les compétences de programmation dont vous avez besoin, et résignez-vous au fait que vous devrez leur enseigner cela. Comme d'autres l'ont dit, leur réponse au concept sera le facteur décisif dans ce cas.
Jolie s'il-vous-plaît! L'intégralité de notre communauté ne vit pas dans des communautés sociales très développées où les hangouts geek et les événements hacky sont trop abondants, nous ne travaillons pas tous dans des sociétés de développement de logiciels 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 jamais rencontrer un autre programmeur dans la chair.
Pour tout ce que je peux comprendre, s'il est un développeur de logiciels expérimenté comme vous le dites, il est probablement un loup solitaire travaillant comme pigiste pour de petites entreprises.