Kann ein guter Programmierer noch nie die Versionskontrolle verwendet haben? [geschlossen]

Ich suche einen erfahrenen Programmierer, um eine schwierige Situation zu lösen.

Die bisherigen Interviews waren überraschend enttäuschend. Der beste Kandidat ist bisher ein sehr erfahrener Programmierer, der noch nie eine Versionskontrollsoftware verwendet hat.

Das Problem selbst ist möglicherweise nicht allzu ernst, da es in kurzer Zeit erlernt werden kann.

Aber es gibt einen tieferen Aspekt, der mich beunruhigt:

Wie ist es möglich, Software für 10-15 Jahre aktiv zu entwickeln, ohne jemals eine Versionskontrolle zu benötigen?

Ist die Tatsache, dass nicht nach einer Lösung für das Problem der Nachverfolgung von Änderungen gesucht wird, ein Zeichen einer falschen Einstellung zur Programmierung?

Ich habe ungefähr 11 Jahre in Unternehmen gearbeitet, die keine Quellcodeverwaltung verwendet haben. Wir haben es geschafft (hauptsächlich durch Kommentieren von Änderungen und Speichern von Code auf einem zentralen Server, der zu jedem Zeitpunkt wiederhergestellt werden konnte). Wir haben nie wirklich gefragt, ob es einen besseren Weg gibt. Das war allerdings auch in den Tagen, als ich die gesamte MSDN-Bibliothek in Buchform auf meinem Schreibtisch hatte.

Ja, es gab eine Programmierung vor dem Internet.

Ich bemühe mich zu sehen, wie Sie jetzt mehr als 10 Jahre in der Branche verbringen können, ohne in die Quellcodeverwaltung geraten zu sein. Aber ich hätte ein gewisses Mitgefühl, ich würde glauben, dass es möglich ist, und ich würde den Kandidaten nicht allein in diesem einen Detail ablehnen. Ich würde untersuchen und herausfinden, wie der Kandidat dies geschafft hat.

Alternativ könnte ich fragen, ob mein Interviewprozess das Problem war. Inwiefern war er der beste Kandidat? Gibt es andere moderne Programmiertechniken, die er nicht hat, für die ich nur nicht die richtigen Fragen stelle? Wenn ich die richtigen Fragen stellen würde, würde ein anderer Kandidat glänzen?

Scheuen Sie sich jedoch nicht, alle Kandidaten abzulehnen, wenn Sie Bedenken haben. Es ist zeitaufwändig, von vorne zu beginnen, aber es ist zeitaufwändiger, die falsche Person einzustellen.

Ich denke, es hängt von seiner Einstellung ab. Wenn er ein sehr erfahrener Programmierer und ein guter Programmierer ist, würde er meiner Meinung nach in der Lage sein, ein Versionskontrollsystem schnell zu erlernen. Er kann auf zwei Arten darüber sprechen:

• Gut

  Ich habe noch nie die Versionskontrolle verwendet, bin aber sehr aufgeregt zu lernen, und es scheint wirklich hilfreich zu sein, die Entwicklung effizienter zu gestalten. Ich habe es nicht so sehr gebraucht, weil ich alleine an Projekten gearbeitet habe.

• Schlecht

  Versionskontrolle ist nur ein Schlagwort, das in der Industrie langsam stirbt. Ich bin über der Versionskontrolle.

Lassen Sie mich Ihnen einen Einblick in die Softwareentwicklung unter DOS und Windows geben.

Versionskontrollsoftware in der Windows / PC-Welt war Anfang der 90er Jahre oft unzuverlässig. Visual Sourcesafe (VSS) war das beste Windows-basierte Programm, das es gibt, aber es könnte eigenartig sein und viele Programmierer hassten es. Einige Teams würden ihren Einsatz einfach nicht unterhalten, nachdem sie sich mit dieser Situation befasst haben.

Die meisten anderen VCS-Optionen waren zu diesem Zeitpunkt nicht Windows-basiert und wurden daher in Windows-Entwicklungsteams nur selten verwendet. Einige davon waren teure Lösungen, und Open Source-Lösungen wurden nicht so schnell akzeptiert wie heute.

In vielen Fällen, in den späten 90ern und frühen 00ern, nutzte ein Windows-Team ohne VSS abgesehen von internen Konventionen nichts für die Quellcodeverwaltung. Einige von ihnen verwenden trotz der Raffinesse von Team Foundation Server (TFS) und großartiger kostenloser Optionen wie Git und SVN immer noch kein VCS.

Es ist möglich, dass jemand, der jahrelang in einem kleinen Windows-Entwicklungsteam gearbeitet hat, kein VCS verwendet hat. Ich habe an einigen Orten, an denen sie nicht verwendet wurden, oder an Orten, an denen ihre Verwendung sehr willkürlich war, befragt und sogar Auftragsarbeiten durchgeführt.

