Mejor respuesta
Pregunta interesante. Para mí, el término «artesanía» implica algo sobre la forma en que se escribe el código real, más que sobre el diseño del sistema de nivel superior. Yo diría que el código bien elaborado hace lo siguiente:
- Sigue estándares externos
- Sigue estándares internos
- Utiliza buenos patrones
- Es legible
Sigue estándares externos. Si su grupo tiene estándares de codificación, sígalos. Si no lo hace » Si te gustan los estándares, aún sígalos.
Sigue los estándares internos. Esto significa que el código debe ser coherente internamente. Los métodos que hacen cosas similares deben presentarse de la misma manera. Si un método sigue el patrón:
if (success) {
doSomething();
} else {
handleError();
}
no tengo otro método que comience:
if (!success)
{
handleError();
Utiliza buenos patrones. Con esto me refiero a patrones de codificación en lugar de patrones de diseño. Su código debe usar modismos apropiados para el lenguaje. (Use scoped\_ptrs para la administración de memoria en C ++, por ejemplo). objetos que no se utilizan en todas las rutas del código.
Es legible. Otros ingenieros leerán su código y usted volverá a leer en un año. El código debe ser lo más fácil de entender posible. Todos los elementos mencionados anteriormente están relacionados principalmente con la legibilidad y con la minimización de elementos inesperados en el código. Sus lectores deben preocuparse por la lógica de su código, no por tratar de averiguar por qué se ha utilizado una construcción no estándar. Si hay una construcción no estándar, sus lectores deben saber que está ahí por una razón, no porque cometiste un error. (Piense en su código como si fuera un mueble. La superficie debe ser lisa y no debe atrapar una astilla si pasa la mano sobre ella. Cualquier irregularidad debe estar allí por una razón).
La legibilidad también se mejora mediante métodos sensibles y nombres de variables, y mediante comentarios apropiados. No se exceda en los comentarios. Si es obvio, no se moleste en explicarlo. Pero tenga algún tipo de descripción general para que el lector conozca el contexto. (Puede ser obvio que el código está transformando la entrada X en la salida Y, pero ayuda si el lector tiene alguna idea de por qué es necesario).
Respuesta
Los gerentes son como niños pequeños. Quieren lo que quieren y lo quieren AHORA . Pero a diferencia de los niños pequeños, los gerentes recuerdan a medias los artículos de Harvard Business Review que citan (sin proporcionar referencias) para justificar sus demandas. Han aprendido una serie de argumentos que desconciertan a algunos desarrolladores.
Dicen: «No podemos permitirnos hacerlo bien. ¡Tenemos que conseguirlo en el mercado AHORA ! ”. No es cierto, lo sabes. Si apresuran su código espagueti a la producción, tienen la oportunidad de enojar a sus clientes de lanzamiento ahora, pero el código no puede escalar. Simplemente significa que su negocio se tambalea por un tiempo antes de colapsar.
Dicen: «Lanzaremos una versión beta para nuestros clientes de lanzamiento». Lo que quieren decir es que quieren que publiques un código perfecto y agradable para el cliente antes de lo que lo harías, solo porque acordaron llamarlo un programa de prueba beta. Es un pensamiento mágico, como creer en Santa Claus.
Dicen: «Te prometo que reescribiremos el código más tarde si publicas tu código medio terminado y de mierda AHORA ! » ¿No suena como «Limpiaré mi habitación más tarde, papá, si puedo ver televisión y comer bocadillos azucarados AHORA ? El problema es que más tarde nunca llega. Todos los días, el gerente tiene la opción de agregar nuevas funciones o limpiar la habitación desordenada que es su base de código. Adivina a cuál le dan prioridad. Y adivina qué, la habitación se vuelve más y más desordenada, por lo que tomará más y más tiempo limpiar. También es más difícil trabajar (para crear nuevas funciones) debido a todo el desorden.
Finalmente, dicen: «Hemos invertido demasiado en esta base de código. Llevará demasiado tiempo reescribirlo. ¡Necesitamos características AHORA ! » Solo cada función tarda dos o tres veces más en codificarse, debido al espacio desordenado que los desarrolladores de software llaman deuda técnica.
Los buenos desarrolladores, como padres pacientes y amorosos, deben detener la locura. Tienen que insistir con firmeza, «Lo siento amor, pero su artículo de HBR dice:» Los ingresos antes, mejor, en igualdad de condiciones . Debe leerlo con más atención.Todas las demás cosas no son iguales si acumula deuda técnica. ¿Qué tal si le damos prioridad a las funciones y tal vez haya algo para que usted venda antes? algo como un código perfecto y agradable para el cliente hasta que se eliminen todos los errores y se implementen todas las funciones.
Debe decirles: «No podemos permitirnos no utilizar buenas prácticas. Vivimos o morimos, pero tenemos que hacer ciertas cosas para vivir, como escribir pruebas y documentación. No es una opción «.
Tienes que sonreír y decir:» Nunca reescribiremos este código. Sé que tienes buenas intenciones, pero cuando se trata de corregir el código o agregar nuevas funciones, sé lo que dirás. Es lo que siempre dice ”.
Al ser un padre firme, ayuda a su gerente a convertirse en el tipo de líder empresarial que usted le gustaría trabajar.