¿Es correcto no entender completamente la funcionalidad del código? [duplicar]

80

Como actualmente estoy luchando con el aprendizaje de WCF para un proyecto en el trabajo, durante los últimos días he estado buscando tutoriales y ejemplos en línea sobre la mejor manera de crear un cliente de WCF; y hoy, cuando le dije a mi jefe que me estaba costando encontrar buenos tutoriales porque algunos de ellos no daban detalles con sus ejemplos (por ejemplo, mostrar un fragmento de código que funciona pero no explicar por qué exactamente, o hacer un ejemplo con solo unas pocas líneas en lugar de hacerlo a una escala más grande), me dijo que no debía tratar de entenderlas completamente, porque hay veces en que un código solo hace lo que hace y debo dejarlo así (me dio el Por ejemplo, cuando hacemos cálculos, por ejemplo, usamos fórmulas que no sabemos cómo fueron concebidas o cómo funcionan, solo sabemos que sí y las usamos).

Y esto me molestó porque siempre me han dicho que es realmente importante entender su código, y que solo copiar y pegar sin saber CÓMO funciona es prácticamente un pecado; por eso siempre me tomo mi tiempo para entender algo antes de seguir adelante con él. Y no es como si estuviera tratando de entender cómo funciona una clase en particular a nivel de lenguaje ensamblador, solo quiero saber por qué un conjunto de instrucciones funciona, y por qué otra no, o por qué ambas lo hacen y bajo qué circunstancias. Pero mi jefe me dice que acabaré perdiendo el tiempo obsesionándome con estos pequeños detalles, y que debería olvidarme. Así que mi pregunta es, ¿está bien? ¿Está bien entender tu código solo hasta cierto punto y seguir adelante, y solo me he obsesionado con cosas pequeñas que no importan?

    
pregunta Ana Ameer 08.05.2014 - 04:10

8 respuestas

124

El único propósito de las abstracciones de software es ocultar los detalles funcionales. Si no fuera por esas abstracciones, no sería posible progresar más allá de cierto punto en la computación, porque los sistemas simplemente colapsarían bajo la Peso de su propia complejidad. Los cerebros humanos solo pueden comprender tanta información a la vez.

Considera lo que sucede cuando escribes un método. Cuando escribe un método, lo que está haciendo es esconder un poco de la funcionalidad del software detrás de una llamada de método. Una vez que se escribe y se prueba que el método funciona al realizar pruebas unitarias sobre ese método, ya no tendrá que pensar qué hay dentro de ese método a menos que necesite cambiar algo sobre su implementación.

Los grandes sistemas de software se basan en muchas capas de estas abstracciones. Usted tiene una capa de microcódigo en el procesador, código de máquina, buses de datos y direcciones, compiladores de idiomas, orientación a objetos, estructuras de datos, dominio Lenguajes específicos, y así sucesivamente. Tiene bibliotecas creadas sobre otras bibliotecas, que a su vez están construidas sobre un sistema operativo. Tampoco entiendes completamente cómo funciona nada de eso, pero aún puedes escribir con éxito programas informáticos que hacen algo útil.

Dicho esto ...

No puedes simplemente copiar / pegar código sin entender cómo funciona . La persona que intenta hacer que su programa funcione copiando un código que no comprende se está configurando para fallar. Debe comprender el código que escribe. Eso no significa que tenga que saber cómo funciona internamente WCF, pero necesita saber cuál es el propósito de WCF. , cómo escribir el código que lo interconecta correctamente, y cómo funciona el código con el que se escribe. Muchos programadores de copiar / pegar ni siquiera tienen una comprensión decente del lenguaje de programación que están copiando / pegando, por no hablar de un conocimiento profundo de las bibliotecas que están utilizando.

Por lo tanto, necesitas tener algunas habilidades decentes y debes comprender el código que escribes (o pegas) que llama WCF. Pero no necesita tener un conocimiento profundo sobre cómo funciona internamente WCF.

Del mismo modo, a los programadores que piensan que pueden unir un programa al cablear aleatoriamente los patrones de software les falta el punto. Llamamos a esas personas programadores de cultos de carga .

    
respondido por el Robert Harvey 08.05.2014 - 04:46
34

Creo que la respuesta es el contexto.

En mi opinión, una de las técnicas más poderosas para administrar la complejidad del código, que es el verdadero trabajo de un ingeniero de software, es la abstracción. Un ingeniero eléctrico no tiene que reprobar las ecuaciones de Maxwell para desarrollar un nuevo producto, y no necesito saber nada sobre un automóvil para usar un volante. Ambas son abstracciones importantes porque nos permiten intuir y usar las cosas sin entenderlas. Esto a su vez nos permite construir abstracciones más grandes.