Ich glaube nicht, dass die mangelnde Erfahrung Ihres Kandidaten in diesem Bereich ein definitives Nein ist, aber Sie möchten wahrscheinlich mehr über seine vorherige Arbeitssituation erfahren, um herauszufinden, warum dies in seiner Erfahrung fehlt. Sie sollten auch ihre Einstellung zur Versionskontrolle untersuchen. Halten sie es für eine gute Idee, aber sie durften es nicht an ihrer vorherigen Position weiterverfolgen, oder halten sie es für Zeitverschwendung?

Können Sie keine Versionskontrolle ohne Versionskontrollsoftware haben? Fragen Sie, wie sie ihren Code verwaltet haben. Vielleicht gab es bereits ein eigenes System.

Manuell arbeiten zu wollen, das Rad neu zu erfinden und sich nicht zu verändern, ist für die Programmierung nichts Neues. Werden Sie über einen Kandidaten sabbern, der Visual Source Safe und "nur" VSS verwendet?

Wenn Sie versuchen, Talente zu finden, müssen Sie in der Lage sein, den Unterschied zu erkennen zwischen: nicht, nicht und nicht.

Es gibt keine Entschuldigung dafür, die Versionskontrolle nicht zu verwenden, auch nicht für ein kleines Projekt, das von einem einzelnen Entwickler entwickelt wurde. Das Einrichten der lokalen Versionskontrolle ist nicht trivial, hat enorme Vorteile. Jeder Entwickler, der nicht weiß, dass dies weder als gut noch als erfahren angesehen werden kann.

Unternehmen, die die Versionskontrolle als "Neuheit" betrachten und nicht bereit sind, Folgendes einzuführen:

• SCCS wurde 1972 veröffentlicht (vor 40 Jahren )
• RCS wurde 1982 (vor 30 Jahren ) veröffentlicht und ist komplett Open Source und kostenlos
• CVS wurde 1990 (vor 21 Jahren ) veröffentlicht, ebenfalls komplett Open Source und kostenlos

Ein Programmierer, der noch nie die Versionskontrolle verwendet hat, hat wahrscheinlich noch nie mit anderen Programmierern zusammengearbeitet. Ich würde wahrscheinlich niemals in Betracht ziehen, einen solchen Programmierer einzustellen, unabhängig von irgendwelchen anderen Anmeldeinformationen.

Scheint in Ordnung wie eine rote Fahne, geht aber tiefer darauf ein, warum er sie nicht benutzt hat. Ich würde immer noch erwarten, dass ein Solo-Entwickler die Versionskontrolle in zehn Jahren einsetzt, aber ich würde es eher verzeihen, als wenn er in einem Team arbeiten würde und nicht einmal versucht hätte, die Versionskontrolle einzuführen.

Ich wäre nicht religiös über mangelnde Erfahrung in der Versionskontrolle. Es ist nur ein Werkzeug. Am Ende können Sie in ein oder zwei Tagen die Grundlagen von svn oder git erlernen. Den Rest werden Sie mit der Zeit abholen. Und ich kann nicht glauben, dass ein halbwegs anständiger Kandidat nicht dazu passen würde, wenn er in einer Umgebung arbeiten würde, in der die Quellcodeverwaltung zum Einsatz kommt.

Die Verwendung der Quellcodeverwaltung ist eher eine Gewohnheit als eine Fertigkeit. Jemand, der es noch nie benutzt hat, kann den erforderlichen Aufwand übertreiben und den erzielten Nutzen unterschätzen. Immerhin hat er sich bis jetzt gut geschlagen. Erst wenn er die Quellcodeverwaltung tatsächlich verwendet, wird er sie zu schätzen wissen.

Die Frage, die Sie sich stellen sollten, ist, wie er es ohne Quellcodeverwaltung geschafft hat. Dies könnte Ihnen etwas über ihn erzählen und wie er seine Arbeit verwaltet.

Sie hinterlassen viele Informationen über seine Erfahrungen.

Grundsätzlich würde ich sagen, dass es sehr wahrscheinlich ist, dass ein Programmierer 10-15 Jahre Erfahrung hat, ohne etwas über die Versionskontrolle wissen zu müssen. Codierung für 10 Jahre ist nicht gleichbedeutend damit, 10 Jahre lang ständig neue Programmiertechniken zu erlernen.

Ich bin sehr jung und habe alte und "erfahrene" Software-Ingenieure gesehen, deren Code ich niemals anfassen möchte. Das heißt, er könnte sehr talentiert sein, aber ich würde aufgrund der wenigen Informationen vermuten, dass er es nicht ist.

Viel Glück.

