Entorno sin culpa: nadie debe escribir código de calidad

En RIT ++, Nikita Sobolevn ( sobolevn ) pronunció, como él mismo lo llamó, un sermón sobre la calidad del código y los procesos en la empresa. Particularmente sensible, sírvase té de manzanilla, pero no le ofrecemos alejarse de las pantallas. Puede estar en desacuerdo con cualquiera de las tesis, insistir en que hablar sobre programas de televisión es la clave para una atmósfera saludable en el equipo, y afirmar que no necesita un marco estricto de linter y CI para escribir un buen código. Pero si alguna vez culpó a otros por fallas en el trabajo, debería leer o ver la historia de Nikita.

¿Alguna vez has trabajado en un mal trabajo?

Trabajé por mucho tiempo. Mi compañía fue terrible. Todo fue muy malo, para nada, todo está fuera de lo común. Tuvimos procesos repugnantes, clientes odiados y desarrolladores ineptos. No se pudo hacer nada al respecto. Cuando todo está tan mal, simplemente no sabes qué llevar ni por dónde empezar. Te sientes como un diente miserable que no puede influir en nada.



Cuando digo que todo está mal, quiero decir que tuvimos:

• código incorrecto: nadie pensó en la calidad del código, nadie pudo siquiera formular cuál es la calidad del código.
• malos procesos
• no pudimos comunicarnos normalmente,
• No hicimos lo que el cliente quería.

Sí, fue un desarrollo subcontratado, pero eso no lo hizo malo. La gente la hizo así.

"Las personas están haciendo un mal trabajo, son las personas las culpables del hecho de que los procesos son malos, el código es pobre y los clientes son malos", este pensamiento me atormentó durante muchos años. La gente tiene la culpa del hecho de que no disfruto mi trabajo.



Atribuí todos los pecados posibles a las personas y pensé que eran la principal fuente de problemas. Esperaba que algún día cambien, u otros aparecerán, y todo estará bien.

Con toda seriedad, pensé en el hecho de que otras compañías emplean a personas fundamentalmente diferentes que difieren en sus cualidades internas y profesionalismo, y que estas otras personas son de una prueba diferente.

Pero en algún momento comencé a adivinar que quizás la gente no tiene la culpa, tal vez un error en un nivel diferente, en algún lugar algo salió mal mucho antes. Y luego aparece el camino a la corrección. Solo entonces puedes salvarte como desarrollador.

Me di cuenta de que necesitamos una revolución, que todo tiene que cambiar: la forma en que trabajo, cómo me siento, que ir a trabajar no se convierte en una prueba para mí. Quería trabajar en un buen lugar.

Solo había un problema: era mi compañía .



Soy la persona que comenzó esta revolución.

Me di cuenta de que necesitas cambiar todo para disfrutar de tu negocio favorito nuevamente. Me encanta programar, estoy listo para hacerlo 12 horas al día y llamarlo mi descanso y mi trabajo.

Por lo tanto, percibí todas las fallas muy dolorosamente. No solo estaban conectados con mi negocio favorito, estaban conectados con mis finanzas, con mi sentido de identidad y las relaciones con otras personas y se reflejaron fuertemente en toda mi vida. Cuando algo no me funcionaba, no podía descansar, no podía pensar en otra cosa.

Decidí que lo más importante que puedo hacer ahora para mejorar mi vida es hacer bien mi trabajo. Para esto, necesitaba repensar todo el caos que teníamos y ponerle orden.



Pero cuando observa el caos, no ve patrones, nada que indique cómo debería ser.

Crear orden a partir del caos es un acto de creación que es difícil.

Debe comenzar desde el principio para comprender cuándo todo voló al caos. Debe determinar un nuevo orden y explicarse qué hacer. Estas son hermosas palabras: "¡Hagamos todo bien!". Pero vienes a trabajar y realmente no entiendes qué emprender para cambiar todo, no hay ideas.

La educación que recibió y los libros que leyó no ayudan, porque todo lo que hizo antes lo aprendió de estos libros y de esta educación.

Declaración del problema.

Entonces pensé: ¿cuál es el mayor problema? ¿Dónde está el punto más doloroso que no permite vivir y trabajar? Me di cuenta de que esta es una declaración del problema . Para mí, establecer una tarea siempre ha sido bastante opcional.

Creo que muchos de ustedes han visto la tarea desde un encabezado "Arreglar el error en el producto". Teníamos muchos de estos, los escribí en una línea, y luego la gente hizo algo mal y trató de arreglarlo mal. Pensé: “¿Por qué no piensan con sus propias cabezas? Que haces Debe corregir un error simple y no hacer todas estas tonterías ".

Entonces no me di cuenta de que realmente establecí mal las tareas. Pero en algún momento todavía me di cuenta de que necesitaba hacer esto de una manera completamente diferente, y desarrollé varios principios.



