¿Qué tan grande es el rol que juega la subjetividad en la programación?

Question

A menudo leo sobre la importancia de la legibilidad y la facilidad de mantenimiento. O bien, leo opiniones muy fuertes sobre qué características de sintaxis son malas o buenas. O discusiones sobre los valores de ciertos paradigmas, como OOP.

Aparte de eso, esta misma pregunta flota en mi mente cada vez que leo debates sobre SO o Meta sobre preguntas subjetivas. O lea preguntas sobre las mejores prácticas y algunas veces me encuentre a mí o a otros en desacuerdo.

¿Qué papel juega la subjetividad en el ámbito de la programación?

A veces creo que juega un papel importante. Los desarrolladores de software son ingenieros en cierto modo, pero también personas. Una gran parte de la programación se trata de código que es humana legible. Esto es muy diferente de las matemáticas o la física u otras disciplinas con reglas muy exactas y estructuradas. Aquí la estructura exacta y las reglas están en gran medida en el aire, cambian por capricho, y de ahí la cantidad de idiomas que existen. Y una persona puede encontrar un idioma muy legible, y otra persona puede encontrar su propio idioma el más reconfortante.

Lo mismo con las prácticas. Una persona puede no gustar ciertas prácticas aceptadas. Yo mismo encuentro las clases divididas en archivos diferentes, muy ilegibles, por ejemplo.

Pero, no puedo decir que las reglas no hayan ayudado en general. Ciertas prácticas tienen y hacen la vida más fácil. Y los nuevos lenguajes han dado lugar a la sintaxis y la estructura que hacen la vida más fácil. Ciertamente, ha habido una progresión hacia el código que es más fácil de leer y mantener incluso dado un grupo de personas en gran parte diverso. Entonces quizás estas cosas no sean tan subjetivas como pensaba.

Me recuerda, en cierto modo, el diseño de la interfaz de usuario. Ciertamente es subjetivo, pero luego hay toda una disciplina involucrada en la creación de una buena IU y tiende a funcionar.

¿Hay algo no subjetivo sobre las ideas detrás de la facilidad de mantenimiento, la legibilidad y otras mejores prácticas? ¿Hay algo tangible que captar cuando uno desarrolla un nuevo idioma o piensa en nuevas prácticas?

Answer 1

Podría decirse que su pregunta es realmente acerca de la distinción entre programación, que es matemática, algorítmica y científica, y la ingeniería de software , que es subjetivo, variable y centrada humano.

Los grandes programadores no son necesariamente buenos ingenieros de software, y viceversa. Los dos conjuntos de habilidades, aunque no son exclusivos de ninguna manera, tienen menos superposición de lo que parecen al principio. Su importancia relativa depende en gran medida del proyecto: un programador brillante que trabaje solo puede producir sorprendentes ejemplos de genio técnico, y no importa que nadie más lo pueda entender o mantener, porque de todos modos no va a compartir el código. Pero muévase a un entorno empresarial, como el desarrollo corporativo de software interno, y con gusto le cambiaré diez genios del "troll de la cueva" para un programador mediocre que comprende la importancia de la legibilidad y la documentación.

Según mi experiencia, el mundo necesita grandes ingenieros de software más de lo que necesita grandes programadores. Relativamente pocas personas en este día y edad escriben software que es verdaderamente crítico para el rendimiento (kernels, compiladores, motores gráficos, sistemas incrustados en tiempo real, etc.) e Internet permite a programadores mediocres obtener rápidamente soluciones algorítmicas para problemas que no podrían resolver solo Pero casi todos los que escriben código profesional tienen que trabajar dentro de un equipo.Y la productividad del equipo aumenta y disminuye drásticamente en la capacidad de sus miembros para comunicarse de manera efectiva y distribuir la carga de trabajo de manera eficiente, dos habilidades que son altamente subjetivas e imposibles de probar mediante una fórmula rígida.

La mayoría de los principios de la ingeniería de software se basan en experiencia en lugar de la ley objetiva. Al igual que las ciencias sociales, estudiamos, aprendemos, nos adaptamos y aplicamos, pero sin garantías reales de resultados. Todo lo que podemos decir es que algunas cosas parecen funcionar mejor que otras en la mayoría de los grupos.