Das Beunruhigendste für mich persönlich ist, dass der Kandidat entweder noch nie auf Versionskontrollsysteme als Konzept gestoßen ist oder entschieden hat, dass es sich nicht lohnt, sie zu verwenden. Ich halte das erste Szenario für sehr unwahrscheinlich, aber wenn dies der Fall ist, gehe ich davon aus, dass der Kandidat für die Dauer seiner Karriere erheblich isoliert war, was ernsthafte Zweifel an seinem Wert als Teil eines Teams aufkommen lassen würde. Insbesondere können sie sehr bizarre Konzepte darüber haben, wie bestimmte Dinge zu tun sind, und keine der "richtigen" Methoden kennen, um Dinge zu tun.

Wenn es der zweite Fall ist, in dem sie sich aktiv gegen die Versionskontrolle entschieden haben, gehe ich davon aus, dass sie entweder nie an etwas von Bedeutung gearbeitet haben oder extrem arrogant sind. Oder sie haben bestenfalls schreckliche Möglichkeiten, Code zu pflegen, z. B. Blöcke zu kommentieren und jede Codezeile einem Autor, einem Datum und einer Fehlernummer zuzuweisen.

Ich sehe hier einige eher wertende Antworten, die die beurteilte Person nicht wirklich berücksichtigen.

Ich persönlich halte Versionskontrollsoftware für ein unschätzbares Werkzeug. Wir haben jedoch nicht alle die Wahl und Kontrolle über die Tools und Prozesse, die in unseren Arbeitsumgebungen verwendet werden. Ich arbeite seit 1990 in der Windows-Entwicklung. Wie von anderen veröffentlicht, war zu dieser Zeit für VCS in Windows nicht viel verfügbar. Wir wollten keine UNIX-Server einführen, nur um ein VCS zu erhalten. Hat mich das zu einem schlechten Programmierer gemacht? Später in meiner Karriere arbeitete ich für ein Unternehmen mit einem kommerziellen Produkt für vertikale Märkte, bei dem die Versionskontrolle ein Prozess und kein Werkzeug war. Hat mich das zu einem schlechten Programmierer gemacht? Meine letzten drei Jobs waren alle stark von VCS-Tools abhängig. Macht mich das zu einem guten Programmierer?

Es wäre großartig, wenn wir alle nur die neuesten und besten Tools, Sprachen und Technologien verwenden könnten. Aber der Beruf der Softwareentwicklung funktioniert nicht immer so. Es ist ein wenig idealistisch zu sagen: "Ich würde den Job sofort verlassen, wenn sie nicht ..." oder "Ich würde niemals einen Job annehmen, der nicht genutzt wird ..." oder "Ich würde sie zwingen, diesen Job zu nutzen." .. ". Wir sind nicht alle von einem unendlichen Angebot an Stellenangeboten umgeben, bei denen alles genau so funktioniert, wie wir es möchten. Wir müssen Rechnungen bezahlen und brauchen einen Job, also kümmern wir uns um das, was uns umgibt.

Am Ende lautet die Antwort auf Ihre Frage: Beurteilen Sie diesen Programmierer nach seinen Fähigkeiten, seinen Philosophien und seinen Entscheidungen, nicht nach den (möglicherweise fehlgeleiteten) Entscheidungen, die die Verantwortlichen in seinen früheren Jobs getroffen haben.

Ich habe mich nie als "Programmierer" betrachtet, bis ich anfing, damit professionell Geld zu verdienen.

Ich habe viel Geld mit der Erstellung von Systemen verdient, mit denen Kunden noch mehr Geld verdienen. Ob ich ein "guter" Entwickler bin oder nicht, ist subjektiv.

Ich kann GSD (Get Something Done Done) schnell ausführen, was für die Webentwicklung normalerweise meine Kunden erfreut. Möglicherweise sehen sie hinter den Kulissen keinen hässlichen Code, fehlende Kommentare usw.

Ich hatte Git nicht benutzt und hatte bis zu diesem Jahr kein Github-Profil, was meiner Meinung nach in Bezug auf moderne Programmierstandards "hinter der Zeit" liegt. Ich habe auch gerade angefangen, Rails- und Django-Projekte zu machen, nachdem ich in der Vergangenheit nur PHP, Flash und iOS gemacht habe. Seitdem ich Verträge über die Entwicklung von Websites sowohl für Kunden als auch für mich abgeschlossen habe, war es nicht allzu schmerzhaft, im Alter von 30 Jahren und ein paar Jahren außerhalb des Programmierens etwas Neues zu lernen.

In der modernen Gesellschaft liegt der Schwerpunkt zu sehr darauf, mit Jones Schritt zu halten und sich darum zu kümmern, was andere Menschen denken. Wenn Sie diese Fesseln abbrechen und überlegen können, was Sie für Ihre Softwareentwicklung benötigen (Geschwindigkeit / Time-to-Market, optimiertes Ressourcenmanagement, gut dokumentierter Code, Skalierbarkeit usw.), ist dies möglicherweise weitaus wichtiger als die Frage, ob jemand Mercurial oder SVN kennt , Git oder andere Versionskontrollsysteme.

