Brevemente sobre lo que es más preocupante en el mundo moderno del desarrollo y por qué necesita probar, aprender, probar y no ser flojo.
Soy desarrollador, pero hace mucho tiempo que no escribo el código
Nichrome no eres un desarrollador.
Si crees que escribir código es un requisito opcional para un buen desarrollador, sal de este planeta. Hay muchas oportunidades para vivir, pero deja de escribir código. Puede ir a la administración, puede migrar a la administración de personal, puede subir a una posición alta, o simplemente puede ir al monasterio. Pero en cualquiera de estas situaciones, deja de ser desarrollador si ya no escribe código.
Por qué Primero: el código no es una bicicleta, si no practicas, lo olvidas. En segundo lugar: los desarrolladores se ofenden mucho cuando "algún tipo de gerente" está tratando de hacerse pasar por los suyos (sí, en general, esto es cierto para cualquier profesión). En tercer lugar: es perjudicial para el CSV; Si se mudó a otra área / industria, aumente su habilidad con carisma nuevamente y no arrastre referencias a éxitos pasados (vea el último pecado).
De los ejemplos.
- Una vez estuve en una entrevista en la oficina estadounidense. Allí, en una de las etapas, un caballero que se presentó como CEO comenzó a preguntarle ferozmente sobre Ruby por escrito (en el sentido de las plantillas preparadas en Google). A las preguntas sobre si escribe el código en sí mismo y por qué tanta indecencia para preguntar a los solicitantes, con tacto cambió la conversación y pidió que se concentrara en las tareas.
- Hay un administrador de recursos familiar que trabaja como psicólogo en su tiempo libre. Entonces, este caballero, hasta ahora, escribe el código en su tiempo libre y, a veces, puede sorprender enormemente al candidato con conocimiento curioso en un área aparentemente poco característica. Parece que no es un programador, pero todos lo toman por su cuenta.
Realicé pruebas, ¿por qué probar la aplicación con mis manos?
Confiar únicamente en los resultados de las pruebas (incluso si entre ellos, dummies integrales de extremo a extremo) es un pecado grave. Al menos una vez durante el desarrollo de cualquier función, debe tomar y usar sus manos para hacer clic en todo el ciclo de esta función. En primer lugar, conocerá un poco mejor la plataforma y la forma en que el usuario la ve, y no cómo está organizada en su interior. Y en segundo lugar, sigue un nuevo escenario y sentido común y puede encontrar algo obvio para usted, pero invisible para las pruebas automáticas. En cualquier caso, las pruebas automáticas son una adición a la verificación manual por parte del desarrollador, no un reemplazo para ella.
Inmediatamente diré sobre las características. No estoy hablando de pruebas manuales completas por parte del desarrollador, hay técnicos de control de calidad especialmente capacitados para esto. Estoy hablando de la necesidad de ejecutar un proyecto local y la verificación mínima de cualquier cambio allí. Y luego en autotests, en la doncella, etapa, preprod y prod.
Entonces sí, debería haber holivars sobre la complejidad de muchos proyectos y su "incapacidad" para ejecutarse localmente. Personalmente, no creo en proyectos tan épicos. Pero en la pereza y la codicia, creo. Por lo tanto, repasemos brevemente los posibles problemas de lanzar un proyecto localmente.
- Un pequeño proyecto independiente: ¡ no hay obstáculos para los patriotas!
- Muchas integraciones externas. Entonces tienes cajas de arena para cada uno de ellos. O tiene talones o emuladores locales de servicios externos. O tiene grandes problemas que serán despedidos pronto.
- Muchos microservicios. La conclusión es el párrafo anterior. La única diferencia es que las posibilidades de emulación local se están expandiendo. Por ejemplo, un conjunto de acopladores con microservicios reales en lugar de apéndices.
- Se necesitan muchos datos para que el proyecto funcione. Pero muy raramente necesita una matriz de datos de varios terabytes completa para el desarrollo. Y si aún lo necesita, se crean varias instancias para desarrolladores para esto. Por ejemplo, 2-3 instancias enormes por equipo de 10-15 desarrolladores. Entonces, sí, no es muy conveniente y costoso para las empresas, pero de lo contrario pagará aún más por el desarrollo de la producción, que se llevará a cabo independientemente de los deseos de los altos directivos.
- Un monstruoso monolito que funciona en un hierro específico y solo en la fase correcta de la luna. Si es así, lo más probable es que esté en una empresa sangrienta y el sentido común no funcione allí.
Ya sé lo suficiente y ya no puedo aprender
En resumen: "el que no se desarrolla, se degrada".
En ciencias teóricas, hay casos en los que puedes encontrar la base y detenerte en ella. Todo es más o menos estable, probado e inmutable allí. Las leyes físicas, afortunadamente, no cambian cada cinco años. Entonces, si no vas a la vanguardia de la ciencia, puedes vivir e incluso trabajar. Aquí, por ejemplo, están las integrales a lo largo del contorno: Feynman las resolvió en Los Alamos después de la Segunda Guerra Mundial y ahora se resuelven por aproximadamente los mismos métodos analíticos.
Pero con el desarrollo y la programación no funcionará así. Todavía no se ha encontrado un único lenguaje de programación divina invariable (el concepto de Avalanche es interesante, pero aún no está abierto). La velocidad de la tecnología cambia de un par de décadas en el caso de sistemas operativos y bases de datos a un par de meses en el caso de JavaScript. Y si no se desarrolla, en uno o dos años puede perder el nivel, y en el período de cinco años simplemente obtiene cero.
Para no ser demasiado holístico acerca de la velocidad del cambio tecnológico, daré un par de ejemplos. Hay un libro de Kernigan y Soldering 1992 embotellado. Al usarlo, puedes aprender Unix bien y no sorprenderte mucho con los cambios que ocurrieron 15 años después. Puede tomar el libro de Tom Kite sobre Oracle 8, que se lanzó alrededor de 2000, y no se sorprenderá mucho de las diferencias que ocurrieron en la versión 18c. Pero cualquier libro sobre JS hace cinco años se puede poner en marcha de forma segura.
Soy lo suficientemente genial y no puedo probarlo
En mi opinión, este es el más difícil y el más común.
Desafortunadamente o afortunadamente, necesita demostrar sus habilidades, idoneidad profesional y cordura toda su vida. Cuando deja de hacer esto, puede descubrir que está jubilado, que tiene demencia o que se ha agotado. En cualquier caso, debe consultar a un especialista.
La frecuencia de la evidencia es diferente. En el caso de amigos y familiares, la prueba no es necesaria tan a menudo. Y en el caso de extraños, de forma regular y completa. Los lugares donde se necesitan pruebas son muy diversos: en entrevistas, conferencias, nuevos colegas, nuevos amantes ... incluso en la tienda, si la compra es un poco más complicada que un taburete.
Si crees que una historia sobre tu experiencia sin confirmación de habilidades es normal y suficiente, visita un planeta vecino. En cuanto a mí, esto se llama fopping y arrogancia.
Con respecto a los ejemplos en esta área, es estricto, porque la mayoría de ellos son negativos y, creo, el lector recordará algo adecuado de su experiencia. Y con lo positivo es aún más difícil, ya que no se notan y simplemente resultan en un diálogo constructivo. Por lo tanto, confío en la experiencia de vida del lector y espero que todos den un buen ejemplo.