Wie stellen Sie die Qualität eines potenziellen Arbeitgebercodes fest, bevor Sie eine Position einnehmen? [geschlossen]

Meiner Erfahrung nach haben Sie vor Ihrem Einstieg in ein Unternehmen keine Gelegenheit, sich die Code-Basis anzusehen (ich habe gefragt und aus Gründen der Vertraulichkeit haben alle immer nein gesagt, ich halte das für fair), also was während des Interviewprozesses Denken Sie, es sind die wichtigsten Fragen, die Sie stellen müssen, um herauszufinden, in welchem ​​Zustand sich der Code befindet? (Wenn es sich um einen Hund handelt, gehören Sie zu den Armen, die jeden Tag laufen müssen.)

AKTUALISIEREN:

Eine Checkliste: Fragen Sie;

• Was sie von der Codebasis halten. Und wenn Sie dies tun, achten Sie genau auf die Mimik und die Zeit, die sie benötigen, um zu reagieren. [Anon]
• Was ist die CMM-Stufe des Unternehmens [DPD] (und wenn Sie hören, dass Stufe 5 in die andere Richtung läuft [Doug T])?
• Welchen Lebenszyklus sie verwenden [DPD] (und wenn Sie "Agile" hören, beginnen Sie, einige durchdringende Fragen zu stellen, um herauszufinden, ob mit "Agile" "Agile" oder "Cowboy-Codierung" gemeint ist [Carson63000])
• Mit welchen Tools bewerten sie die Codequalität? [DPD]
• Welche Tools verwenden sie für die Entwicklung? [DPD] (Nach Refactoring-Tools und Continuous Build-Servern suchen)
• Welches Quellcode- (Versionskontroll-) System verwenden sie, und eine gute Fortsetzung ist die Frage, warum sie es verwenden. [Zachary K].
• Wie sind ihre Testverfahren? [Karl Bielefeldt] (Achten Sie besonders auf Teams, die spöttische Frameworks verwenden, und legen Sie den Schwerpunkt auf gründliche automatisierte Komponententests durch etablierte Frameworks wie NUnit / JUnit. Lassen Sie sich nicht von Teams abschrecken, die kein testgetriebenes Entwicklungs-TDD verwenden Seien Sie vorsichtig, wenn Sie das Testen nicht als integralen Bestandteil und Grundpfeiler einer soliden Softwareentwicklung betrachten. Suchen Sie nach Teams mit engagierten Testern.)
• Welche Aufgaben erhalten neue Entwickler? Erfahrene Entwickler? [Karl Bielefeldt]
• Wie viele Leute arbeiten an einem Projekt? [Karl Bielefeldt]
• Ist Refactoring erlaubt? Ermutigt? [Karl Bielefeldt]
• Welche qualitätsbezogenen Prozess- oder Architekturänderungen werden in Betracht gezogen oder wurden kürzlich durchgeführt? [Karl Bielefeldt]
• Wie viel Autonomie haben Einzelpersonen über ihre Module? [Karl Bielefeldt]
• Werden Sie neuere Projekte (Greenfield Development) oder Legacy-Projekte (Brownfield Development) entwickeln? (Greenfield-Entwicklung macht im Allgemeinen mehr Spaß und hat weniger Probleme, da Sie nicht mit den Fehlern anderer aufräumen).
• Ist die Mitarbeiterfluktuation in der Organisation oder im Team hoch? (Dies deutet oft auf eine schlechtere Codequalität hin.) [M.Sameer]
• Einige eigene Programmierprobleme; aber vermeiden Sie es, wie ein Idiot zu wirken. [Sparky]
• Wie arbeiten die Entwickler zusammen und wie wird das Wissen im Team geteilt? (Dies sollte zu Ihrer Persönlichkeit passen. Ich würde sagen, dass eine Mischung aus Einzel- und Paararbeit am besten ist, wobei das Verhältnis Ihren sozialen Bedürfnissen entspricht.)
• Wie nah ist ihre Datenbank an der 3. Normalform (3NF) und ob sie wo und warum davon abweicht? (Wenn sie "3NF ???" sagen, gehen Sie. Wenn nicht, und es könnte gute Gründe dafür geben, dann finden Sie heraus, was sie sind).