Ich ziehe es vor, Entwicklerkandidaten zu fragen, was sie für eine Leidenschaft haben, was das coolste System ist, das sie je in ihrer eigenen Meinung entwickelt haben, und was sie in ihrer Freizeit verwenden, um ihre Fähigkeiten zu entwickeln. das macht mir mehr angst als anderen dingen, bedeutet aber nicht, dass es dir angst machen muss.

Ich denke, Sie haben bereits einige gute Antworten auf diese Frage von den Leuten hier, und das sollte Ihnen helfen, Ihre eigene fundierte Entscheidung basierend auf Ihren Anforderungen zu treffen.

Ich finde es unglaublich, dass ein Softwareprofi noch nie die Quellcodeverwaltung verwendet hat, und ich bin sehr nervös, ihn einzustellen.

Welche Erfahrung hat er? Ich würde mich fragen, was er sonst noch nicht weiß, was du bisher noch nicht rausgefunden hast.

Welche Erfahrungen haben Sie in der Softwareentwicklung gemacht? Können Sie ihn nach Architektur, Entwurfsmustern, allgemeinen Problemen bei der Softwareentwicklung, Fragen zur Systemleistung, zur Systemsicherheit usw. fragen?

Wenn er sich mit solchen Dingen stark machen würde, könnte ich vielleicht den Mangel an Kenntnissen über die Quellcodeverwaltung übersehen.

Kann ein guter Programmierer noch nie die Versionskontrolle verwendet haben?

Ja. Viele kleine Unternehmen mit Autodidakten verwenden es nicht.

Wie ist es möglich, Software für 10-15 Jahre aktiv zu entwickeln, ohne jemals eine Versionskontrolle zu benötigen?

Ich habe 2 kleinen Unternehmen die Versionskontrolle persönlich vorgestellt, ein mittelständisches Unternehmen von etwas Schrecklichem auf SVN (die beste Option zu der Zeit) aktualisiert und in einem anderen kleinen Unternehmen gearbeitet, das nur einige VCs hatte, für einige Codes eine eigene VC-Lösung geschrieben und Hatte viel Code einfach nicht in irgendeiner VC.

Ist die Tatsache, dass nicht nach einer Lösung für das Problem der Nachverfolgung von Änderungen gesucht wird, ein Zeichen einer falschen Einstellung zur Programmierung?

Nun, es ist kein sofortiger Misserfolg, aber ich würde mit Sicherheit viele weitere Fragen stellen. Dinge wie:

Haben Sie jemals eine VC-Software ausprobiert? Was? Was hast du darüber gedacht? Gibt es einen Grund, warum Sie es nicht benutzen würden? Was haben Sie zuvor verwendet, um Code zu verwalten? Haben Sie schon einmal mit jemandem auf derselben Codebasis gearbeitet und mit welchen Methoden haben Sie Konflikte vermieden?

Ich würde gerne Explosion Pills zustimmen (aber meine Wiederholung ist zu niedrig, atm ...) ... Haltung ist viel wichtiger.

Es gibt ein paar Dinge, nach denen ich glaube, dass sie für exzellente Programmierung sorgen:

1. Kommunikation
2. Kreativität
3. Mitgefühl (sag was?)

Und oft mehr als eine kleine Zwangsstörung.

Sie kennen den Typ ... diejenigen, die da sitzen und sich auf ein Problem einlassen und sich in ihrem Code verlieren, während sie nach Optionen suchen. Dies sind diejenigen, die sich Notizen machen, Kommentare in ihrem Code hinterlassen, um sicherzustellen, dass sie ihre eigenen logischen Pfade verstehen (und den Weg für sich selbst oder andere Programmierer aufzeigen, die möglicherweise in Zukunft mit dem Code umgehen müssen. .. also "Mitgefühl" in meiner obigen Liste!) und vermitteln Entscheidungsträgern in der Kette schnell und klar komplexe Ideen, damit Probleme effizient angegangen werden können.

Ein ausgezeichneter Programmierer kann jahrelang in einer Umgebung stecken geblieben sein, die sich entweder nicht mit der Idee von VCS einverstanden erklärt hat, schlechte Erfahrungen mit VCS gemacht hat (a la VSS), die sie scheu gemacht haben, neue Systeme auszuprobieren, aber das würde ich garantieren Ein ausgezeichneter Programmierer in dieser Situation hätte immer noch eine Art Routine eingerichtet, um sich davor zu schützen, all seine Arbeit durch ein paar schlechte Design-Iterationen zu verlieren.

Die Art von Programmierer, vor der man sich in Acht nehmen muss, ist derjenige, der behauptet, niemals ein VCS oder eine Maßnahme zum Schutz vor unvermeidlichen Fehlern benötigt zu haben . Ihre Haltung ist eine der folgenden: "Nun, ich habe es gebaut, deshalb kann es nicht falsch sein." Das sind die, vor denen ich mehr Angst habe als vor Anfängern, da Anfänger lernen können, die Stärken von VCS zu schätzen, weil sie erkennen, wie wenig sie tatsächlich wissen.

