Codificación: Genius vs. Monkey

Recientemente, un cliente que buscaba construir una aplicación grande con un presupuesto propuso una gran pregunta. Estaba decidiendo si debía contratar a una empresa, contratar a un desarrollador a tiempo completo o obtener un pasante de una universidad local para desarrollar su solicitud. En un momento, dijo: "¡El problema es que no sé cuánto de la codificación es genial y cuánto puede hacer un mono!" Me di cuenta de que esta es una pregunta pertinente que ayudaría a muchos de nuestros lectores. Aunque la respuesta varía del proyecto para proyectar, creo que puedo arrojar un poco de luz aquí. Un fondo rápido Voy a simplificar la codificación en dos partes. El interfaz y el backend. El frontend es cualquier cosa que el usuario final verá en la web. Esto es probablemente lo que piensas cuando alguien menciona un sitio web. El backend es todo lo que sucede detrás de escena, lo que en algunos casos es mucho más complejo que la parte delantera. Por ejemplo, la codificación de back -end implica cálculos complejos o extrayendo contenido de bases de datos. Para sitios particularmente complejos, me refiero al backend como el "trabajo pesado". Prueba futura Entonces, para explicar qué partes de la codificación son geniales y cuáles son tan triviales que un mono podría hacerlas, comenzaré con el interfaz. Hay un factor muy importante en el desarrollo frontend que yo llamo "pruebas futuras". La prueba futura es muy importante para nosotros en Brolik, y creo que es un signo seguro de profesionalismo cuando se hace bien. La prueba futura incluye tres factores principales. El primero es Escalabilidad . El código debe escribirse para asegurarse de que esté listo para futuras adiciones. Esta podría ser una nueva herramienta que sale o una nueva tendencia que surge en la web. Si el cliente regresa con una solicitud después de que termine un proyecto, nunca queremos decir: "No, no puede agregar eso sin comenzar desde cero". El segundo factor es Actualización . Después de codificar inicialmente un sitio web, a veces necesitaremos hacer cambios específicos o globales sobre cómo se ve o funciona en la interfaz. Si se codifica correctamente, debe ser simple y rápido hacer estos cambios globales. Esto requiere un código organizado adecuadamente estructurado que esté bien comentado ( ¿Qué comenta el código? ). El tercer factor de prueba futuro se ocupa de estándares y depreciación . La web siempre está cambiando, y a veces bits de código se "deprecia" y finalmente eliminan eliminando. Además, las "mejores prácticas" del sitio web cambian con el tiempo, y el código que solía ser de vanguardia finalmente se vuelve desactualizado. Sin embargo, hay suficiente documentación por ahí, para que un buen desarrollador pueda saber qué se desactualará pronto y evitarlo. Como habrá adivinado, toda esta prueba futura cae bajo el lado genio de la codificación. No hay muchas sorpresas peores que recoger un proyecto de otra empresa y darse cuenta de que no fue escrito de una manera que facilita la modificación. El código "oculto" del backend Algunas partes de un sitio web o aplicación están más establecidas en piedra, y un buen codificador dividirá estas partes en archivos "ocultos" separados que se ejecutan en segundo plano. Si está familiarizado con la codificación, estas piezas serían JavaScript incluyen o archivos de clase PHP, por ejemplo. Lo más probable es que controlen las funciones comunes o estándar, como un carrito de compras de comercio electrónico. Estos archivos toman información, la procesan y luego obtienen nueva información para que el frontend del sitio web se muestre al usuario final. Debido a que este código generalmente está basado en funciones y es poco probable que cambie mucho en el futuro, no es tan importante ser a prueba de futuro o escrito con la legibilidad humana en mente (es una buena práctica formatear el código para que sea fácil para un humano mirar y evaluar qué es lo que es). Mientras este código "oculto" funcione según lo previsto, importa menos qué tan bien se escribe el código. Por esta razón, el "levantamiento pesado" generalmente puede ser manejado por cualquier codificador con un título de informática o tecnologías de información. Por supuesto, la experiencia y la habilidad individual tendrán un nivel aquí, como llegaré a continuación. Complejidad del proyecto A veces, esa parte de backend de elevación pesada de un sitio web o aplicación es mucho más compleja, importante o sensible que un proyecto típico. En este caso, estarías mucho más seguro en manos de un genio. Debido a que hay diferencias en el código bueno y malo, los casos en que el código malo es una posible amenaza de seguridad (como los sitios que manejan tarjetas de crédito o almacenan grandes cantidades de información corporativa confidencial) no deben dejarse en un mono. Compare las medidas de seguridad de datos y los estándares de cumplimiento de diferentes proveedores de pagos de la tarjeta || 80 card payment providers . Knowing when you should hire a genius and when you can get away with a monkey will surely still be a challenge if you aren’t a coder yourself. Learning and understanding these general concepts can, however, go a long way for a business owner.