Las tareas deben ser cortas . No en términos de describir cómo "corregir un error en el producto", sino de naturaleza breve. Las tareas pequeñas y cortas son convenientes para hacer. Son comprensibles para cualquiera: un desarrollador principiante, promedio y experimentado. Todos pueden entender esa tarea y hacerlo, por ejemplo, en medio día de trabajo. Puedes comenzar con esto.

Las tareas deben ser ordenadas . Cuando establecen tareas, a menudo no piensan en qué orden deberían hacerse. Pero las tareas pueden bloquearse entre sí, paralelizarse o agregar complejidad adicional a otras tareas si se completan con anticipación, etc.

Se dice muy poco sobre el orden de las tareas: se llevan a Jira o Trello, y luego se llevan desde allí. Pero pocos piensan, y en qué orden, por qué y por qué el orden es solo esto.

Todas las tareas deben ser individuales . ¿Qué significa esto? Las tareas son entidades que existen dentro de un proyecto y siempre pertenecen a alguien. A veces, justo en la descripción del problema puedes encontrar: “Sergey, Masha, corrige esto. Ya sabes cómo hacerlo. No puede hacer esto, necesita dar todo el contexto para que esta tarea se vuelva individual en sí misma, para que cualquier persona que la lea pueda cumplirla. Para que no haya conocimiento disperso sobre el proyecto, y no hay significados ocultos en el marco de esta tarea.

Cuando las tareas se volvieron individuales, cortas y ordenadas, la gente comenzó a hacerlas como yo quería.

Simplemente cambiando la forma de comunicación, me aseguré de que las mismas personas que habían hecho estas tonterías comenzaran a hacer lo que yo quiero: ¿no es mágico? ¿No es esto una prueba de que mucho es fácil de cambiar? Y comencé a profundizar en este tema.

A menudo le fallamos al cliente, no hicimos lo que lo beneficiaría. Pensé que si los desarrolladores comenzaban a comprender nuestras tareas y a hacerlas como deberían, ¿pueden entender lo que el cliente realmente quiere y hacer lo que el cliente quiere?

Traté de combinar esto en una especie de figura de dos caras, que por un lado piensa como un desarrollador, por otro lado, como un cliente.



Esta no es una tarea nueva. En general, este enfoque se llama Diseño impulsado por dominio y se ha aplicado con éxito durante muchos años. Decidí tomar lo mejor: una forma de comunicación, herramientas, tecnologías y tratar de hacer que los desarrolladores entiendan lo que hay que hacer para satisfacer los deseos del cliente.

La tarea fue muy difícil y todavía estoy trabajando en su solución. Pero desarrollé una fórmula simple para mí.

Requerimientos Todo comienza con ellos, el cliente nos expresa su voluntad a nosotros, los desarrolladores, en forma de requisitos. El cliente dice condicionalmente: "Exijo que la página de inicio de sesión funcione". Su conciencia comienza, garabateando en forma de tablas, listas, gráficos, etc. Los requisitos permanecen con usted como la parte más importante de su proyecto. Esto es lo que haces al más alto nivel.

Pero estos requisitos no son operativos para el desarrollador, son demasiado altos y sin procesar. Para comenzar, el programador necesita documentación.

La documentación y los requisitos son hermanos gemelos, esta es la doble unidad. Requisitos: esto es lo que debe hacer y la documentación: cómo hacerlo.

Cuando me di cuenta de que, en principio, la documentación se puede generar a partir de los requisitos, esto se convirtió en una parte importante de nuestro proceso comercial. Aprendimos a registrar requisitos en un formato especial y generar documentación.

Pruebas El siguiente paso lógico es verificar que funcione. Comenzamos a probar nuestros requisitos para asegurarnos de que realmente estamos haciendo lo que se necesita.

Lo más interesante es que no inventé nada, no escribí una sola línea de código para que esto funcione. Acabo de tomar las tecnologías existentes y recibí: requisitos, son documentación, son pruebas.

El siguiente paso lógico fue extraer el código de todo, porque el código es en lo que estamos directamente involucrados.

Código : por el bien de lo cual todo se inició realmente. Al parecer, para que el cliente y el desarrollador se conecten, debe meterse en uno de ellos en la cabeza y asegurarse de que se entiendan entre sí. Pero para entrar en la cabeza, puede tomar las mismas herramientas y conectarlas para que el desarrollador comience a comprender lo que está sucediendo. Aquí puedes leer cómo lo hago en la práctica.

Tan pronto como combinamos (¡el Código es uno!) Los desarrolladores y el cliente con la ayuda de un entretejido tan ingenioso de diferentes entidades, logramos muy importante: nuestros desarrolladores finalmente comenzaron a hacer lo que el negocio necesitaba . Dejaron de introducir algo así, porque vieron los requisitos y los entendieron, entendieron lo que había que hacer.