ANMERKUNG: Ich habe Anons Antwort akzeptiert, weil die Community nach ungefähr einer Woche der Meinung ist, dass es das Beste ist. Ich denke, dies legt nahe, dass es nur etwas ist, für das Sie irgendwie einen sechsten Sinn entwickeln müssen. Aber ich denke, jeder hat etwas Wertvolles zu sagen gehabt.

Anstatt nach ihrem Code zu fragen, fragen Sie, was sie von der Codebasis halten. Und wenn Sie dies tun, achten Sie genau auf die Mimik und die Zeit, die sie benötigen, um zu reagieren.

Wenden Sie dann Ihr Wissen über die nonverbalen Gesten Ihrer Kultur an, um zu interpretieren, was sie wirklich sagen. Für ein nordamerikanisches Unternehmen sollte Folgendes zutreffen:

• Ein kleines Achselzucken und eine schnelle Antwort von "Es könnte besser sein": Es ist wahrscheinlich ziemlich gut.
• Eine lange Pause, ein Anhalten des Atems, vielleicht ein kleines Lachen: Es ist nicht angenehm, und die Leute, die Sie interviewen, fühlen sich nicht wohl, wenn sie Ihnen das sagen.
• Rollende Augen, schnelle Reaktion von "es ist scheiße": mag gut sein, mag schlecht sein, aber es finden politische Spiele statt. Wenn Sie nicht bereit sind, dieses Spiel zu spielen oder ein stiller Niemand zu sein, bleiben Sie weg.
• Hochgezogene oder zusammengezogene Augenbrauen: Sie verstehen die Frage nicht, und die Codebasis ist mit ziemlicher Sicherheit faul.

Wenn Sie Probleme mit der zwischenmenschlichen Kommunikation haben, funktioniert dies möglicherweise nicht für Sie.

Ich bin überrascht, dass Sie sogar gefragt haben. Kein Unternehmen wird Ihnen jemals den Code zeigen, bevor Sie beigetreten sind. Nicht einmal an Berater, die für den Prozess hinzugezogen wurden, es sei denn, sie haben eine Vertraulichkeitsvereinbarung unterzeichnet.

Hier ist, was Sie fragen können, um herauszufinden.

• Wie hoch ist die KMG- Stufe des Unternehmens (idealerweise 5) ?
• Was ist der Prozess, der in Ihrem zukünftigen Projekt verfolgt wird?
• Welchen Lebenszyklus verwenden sie? (Seien Sie nicht wertend, wenn Sie "Agile" nicht hören. Möglicherweise haben sie einen gültigen Grund für die Verwendung der alten Schulmodelle.)
• Fragen Sie, ob sie Tools und Metriken verwenden, um die Codequalität zu überprüfen. Und wenn ja, welches (wenn sie mindestens ein Tool für Metriken und ein anderes für die Qualität verwenden, ist dies ein gutes Zeichen.)
• Beachten Sie auch, welche Tools sie verwenden. Wenn es sich um ein teures Tool wie Resharper handelt, anstatt um ein Freeware-Tool, dann sind sie absolut qualitätsbewusst.

1. Fragen Sie sie, ob sie die Quellcodeverwaltung verwenden.
   • Keine Quellcodeverwaltung? -> Code höchstwahrscheinlich beschissen
2. Fragen Sie sie, wie oft Codeüberprüfungen durchgeführt werden.
   • Keine Codeüberprüfung? -> Code könnte verdächtig sein (aber nicht unbedingt, besonders wenn es sich um ein kleines Team aus anständigen Entwicklern handelt.)
3. Fragen Sie sie, ob sie testen und bereitstellen, bevor sie in die Produktion gehen.
   • Keine Testumgebung? Direkter Einsatz in der Produktion? -> Code höchstwahrscheinlich beschissen.
4. Fragen Sie sie, ob sie eine kontinuierliche Integration durchführen (z. B. Builds mit Hudson ausführen).
   • Keine kontinuierliche Integration? -> Code könnte verdächtig sein, aber nicht unbedingt.