Wie ist es möglich, Software für 10-15 Jahre aktiv zu entwickeln, ohne jemals eine Versionskontrolle zu benötigen?

Wenn er aus alten Schulteams kommt, in denen kleine Projekte von einer einzelnen Person verwaltet werden, ist dies sehr gut möglich. Möglicherweise verfügt er über 10 Jahre Erfahrung mit derselben Technologie, ohne etwas zu lernen und sich selbst zu verbessern.

Ist die Tatsache, dass nicht nach einer Lösung für das Problem der Nachverfolgung von Änderungen gesucht wird, ein Zeichen einer falschen Einstellung zur Programmierung?

Wenn sich Ihr Kandidat in einer Team-Entwicklungsumgebung befunden hat (mindestens 4 oder mehr Programmierer), ist dies eine triviale Frage. Es kann jedoch zu einer Arbeitsteilung zwischen Programmierern kommen, die nur an ihnen zugewiesenen Modulen arbeiten, wodurch die Notwendigkeit einer Quellcodeverwaltung verringert werden kann.

Es ist jedoch eine wirklich überraschende Situation, im Internet-Zeitalter nichts über die Quellcodeverwaltung zu hören . Daher würde ich seine Bereitschaft prüfen, neue Dinge zu lernen (in Bezug auf Ihre Entwicklungsumgebung) und wie offen er für ein dynamisches Arbeitsumfeld ist.

Erfahrung ist wichtig und Sie haben Recht, dass die Mechanismen der Verwendung von Versionsverwaltungs-Tools ziemlich schnell erlernt werden können. Aber Sie haben Recht, eine rote Fahne zu sehen.

• Ist Ihr Kandidat vom Beruf und seinen Trends isoliert?
• Müssen auch die vielen anderen Aspekte der Teamarbeit gelernt werden?

Für mich ist das Problem der Versionskontrolle eher ein Symptom als die Krankheit. Die Ursache kann variieren und ziemlich harmlos sein. Viele Ad-hoc-Programmierer haben gerade erst angefangen, das zu tun, was sie für sinnvoll hielten, angefangen mit ein paar Büchern über Programmierung, und keine systematische Untersuchung der Softwareentwicklung durchgeführt. Manchmal, früher noch häufiger, schlossen Informatik-Majors ab, ohne jemals ein Quellcodeverwaltungssystem verwendet zu haben, da alle ihre Projekte Einzelprojekte waren und sie zu Unternehmen gingen, die einen hochgradig unausgereiften Softwareprozess hatten.

Er hat es jedoch geschafft, wenn er seit einem Jahrzehnt oder länger ein Einzelgänger ist, kann es schwierig sein, mit Menschen zu leben.

Es könnte sich lohnen zu fragen, ob Ihr Kandidat noch ein paar Sondierungsfragen hat.

• Erzählen Sie mir von einer Zeit, in der Sie als Teil eines Teams gearbeitet haben?
• Erzählen Sie mir von einer Zeit, in der ein Team, an dem Sie gearbeitet haben, einen Konflikt zwischen Teammitgliedern hatte?
• Erzählen Sie mir von einer Zeit, als Sie Code von einem anderen Entwickler erhalten und sein Projekt vorangebracht haben?
• Sagen Sie mir, wie Sie und andere Mitglieder Ihres Teams beim gemeinsamen Erstellen von Code voneinander abgehalten wurden.
• Erzählen Sie mir von einem vom Kunden gemeldeten Problem mit einer Funktion, die früher funktioniert hat, in einer späteren Version jedoch nicht funktioniert hat. Wie hast du das gelöst?
• Was magst du an der Arbeit im Team?

Er ist möglicherweise auch daran gewöhnt, seine Methoden und Prozesse nahezu vollständig zu kontrollieren und in einer Rolle zu arbeiten, in der er der einzige Software-Experte ist. Sie wollen jemanden, der offen für neue Dinge ist. Mehr Fragen:

• Erzählen Sie mir von einer Zeit, die Sie für die Erstellung eines Codierungsstandards verwendet oder mitgeholfen haben?
• Welche Art von Dingen möchten Sie in einem Codierungsstandard sehen?
• Wie steht es mit dem Umschreiben des Codes eines anderen?
• Erzählen Sie mir von einer Zeit, als Sie an Peer-Reviews von Software oder Dokumentation teilgenommen haben?
• Können Sie mir über ein Angebot oder einen Vertrag für die Softwareentwicklung erzählen, an dem Sie schriftlich beteiligt waren?
• Erzählen Sie mir von Ihrem bevorzugten Software-Manager oder Supervisor?
• Erzählen Sie mir von Ihrem Lieblingsmitarbeiter oder Untergebenen?

