El código de baja calidad puede ser un costo adicional en el desarrollo del sitio e, incluso peor, todo el negocio. Muchos empresarios no tienen idea sobre programación o tampoco puede obtener ayuda de una persona técnica en esta área. Por suerte, puedes comprobar código de calidad por ti mismo. ¿Te preguntas cómo? Simplemente siga las instrucciones especificadas en ¡Este artículo!
Primero: prevención
Antes de comenzar la cooperación con un programador, vale la pena verificar la calidad del código que se crea en un empleado potencial. ¿Cómo hacerlo? Es mejor solicitar una muestra de código de forma privada o mediante un servicio similar a Github. Verifique el código con la clave obtenida o solicite a un programador experimentado una evaluación inicial.
¿Qué afecta la mala calidad del código?
Hay varios elementos que afectan la mala calidad del código. Y, de hecho, la negligencia del programador no siempre es la principal. Usted, como comisionado, también puede contribuir a reducir la calidad del código al:
- tiempo de entrega demasiado corto,
- proyecto mal planificado, especificación preparada con prisa, </li> <li> mala estimación del alcance y presupuesto del proyecto, por lo que el programador agrega cambios adicionales dentro del mismo presupuesto,
- donde hay seis programadores, también hay … olor a código: intente mantener un equipo permanente y conocido,
- el proyecto / cooperación con usted es único, lo que reduce el compromiso,
- aprenda los conceptos básicos del lenguaje de programación, en el que se lleva a cabo su proyecto.
¿Por qué el código pobre es tan malo?
Hay varias razones y todas tienen un impacto negativo en los negocios:
- el desarrollo y mantenimiento del código es costoso,
- puede ser necesario reescribir el proyecto desde cero,
- es difícil encontrar programadores dispuestos a trabajar con código de baja calidad,
- puede detener o ralentizar el desarrollo empresarial,
- seguridad reducida,
- genera errores, que son difíciles de identificar y corregir.
Desorden en el código
Abra algunos archivos y mire de cerca el código. Si en lugar de un texto agradable, con formato regular que no entiendes en absoluto … ves un desastre que ni siquiera puedes leer, entender, interpretar en absoluto ni vea ninguna lógica; luego informe al contratista sobre sus inquietudes.
Convención de nombres y nombres
Si de alguna manera te has ocupado de la programación, sabes qué funciones y variables son. Si no estás familiarizado con eso, 5 minutos de lectura de alguna guía te permitirán reconocer funciones, clases, variables en código probado. Lo que debería alarmarte:
- Entradas no en inglés,
- nombres incomprensibles, por ejemplo: xyz () en lugar de addUser (),
- inconsistencia en el formato, por ejemplo, nombre de función, nombre_función, nombre_función.
<!- Demasiados comentarios->
Puede parecer que / * comenta en el código que describe el procedimiento de todo * / Parece una buena práctica. Bueno, no exactamente, especialmente si el contratista tuvo problemas en el párrafo anterior y trató de ponerse al día utilizando comentarios. En definitiva, el código debería ser comprensible sin una descripción adicional. Los comentarios solo deben usarse cuando Eso no es posible.
Suficientes marcos son suficientes
¿El contratista aconseja el uso de muchos marcos diferentes? Si es así, vale la pena considerar si todos ellos son necesarios. Duplicar marcos que realizan las mismas tareas es La forma más fácil que lleva a un código complicado. Como resultado, el sitio será más pesado y Más propenso al fracaso.
Nuevas tecnologías o oldies, pero goldies
Es muy fácil verificar si el contratista usará el marco que aprendió X años
Hace mucho tiempo (y todavía está tratando de llevarlo a los clientes), o tratando de convencernos de innovar. En En ambos casos, esto puede llevarnos a problemas de mantenimiento con respecto a nuestro sitio web.
Compruebe la forma en que se ejecuta el repositorio
En el caso de crear sitios web, no necesitaría un repositorio, pero si tiene acceso a uno, le permitirá realizar un seguimiento del progreso del trabajo. También después del llamado “Commits” y su descripción, puede evaluar cómo se ejecuta el proyecto. Si la descripción de el “commit” único no tiene sentido y no proporciona ninguna información, puede ser difícil para encontrar en el futuro.
Solicitar pruebas
En el caso de las aplicaciones, las pruebas unitarias deben escribirse al mismo tiempo. Su tarea es acelerar las comprobaciones de código. Además, imponen más atención a la calidad del código.
sí mismo.
Si acabo de enmarcar a su programador …
porque te motivé a inspeccionar la calidad del código, pido disculpas por el problema. Dependiente En sus contratos y obligaciones, debe indicar las fuentes del olor del código, describir un plan de recuperación y lo que es importante, impleméntelo lo antes posible, para no continuar El callejón sin salida.
Y finalmente, les deseo proyectos exitosos con código de alta calidad. 🙂