¿Cómo evaluar la calidad del código cuando no estás familiarizado con el idioma? [cerrado]

Como hipotético, si tuviera que entrevistar a alguien para un nuevo puesto de desarrollador de PHP cuando mi experiencia es en .NET, ¿cómo puedo determinar si la muestra de código que me han proporcionado es eficiente y de buena calidad?

En otras palabras, ¿cuál es la mejor manera de evaluar el código de un programador si no está familiarizado con el lenguaje?

¿Cómo puedo determinar si la muestra de código que me han proporcionado es eficiente y de buena calidad?

Las cosas que no podrá evaluar son el uso correcto de las expresiones idiomáticas y el uso de la biblioteca. Por lo tanto, estas no son cosas que debe tratar de mirar.

Lo que puedes evaluar es:

• Cuán bien estructurado se ve el código
• Variables bien nombradas (¿puedes entender las cosas?)
• Funciones / unidades de código bien compuestas
• Consistencia en la base del código

Los puntos anteriores (aunque no exhaustivos) indicarán si el código huele o no y debe ser algo que un programador experimentado pueda identificar como bueno o malo.

En resumen: busque cosas que deberían indicar un buen código, independientemente del idioma.

Pídales que lo tracen en un diagrama de flujo o que lo guíen como parte de la entrevista. Tienes la excusa perfecta para preguntar y te dice un poco de cómo piensan ver cómo explican.

Si van a saltar a su idioma preferido, sabe que tiene una gran cantidad de tutoría, por lo que debe buscar buenas habilidades de lógica / razonamiento sobre todo de todos modos.

Si van a seguir trabajando en su idioma preferido, tendrá que aceptar que me manejarán un poco con los detalles específicos del idioma hasta que alguien más se ponga al día de todos modos, por lo que tendrá que interactuar con es el lado del diseño allí también.

Dejando a un lado el código con cabeza de hueso / obviamente equivocado, eficiente dependerá en gran medida del compilador / intérprete del idioma en cuestión, y realmente no podrá ver eso desde una muestra de código. Una muestra de código podría estar bellamente escrita y elegante como porcelana fina en tapetes, pero funcionar lentamente si se compila / interpreta mal.

No podrá evaluar el uso idiomático de las características del lenguaje / azúcar sintáctico / convenciones sin cierta familiaridad.

Debería poder saber si está bien escrito en general sobre la base de consideraciones universales como el orden, el flujo de control, el nombre variable, el orden de las operaciones, etc.

Sin embargo, más prácticamente, si sabe cuál será el idioma en el proceso, podría intentar encontrar una o más guías de estilo para ese idioma, ir a la librería y hojear un par de libros para ese idioma y hojee los ejemplos de código en busca de análogos a algo que conozca con el / los idioma (s) de su elección, consulte uno o más proyectos de código abierto que usen ese idioma, y ​​así sucesivamente.

Si tiene el tiempo y no hay una barrera de costos, incluso podría llegar a configurar un entorno de desarrollo para ese idioma y crear una aplicación Hello World, hacer un kata de código o escribir una pequeña aplicación simple en eso. Desarrollará un marco de referencia rudimentario bastante rápido y no solo le dará una ventaja para el propósito específico de revisar el código en cuestión, sino que también se verá obligado por el idioma y se ramificará un poco.

Independientemente del idioma:

• ¿Existen claras separaciones de preocupaciones, uso apropiado de clases (para lenguajes OO), o alguna indicación de intentos deliberados de descomponer el código en 'bloques' reutilizables y modulares?
• Del mismo modo, ¿alguna evidencia de prueba - prueba de unidad o de otra manera?
• Si se trata de un código de producción, ¿está lleno de cadenas de depuración que podrían sugerir una pequeña separación entre el desarrollo y la implementación?
• ¿El código sigue algún tipo de convención de nomenclatura (si te gusta esa convención o no, es irrelevante)?
• Si tiene el archivo, en lugar de una copia impresa, todas las funciones / clases en el archivo se relacionan con el (por lo tanto, si es un archivo llamado data_access_layer , la evidencia de las funciones que procesan imágenes probablemente estaría fuera de lugar).
• Cualquier indicio de falta de confianza para la entrada del usuario también es buena, especialmente para lenguajes basados ​​en la web como PHP. Entonces, estructuras como input = escape (input) al menos te muestran que están al tanto del problema.
• Los comentarios o el código autodescriptivo siempre son buenos. Hay varias escuelas de pensamiento sobre la cantidad de comentarios que deberían estar presentes, pero la ausencia total de comentarios
• A costa de ser cínico, también buscaría en Google parte del código antes de la entrevista. Podría ser fácilmente un trabajo de copiar y pegar, lamentablemente.

No digo que cualquier código que no tenga todo esto sea automáticamente pobre, pero consideraría que estos son indicadores de alguien que ha reflexionado y considerado su práctica.

Sin embargo, para todos estos indicadores, debe preguntar cuál es la razón para que el código sea así. Puede haber una buena razón específica de idioma para sus elecciones ... y después de eso, google es tu amigo cuando ellos y los otros candidatos se van, ¡ya que puedes verificar si lo que dijeron suena plausible ...!

Buena suerte, ya que la contratación de buenas personas es uno de los roles más importantes en su organización;)

Debe pedirle a alguien que conozca el idioma en cuestión que venga a la entrevista o eche un vistazo a la muestra. Es más probable que esa persona encuentre los puntos malos, si los hay.

¿El candidato va a trabajar en equipo? Deje que los miembros del equipo lo conozcan y le hagan preguntas sobre sus habilidades.

Pregúnteles sobre las limitaciones que han encontrado al usar el idioma. Pídales que le muestren una consulta SQL simple. Cualquier desarrollador de Php que valga la pena debería poder realizar una consulta básica de selección / actualización / eliminación sin demasiado esfuerzo.

doug