5. (Bezogen auf # 3), fragen Sie sie, ob ihre Testumgebung von Ihrer Entwicklungsumgebung getrennt ist ?
   • Test ist dev? -> kein gutes Zeichen, es sei denn, sie sind wirklich mit Bargeld besetzt, aber wie teuer wäre eine zusätzliche Schachtel?
6. Fragen Sie sie, ob sie eine Aktionsliste überprüfen, bevor sie sie in der Produktion bereitstellen.
   • Keine Überprüfung der Aktionen vor der Bereitstellung in der Produktion? -> Schlechter Juju.
7. Fragen Sie sie, wie viele Schritte sie für einen Build benötigen.
   • Mehr als 3? -> typisch schlechtes juju.
8. Nehmen sie (oder schätzen sie) Codemetriken wie zyklomatische Komplexität oder LCOM (ein Maß für den Klassenzusammenhalt)?
   • Ja? -> wahrscheinlich (aber nicht sicher) ein gutes Zeichen für ihre Codequalität.
   • Nein, aber sie verstehen die Konzepte (zumindest die zyklomatische Komplexität)? -> schwer zu sagen
   • Sie denken, dass die zyklomatische Komplexität ein exotisches Gericht oder Aphrodisiakum von Timbuktu ist (mit anderen Worten, sie wissen nicht, was das ist)? -> mögliche schlechte juju.
   • Sie denken, dass das irrelevante Scheiße ist (oder irgendein anderes Verhalten dieser Art)? -> weglaufen.
9. Fragen Sie sie, wie sie die Fehler im Auge behalten.
   • Sie verfolgen die Anzahl der Fehler in Bezug auf eine Metrik (z. B. pro Projekt, Anzahl der geänderten Module oder Anzahl der Anforderungen / Änderungsanforderungen, etwas!). -> gutes Zeichen über ihren Code (und ihren Softwareprozess).
   • Sie führen die oben genannten Schritte aus und versuchen, die Anzahl möglicher Fehler, die in einem zukünftigen (oder laufenden) Projekt auftreten könnten, anhand einer erwarteten Metrik (Anzahl der Änderungsanforderungen, Projektgröße usw.) vorherzusagen. -> sehr gutes zeichen.
   • Sie verfolgen Fehler nur zur Fehlerbehebung? -> schwer zu sagen
   • Kein konsequentes Tracking? -> weglaufen.

Das würde von oben kommen. Sie werden feststellen, dass sich einige meiner Fragen auf den Softwareentwicklungsprozess beziehen und nicht nur auf die Codierung. Die Qualität der letzteren ist eine direkte Funktion der Qualität der ersteren.

Gehen Sie daher vorsichtig vor, wenn Sie diese Fragen stellen. Studieren Sie sie und wählen Sie einige zum Zeitpunkt eines Interviews aus.

Ein paar Dinge, die Sie beachten sollten. Ein gutes Entwicklungsteam freut sich, wenn eine befragte Person diese Fragen stellt ... vorausgesetzt, sie werden mit Fingerspitzengefühl gestellt. Wenn Sie es falsch machen, vermitteln Sie dem Interviewer einen Eindruck von Arroganz und Perfektionismus. Egal wie gut ein Entwicklerteam ist, keine Gruppe ist perfekt und alle haben Probleme zu lösen, Kompromisse in der Qualität und so weiter. Sie wollen einen Teamplayer mit einer Vorliebe für Qualität, keinen störenden Perfektionisten. Also sei vorsichtig.

Es kann auch Fälle geben, in denen Sie ein Team von guten Leuten haben, die unter äußeren Umständen in Code arbeiten müssen, der von unterdurchschnittlicher Qualität ist (es können Junior-Entwickler sein oder sie haben einfach einen Haufen Mist geerbt, an dem sie jetzt nur noch eingeschränkt arbeiten müssen) Ressourcen für die Verbesserung der Qualität.) Sie können mit schlechtem Code arbeiten und trotzdem eine gute Arbeitserfahrung haben, wenn die Menschen in Ihrer Umgebung auch gute Menschen sind (sowohl persönlich als auch beruflich). Geben Sie ihnen den falschen Eindruck, wenn Sie die Fragen stellen, und sie könnten es einfach vermeiden, Sie insgesamt einzustellen (Ihnen die Gelegenheit rauben, mit guten Leuten in einer sehr schwierigen und herausfordernden Situation zu arbeiten).