Answer 2

Creo que mucha de ella está necesariamente determinada por cuánto puede procesar nuestra mente al mismo tiempo. De modo que todo se reduce a cuánto el lenguaje y las herramientas permiten que un equipo o un desarrollador descomponga el problema en pedazos que son significativos por sí mismos, pero no tan grandes que se vuelve demasiado difícil comprenderlos. El tema común es el arte de organizar la información (en este caso, el código, la lógica, ...). Pero eso no es tan diferente de las matemáticas o la física, por cierto.

Answer 3

Todo depende del punto de vista :-)

Pero para responder a sus preguntas, creo que una manera de ver la subjetividad es reconocer que los lenguajes de software, herramientas y mejores prácticas son un medio de comunicación comunes entre individuos. Sí, un lenguaje de programación es una forma formal de instruir a una computadora sobre cómo comportarse, pero un lenguaje de programación también se puede ver como una forma de definir y comunicar especificaciones con un alto nivel de detalle (el código es la última especificación, ¿no? ?).

Por lo que podemos querer preocuparnos por el grado de subjetividad en los lenguajes de software, las herramientas y las mejores prácticas, diría que la falta de subjetividad puede indicar qué tan bien se facilita la comunicación.

Sí, las personas tienen ciertas inclinaciones que se expresan en sus hábitos y tendencias, pero que en última instancia no deberían importar demasiado en la plataforma perfecta para el desarrollo.

Answer 4

Así como los mejores autores toman prestados muchos estilos, los mejores programadores mantienen una amplia gama de patrones en su arsenal mental. Seguir escandalosamente algunos patrones y adherirse a una verdad absoluta es a la vez perezoso y peligroso.

Puesto de otra manera, el día en que confiamos en los robots para la revisión del código es el día en que renuncié.

Answer 5

Pasando a mi esposa PhD de matemáticas, le pregunté si había alguna subjetividad en matemáticas. Su respuesta es afirmativa, sobre todo en la forma en que nosotros, los humanos, alcanzamos la respuesta.

Si el resultado es una prueba matemática, la forma de llegar a ese resultado puede variar. Si el conjunto de datos es grande, es posible que deba utilizar una computadora, lo que puede introducir errores, y por lo tanto debatir si ese es el enfoque correcto. O a veces los matemáticos pueden estar en desacuerdo con la teoría: uno trata de demostrar que x es verdadero mientras que el otro intenta probar que x es falso.

Creo que lo mismo existe en ciencias de la computación. Una respuesta correcta es un programa que se ejecuta correctamente, pero esa definición de correcto puede ser diferente para cada proyecto. Algunas veces correcto significa que no hay errores. A veces significa ejecutar de manera eficiente.

Desde aquí los programadores pueden argumentar la mejor manera de lograr el resultado "correcto". Un buen ejemplo de esto es la aplicación FizzBuzz. Una respuesta simple sería solo un ciclo for, pero Enterprise FizzBuzz también es "correcto" porque produce la respuesta correcta, pero generalmente se ríe de la ingeniería como "mala" debido a su complicación excesiva de la idea (era una aplicación de broma después de todo)

¿Qué tan grande es el rol que juega la subjetividad en la programación? Yo diría que es una gran parte de lo que hacemos, simplemente porque somos humanos, y porque hay múltiples formas de obtener la respuesta "correcta", por lo que hay desacuerdo sobre cuál es la mejor manera.

Answer 6

Se han realizado estudios que muestran que ciertas prácticas reducen las tasas de defectos en el software. Por ejemplo, un study encontró una fuerte correlación entre la complejidad ciclomática y la probabilidad de ser propenso a fallas. Other studies muestra que la efectividad promedio del diseño y las inspecciones de código son del 55 y 60 por ciento. Por lo tanto, parece ser lo mejor para nosotros favorecer la simplicidad, verificar las métricas y hacer revisiones de códigos.

Estamos hablando de probabilidades aquí, sin embargo. Si reviso su código, no estoy seguro de encontrar el 60% de sus errores. También hay algunos absolutos en el desarrollo de software; los desarrolladores experimentados saben que la respuesta correcta generalmente es "depende". Dicho esto, hay una serie de prácticas con datos objetivos a su favor.