Question:
Lorsqu'elle postule à des postes de développement logiciel, dans quelles conditions est-il acceptable pour l'entreprise de ne pas utiliser le contrôle de code source?
Nelson
2017-11-13 11:45:45 UTC
view on stackexchange narkive permalink

J'ai eu 3 ans d'expérience en développement avec deux entreprises différentes. L'un utilisait SVN. L'un utilisait VSS (Visual Source Safe. Pas le meilleur ... mais c'est quelque chose.)

Dans mon dernier rôle de développement Web, pendant le processus d'entrevue, j'ai posé des questions sur le contrôle de version qu'ils utilisent et ils a dit "Nous avons essayé SVN, et nous avons essayé GIT, mais pour le moment, nous ne faisons que passer des fichiers zip".

Je trouvais que c'était un peu bizarre, mais j'ai quand même accepté le travail. Je ... n'ai pas été impressionné.

Je suis à nouveau à la recherche d'un emploi et j'ai rencontré une autre entreprise qui n'utilise actuellement aucun contrôle de version.

Dans quelles conditions est-ce un réponse acceptable? Comment dois-je procéder avec l'entreprise si je suis toujours intéressé?

Cependant, ils font les choses, c'est acceptable si cela vous convient.
Le problème est que je n'ai aucune idée de la façon dont ils font les choses au niveau des entretiens.Moi-même, je ne peux pas penser à une raison pour laquelle ils n'utiliseraient pas le contrôle de version, car je l'utilise même pour des projets solo!Même quelque chose comme le coller dans Dropbox est le contrôle de version ...
Alors demandez-leur de vous expliquer comment ils font fonctionner les choses pour lesquelles vous utiliseriez le contrôle de code source?
C'est un drapeau rouge assez grand.Ce n'est pas tout à fait rare (j'ai travaillé avec des entreprises utilisant leurs outils ERP pour la gestion des balises / versions uniquement), mais c'est un indicateur que l'entreprise n'accorde pas de valeur au développement logiciel.
"Nous avons essayé SVN, et nous avons essayé GIT, ..." - Vous n'avez pas demandé ce qui n'allait pas avec ces deux?Une raison pour ne pas utiliser le contrôle de source est la méconnaissance.Peut-être que ce n'est pas grave si vous êtes une personne sans expérience suffisante, mais pas si vous êtes une société de développement de logiciels.
Je pense que cela appartient plus à Software Engineering SE qu'ici (mais je ne peux pas le signaler pour y déménager pour une raison quelconque).En ce qui concerne les entretiens, vous savez déjà que vous préféreriez une entreprise qui utilise le contrôle de source.Soit vous en faites un facteur décisif, soit vous essayez d'attribuer une valeur pour être en mesure de décider d'accepter un emploi ou non.Je ne pense pas que nous puissions vous aider à décider à quel point le contrôle de source est précieux pour vous ...
Je n'accepterais pas un tel travail.S'ils ne sont pas capables (ou n'ont pas besoin) d'utiliser VCS, je suis presque sûr que ce ne sera pas le travail le plus techniquement difficile.
Je peux sympathiser avec les magasins sans contrôle de source ayant du mal à se convertir à Git.Il nous a fallu environ six mois pour convertir nos processus.Cela a pris beaucoup d'heures de travail.Cela en vaut vraiment la peine maintenant, mais si vous l'abordez avec un état d'esprit du genre: "hé, nous allons faire Git" et que vous vous attendez à ce que ce soit une chose facile, vous allez frapper ce mur très fort.
Connexes: [Est-il possible pour un bon programmeur de n'avoir jamais utilisé le contrôle de version?] (Https://softwareengineering.stackexchange.com/questions/167044/is-it-possible-for-a-good-programmer-to-have-never-used-version-control).
Le manque de contrôle de version pour le développement logiciel est un facteur décisif et je m'enfuirais loin de toute entreprise qui ne l'utilise pas.
Six réponses:
user79491
2017-11-13 13:27:53 UTC
view on stackexchange narkive permalink

Je ne pense pas être d'accord avec les autres types de réponses «ça dépend». Ne pas utiliser de contrôle de version est un énorme drapeau rouge .

Le fait qu'ils n'utilisent pas de solution connue ne serait pas un problème à mon avis, mais ils déclarent qu'ils n'utilisent aucun type de contrôle de version, que ce soit interne ou externe.

Cela signifie probablement que vous passerez des heures et des heures à résoudre les bogues des clients, en essayant de fusionner manuellement les bogues déjà corrigés en Dieu sait comment de nombreux fichiers des lots de versions. Avez-vous posé des questions sur la gestion des versions des versions, au fait?

Je ne considérerais pas le poste comme un défi, car s'ils sont toujours une entreprise, je ne vois pas comment créer des logiciels complexes et fiables en ayant un humain faisant la base de données du journal, fusionnant les modifications dans plusieurs fichiers, marquant manuellement les versions.

Le résultat est: des problèmes avec le support client, une mauvaise fiabilité du logiciel, pas une position difficile.

Aucun contrôle de version (que ce soit Git, SVN ou un contrôle sur mesure / interne) ne doit être un facteur décisif.Une telle entreprise a probablement d'autres processus horribles.
D'après mon expérience, les entreprises sans contrôle de version ont une attitude «ce n'est pas grave, nous utiliserons le correctif temporaire comme solution définitive à notre problème» sur tout.Même s'il est possible de travailler de cette façon, de nombreux problèmes importants surgiront, et généralement ce type d'entreprise n'essaiera même pas de les résoudre, il suffit de les contourner.Vous finissez par passer la plupart de votre temps à travailler sur tout et à ne pas faire votre travail.
J'ai réussi à implémenter le contrôle de version sur les quelques entreprises pour lesquelles j'ai travaillé sans lui.Ce n'est pas parce qu'ils ne l'ont pas actuellement qu'ils ne peuvent pas commencer à l'utiliser avec l'incitation appropriée!
Oh, travailler sur un tel projet serait certes difficile, sauf que le mot défi dans ce contexte signifierait quelque chose de différent de ce que nous utilisons normalement.
J'ajouterais dans la liste la raison du truc des drapeaux rouges: il est possible qu'ils ne l'utilisent pas parce que vous serez le seul développeur, et beaucoup d'entre nous préfèrent travailler en équipe.
akaioi
2017-11-13 12:04:28 UTC
view on stackexchange narkive permalink

Eh bien ...

Tout est question de jugements de valeur. Il doit y avoir un facteur qui vous a attiré vers cet emploi en premier lieu: peut-être que c'est près de chez vous; peut-être que vous aimez leur produit; peut-être que vous "cliquez" bien avec l'équipe. Vous devez peser ces bons facteurs avec ce facteur extrêmement négatif d’absence de contrôle de code source .

Personnellement, je traiterais l’absence de contrôle de code source comme un gigantesque drapeau rouge qui indique probablement beaucoup d'autres problèmes de processus que vous n'apprécierez pas. Je ne les rejoindrais probablement pas du tout à moins d'être embauché avec pour mandat d'aider à rationaliser cette situation.

Votre kilométrage, bien sûr, peut différer. Comme ci-dessus, considérez cette donnée comme l'un des facteurs qui pèsent sur la décision globale que vous devez prendre concernant l'entreprise.

Bonne chance!

dreamcatcher
2017-11-13 15:44:12 UTC
view on stackexchange narkive permalink

Il n'y a aucune condition pour qu'une entreprise n'utilise pas le contrôle de source sauf une. C'est alors qu'ils essaient d'embaucher quelqu'un pour implémenter le contrôle de code source. Donc, si vous interviewez pour le poste pour implémenter le contrôle de source, ok, allez-y. Sinon, vous pouvez faire mieux.

Charles E. Grant
2017-11-13 12:21:30 UTC
view on stackexchange narkive permalink

La première chose que vous devriez faire après avoir entendu ceci est de vous renseigner davantage et de découvrir pourquoi diable non.

En fin de compte, ne pas utiliser le contrôle de source est simplement un point de données sur l'entreprise. Cela n'établit absolument rien. Cela vous donne une idée assez forte du fait que les développeurs de cette entreprise ne sont pas très expérimentés, ou pas très disciplinés, ou qu'il y a quelque chose de très idiosyncratique dans leur processus de développement, dont chacun est un motif de préoccupation majeur. Selon la situation, il peut s'agir d'une lumière rouge clignotante ou d'autres facteurs peuvent l'emporter sur cela. Par exemple, ils pourraient avoir un plan d'affaires absolument génial, mais vous êtes le premier développeur expérimenté qu'ils ont embauché.

D'accord.Même sans contrôle de source, je veux dire, passer des fichiers zip?Même utiliser des fichiers réseau partagés et (légèrement mieux) les copier localement serait plus facile (bien que toujours terrible).Ne savent-ils même pas cela?
illustro
2017-11-13 16:23:38 UTC
view on stackexchange narkive permalink

Il existe des environnements de développement de logiciels spécifiques à l'industrie qui empêchent l'utilisation d'un système de contrôle de version programmatique (comme git ou svn).

Dans ces cas, j'attendrais (en tant qu'employé potentiel) de l'entreprise qu'elle ont un processus manuel de contrôle des versions des versions de logiciels afin de contrôler les versions de leurs logiciels.

Il y a une grande différence entre pas de contrôle de version et ne pas utiliser une solution comme svn ou git.

Par exemple, dans l'espace de développement logiciel du secteur de l'assurance, les plus grands progiciels de modélisation financière nécessitent un codage pour modéliser l'activité d'une entité donnée, mais ne se prêtent pas du tout à un système de type SVN .

Les exigences d'audit, cependant, exigent généralement la mise en œuvre d'un système de contrôle de version plus manuel pour ces modèles.

J'ai travaillé pour une compagnie d'assurance (quoique pour une courte période) et cela ne me dit rien.Mais j'ai pu voir comment les scripts VBA dans une feuille Excel ne sont pas facilement placés sous contrôle de code source.Encore un drapeau rouge - de tels scripts VBA sont connus pour être problématiques du point de vue de la maintenance logicielle.
@MSalters le logiciel que je fais référence (logiciels de modélisation actuarielle pacakages) ont des problèmes similaires au contrôle de version d'un tableur Excel / VBA, car ils sont à la fois un environnement de développement et un environnement d'exécution de modèle de production.Pourtant, il est nécessaire qu'un progiciel comme celui-ci soit utilisé pour évaluer l'activité d'assurance qu'une entreprise a vendue.(Le logiciel de base fournit des fonctionnalités [comme le traitement distribué] qui ne devraient pas être développées en interne dans une compagnie d'assurance)
Kilisi
2017-11-13 12:01:52 UTC
view on stackexchange narkive permalink

C'est uniquement à l'entreprise de décider si elle souhaite utiliser le contrôle de version ou non. Si c'est quelque chose dont vous ne pouvez pas vous passer, refusez le travail.

Si leur réseau est correctement construit, contrôle de version en termes de git, etc. n'est pas nécessaire. Je n'utilise ni l'un ni l'autre mais j'ai une solution d'ingénierie à la place.

Je ne suis pas sûr que ce ne soit pas une info-overkill pour cette SE, mais j'aimerais sûrement en savoir un peu plus sur cette solution ...
Au fond, c'est très simple, je peux tout extraire des sauvegardes automatiques qui sont toutes horodatées et les interactions des utilisateurs sont toutes enregistrées, donc cela réalise à peu près la même chose.Je peux ramener un logiciel là où il était hier ou là où il se trouvait il y a 5 ans à une date précise avec des sauvegardes normales.Si les développeurs font des sauvegardes manuelles supplémentaires, je peux être encore plus précis.
Hmm ... Je me souviens du système de fichiers VMS que j'ai utilisé il y a longtemps.Même si j'ai hâte d'ouvrir une énorme discussion sur les sauvegardes automatiques et le contrôle de version formel, je serai un bon citoyen et je vous remercie simplement pour l'info.;RÉ
@akaioi, assurez-vous simplement de sauvegarder votre contrôle de version formel;)
Les bonnes sauvegardes ne remplacent pas le contrôle de version et le contrôle de version ne remplace pas les bonnes sauvegardes.Ils servent des objectifs différents.
@Kilisi Mais pouvez-vous vérifier rétrospectivement pourquoi le changement a été effectué?Ou vous savez que la régression s'est produite et vous voulez présélectionner les changements en fonction de ce qu'ils font?Si quoi que ce soit d'autre, le VCS fournit des outils standard pour faire de telles choses.
Une si mauvaise réponse.OP veut élargir ses connaissances et sa compréhension des pratiques dans l'industrie, et vous répondez par "si vous ne l'aimez pas, passez à autre chose".
@MaciejPiechotka oui, je ne vais pas dire que ce n'est pas nécessaire dans de nombreuses petites entreprises.La plupart des entreprises n'écrivent pas de gros logiciels.
C'est un conseil horrible.Le contrôle de version est très important, même pour une entreprise qui ne produit qu'une petite quantité de logiciels.Sinon, comment pourriez-vous suivre le moment où vous avez apporté une modification ou faire quelque chose comme créer de nouvelles branches et les fusionner plus tard?Je n'irais pas près de n'importe quel endroit qui me disait d'utiliser des sauvegardes comme contrôle de version.
@ayrtonclark beaucoup de gens ne sont pas si stupides qu'ils ne peuvent pas savoir quand ou pourquoi ils ont fait un changement ...
@Kilisi pour que vous me disiez que vous pouvez vous souvenir de chaque changement que vous avez fait au cours des 5 dernières années?Qu'en est-il des changements apportés par d'autres membres de l'équipe, ou même des personnes qui y ont travaillé avant votre arrivée?Ne répond pas non plus au reste de mon commentaire.
@async pour être juste, OP ne pose * pas * de questions sur les meilleures pratiques ... il demande à quel point le manque de contrôle de code source devrait être important, du moins c'est ainsi que je lis la question.Je me méfie un peu de l'approche de Kilisi, mais ce n'est pas l'objectif principal (j'aimerais voir une discussion de son approche sur un forum au format de discussion ouverte, mais ce n'est pas l'endroit).
@Kilisi Il ne s'agit pas d'être "si stupide".Les systèmes de contrôle de source ont des opérations comme «blâme» qui vous permettent de voir ligne par ligne qui a changé quelles parties d'un fichier et pourquoi.Ils ont des mécanismes de branchement et de versionnage afin que vous puissiez avoir des conversations cohérentes sur la version du code que chacun possède et vous pouvez tester et distribuer les modifications proposées.C'est une chose de dire que vous avez personnellement décidé que les frais généraux de ces outils dépassent les avantages pour votre projet, c'est votre jugement, mais il est carrément faux d'insinuer qu'un est stupide de les vouloir.
@ZachLipton Je ne suis pas un développeur Je suis un ingénieur, je peux me souvenir de chaque changement majeur que j'ai fait et les plus petits n'ont pas vraiment d'importance tant que je sais pourquoi quelque chose fonctionne correctement.Mais ce n'est pas pour toutes les entreprises bien sûr.J'imagine que s'il y avait plusieurs développeurs travaillant sur une chose qui ne communiquent, ne documentent ou ne se souviennent de rien, un contrôle de version serait utile pour chercher qui blâmer lorsque tout s'effondre.


ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...