• Übrigens glaube ich von ganzem Herzen, dass es ein Muss für einen Softwareentwickler ist, mindestens einmal mit irgendeiner Art von Code gearbeitet zu haben, der jenseits der Hoffnung (oder nahezu jenseits der Hoffnung) liegt. Du überlebst das und machst eine gute Arbeit, das ist eine wertvolle Lektion.

Sie könnten auch eine beschissene Entwicklungsgruppe mit beschissenen Leuten treffen. Dann wird ihr Code offensichtlich beschissen sein und sie werden bei jeder dieser Fragen durchfallen. Sie mögen dich verachten, weil du ihnen knifflige Fragen gestellt hast (und dir damit einen Gefallen tun), oder sie werden dich einstellen, weil sie dich brauchen (auch wenn sie nicht in der Lage sind, mit dir zu arbeiten).

Wenn das passiert, müssen Sie sich fragen, ob Sie diesen Job so dringend brauchen . Manchmal tust du das und du musst einen Sprung in einen Haufen Spaghetti-Scheiße wagen. Manchmal tut man das nicht (was bedeutet, dass man es sich leisten kann, es nicht zu tun).

Dies sind die Dinge, die Sie berücksichtigen müssen, wenn Sie einen Interviewer nach der Qualität seines Codes und seiner Softwareprozesse fragen.

Anstelle der eigentlichen Codequalität suche ich lieber ein Unternehmen, in dem die Bedeutung der Codequalität gut verstanden wird.

Angenommen, Unternehmen A hat Manager, die glauben, "Planung ist Zeitverschwendung" und "wir können Konstruktionsprobleme später beheben (z. B. wenn die Hölle zufriert. Dann haben wir Zeit)". Selbst wenn diese Firma jetzt zufällig eine gute Codebasis hat, wird es nicht lange dauern. Und du wirst derjenige sein, der es noch schlimmer machen wird (muss).

Angenommen, Unternehmen B hat eine schlechte Codebasis, aber das Management weiß, dass die Codequalität all diese Fehler und Verzögerungen verursacht, dass Änderungen erforderlich sind und dass es bereit ist, etwas dagegen zu unternehmen (z. B. in großem Maßstab) refactoring oder sogar umschreiben). Diese Firma wird ihre Codebasis verbessern, und Sie können ihnen dabei helfen, dies zu erreichen.

Ich weiß, wo ich arbeiten möchte.

Es besteht eine Wahrscheinlichkeit von 99,9%, dass Sie den Code nicht sehen können, bevor Sie beginnen. (Es sei denn, sie geben natürlich freie Software heraus)

Also, was können Sie tun, ich würde nach dem Prozess fragen, im Allgemeinen wird ein guter Prozess einen guten Code erzeugen. Ich würde mit dem Joel-Test beginnen und nach der Entwicklungsmethode fragen. Gehen Sie auch über die Grundlagen hinaus. Ich frage zum Beispiel immer, welches Quellcodesystem sie verwenden, daher ist es eine gute Fortsetzung, zu fragen, warum sie es verwenden.

Der Ort, an dem ich mit sehr hochwertigem Code gearbeitet habe, erlaubte im Grunde zwei Dritteln der Entwickler nicht, den Code zu berühren. Die anderen schrieben stattdessen automatisierte Black-Box-Testskripte. Wenn Sie sich als änderungswürdig erwiesen haben, waren die Anforderungen so hoch, dass es sich im Grunde genommen nur um eine Transkription in Quellcode handelte. Das Schreiben der Testskripte hat tatsächlich mehr Spaß gemacht.

