¿Cómo determina la calidad del código de un posible empleador antes de tomar un puesto? [cerrado]

En mi experiencia, antes de comenzar a trabajar para una empresa, no tiene la oportunidad de mirar el código base (he preguntado y por razones de confidencialidad todos siempre han dicho que no, creo que es justo), así que durante el proceso de la entrevista, qué ¿crees que son las preguntas más importantes para averiguar en qué tipo de estado se encuentra el código (después de todo, si es un perro, entonces estarás entre los desafortunados pobres que tienen que caminarlo todos los días)?

ACTUALIZAR:

Una lista de verificación: preguntar;

• Lo que piensan de la base de código. Y cuando lo haga, preste mucha atención a las expresiones faciales y al tiempo que les toma responder. [Luego]
• ¿Cuál es el nivel CMM de la empresa [DPD] (y si escucha que el Nivel 5 se ejecuta en sentido contrario [Doug T])
• Qué ciclo de vida usan [DPD] (Y si escuchas "Agile", es cuando comienzas a hacer algunas preguntas penetrantes para tratar de descubrir si por "Agile" se refieren a "Agile o" codificación de vaquero "[Carson63000])
• ¿Qué herramientas usan para evaluar la calidad del código? [DPD]
• ¿Qué herramientas usan para el desarrollo? [DPD] (Busque herramientas de refactorización y servidores de compilación continua)
• Qué sistema de código fuente (control de versiones) usan, y un buen seguimiento es preguntar por qué lo usan. [Zachary K].
• ¿Cómo son sus procedimientos de prueba? [Karl Bielefeldt] (Busque especialmente los equipos que usan marcos de trabajo burlones y ponga énfasis en pruebas de unidades automatizadas exhaustivas a través de marcos establecidos como NUnit / JUnit; no se desanime por los equipos que no usan TDD de desarrollo basado en pruebas, pero sea Tenga cuidado si no consideran que las pruebas son parte integral y la piedra angular del desarrollo de software sólido. Busque equipos con evaluadores dedicados).
• ¿Qué tipo de tareas se asignan a los nuevos desarrolladores? ¿Para desarrolladores experimentados? [Karl Bielefeldt]
• ¿Cuántas personas trabajan en un proyecto? [Karl Bielefeldt]
• ¿Se permite la refactorización? ¿Alentado? [Karl Bielefeldt]
• ¿Qué procesos relacionados con la calidad o cambios de arquitectura se están considerando o se han realizado recientemente? [Karl Bielefeldt]
• ¿Cuánta autonomía tienen los individuos sobre sus módulos? [Karl Bielefeldt]
• ¿Desarrollará proyectos más nuevos (desarrollo greenfield) o proyectos heredados (desarrollo brownfield)? (El desarrollo de Greenfield es generalmente más divertido y tiene menos problemas ya que no está limpiando los errores de otra persona).
• ¿La tasa de rotación de empleados es alta en la organización o en el equipo? (Esto a menudo indica una calidad de código inferior) [M.Sameer]
• Algunos problemas de programación propios; pero evita parecer un imbécil. [Sparky]
• ¿Cómo colaboran los desarrolladores y cómo se comparte el conocimiento entre el equipo? (Esto debería coincidir con su personalidad; diría que una combinación de trabajo en solitario y en pareja es probablemente la mejor, con la proporción que coincida con sus necesidades sociales)
• ¿Qué tan cerca está su base de datos de la 3ra forma normal (3NF) y si se desvía de dónde y por qué? (Si dicen "3NF ???", váyase. Si no, y puede haber buenas razones para no hacerlo, descubra cuáles son).

NOTA: He aceptado la respuesta de Anon porque después de aproximadamente una semana, la comunidad cree que es la mejor, creo que esto sugiere que es algo para lo que de alguna manera necesitas desarrollar un sexto sentido. Pero, creo que todos han tenido algo valioso que decir.

En lugar de pedir ver su código, pregunte qué piensan de la base de código. Y cuando lo haga, preste mucha atención a las expresiones faciales y al tiempo que les toma responder.

Luego aplique su conocimiento de los gestos no verbales de su cultura para interpretar lo que realmente están diciendo. Para una empresa norteamericana, lo siguiente debe ser exacto:

• Un pequeño encogimiento de hombros y una rápida respuesta de "podría ser mejor": probablemente sea bastante bueno.
• Una pausa larga, respiración, tal vez una pequeña risa: no es agradable, y las personas que estás entrevistando no se sienten cómodas diciéndote eso.
• Ojos fruncidos, respuesta rápida de "apesta": podría ser bueno, podría ser malo, pero están sucediendo juegos políticos. A menos que estés listo para jugar ese juego o ser un callado nadie, mantente alejado.
• Cejas levantadas o contraídas: no entienden la pregunta, y la base de código es casi seguramente pútrida.

Por supuesto, si tiene problemas con la comunicación interpersonal, esto podría no funcionar para usted.

Me sorprende que incluso hayas preguntado. Ninguna compañía le mostrará el código antes de unirse. Ni siquiera a los consultores llamados para el proceso, a menos que hayan firmado un acuerdo de confidencialidad.

Esto es lo que puede pedir para averiguar.

• ¿Cuál es el nivel CMM de la empresa (idealmente 5)?
• ¿Cuál es el proceso que se sigue en su proyecto prospectivo (por cierto, preguntar esto es bueno porque muestra que está interesado en "este" trabajo y no en cualquier trabajo)
• ¿Qué ciclo de vida usan? (No seas crítico si no escuchas "Agile". Pueden tener una razón válida para usar los modelos de la vieja escuela)
• Pregunte si usan alguna herramienta y métrica para verificar la calidad del código. Y en caso afirmativo, cuál (si usan al menos una herramienta para las métricas y otra para la calidad, es una buena señal).
• También tenga en cuenta qué herramientas utilizan. Si se trata de una herramienta costosa como Resharper en lugar de una herramienta gratuita, entonces la calidad es muy seria.

1. Pregúnteles si usan el control de fuente.
   • ¿Sin control de fuente? -> código muy probablemente de mierda
2. Pregúnteles con qué frecuencia hacen revisiones de código.
   • ¿Sin revisión de código? -> el código puede ser sospechoso (pero no necesariamente, especialmente si se trata de un pequeño equipo formado por desarrolladores decentes).
3. Pregúnteles si prueban y despliegan antes de entrar en producción.
   • No hay entorno de prueba? ¿Despliegue directo en producción? -> código muy probablemente de mierda.
4. Pregúnteles si realizan una integración continua (es decir, ejecutando compilaciones con Hudson)
   • ¿Sin integración continua? -> el código puede ser sospechoso, pero no necesariamente.
5. (Relacionado con el n. ° 3), ¿les pregunta si su entorno de prueba es independiente de su entorno de desarrollo?
   • Prueba es dev? -> no es una buena señal, a menos que estén realmente con poco dinero, pero ¿qué tan costosa sería una caja extra?
6. Pregúnteles si revisan una lista de acciones antes de implementarla en producción.
   • ¿Ninguna revisión de acciones antes del despliegue de producción? -> Bad juju.
7. Pregúnteles cuántos pasos les toma hacer una compilación.
   • Más de 3? -> típicamente mal juju.
8. ¿Toman (o estiman) las métricas de código como la complejidad ciclomática o LCOM (una medida de cohesión de clase).
   • ¿Sí? -> probablemente (pero no ciertamente) una buena señal con respecto a la calidad de su código.
   • No, pero entienden los conceptos (al menos la complejidad ciclomática)? -> difícil de decir
   • ¿Creen que la complejidad ciclomática es un plato exótico o afrodisíaco de Tombuctú (en otras palabras, no saben qué es eso)? -> posible mal juju.
   • ¿Creen que es una mierda irrelevante (o algún otro comportamiento de ese tipo)? -> huir.
9. Pregúnteles cómo hacen un seguimiento de los errores.
   • ¿Realizan un seguimiento del número de errores contra alguna métrica (es decir, por proyecto, número de módulos modificados o número de requisitos / solicitudes de cambio, ¡algo!)? -> buena señal sobre su código (y su proceso de software).
   • ¿Hacen lo anterior e intentan predecir el número de posibles errores que podrían encontrar en un proyecto futuro (o en curso) en función de una métrica esperada (# de solicitudes de cambio, tamaño del proyecto, etc.)? -> muy buena señal.
   • ¿Siguen los errores solo para la resolución de errores? -> difícil de decir
   • ¿Sin seguimiento constante? -> huir.

Eso sería desde lo alto de mi cabeza. Notarás que algunas de mis preguntas se refieren al proceso de desarrollo de software, y no solo estrictamente a la codificación. La calidad del último es una función directa de la calidad del primero.

Dicho esto, cuando haga estas preguntas, proceda con precaución. Estúdialos y selecciona algunos al momento de una entrevista.

Un par de cosas que debes tener en cuenta. Un buen equipo de desarrollo se alegrará de escuchar a una persona entrevistada hacer estas preguntas ... siempre que se las haga con tacto. Hazlo mal y le darás al entrevistador una impresión de arrogancia y perfeccionismo. No importa cuán bueno sea un equipo de desarrollo, ningún grupo es perfecto y todos tienen problemas que resolver, compromisos de calidad y demás. Quieren un jugador de equipo con una inclinación por la calidad, no un perfeccionista disruptivo. Así que ten cuidado.

Además, podría haber casos en los que tenga un equipo de personas buenas que, por circunstancias externas, deben trabajar en un código de calidad inferior (podrían ser desarrolladores junior o simplemente heredaron un montón de basura en la que ahora deben trabajar con recursos dedicados a mejorar la calidad.) Puede trabajar con código de mierda y aún así tener una buena experiencia laboral si las personas que lo rodean también son buenas personas (tanto personal como profesionalmente). Déles una impresión equivocada cuando haga las preguntas, y tal vez eviten contratarlo por completo (robándole la oportunidad de trabajar con buenas personas en una situación muy difícil y desafiante).

• Por cierto, creo sinceramente que es imprescindible que un desarrollador de software haya trabajado al menos una vez con algún tipo de código más allá de la esperanza (o casi más allá de la esperanza). Sobrevivir a eso y hacer un buen trabajo, es una lección valiosa.

También puede encontrar un grupo de desarrollo de mierda con gente de mierda. Obviamente, entonces, su código será una mierda, y rechazarán cualquiera de estas preguntas. Podrían despreciarlo por hacerle preguntas difíciles (y por lo tanto podrían hacerle un favor), o lo contratarán porque lo necesitan (incluso si son / serán incapaces de trabajar con usted).

Cuando eso sucede, debe preguntarse si necesita este trabajo tan mal. A veces lo haces, y tienes que zambullirte en un montón de mierda de espagueti. A veces no lo hace (es decir, puede darse el lujo de no hacerlo).

Esas son las cosas que debe tener en cuenta cuando / si elige preguntarle a un entrevistador sobre la calidad de sus procesos de código y software.

En lugar de la calidad del código real, preferiría buscar una compañía donde se entienda bien la importancia de la calidad del código.

Por ejemplo, digamos que la compañía A tiene gerentes que creen que "la planificación es tiempo perdido" y "podemos solucionar los problemas de diseño más adelante (por ejemplo, cuando el infierno se congele. Tendremos tiempo entonces)". Incluso si esa compañía tuviera una buena base de código ahora, no la tendrán por mucho tiempo. Y usted será el que (se verá obligado) a empeorar las cosas.

Por otro lado, digamos que la compañía B tiene una base de código incorrecta, pero la gerencia entiende que la calidad del código está causando todos esos errores y retrasos, ven la necesidad de un cambio y están dispuestos a hacer algo al respecto (por ejemplo, a gran escala refactorización o incluso reescritura). Esa compañía mejorará su base de código, y usted puede ayudarlos a lograrlo.

Sé dónde me gustaría trabajar.

Hay un 99.9% de posibilidades de que no pueda ver el código antes de comenzar. (A menos que publiquen un producto de software libre, por supuesto)

Entonces, ¿qué puede hacer? Preguntaría sobre el proceso, en general, un buen proceso producirá un buen código. Comenzaría con la prueba de Joel y preguntaría sobre el método de desarrollo. También ve más allá de lo básico. Por ejemplo, siempre pregunto qué sistema de código fuente usan, por lo que un buen seguimiento es preguntar por qué lo usan.

El lugar donde trabajé con código de muy alta calidad básicamente no permitió que dos tercios de los desarrolladores tocasen el código. Los otros escribieron scripts de prueba de caja negra automatizados. Si demostró ser digno de cambiar el código real, los requisitos estaban tan extremadamente especificados que básicamente no era más que una transcripción al código fuente. Los guiones de prueba fueron realmente más divertidos de escribir.

Los lugares en los que he visto el código de menor calidad fueron exactamente al revés: solo los programadores relativamente sin entrenamiento o sin adornos tocaron el código, generalmente porque era una herramienta que no estaba directamente relacionada con el producto de la compañía o que se consideraba experimental.

Los lugares más agradables para trabajar tienen un equilibrio. A los nuevos desarrolladores se les asignan tareas reales, pero son asesorados. Hay un buen departamento de control de calidad y un proceso de revisión por pares para detectar sus errores. No se lo castiga por cometer errores, pero se espera que los corrija y aprenda de ellos. Ocasionalmente, un módulo mal escrito cae en el olvido, pero no se le critica por pasar tiempo mejorando la calidad del código cuando se los encuentra. La compañía en su conjunto se esfuerza continuamente por encontrar nuevas formas de mejorar el código.

Por lo tanto, las preguntas que haría para evaluar la calidad del código son:

• ¿Cómo son sus procedimientos de prueba?
• ¿Qué tipo de tareas se asignan a los nuevos desarrolladores? ¿Para desarrolladores experimentados?
• ¿Cuántas personas trabajan en un proyecto?
• ¿Se permite la refactorización? ¿Alentado?
• ¿Qué procesos relacionados con la calidad o cambios de arquitectura se están considerando o se han realizado recientemente?
• ¿Cuánta autonomía tienen los individuos sobre sus módulos?

Como dijeron @DPD y @Zachary, el proceso y el SDLC son factores muy importantes, pero quiero agregar algunos otros factores que, según mi experiencia, tienen un impacto significativo en la calidad del código:

• Pregunte si va a trabajar en desarrollo en un proyecto relativamente nuevo o en el mantenimiento de una aplicación heredada. Las aplicaciones heredadas tienden a ser menos limpias que los proyectos nuevos.
• Intente saber si la tasa de rotación del empleado es alta en la organización o en el equipo. Es muy probable que esto también disminuya la calidad del código.

Tenga en cuenta que un proceso ayuda mucho, pero no dará inmunidad total contra los factores anteriores. Cuando muchos desarrolladores pasan un proyecto, cada uno tiene una mentalidad diferente. El arquitecto y el desarrollador no seguirán exactamente la forma en que lo hicieron sus predecesores, lo que generará algunas inconsistencias.

Mi actitud es esta, el código es código, si es malo, bueno, es un desafío mejorarlo. Si es bueno, ¡es un desafío aún más difícil mejorarlo!

Lo más importante para mí es si quiero trabajar para la empresa y las personas con las que tengo la oportunidad de interactuar. El código se puede cambiar, la gente no puede ...

Le digo en broma un poco, entrevista conmigo .

Normalmente uso un error real (ya corregido) en nuestra base de código como prueba de entrevista, por lo que ve un código real. Generalmente es un código un poco complicado y tiene un error.

Animo a todos a usar esta técnica, ya que ya saben que el error es real, el problema es real y saben cuánto tiempo llevó encontrarlo y solucionarlo.

Lo bueno es que puedes tener un problema difícil de medir.

He utilizado un problema muy difícil como última pregunta de la entrevista para separar a los expertos de los bastante buenos.

La relevancia para la pregunta del OP es que todos los que llegan a una entrevista física pueden ver algún código. (No hay nada con contenido confidencial de la compañía)

Si no pudiste usar esta técnica, por decir blasfemias en la base del código, entonces la prueba funciona, ya que los posibles empleados preguntarán "¿puedo ver el código" y la respuesta sería "oh, no puedes, es lleno de blasfemias ".

Por supuesto, la respuesta estándar de "todo es un secreto de la compañía" es el juego completo.
Mi prueba: en mi anterior empleador, una parte no confidencial de un producto militar era el ejemplo de código para la pregunta de la entrevista. [Afortunadamente sin clasificar]

Dejo el problema de determinar la calidad de los diseños clasificados antes de trabajar allí a alguien más inteligente que yo. Sugiero que puede ser común que clasificado sea sinónimo de libre de supervisión.

Es dudoso que te permitan ver su código, pero es posible que puedas hacerte una idea de cómo sería si les asignas una tarea de programación. Muchos lugares dan a los entrevistados una tarea de programación para llevar a casa que pueden usar para evaluarlo. Devuelva el favor: espere uno de ellos para que pueda evaluar mejor en qué podría estar metiéndose.

Pregunte qué se requiere para que el código llegue a la compilación de producción. Si obtienes 'uhh ... el desarrollador lo comete ...' entonces es casi seguro que es basura.

Hay varias cosas que tienden a aumentar la calidad del código (obviamente, no hay garantías).

• Análisis estático (en .NET esto es cosas como fxcop / stylecop)
• Un subconjunto (o conjunto completo) del conjunto de pruebas: unidad / integración / regresión / manual, etc.
• Compilación de amigos (otro desarrollador del equipo crea los cambios para ver si hay algún problema dependiente de la máquina / usuario, a veces también ejecutando una cordura rápida)
• Revisión de código

Estos pueden ayudar a mejorar, no solo la fuerza del código, sino también la calidad del código.

Pregúnteles sobre las pruebas unitarias. Si se lo toman en serio, entonces el entrevistador probablemente tendrá algunas opiniones definitivas sobre el tema y estará encantado de compartirlas. Si las respuestas son vagas, es una gran señal de advertencia.

Si se trata de una tienda Java, pregúnteles qué biblioteca ORM están utilizando. Si han rodado los suyos, entonces podría ir de cualquier manera, podría ser una mierda, o podría estar bien. Si no están usando ninguno, corre hacia la puerta de inmediato.

Esta es una tarea difícil porque hay tantas prácticas diferentes de codificación incorrecta que nunca podrás predecirlas todas.

No puedes, desafortunadamente. Ninguna compañía le permitirá ver su código (pero le pedirán ver SU código ...), y lo más probable es que si les hace preguntas sobre el entorno, le mentirán directamente ("¿Control de versiones? Seguro ... usamos ... uhh ... pensando en Sub ... Sub-algo ") o nos equivocamos acerca de la calidad (" Estamos usando el último y mejor .NET 4 "solo para descubrir que mientras usan .NET 4 ellos ' reescribiéndolo como .NET 1.1).

Me he quemado muchas veces en el pasado y todavía no he encontrado una buena manera de medir la calidad. Por lo general, la mejor manera es usar su propio criterio y, si todo se reduce a eso, irse inmediatamente si es peor de lo que pensaba; podrías terminar en una bolsa de trabajo pero mantendrás la cordura.