Im Jahr 2012 ist es für jemanden mit 15 Jahren Branchenerfahrung eine rote Fahne, niemals die Versionskontrolle verwendet zu haben. Wenn das Jahr 1982 oder sogar 1992 war, könnte es keine so rote Fahne sein. Aber heute sollte es eine ausgezeichnete Erklärung für diese rätselhafte Lücke im Hintergrund des Entwicklers geben.

Außergewöhnliche Situationen erfordern außergewöhnliche Erklärungen.

Das ist ein bisschen wie bei einem Automechaniker, der behauptet, er habe 15 Jahre lang Autos repariert, aber noch nie so viel Fett auf sich gebracht.

Wenn Sie sich mit Fett schmieren, wird das Getriebe natürlich nicht repariert, und keiner der Schritte in der Reparaturanleitung verlangt dies, aber das ist nicht der Punkt. Der Punkt ist, dass blitzsauber zu sein klaffend unvereinbar ist mit dem, wie Automechaniker tatsächlich aussehen, wenn sie arbeiten. Bei dieser Arbeit fetten Sie sich.

Wenn Sie einen erfahrenen Interviewer befragen, der zugibt, dass er keine Erfahrung mit der Versionskontrolle hat, übertreibt oder fabriziert er wahrscheinlich einen Teil seiner Erfahrungen (und weiß nicht einmal, dass die Versionskontrolle etwas weit verbreitetes und wichtiges ist und worüber er auch lügen sollte! )

Es ist möglich, alle Arten von Jokern in Interviews zu sehen. Ich habe Leute gesehen, die kein Diagramm einer verknüpften Liste zeichnen oder keine Funktion schreiben können, die einen Knoten am Anfang einer verknüpften Liste einfügt. Sie haben jedoch 20 Jahre Berufserfahrung vorzuweisen.

Selbst für neue Absolventen der Informatik ist eine passive Vertrautheit mit der Versionskontrolle zu erwarten, auch wenn sie diese noch nicht umfassend genutzt haben.

Ich würde es seltsam finden, aber für ein erfahrenes Programm ist es nicht unmöglich, niemals eine dedizierte Quellcodeverwaltung zu verwenden. In einer Firma, mit der ich zusammengearbeitet habe, haben sie die Quellcodeverwaltung ausgiebig für ihren traditionellen C # - und VB-Code verwendet. Der reine Datenbankcode (gespeicherte Prozeduren und Skripts sowie Tabellendefinitionen) befand sich jedoch nicht in der Quellcodeverwaltung, obwohl zwei professionelle SQL-Entwickler den Hauptauftrag hatten, reinen Datenbankcode zu schreiben, zu warten und auszuführen. Ich habe mich für die Quellcodeverwaltung der dortigen Datenbankentitäten stark gemacht und war nur teilweise erfolgreich.

Bei einem anderen Unternehmen war das Entwicklungsteam klein (ein Mann kaufte lange, dann zwei). Bei der Quellcodeverwaltung des vorherigen Entwicklers wurden mehrere Kopien der Quelldateien mit einem Datum am Ende hinzugefügt. Abgesehen davon, dass es kein besseres Quellcodeverwaltungssystem gab, war mein Vorgänger auf jeden Fall kompetent und ein kluger Mann.

Bevor ich Profi wurde, war ich ein Hobbyist und benutzte überhaupt keine Quellcodeverwaltung. Ich wusste vage, was es war, störte mich aber nicht.

Kurz gesagt, ich finde es seltsam, dass ein Profi damit nicht sehr vertraut ist, aber vor allem, wenn er an sehr kleine Teams gewöhnt ist, ist es sicherlich möglich, kompetent zu sein, ohne es. Bei der Einstellung würde ich ihm das nicht vorenthalten. Ich würde es absolut ablehnen zu lernen und anfangen, es im Beruf gegen ihn einzusetzen ...

Mein 2c ist, dass es davon abhängt, wie er auf die Frage nach VC reagiert. Die möglichen Reaktionen könnten sein:

1. Huh? Was ist das
2. Nein, wir haben stattdessen
3. Kein peinliches Durcheinander , das Management würde es uns nicht erlauben
4. Kein peinliches Durcheinander , aber ich habe mich selbst ein wenig umgesehen und dachte, es sieht so aus, als ob wir etwas tun sollten.

Bei 4 würde der Typ einen Pass von mir bekommen, er hat die richtige Einstellung und wird ihn wahrscheinlich gut aufnehmen. Im Fall von 3 bekommt er Anerkennung für das Verständnis, dass es etwas ist, das getan werden sollte, aber nicht so viel Anerkennung wie 4. Wenn er ein paar Faktoids über VC benennen könnte (liste einige der VC-Pakete da draußen auf) I ' Ich nehme das als Beweis für eine gewisse Neugier und könnte ihn überholen.