Die Stellen, an denen ich den Code mit der niedrigsten Qualität gesehen habe, waren genau umgekehrt: Nur relativ ungeübte oder ungeübte Programmierer haben den Code jemals berührt, normalerweise, weil es sich um ein Tool handelte, das nicht direkt mit dem Produkt des Unternehmens zusammenhängt oder als experimentell gilt.

Die angenehmsten Arbeitsplätze haben ein Gleichgewicht. Neue Entwickler erhalten echte Aufgaben, werden aber betreut. Es gibt eine gute QA-Abteilung und einen Peer-Review-Prozess, um Ihre Fehler aufzufangen. Sie werden nicht für Fehler bestraft, sondern müssen sie beheben und daraus lernen. Gelegentlich fällt ein schlecht geschriebenes Modul durch die Lücken, aber Sie werden nicht dafür kritisiert, Zeit damit zu verbringen, die Codequalität zu verbessern, wenn Sie auf diese stoßen. Das gesamte Unternehmen ist ständig bemüht, neue Wege zu finden, um den Code zu verbessern.

Die Fragen, die ich zur Beurteilung der Codequalität stellen möchte, lauten daher:

• Wie sehen Ihre Testverfahren aus?
• Welche Aufgaben erhalten neue Entwickler? Erfahrene Entwickler?
• Wie viele Leute arbeiten an einem Projekt?
• Ist Refactoring erlaubt? Ermutigt?
• Welche qualitätsbezogenen Prozess- oder Architekturänderungen werden in Betracht gezogen oder wurden kürzlich durchgeführt?
• Wie viel Autonomie haben Einzelpersonen über ihre Module?

Wie @DPD und @Zachary sagten, sind Prozess und SDLC sehr wichtige Faktoren, aber ich möchte einige andere Faktoren hinzufügen, die meiner Erfahrung nach einen erheblichen Einfluss auf die Codequalität haben:

• Fragen Sie, ob Sie in einem relativ neueren Projekt in der Entwicklung arbeiten oder eine ältere Anwendung warten möchten. Ältere Anwendungen sind in der Regel weniger sauber als neuere Projekte.
• Versuchen Sie herauszufinden, ob die Fluktuationsrate des Mitarbeiters in der Organisation oder im Team hoch ist. Dies wird höchstwahrscheinlich auch die Qualität des Codes verringern.

Beachten Sie, dass ein Prozess viel hilft, aber keine vollständige Immunität gegen die oben genannten Faktoren bietet. Wenn viele Entwickler ein Projekt weitergeben, hat jeder eine andere Denkweise. Der Architekt und der Entwickler werden nicht genau der Vorgehensweise ihrer Vorgänger folgen, was zu Inkonsistenzen führen wird.

Meine Einstellung ist: Code ist Code. Wenn es schlecht ist, ist es eine Herausforderung, es besser zu machen. Wenn es gut ist, ist es eine noch schwierigere Herausforderung, es besser zu machen!

Für mich ist es am wichtigsten, ob ich für das Unternehmen und die Menschen arbeiten möchte, mit denen ich Kontakt aufnehmen kann. Code kann geändert werden, Leute können nicht ...

Etwas scherzhaft sage ich, interview mit mir .

Normalerweise verwende ich einen (bereits behobenen) Fehler in unserer Codebasis als Interviewtest, sodass Sie einen tatsächlichen Code sehen. Im Allgemeinen etwas komplizierter Code, der einen Fehler enthält.

Ich ermutige alle, diese Technik zu verwenden, da Sie bereits wissen, dass der Fehler echt ist, das Problem echt ist und Sie wissen, wie lange es gedauert hat, ihn zu finden und zu beheben.

Das Tolle ist, dass Sie ein messbar schwieriges Problem haben können.

Ich habe ein sehr schwieriges Problem als letzte Interviewfrage verwendet, um die Experten von den ziemlich guten zu trennen.

Die Relevanz für die Frage des OP ist, dass jeder, der es zu einem physischen Interview schafft, Code sehen kann. (Nichts mit vertraulichen Inhalten des Unternehmens)

