Increíble tu producto todavía funciona

Ahora te contaré el secreto de la puerta abierta. Listo?



La mayoría del software está muy mal escrito. Al mismo tiempo, ganan dinero con eso. Se puede tener millones de usuarios, pueden ser traducidos a varios idiomas, sin embargo, desde el punto de vista del código fuente y la arquitectura, ser una mierda compilación de antipatrones y código espagueti que va a caer con la primera solicitud generada de forma incorrecta.

¿Es así, por qué y qué hacer?

Rápidamente para aquellos que piensan que tiene un producto que está bien para él y que no pueden leer más.

Primero para los técnicos. Responda usted mismo: sigue los principios de código limpio, SÓLIDO, SECO y todo lo que está escrito en los artículos y, por supuesto, no tiene valores mágicos en el código. Realmente tiene una cobertura de prueba del 100%, tiene un CI / CD automático honesto, su REST usa todos los códigos HTTP necesarios, no solo 200, 201 y 404. Todos los puntos finales y la deuda técnica mínima se describen perfectamente, y el código heredado se refactoriza allí mismo ? Si no, entonces tú mismo entendiste todo. Y todavía no hablé sobre monitoreo y sobre muchas cosas.

Ahora para los gerentes. Chicos, no están trabajando en una cascada, ¿verdad? Bueno, tu scrum es honesto, no equiparas los puntos de la historia a horas o días y haces planes de póker, discutiendo el resultado, ¿verdad? Y definitivamente no tiene ninguna tarea de bloqueo en el sprint y la defensa de hecho, y después de la implementación, la tarea entra inmediatamente en producción. Tiene una hoja de ruta del producto, la documentación y las tareas pasadas a los desarrolladores contienen más de tres palabras y describen por qué estamos haciendo esto, qué estamos haciendo, cómo probar y qué resultará en ello. Y todos los casos de negocios se describen ... Y estas son solo un par de cosas que deben hacerse, todos lo sabemos.

Aquellos que tengan todo esto, pueden terminar de leer el artículo. Ya tienes un muy buen producto. Envíenme una referencia, si es fácil, lo miraré con placer.

Para aquellos que todavía están aquí, y creo que la mayoría de ustedes, comprendamos por qué sucede esto y por qué les conviene a todos.

Esto sucede porque los gerentes a menudo no entienden nada en el desarrollo. Entienden el ROI y el KPI, recibieron MBA, y si tienen algún tipo de experiencia como una educación semi-especializada, entonces no fueron más allá del Hello World condicional. En general, sus plazos están activados, y descomponer adecuadamente una tarea a MVP, sin conocimientos técnicos, es bastante difícil. Esto agrega la aversión de los programadores a los gerentes, obviamente no los ayudarán. Por lo tanto, les queda a los gerentes escribir historias o novelas a las historias y proponer métricas indirectas para comprender si esta o aquella tarea se realizó de manera cualitativa. Sí, solo todas estas métricas son sintéticas, no tienen nada que ver con la calidad del desarrollo, o muy indirectamente.

¿Y qué hay de los desarrolladores? Sí, en realidad nada, la mayoría de ellos no quieren nada, ella ya sabe lo que significan estas letras. El gerente todavía no entiende nada, así que aquí usamos un par de antipatrones y pegamos un par de muletas, comenzamos la compilación sin pruebas, pero ¿por qué comenzarlas? ... y vamos a tomar un café. Todo se decidió por experiencia, por así decirlo. Bueno, pero el hecho de que rompieron el despliegue, no importa, lo cambiaremos con nuestras manos.

Casi nadie quiere entender la teoría, en la industria hay muchos de los que no tienen idea de cómo funciona su marco, pero solo saben qué método usar. Por así decirlo, usa la magia. Debido a la falta de desarrolladores, el nivel de profesionalismo ha disminuido significativamente.

Entiendo que a nadie le gustan las críticas, pero este enfoque es muy cercano. No lo harían de esa manera, no habría lo que describí en los primeros párrafos.

Ahora, ¿por qué se adapta a todos? Sí, sí, se adapta absolutamente a todos. Aquellos que no están satisfechos con esto, o no trabajan en estos productos, o los refactorizan y los devuelven a su forma normal.

Esta situación es adecuada para los gerentes porque ni siquiera entienden la magnitud de los problemas. El producto se ha encendido y está bien, y los usuarios encontrarán errores en la mañana. Escribieron en el informe, obtuvieron un tic, elogió el chef. No son excesivos, por lo que los programadores tienen la culpa. En general, cuando hay alguien a quien empujar, entonces no hay nada que mejorar.

¿Por qué esto se adapta a los programadores? Probablemente porque muchos no pueden hacerlo mejor, porque para hacerlo mejor necesitas trabajar constantemente en ti mismo. Y para muchos ni siquiera hay una pregunta: por qué, si el dinero ya está pagado. Si lees ebanoe.it, se les aconseja directamente que trabajen tanto como para no ser expulsados. Y eso no significa nada.

Entonces resulta un círculo vicioso, algunos no pueden, otros no quieren.

¿Qué hacer con ello? Todos los días para desarrollar. Mejore las tareas, los enfoques, aplique las mejores prácticas y principios. No está de acuerdo con el hecho de que se le ofrece hurgar en él. Haga que no se avergüence de mostrar su proyecto a personas de afuera. Y hazlo en ambos lados. No hay otra receta.