Aparte de eso, debido a que la abstracción es tan importante, creo que a veces es bueno hacerla cumplir con otros desarrolladores. Por ejemplo, en mi oficina a veces tenemos un desarrollador que escribe las pruebas unitarias para un bloque de código antes de que un segundo desarrollador escriba el bloque de código. Hace cumplir la idea de interfaces simples y abstracciones claras.

Dicho esto, la abstracción no es una excusa para no entender cómo funciona el código cuando importa que sepas cómo funciona . El código de refactorización es un escenario obvio en el que los detalles de la implementación importan bastante. No necesito saber cómo funciona un automóvil para conducirlo, pero un ingeniero mecánico y un mecánico deberían entender cómo funciona un automóvil, posiblemente de diferentes maneras.

Dejando de lado, una de mis primeras lecciones en el trabajo fue nunca tocar el código que realmente no entendía. Por ejemplo, una vez estuve trabajando en una nueva función y noté otra línea de código en el módulo que no tenía sentido, así que la "arreglé" y luego lancé un error. Eso me enseñó una gran lección, que es admitir cuando no entiendo fácilmente una parte del código y reconocer que un código bueno y complejo y no trivial puede no ser obvio. Soy bastante nuevo en el desarrollo de software, pero he descubierto que la idea de que "un buen código es fácil de leer" es una insidiosa que ningún desarrollador de software que conozco pone en práctica. Claro, no escriba código oscuro o malo, pero los problemas difíciles a menudo requieren un código complejo. No se enoje si le toma tiempo entender las cosas. Mi cita favorita de Feynman es: "Pero no es complicado; hay mucho de eso".

Entonces, ¿cuándo abstraes y cuándo desarmas el reloj suizo? Supongo que depende de cuándo estés usando el reloj y cuando lo estés construyendo. Mi opinión es que las mejores personas en cualquier campo son T shaped en forma de T , lo que significa que entienden su trabajo de forma más amplia. contexto, algo que solo se logra a través de la abstracción, pero también sabe lo que necesitan saber en profundidad.

    
respondido por el gwg 08.05.2014 - 05:00
19

Hay tres partes diferentes para entender el software:

  1. Primero se entiende por qué existe una pieza de software (tan grande como una aplicación o tan pequeña como una sola función). Necesita saber el punto de ello, por qué fue escrito.
  2. A continuación, creo que es entender lo que hace un trozo de código.
  3. Por último, debes saber cómo funciona un fragmento de código, qué aspecto tienen y cómo funcionan los elementos internos.

En cuál de estos necesita tener un control para comprender una pieza de software diferente según lo que necesite hacer con ese código.

Por ejemplo, tome el método String.ToUpper () de .NET. Sé lo que hace este método y por qué querría usarlo, pero no sé cómo está escrito (eso es un detalle de la implementación) y realmente no me importa, siempre que pueda usarlo correctamente. Nunca necesitaré modificar este método, por lo que no es necesario entender los aspectos internos.

Si estaba copiando el código de Internet, debo asegurarme por completo de qué hace el código y por qué. Si solo lo copiaba y nunca lo modificaba (es poco probable), entonces no siento ninguna necesidad de entender cómo funciona. Pero si iba a modificarlo (es probable), entonces necesitaré saber cómo funciona; de lo contrario, solo estoy usando suposiciones para modificar el código, y eso probablemente no va a terminar bien.

    
respondido por el Jack Scott 08.05.2014 - 04:46
14

No es que no esté de acuerdo con las otras respuestas, pero permítame responder a lo que leo entre líneas. Si su jefe le está informando que no necesita entender cómo funciona algo, podría ser un comentario que esté demorando demasiado en hacer algo. Algunas personas se distraen fácilmente con detalles sin importancia y para ellos es recomendable trabajar para mantenerse en el camino.

Por otra parte, si la programación es su profesión elegida y usted tiene la curiosidad intelectual de profundizar en alguna tecnología que sea importante para lo que hace, entonces lo alentaría a que se tome un tiempo adicional para seguir sus intereses cuando posible. La información que obtenga, aunque no recompensará de inmediato, pagará dividendos a largo plazo. Le ayudará a darle sentido a la tecnología, lo pondrá en condiciones de extenderlo en muchos casos y lo preparará para una comprensión aún más profunda en el futuro. Con el tiempo, esto es lo que diferencia a un experto de un usuario ocasional.

    
respondido por el Paul Jackson 08.05.2014 - 13:33
6