Wenn er auf 1 oder 2 antwortete, das heißt, wenn er VC kannte und nicht kannte, würde ich das Urteil des Kandidaten ernsthaft in Frage stellen. Es wird andere Tools geben (Fehlerverfolgung, Qualitätsmetriken, Build-Automatisierung usw. usw.), mit denen er arbeiten muss, und Sie werden wahrscheinlich feststellen, dass Sie in all diesen Fragen einen harten Kampf haben, wenn er nicht bereit ist, neue zu probieren Ansätze.

Wie die meisten Leute hier finde ich es unfair, den Kandidaten zu benachteiligen, nur weil sein Arbeitgeber nicht auf dem neuesten Stand war. Für mich hängt alles davon ab, wie sie darauf reagiert haben.

Wenn man zurückblickt, ist es gut zu schreiben, was sich geändert hat. Ich habe viele Male gespart, als ich herausgefunden habe, was los ist, und viele Probleme wurden schnell behoben, weil ich sie aufschreiben ließ. Meiner Meinung nach ist es gut, ein Protokoll zu führen. Vor allem, wenn Sie mit mehr Leuten als Ihnen selbst programmieren.

Wenn Sie eine Web-App schreiben, können Sie weiterhin Funktionen ohne Versionskontrolle hinzufügen, da Sie ständig neue Funktionen hinzufügen. Aber vielleicht schreibst du ein Protokoll oder einen Nachrichtenbeitrag mit den Dingen, die neu sind.

Es geht nur darum, worauf Sie programmieren.

Ich habe an Orten gearbeitet, an denen der Genehmigungsprozess für Software 12 bis 18 Monate dauerte. Wenn es nicht bereits in der Liste der zugelassenen Software enthalten war, gab es keine Möglichkeit, es auf die Computer zu übertragen. CD / DVD-Laufwerke wurden gesperrt und die Computer waren nicht mit dem Internet verbunden.

Der erste Punkt, an dem ich in die Quellcodeverwaltung geriet, war, dass ein Entwickler seine eigenen schrieb, als das mehrjährige Projekt zum Testen fertig war. Sie spielten darauf, dass das Schreiben von Grund auf schneller war als der Genehmigungsprozess.

Der zweite Ort, an dem ich auf dieses Problem gestoßen bin, hat in den ersten Monaten die Quellcodeverwaltung verwendet, aber dann wollte der Kunde, dass die gesamte Entwicklung in seinem internen Netzwerk durchgeführt wird. Sie haben wieder alles gesperrt, so dass es wieder viele gezippte Ordner gab.

Ich kenne Entwickler, die nur unter diesen Bedingungen gearbeitet haben. Sie möchten diese Tools verwenden, sie würden diese Tools gerne verwenden, aber sie dürfen diese Tools nicht verwenden.

Untersuchen Sie, warum sie sie nicht benutzt haben. Das Verstehen der Abläufe aufgrund von Null-Erfahrung ist weitaus anders als das Ablehnen der Werkzeuge.

Ich entwickle seit 15 Jahren. Versionskontrolle nur wenige Male verwendet. Ich verwende immer noch meine eigenen geplanten Skripts und Programme, um alle Entwicklungsordner inkrementell zu sichern. Ich weiß nicht, was ich sagen soll, wenn mich jemand fragt, ob ich die Versionskontrolle verwende. Ich habe noch nie ein Versionskontrollsystem gebraucht, ich habe immer an kleinen Projekten gearbeitet. Ich meine, ich bin nicht der beste Programmierer, aber ich bin mir sicher, dass ich nicht der schlechteste bin. Die meiste Zeit ist es mir peinlich, den Leuten zu sagen, dass ich das Versionskontrollsystem nicht regelmäßig benutze, aber so ist es für mich.

Aus meiner Erfahrung als Programmierer auf IBM MVS-Systemen: In den ersten zehn Jahren meiner beruflichen Laufbahn verfügte das Betriebssystem, mit dem ich arbeitete, über genau einen versionierbaren Dateityp: den Generierungsdatensatz. Dies war im Wesentlichen eine Datei mit einer festgelegten Anzahl von Versionen, und Sie mussten sich daran erinnern, welche Version was war - praktisch nutzlos für die moderne Versionskontrolle. In Verbindung mit einem Dateisystem ohne echte Verzeichnisse, nur mit mehr oder weniger (8-stelligen) Qualifikationsmerkmalen, war das Konzept eines Quellcode-Verwaltungssystems für jeden, der in dieser Umgebung arbeitet, völlig fremd.

Ich habe eigentlich kein Quellcode-Kontrollsystem gesehen, bis ich auf SunOS 3 umgestiegen bin und RCS verwendet habe. Zu diesem Zeitpunkt war ich ein äußerst einfacher IBM-Systemprogrammierer, hochproduktiv und in meinem Job sehr gut. Die gesamte Versionierung wurde durchgeführt, indem Backups auf Band kopiert und aufgezeichnet wurden, was wo war.