Para asegurarnos de que ejecutamos, tenemos pruebas escritas en forma de requisitos, y estos requisitos son lo suficientemente claros como para implementarse en un lenguaje comprensible en el código, y escribimos un buen código de acuerdo con estos requisitos.

Comunicación

Ya he mencionado la "comunicación" muchas veces. Me encanta hablar con mis amigos y familiares, pero no en el trabajo. En el trabajo, tengo que comunicarme con la gente; no los elegí sobre esta base. Muy a menudo, la comunicación en el trabajo no ayuda .

Todos nos comunicamos con colegas sobre temas que no funcionan (discusiones sobre programas de televisión, etc.), porque somos personas. Afortunadamente, este defecto es reparable. Para comprender cuán desastrosa es la comunicación para nosotros, puede ver varios ejemplos.

En primer lugar, las personas se distraen entre sí y se rompen de un estado de flujo. El hombre se acercó y dijo algo: ¿qué debo hacer con esto ahora? ¿Por qué me dijo que quería transmitir esto?

O manifestaciones. Los odio, siempre me siento como un idiota cuando me siento en las reuniones. Todos parecen entender algo, tienen caras inteligentes, y extraño uno y pienso cuándo terminará. Quiero irme porque todo lo que discutimos se puede discutir mucho más rápido.

Las manifestaciones roban una gran cantidad de tiempo y no sirven de nada.

Hay varios otros asuntos importantes, por ejemplo, las personas comienzan a maldecir en estos mítines. Imagina que te pusieron en una habitación pequeña llena de personas a las que realmente no quieres ver. Quieres irte, y estas personas te hacen tomar algunas decisiones serias. Naturalmente, comienza el abuso: primero la agresión pasiva, luego los insultos obvios. Desafortunadamente, no se puede hacer nada con esto, porque las personas son seres en conflicto. No importa cómo trates de moderar la situación, no importa cómo recojas a las buenas personas que no juran, la gente jurará, y esto es normal .

Hay otro problema en nuestro negocio: la gente desaparece . Su front-end o devops pueden dejar de responder fácilmente algún día. Especialmente las personas que trabajan de forma remota pueden simplemente apagar el teléfono y finalizar la conversación unilateralmente.

Estos y algunos otros problemas parecen insolubles. No se puede enseñar a todas las personas a ser buenas, sin conflictos, responsables, es simplemente imposible.

Pero puedes vivir con eso. Siendo realista, puedes entender que la vida es así: las personas desaparecerán, maldecirán, no querrán comunicarse contigo; esto es normal. Resolví este problema de la siguiente manera: comunicación estructurada.



Para estructurar la comunicación, es suficiente tomar dos pasos:

• Vaya a Telegram ahora y elimínelo. Una vez que elimine todas sus páginas en las redes sociales, las personas no podrán escribirle.
• Después de eso, inicie un canal y diga que solo puede comunicarse de esta manera.

Cuando estás en una posición en la que puedes dictar tu voluntad a otras personas, les enseñas a comunicarse. Muestra que la comunicación debe ser estructurada y útil para todos los participantes .

Elegimos la comunicación a través de GitLab. Si tiene alguna pregunta, hágala en GitLab. Si quieres hacer alguna pregunta extraña, hazla allí. Si comprende que no hay un lugar donde pueda hacer tal pregunta, tal vez no sea necesario hacerla.

Solo nos comunicamos sobre temas de trabajo . Si alguien quiere hablar sobre el Juego de Tronos, lo sentimos, estamos trabajando y habla sobre el Juego de Tronos con tus amigos. Si desea hablar sobre una nueva tecnología, crear un ticket, hablemos de ello: tal vez se beneficiará el proyecto. Pero "Juego de Tronos" ciertamente no traerá beneficios al proyecto.

La comunicación estructurada hace que diferentes personas sean iguales. GitLab incluso tiene avatares casi iguales: uno tiene la letra K, el otro C, y no sé quiénes son estas personas. No me importa lo que sean, lo principal es que se comunican dentro de la estructura.

Después de estructurar la comunicación, establecer un trabajo con el cliente, aprender a escribir tickets comprensibles, es hora de llegar al código.

Código

Y aquí hay un nuevo problema: la gente no sabe cómo escribir código, y esto es normal . Solía ​​pensar que otros escriben códigos malos, y estoy bien. Pero luego me di cuenta de que yo mismo estaba escribiendo un código incorrecto. Y después de un tiempo me di cuenta de que todas las personas escriben códigos incorrectos , y eso está bien.

Las personas no están hechas para escribir código. La programación es un entorno agresivo al que una persona no está predispuesta. El código tiene muchas complejidades: arquitectura y una gran cantidad de información. En sistemas distribuidos, es terrible en general. Es difícil para una persona hacer frente al flujo de información. Y esto es normal.