Wenn Sie diese Technik nicht anwenden könnten, weil es Profanitäten in der Codebasis gibt, funktioniert der Test, da potenzielle Mitarbeiter fragen: "Kann ich den Code sehen?" Und die Antwort lautet: "Oh, das können Sie nicht." voller Schimpfwörter ".

Natürlich lautet die übliche Antwort "Es ist alles ein Unternehmensgeheimnis" "Pferdefick".
Mein Beweis: Bei meinem früheren Arbeitgeber war ein nicht vertraulicher Teil eines Militärprodukts das Codebeispiel für die Interviewfrage. [Zum Glück nicht klassifiziert]

Ich überlasse es jemandem, der schlauer ist als ich, das Problem, die Qualität klassifizierter Entwürfe zu bestimmen, bevor ich dort arbeite. Ich schlage vor, es kann üblich sein, dass klassifiziert für übersichtsfrei steht.

Es ist zweifelhaft, ob sie Ihnen erlauben, ihren Code zu sehen, aber Sie können möglicherweise eine Vorstellung davon bekommen, wie es sein könnte, wenn Sie ihnen eine Programmier-Hausaufgabe geben. An vielen Orten erhalten die Befragten einen Programmierauftrag zum Mitnehmen, mit dem sie Sie einschätzen können. Erwidere den Gefallen - erwarte einen von ihnen, damit du besser einschätzen kannst, worauf du dich einlassen könntest.

Fragen Sie, was für den Code erforderlich ist, damit er in den Produktionsbuild aufgenommen wird. Wenn Sie "äh ... der Entwickler begeht es ..." bekommen, dann ist es mit ziemlicher Sicherheit Müll.

Es gibt eine Reihe von Dingen, die dazu neigen, die Qualität des Codes zu verbessern (offensichtlich gibt es keine Garantien).

• Statische Analyse (in .NET sind dies Dinge wie fxcop / stylecop)
• Eine Teilmenge (oder eine vollständige Menge) der Testsuite - Einheit / Integration / Regression / Handbuch usw.
• Buddy-Build (ein anderer Entwickler im Team erstellt die Änderungen, um festzustellen, ob es Probleme gibt, die von der Maschine oder dem Benutzer abhängen. Manchmal wird auch eine schnelle Funktion ausgeführt.)
• Code-Review

Dies kann dazu beitragen, nicht nur die Stärke des Codes, sondern auch die Qualität des Codes zu verbessern.

Fragen Sie nach Unit-Tests. Wenn sie es ernst nehmen, wird der Interviewer wahrscheinlich einige eindeutige Meinungen zu diesem Thema haben und sie gerne teilen. Wenn die Antworten vage sind, ist das ein großes Warnsignal.

Wenn es sich um einen Java-Shop handelt, fragen Sie sie, welche ORM-Bibliothek sie verwenden. Wenn sie ihre eigenen gerollt haben, dann könnte es in beide Richtungen gehen - es könnte saugen oder es könnte in Ordnung sein. Wenn sie keine benutzen, rennen Sie sofort zur Tür.

Dies ist eine schwierige Aufgabe, da es so viele verschiedene schlechte Codierungsmethoden gibt, dass Sie nie alle vorhersagen können.

Das kannst du leider nicht. Keine Firma lässt Sie ihren Code sehen (aber sie werden nach IHREM Code fragen ...), und wenn Sie ihnen Fragen zur Umgebung stellen, werden Sie wahrscheinlich direkt belogen ("Versionskontrolle? Sicher .. wir benutzen .. ähh .. denken an Sub .. Sub-etwas ") oder irregeführt über die Qualität (" Wir benutzen das neueste und beste .NET 4 "), nur um herauszufinden, dass sie, während sie .NET 4 benutzen, schreiben Sie es wie .NET 1.1).

Ich habe mich in der Vergangenheit oft daran verbrannt, und ich habe noch keinen guten Weg gefunden, um die Qualität einzuschätzen. Normalerweise ist es am besten, sich ein eigenes Urteil zu bilden, und wenn es darauf ankommt, gehen Sie sofort, wenn es schlimmer ist, als Sie dachten. Sie könnten einen Job Hopper enden, aber Sie werden Ihre geistige Gesundheit behalten.