Wenn ich zu diesem Zeitpunkt noch an Mainframes gearbeitet habe, ist es durchaus möglich, dass ich noch nie einem formalen Versionskontrollsystem ausgesetzt war. Die Alternativen, die speziell unterstützt werden, sind ClearCase und Rational, von denen keine kostenlos ist (und tatsächlich beide recht teuer sind).

Zu sagen, dass jemand per Definition inkompetent ist, weil er oder sie noch nie die Versionskontrolle verwendet hat, ist ein Scheinargument. Es ist notwendig, sich die Details anzuschauen. Wenn sie behaupten, ein Linux / Unix / Mac OS-Entwickler zu sein, aber noch nie die Versionskontrolle verwendet haben, spricht dies weniger für sie, und Sie müssen möglicherweise abwägen, ob ihre Gesamterfahrung so gut passt, dass Sie gewillt wären, dies zu tun schulen sie in moderner Softwareentwicklung. Wenn sie und Mainframe-Programmierer der alten Schule sind - und genau das brauchen Sie -, dann konzentrieren Sie sich darauf, ob sie genau die Programmierkenntnisse haben, die Sie wollen, und geben Sie sich damit ab, dass Sie ihnen dies beibringen müssen. Wie andere gesagt haben, wird in diesem Fall ihre Reaktion auf das Konzept der entscheidende Faktor sein.

Bitte schön! Die gesamte Community lebt nicht in hoch entwickelten sozialen Communities, in denen es zu viele Geek-Hangouts und Hacky-Events gibt. Wir alle arbeiten auch nicht in Softwareentwicklungsunternehmen, und einige von uns können nicht einmal relevante oder aktuelle veröffentlichte Ressourcen finden Lassen Sie sich in unseren Muttersprachen, ob gedruckt oder online, mit einem Programmiererkollegen in Kontakt bringen.

Nach allem, was ich verstehen kann, ist er, wie Sie sagen, ein erfahrener Softwareentwickler, wahrscheinlich ein Einzelgänger, der als Freiberufler für kleine Unternehmen arbeitet.

Es gibt einige mögliche Gründe, die Versionskontrolle nicht zu verwenden:

1. Arbeiten in Unternehmen, die keine Softwareentwicklung als Hauptgeschäftsfeld betreiben.
2. Oder wenn sich der Entwickler für ein anderes System entschieden hat - nur für erfahrene.
3. Oder wenn der Entwickler noch nicht gelernt hat, wie jedes System funktioniert
4. Oder es ist ein Einstellungsproblem gegenüber den Werkzeugen, die sie nicht kennen

Aber Sie sollten vorsichtig sein, wenn Sie Leute treffen, die annehmen:

1. Dass es nur einen Weg gibt, etwas zu tun
2. Oder dass jeder Programmierer es genauso machen muss, wie er es tut
3. Oder dass die Praktiken, die Menschen verwenden, leicht zu ändern sind

Genauso wie es für einen armen Programmierer möglich ist, ein Experte für Versionskontrolle zu sein. Mein Punkt ist, ich weiß nicht, was die Versionskontrolle für Ihre Programmierkenntnisse oder Problemlösungsfähigkeiten bewirkt. Es ist eine Frage der Erfahrung. Viele kleinere Geschäfte benutzen es entweder nicht oder überlassen es den Einzelpersonen (die oft alleine arbeiten), um es selbst herauszufinden.

Ich denke, es ist nicht so sehr eine Frage von "Wie ist es möglich, Software für 10-15 Jahre aktiv zu entwickeln, ohne jemals eine Versionskontrolle zu benötigen?", Sondern von "Wie ist es möglich, Software für die letzten 10-15 Jahre aktiv zu entwickeln, ohne jemals." benötigen Sie eine Versionskontrolle? "

Sicheres Programmieren ist ohne Versionskontrolle möglich, aber ein Fachmann sollte mit dem aktuellen Stand der Technik vertraut sein und in der Lage sein, die richtigen Werkzeuge für die jeweilige Aufgabe auszuwählen. Wenn Sie die entsprechende Versionsverwaltungssoftware nicht verwenden, ist Ihre Arbeit riskant und unzuverlässig. Einer der Gründe, warum Sie einen professionellen Entwickler beauftragen möchten, besteht darin, dass er in der Lage sein sollte, das Risiko zu managen.

Eine Codebasis, die in einem VCS ordnungsgemäß mit Anmerkungen versehen ist, ist weitaus mehr wert als eine, die dies nicht ist. Der Grund für jede Änderung kann nachverfolgt und verstanden werden, sodass die Betreuer einen tieferen Einblick in das bekommen, was sie wissen müssen. Dies nicht zu tun ist unprofessionell und die einzige Entschuldigung dafür wäre, wenn er / sie bei seiner / ihrer vorherigen Arbeit von armen Managern eingeschränkt worden wäre. Hätten sie auch dann nicht die Versionierung für ihre privaten Projekte verwenden sollen?