Pero si es así, puede hacer algo con esto y aprender a trabajar en estas condiciones.



Para trabajar con esto, necesita rigor : CI y pruebas que sean lo más estrictas posible en lo que hace. Debe ser el Juicio Final : una herramienta que responde a la pregunta, código bueno o malo. Solo al mirarlo, el ojo que todo lo ve de CI le dirá si su trabajo irá a la maestría o si permanecerá en algún lugar del escenario.

Tal CI, por supuesto, debería ser inevitable. Tan pronto como alguien obtiene el derecho exclusivo de comprometerse a dominar, todos los intentos de construir procesos se desmoronan, porque este alguien comienza a hacer todo tipo de tonterías.

El CI inevitable y riguroso ofrece algunas características más interesantes. Esta es una oportunidad para desarrollar, porque ahora hay una barra base desde la cual puede construir: cada fragmento de código posterior es mejor que el anterior. Cada fragmento de código posterior agrega valor al proyecto y mejora el CI. Cada fragmento de código posterior es un paso hacia el desarrollo.

Una vez que la base esté lista, puede seguir adelante.

Pero la gente seguirá cometiendo errores, porque ningún CI, incluso configurado de la manera más rigurosa, puede detectar todos los errores . Y aparecerán en lugares en los que nadie más pensará.

¿Qué se puede hacer al respecto? Puede volver a las tácticas habituales y decir: “Cometiste un error, corrígelo. Escribiste un código incorrecto. Aprende a escribir el código ". Este es un mal camino que no conduce al desarrollo.

Para escribir realmente correctamente y desarrollar su producto, necesita un nuevo enfoque y una nueva mentalidad.

Ambiente sin culpa

Llamé a este enfoque Entorno sin culpa ; esto significa que nunca culpo a las personas por nada . Si un error entró en su proyecto, este es un problema del proyecto. Este error debe repararse para que nunca vuelva a suceder. Si se trata de un error en el código, debe escribir una prueba de regresión. Si se trata de un error en la infraestructura del proyecto, debe escribir una herramienta que evite este error.



Cuando empiezas no solo a corregir errores y esperas que todo no se desmorone en la producción, sino a corregirlos a nivel de sistema, comienzas a crear y crear: crear nuevas herramientas, desarrollar nuevos enfoques y patrones arquitectónicos. Empiezas a pensar con la cabeza y te aseguras de que los errores no se repitan.

El trabajo constante en los errores lleva al desarrollador a un nivel fundamentalmente diferente. Comienza a inventar herramientas para desarrolladores, implementarlas, promover, etc.

La creación de la que estoy hablando ahora es masiva. Cuando intente utilizar este enfoque, se encontrará con el hecho de que todo lo que existe ahora, especialmente para algunos lenguajes de programación, no es lo suficientemente estricto.

Una vez me pregunté si podría escribir un linter que haría que todos escribieran el mismo código. Fui muy estricto e incluí todas las reglas posibles que se me ocurrieron. Pero la gente todavía escribe un código diferente . Es muy similar, pero siempre puedo entender que este código fue escrito por diferentes personas. Por lo tanto, mi linter aún no es lo suficientemente estricto: espere nuevos lanzamientos.

El enfoque permanece, estamos esperando que la máquina responda, el programa está bien hecho o no. Y funciona, porque tales herramientas ayudan en el trabajo.

Pero no debemos olvidar que las personas son participantes necesarios en el proceso . No importa qué excelente configuración técnica realice, si el aspecto experimentado de la persona no pasó por su código, todavía puede haber algo que provoque que su cabello se ponga de punta, aunque CI pasó.

Por un lado, hemos abordado nuestro problema y hemos rechazado códigos muy malos. Pero, sin embargo, no estamos completamente aislados de él. Se requiere un proceso de revisión de código . Si el código no pasó la revisión del código, entonces todo lo que ha hecho antes no tiene sentido.

Cada paso siguiente tiene sentido solo cuando hay una base para el anterior.

Si no comprende lo que está haciendo o si configura la tarea de manera incorrecta, no se realizará ninguna revisión de código y CI lo ayudará. , , . - — .



— .

— . . : « , ?!» , , .

: , . , , , — : . , .

- — . , , , : « ? . , - ». — , - , - . .

— , — .

— , . , .

, , . . . , .

, , , , . , , , .

, , , , , , , .

— . , — , , , .

, . , , . open source , .

. , , , — .

. , , , , . , — , — . , .

. , . : — , — . .

. , , — ? , , , . .

. , , — , . - , , . , . open source.

. , , , , , . , , , .. !

. : . - , . , , . . , , . .

. , , - , . -, .

. , . - — , . , .

, . , . , .

Agile , . QualityConf , ++, — . , , .