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

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?

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.

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.

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?

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.

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

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é.

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.

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.

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.

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.

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.

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.

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.

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?

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.

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.

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é?

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é.

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 ...

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.

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.

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.

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.

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.

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.

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

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.

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?