Todo lo viejo un día se vuelve nuevo otra vez. Llega un momento en que incluso los programadores experimentados pisan el mismo rastrillo. No es posible enumerar todas las "reglas no escritas" de ninguna disciplina, en parte porque muchas de ellas ni siquiera son reglas . Esta es a menudo una forma de reformular verdades abstractas y eternas.

Marie Kondo hizo una carrera aplicando los principios universales de eficiencia, limpieza y belleza a la tarea doméstica de la limpieza. Resulta que muchas personas solo necesitan un traductor entre la sabiduría eterna y su vida cotidiana para realmente "entender" el significado de lo que sucede a su alrededor (ver también "Zen y el arte del mantenimiento de motocicletas" ). Esperamos sinceramente que disfrute nuestro intento de hacer lo mismo para la programación.

1. No hay depósitos los viernes

Incluso si tiene un sistema de implementación continua. El viernes es el día más inapropiado para iniciar el maestro, por la razón obvia: solo queda medio día para arreglar posibles jambas. Por lo general, después de las actualizaciones, se observan aumentos repentinos en los tickets de soporte técnico, especialmente después del lanzamiento de nuevas funciones e, inevitablemente, nuevos errores. La gente los viernes tiene sueño, falta de atención, tiende a posponer todo hasta más tarde ... ya sabes cómo sucede.

¡Nadie es inmune a las fuerzas de otro mundo que siempre eligen viernes por errores! Por lo tanto, observe las mejores prácticas y, si no está seguro, preste atención a los líderes de la industria. Por ejemplo, Apple supuestamente hace lanzamientos los martes , dejando suficiente tiempo en ambos lados de un evento tan crítico como el Despliegue: el lunes para probar y detectar los últimos errores, y de miércoles a viernes para realizar cambios urgentes. Y con las ganancias de Apple, te das cuenta de que su modelo de despliegue se lava con sangre y sudor.

2. Copias de seguridad regulares

Es difícil sobreestimar la importancia de las copias de seguridad periódicas. Toda nuestra industria se basa en un sistema de copia de seguridad progresivo abstracto. Por supuesto que estoy hablando de Git, pero eso no es suficiente. Su base de datos, claves criptográficas, archivos de configuración, imágenes de VM, imágenes / videos ... incluso los paquetes importados deben almacenarse de forma segura donde siempre estarán disponibles en caso de emergencia. Si no tiene un sistema automatizado, deje que al menos un par de empleados archiven regularmente la carpeta de trabajo y la copien en una unidad externa. Sí, solo un par: la redundancia no es superflua.

Probablemente nunca necesitará 9 de cada 10 copias de seguridad. Pero un día, como lo estoy hoy, ¿querrás volver al pasado y descubrir exactamente cuándo cometimos este error discreto pero completamente mortal que nadie ha notado? Entonces se alegrará de haberse tomado el tiempo para hacer una copia de seguridad. O bien, cuando un nuevo empleado elimina accidentalmente 100,000 líneas de código. Sucede No guardamos rencor a las personas, sino que aprendemos de los errores. ¡Haga copias de seguridad, incluso si es difícil!

3. Obtenga la especificación completa antes de comenzar el desarrollo

A menudo sufro el síndrome de "comenzó demasiado temprano". Más de una vez tuve que reescribir grandes fragmentos de código, porque no hice suficientes preguntas en las primeras reuniones con el cliente, donde describió los contornos de la tarea. Nuestro cerebro es realmente pequeño y odia la precisión, especialmente cuando la precisión es compleja y costosa (léase: necesario para el cliente). Encuentra similitudes donde ni siquiera está cerca. Esto es especialmente cierto en el diseño de programas: en una aplicación bastante compleja, diez botones similares realizan una docena de tareas completamente diferentes. Antes de comenzar a codificar, debe captar estas sutilezas si desea aprovechar al máximo su tiempo y el de los clientes. No seas como yo o mi cerebro. Dibuje todo en papel, asegúrese de que todo esté claro y, si es necesario, puede volver a dibujar el sistema desde cero (teniendo en cuenta el tiempo de preparación suficiente, todos somos humanos).

Nadie logrará la perfección en este proceso. Todavía confío demasiado en las conjeturas. Pero desde que me di cuenta del problema, las suposiciones infundadas se han vuelto menos. Debería pensarse como una computadora: inequívocamente y sin pensar en su lógica. En el concepto de diseño de sistemas, estudie situaciones fronterizas, sea un "defensor del probador", y probablemente encontrará un diseño que elimine de inmediato las clases enteras de errores que se permiten en un diseño menos considerado.

4. Si ves tonterías sin importancia, dilo

Intente detener suavemente o evitar discusiones improductivas antes de que se salgan de control. Nuestro tiempo de oficina es casi tan valioso como las 3-8 horas que pasamos inconscientes todas las noches, es decir, ¡es muy importante! Desde el punto de vista comercial, cuantas más personas haya, más efectiva debería ser la reunión, porque el pago por hora se multiplica por 20-500 desarrolladores en una habitación / sala de conferencias / etc. Esto es dinero loco, especialmente en la soleada California con sus salarios. El tiempo es dinero! Y estamos trabajando con este dinero inventando trucos intelectuales alrededor de monstruos con tentáculos que están ocultos detrás de cada base de código y solo esperamos para romper expectativas inocentes con errores crueles y accidentes.

Pero no siempre deambulamos por catacumbas de código olvidadas con una antorcha temblorosa y una frente sudorosa. A veces nos sentamos en reuniones o discutimos algo tenso fuera de las reuniones formales. Slack es famoso por aumentar la cohesión del equipo, pero ¿a qué costo (aparte de una tarifa mensual)? En mi experiencia, Slack aumenta dramáticamente el "tiempo sin sentido" de su cerebro: el tiempo necesario para filtrar otro flujo constante de alertas de sonido (a menudo inapropiadas) cuando intenta hacer lo que la compañía le paga; es decir, desarrollar y reparar código útil. Y las personas caen fácilmente en disputas innecesarias.

Está bien pedir que finalice la discusión si toma demasiado tiempo. Hoy en día, a los niños les gusta decir que "el presente ve el presente": personas que realmente hacen un trabajo real, ayudan a los clientes, a los usuarios y al mundo; estarán agradecidos por pedirle que termine la discusión sobre si el nuevo refrigerador debería ser negro o cromado. "Sí, arrojas una moneda, cuál es la diferencia ... tenemos problemas más serios". Y muchas de las personas que te prestan atención serán del liderazgo.

Gracias por acompañarme en este viaje. Que veas la misma sabiduría que aquellos que escribieron estos consejos antes que nosotros. Y, por favor, si en su experiencia ha aprendido algunas otras reglas tácitas, ¡escríbalas y háganos saber!