En el gran programador pragmático de libros, esto se denomina "programación por coincidencia" ( enlace )

El mayor problema con esto es que, si no sabe por qué una pieza de código funciona cuando esta pieza de código falla por alguna razón, no sabe por qué falla y no puede solucionarlo.

    
respondido por el AlfredoCasado 08.05.2014 - 20:14
3

No estoy completamente de acuerdo con la afirmación: "No puedes simplemente copiar / pegar el código sin entender cómo funciona".

Perdone mi estupidez, pero desde un punto de vista programático, ¿no incluye una biblioteca de métodos / funciones que no sé que funcionan esencialmente igual que copiar / pegar ese código en mi cuenta?

Es decir, si estoy programando usando jQuery, incluyo la biblioteca jQuery y luego la uso. Usando la respuesta de Robert Harvey, esto está bien ya que jQuery ha abstraído todas las cosas que necesito usar sin tener que escribir el código por mí mismo o incluso entenderlo por completo. ¿Realmente necesito saber exactamente cómo funciona jQuery detrás de escena antes de poder usarlo?

Habiendo dicho eso, estoy de acuerdo con el principio detrás de la declaración, pero quería señalar que el concepto de "copiar / pegar" el código (sin una comprensión completa) es en realidad más común de lo que uno podría pensar y no tan oneroso como este declaración lo haría parecer.

    
respondido por el reblevins 08.05.2014 - 21:29
2

Como la mayoría de las veces, todo depende. En el extremo, está el uso de una biblioteca. Se supone que no debes saber o preocuparte cómo funciona. Se supone que debes saber qué poner y qué sale, qué puede y qué no puede hacer.

En el otro extremo, no sabes cómo hacer alguna tarea porque no lo has hecho antes. Usted encuentra diez líneas de código en Internet, lo que parece más fácil que encontrar la información correcta en su documentación (y con frecuencia lo es). En ese momento, sugiero firmemente que now es el momento adecuado para aprender a realizar esa tarea. Así que toma el código, entiéndelo, hazlo tuyo. Tenga en cuenta que muchos de los códigos en Internet no están necesariamente escritos por las personas más inteligentes, por lo que puede haber debilidades y malentendidos, por lo que al aprender ahora puede asegurarse de que el código funcione. Y en el punto en el que incluya esas diez líneas en su proyecto, son su responsabilidad. Si el código no funciona, es tu culpa. Así que tienes que entenderlo, como si lo hubieras escrito.

Entonces, ¿cuál es la diferencia con la biblioteca? ¿No es esa también tu responsabilidad? El código de la biblioteca no lo es. La elección de la biblioteca y el uso de la biblioteca es. Si la biblioteca bloquea su aplicación diez veces al día, es porque eligió una biblioteca que no es confiable. No tiene que entender el código de la biblioteca, pero tiene que entender sus problemas de confiabilidad y actuar.

    
respondido por el gnasher729 09.05.2014 - 18:52
1

El consejo de su jefe podría funcionar bien, pero es arriesgado. Existe el peligro de que, a largo plazo, tenga problemas mayores, que podrían evitarse si se toma el tiempo de entender las cosas en primer lugar. Si esto es algo de una sola vez, el riesgo es relativamente pequeño. Si construyes un sistema de software completo de esta manera, tienes una bomba de tiempo en tus manos. Lo que no entiendes, no tienes ninguna esperanza de arreglarlo o cambiarlo sin causar errores.

Por otro lado, si desobedeces a tu jefe, tu propio trabajo puede estar en riesgo. Si le gusta su trabajo, en el futuro, intente resolver los problemas técnicos por su cuenta antes de que se involucre. Una vez tuve un jefe que arruinaría las cosas cada vez que se involucraba en decisiones técnicas (aunque él era un estelar en ventas y relaciones con los clientes). La mayoría del personal técnico aprendió a escuchar lo que él diría, luego dar la vuelta y hacer algo diferente. Mientras el software funcionara, nunca haría un seguimiento y verificaba si su asesoramiento técnico estaba realmente implementado. El trabajo se pagó bien, pero me alegro de no estar más allí.

Si esta actitud es generalizada en su lugar de trabajo, al menos consideraría otras opciones de trabajo.

    
respondido por el Alex D 10.05.2014 - 21:21

Lea otras preguntas en las etiquetas