Al comienzo de mi carrera, escuché esta frase del jefe del departamento de ACS de una de las fábricas soviéticas cuando se ofreció a trabajar en su departamento.Naturalmente, entonces no pensé, y ahora no creo que la programación pueda ser un sustituto del buen sexo. Pero solo después de años, pudo apreciar completamente la profundidad de las emociones que puso en su frase clave. Incluso porque yo mismo a veces siento sentimientos de temblor al crear la arquitectura perfecta o el hermoso código del programa. Y aunque el concepto de belleza para cada persona puede tener el suyo, el ansia de perfección es el mismo para todos.Sin embargo, las emociones son una cosa y el ingeniero hombre razonable, es diferente. Y hace tiempo que me interesa la pregunta, pero ¿cuál es la verdadera razón por la que quiero que el código sea hermoso?Cualquier persona interesada en pensar en la razón para encontrar lo bello en el desarrollo de software y en otras disciplinas técnicas, pregunto bajo cat.Prefacio
El ímpetu para escribir este artículo fue el material reciente sobre Habr " Deja de temer ya decisiones subjetivamente hermosas en el código: no eres robots " , en el que el autor intenta corroborar su deseo intuitivo de crear código hermoso.Sin embargo, a juzgar por los comentarios sobre ese artículo, no todos los lectores comparten los argumentos del autor al nivel de "ingeniería chuyka". Aunque hay consonantes con tal argumento:“Por supuesto, el código debería ser hermoso. Árboles de navidad, palos, ¡TODO en la vida debería ser hermoso! De lo contrario, si algo es feo, puede reforzar el hormigón y decir "esto es un error" (a veces tiene que vivir con eso, ¡pero es un error!)
Es cierto que otros sugieren resistir la voz interior y no retrasar el inicio del tratamiento para el "perfeccionismo patológico, que puede ser una forma de obsesión, compulsiones u TOC".Pero si descartamos las bromas y las bromas, entonces el fenómeno del ansia de belleza se ha notado desde la antigüedad y no es ajeno a ninguna de las disciplinas técnicas. Después de todo, es poco probable que alguien discuta que el resultado del trabajo de un arquitecto o un ingeniero en el diseño de automóviles no puede ser la perfección tanto técnica como estética.
Pero para mí, el desarrollo de software está más cerca, lo que se discutirá más adelante.Sacramentos del proceso de creación de software
El desarrollo de software puede abordarse desde diferentes ángulos. Por un lado, esta es una disciplina puramente técnica que no permite libertades, basada en un enfoque de desarrollo duro y consistente. Este es un proceso de larga data y depurado, que incluye la recopilación de requisitos, el desarrollo de especificaciones técnicas, la planificación, el seguimiento de la implementación de los planes, la ejecución de los resultados obtenidos, etc.Otra opción para desarrollar un producto de software es Agile imprudente, que escupe las convenciones y ensalza los deseos de los clientes. Está listo para rehacer al menos cada iteración de la arquitectura del producto de software en un intento por lograr el resultado deseado. Este método es más como el arte de lograr un equilibrio entre conseguir que el software funcione y el agotamiento total de la confianza y los recursos del cliente.Y solo con el tiempo comienzas a comprender que las verdades comunes son mucho más flexibles. Y en una cascada clara hay un poco de flexibilidad, y en Agile hay planes y plazos. Por lo tanto, la verdad, como siempre, está en algún punto intermedio.Pero todo esto se aplica solo al lado externo del proceso de trabajo. Y lo más triste es que crear código hermoso de ninguna manera depende de ello.¡Además, el mismo código puede ser reconocido como hermoso y feo al mismo tiempo! Y esto significa que los conceptos de belleza son puramente individuales (quién lo dudaría). ¿Qué es un código hermoso y cómo escribirlo? , Los resultados de la 20a Competencia Internacional de código desconocido en el C .Por lo tanto, tuve que cavar más profundo, hasta la base de este proceso. En la dirección de la identidad personal del desarrollador, que puede actuar como programador, arquitecto, probador, analista, o incluso ser todos a la vez al mismo tiempo o en diferentes momentos.Entonces, ¿qué impulsa estos engranajes, en pequeñas empresas y grandes corporaciones, en las máquinas sin alma de la industria del software?Por supuesto, la búsqueda de una fuerza impulsora no puede prescindir de la psicología.¿Cuál es la fuerza impulsora?
No, no voy a citar artículos científicos sobre psicología o motivación personal. Ahora cualquiera, si lo desea, encontrará muchos artículos sobre estos temas.Estaba interesado en la clasificación de razones motivadoras que motivan a los desarrolladores a crear código de programa. Dado que existía la esperanza de que en esto sea posible encontrar la razón del deseo de los desarrolladores, a veces se evalúa la fuente desde un punto de vista estético.Desafortunadamente, no cumplí con dicha clasificación (tal vez no la encontré o no estaba buscando allí), por lo tanto, como resultado de analizar mi propia experiencia y comunicarme con mis colegas, decidí identificar de forma independiente los siguientes tipos de motivación para desarrolladores con nombres convencionales: Material , Social e Interno .Motivación material
Este tipo de motivación se basa en incentivos económicos. Al desarrollador no le importa qué y cómo escribir. Intentará adherirse al estilo de codificación aprobado en el proyecto y no le importa la belleza del código. En consecuencia, la evaluación de los resultados del trabajo (tanto los propios como los resultados del trabajo de los colegas) se llevará a cabo desde un punto de vista formalizado, donde no hay lugar para la estética.Motivación social
En este caso, el criterio principal para evaluar los resultados del trabajo es la opinión del equipo, que puede ser compañeros de trabajo, amigos en la universidad, etc. Además, la evaluación se realiza no solo por criterios formales para el cumplimiento del estilo de codificación. Ya existe un componente emocional, un criterio abstracto de belleza.Y ya se está volviendo importante para el desarrollador que, en primer lugar, el equipo acepte y apruebe el resultado de su trabajo, y las razones materiales pueden quedar en el camino. En los casos más avanzados, el desarrollador está listo para escribir código incluso "para alimentos", con el fin de satisfacer un sentido de autoestima entre el grupo objetivo o en su entorno social.Motivación intrínseca
Tal motivación es muy similar a la social, solo el factor de evaluación no es el equipo, sino el desarrollador mismo. Con la motivación interna, los incentivos materiales están completamente ausentes, y el resultado del trabajo nunca se publicará en absoluto, porque él ya ha traído (o continúa trayendo) satisfacción a su autor simplemente por el hecho mismo de su existencia y no requiere ninguna evaluación confirmatoria del exterior.Por supuesto, tal separación de motivos para los programadores es condicional y puede fluir de un tipo a otro o incluso ser una combinación de varios factores motivadores.Pero si observa el resultado del trabajo de los programadores desde este punto de vista, entonces en un sistema de clasificación de este tipo ya puede encontrar algo de lógica e intentar encontrar belleza en casi cualquier código fuente (programa del concurso IOCCC ):typedef unsigned char t;t*F="%c",l[]="|\\/=_ \n](.\0(),*(.(=(}*.)[[*.",N='\n',*
r;typedef(*H)();extern H Ar;Q(a){return(a|-a)>>31;}H S(c,a){return(H)(a&~c|(int
)Ar&c);}extern t*ist;V(t*u){*u^=*u&2^(*u>>7)*185;}Z(t*u,t n){*u-=n;}e(t c,H h){
R(h,Q(* r^c));}
I(){r=l +7-4*Q(
getchar ()^*l);
}R(H h, int c){Ar=S
(c,h);- main() ;}P(){r
++;}z() { O(&N);}
O(t*c){ printf( F,+*c);
}T(){r= "This is not a function\n" ;}w(U){
U=Z(r,8 ); r-=~Q(*
r/8-4); return 0; }M(){r=
ist-68; } h(){t G
=r[1]-r [2]^*r;
G^=30;V (&G);e(
0,(O(&G ),P(P(*
r++)),z));}g(){M();R(h,0);}f(){P(O(r));e('f',g);}p(){P();e('a',f);}d(){P(O(r));
e('n',p);}c(u){u=r[-2];T(Ar=d);R(f,Q(u^'"'));}n(){e(w(O(l+*r%8)),c);}a(){I();R(
n,0);}main(){S(Q(Ar),a)();}H Ar;t*ist="Rene Magritte"-(1898-1967);
Cuando una broma te hace pensar
Inicialmente, este artículo fue escrito como una broma, y su nombre habla por sí mismo, por lo que la imagen se eligió en consecuencia.Imagine mi sorpresa cuando me di cuenta de que la clasificación formulada de los motivos para los programadores ansiosos por la belleza me recuerda mucho a algo. Estos motivos se proyectan muy claramente en la famosa pirámide de necesidades de Maslow.
La motivación material cierra la necesidad de la fundación de la pirámide. Estas son necesidades fisiológicas y de seguridad. La motivación social se encuentra en el medio de la pirámide y conduce a la satisfacción de las necesidades de pertenencia, amor y reconocimiento. Y finalmente, la motivación intrínseca Se proyecta muy claramente en la parte superior de la pirámide y cierra la necesidad de conocimiento, estética y autorrealización.¿No es esto una broma?
Como resultado de un intento no serio de estudiar los antojos de belleza entre los programadores, se obtuvieron conclusiones bastante razonables que, si se desea, pueden usarse en la industria del desarrollo de software.De hecho, en el caso de la aparición de una metodología real para evaluar la belleza de un código desde el punto de vista de la motivación, no será difícil agregarlo a varias utilidades para evaluar el estilo de codificación, como pylint, cpplint y otras pelusas. Y después de eso, será posible evaluar la motivación de desarrolladores específicos sin realizar pruebas psicológicas y llenar cuestionarios aburridos. Será suficiente pasar su código a través del analizador.Tal vez incluso deje salir al genio de la botella, porque Si es posible medir la motivación por el código creado, el siguiente paso natural será la transición a su gestión. De hecho, este método de evaluación de la motivación es muy fácil de automatizar, y donde hay una oportunidad para la medición operativa, también existe la oportunidad para la gestión operativa del parámetro medido.En otras palabras, hacer que los gerentes de proyecto tengan información actualizada sobre el estado mental de los miembros del equipo los ayudará a evaluar los resultados de los intentos de cambiar la motivación hacia motivos sociales o internos, naturalmente, para ahorrar en incentivos económicos. ;-)ACTUALIZACIÓN 1: Dejaré un enlace al boceto dejanvarevsobre el tema del artículo: Sergey y "la programación es mejor que el sexo"ACTUALIZACIÓN 2:Según los primeros resultados de la votación, surgió una tendencia a votar principalmente por la motivación intrínseca (145 - 60.3%). Pero antes de elegir la tercera opción al votar, considere esto: ¿Quién establece los criterios de calidad (o estética) en su proyecto?Si usted es un líder de equipo, arquitecto u otra persona que acepta o influye significativamente en las reglas para determinar dicha evaluación, entonces su elección es la correcta.Pero si su contribución a la formación de los criterios de calidad del código es insignificante (por ejemplo, dichos criterios se determinaron incluso antes de unirse al proyecto), pero todo le conviene por completo, lo más probable es que esté en armonía con la motivación interna y social, pero cuando lo entrevistan, la elección correcta votar por la segunda opción, es decir Motivación social.Para verificar esto inequívocamente, imagine una situación en la que tenga un mal humor "negro" y el resultado del trabajo (el código del programa escrito en ese momento) le corresponda. ¿Se aprobará su compromiso? En caso afirmativo, incluso si no cumple completamente con los criterios de calidad aceptados, su motivación es realmente interna. Pero si su código es rechazado, su motivación sigue siendo social, aunque generalmente está en armonía con lo interno.