¿Está bien vivir sin saber cómo funciona el programa que creó?

Quiero decir, hay libs realmente útiles que pueden resolver problemas cuando estás atascado y no sabes cómo resolver esto o aquello con tu conocimiento del lenguaje de programación que usas ... Por ejemplo, Boost para C ++ o JQuery para JavaScript o Spring para Java ... Resuelven problemas en segundos y realmente no te importa cómo lo hicieron (a pesar de que están escritos en el mismo lenguaje en el que estás programando) ... Así que me pregunto si estoy solo usando libs mientras no estoy capaz de escribir soluciones para mis problemas desde cero o es una práctica estándar?

¿Está bien no entender cómo resolver los problemas usted mismo y utilizar bibliotecas en su lugar?

En general, no, no lo es.

Una biblioteca puede ahorrarte el trabajo (¡difícil!) De descubrir cómo resolver un problema y luego depurar la solución y luego mantenerla. Pero, si lo va a usar, será mejor que se asegure de comprender cómo funciona: por qué la solución realmente resuelve el problema. No tiene que saber cómo inventar automóviles, motores y robots que construyen motores de automóviles, si trabaja como mecánico, pero comprenderá mejor cómo funcionan las piezas, qué hacen y cómo funcionan. ¡conjugarse!

Esta es la razón por la que verá que muchas personas se vuelven muy especializadas, muchas veces solo aprenden a trabajar con un solo idioma, una sola plataforma, un solo marco y un conjunto de bibliotecas.

Dicho esto, solo tendrás mucho tiempo para aprender. A veces tienes que tomar atajos, tómalos, pero debes saber que son atajos. Quizás solo leyó lo suficiente sobre una biblioteca para saber que podría resolverlo, si tuviera tiempo. O tal vez solo descubra las dos funciones que realmente necesita llamar, y solo lo suficiente para hacer las llamadas correctamente. Es un acceso directo, que tendrá un precio, generalmente más tarde, cuando alguien (tal vez un mayor y más experimentado, usted) tiene que arreglar el código.

Una vez computerworld.com.au le preguntó a Bjarne Stroustrup "¿Tienes algún consejo para los programadores prometedores?"
Y el respondió"Conozca los fundamentos de la informática: algoritmos, arquitecturas de máquinas, estructuras de datos, etc. No solo copie ciegamente las técnicas de una aplicación a otra. Sepa lo que está haciendo, que funciona y por qué funciona. No piense que sepa qué será la industria dentro de cinco años o qué hará entonces, así que reúna una cartera de habilidades generales y útiles. Intente escribir un código mejor y más basado en principios. Trabaje para hacer que la "programación" sea más una actividad profesional y menos de una actividad de "pirateo" de bajo nivel (la programación también es un oficio, pero no solo un oficio). Aprenda de los clásicos en el campo y los libros de texto mejor avanzados; no se conforme con el "cómo" fácil de digerir guías y documentación en línea: es superficial ".
Espero que aclare sus dudas sobre lo que se requiere para unProgramador verdadero y lo que es necesario para que cualquiera sea uno.

Sí, ¡y todos lo hacemos!

Tomemos, por ejemplo, un error muy simple que estaba arreglando en un código gráfico relacionado con Mac. El código alrededor del error implicaba varios pasos:

1. Primero, un método Objective C asigna un búfer de píxeles usando malloc () y lo asocia a su objeto Objective C.
2. Más tarde, sucede algo y una rutina C envía un mensaje al objeto Objetivo C y recupera el búfer de píxeles.
3. La rutina C comprime el contenido del búfer de píxeles utilizando jpeglib y lo envía a través de una conexión TCP / IP.

¡Están pasando muchas cosas allí! Aquí hay algunas cosas:

• Un asignador dinámico de memoria para implementar malloc (), que asume que la memoria es físicamente contigua y direccionable linealmente.
• El sistema de memoria virtual del núcleo Darwin subyacente para mapear tanto la RAM física fragmentada como el espacio en disco (que es un dispositivo físico diferente de la RAM), en algo que parece al asignador de memoria dinámica como si fuera RAM físicamente contigua y direccionable linealmente.
• Sistema de objetos del objetivo C
• El sistema de mensajería en tiempo de ejecución de Mac OS y la forma en que interactúa con los objetos del Objetivo C
• La implementación de la biblioteca jpeglib del estándar de compresión de imágenes ráster con pérdida JPEG, que utiliza un algoritmo de transformación de coseno discreto
• La rutina de red de espacio de usuario para enviar los datos, que llama a través de las diversas implementaciones de protocolo TCP e IP, que a su vez llama al núcleo del sistema operativo. Luego, dependiendo de lo que haya activado para su red, puede llamar un controlador para el puerto Ethernet, un chip wi-fi o, más inusualmente, un controlador USB o Firewire.

¿Entiendes todos los detalles de cómo se implementan realmente todas esas cosas? ¡Claro que no! Dudo que haya muchas personas en el planeta que lo hagan, tal vez incluso ninguna. Así que no me preocupo por eso.

Pero es bueno ser curioso y aprender al menos un poco sobre las bibliotecas y herramientas que utiliza. Cuando comencé a programar, sabía que los compiladores y los sistemas operativos no podían ser mágicos, pero seguro que me parecían así. Al complacer mi curiosidad por esas cosas, he aprendido muchísimo y he tenido una gran carrera hasta ahora.

Creo que la razón principal por la que usamos las bibliotecas es para no "reinventar la rueda" todo el tiempo, abstrayendo los problemas que pretenden resolver. Podría intentar resolver los problemas usted mismo, pero eso llevaría más tiempo.

Sin embargo, creo que también necesitamos saber o adivinar cómo resuelve el problema la biblioteca. Esto generalmente está documentado en la documentación del usuario de la biblioteca y con el software de código abierto, siempre puede mirar el código usted mismo.

También generalmente resolvemos problemas abstrayendo las partes difíciles de todos modos, entonces, ¿por qué no está bien?

Las bibliotecas están ahí para proporcionar soluciones a problemas comunes. Debe decidir si resuelven el problema particular que está resolviendo. NO son un sustituto de no saber cómo resolver un problema. Por ejemplo, suponga que su aplicación requiere una tabla hash, debe tener suficiente conocimiento para comprender qué problema está resolviendo una tabla hash. Debe poder evaluar el rendimiento de la biblioteca que está utilizando para decidir si funcionará o no en su aplicación. Creo que usar una biblioteca para cubrir el conocimiento técnico inadecuado no es el caso de uso correcto. La decisión de usar una biblioteca debe girar en torno a si usar o no la biblioteca acelerará el desarrollo y proporcionará una solución probada y confiable. La decisión de usar una biblioteca no debe girar en torno a la incapacidad de los programadores para resolver un problema dado.

Depende de usted, de verdad .

Cuanto mejor comprenda las herramientas con las que está trabajando, mejor podrá aprovecharlas.

Por ejemplo, rara vez uso jQuery, pero cuando tengo que hacerlo, sé qué aprovechar y cómo puedo hacer que coexista con otros marcos como Mootools.

Además, pronto me aventuraré en gamedev con UDK, y estoy seguro de que cuanto más lo entienda, más podré doblegarlo a mi mala voluntad, pero también podría seguir tutoriales obvios. Elijo el primero, solo un poco de tiempo extra y ciclos cerebrales y obtendré mejores y más fáciles resultados .

Es importante conocer tu reino y tu parte del proceso.

Por ejemplo, supongamos que está utilizando una biblioteca de procesamiento de imágenes. ¿Realmente necesita saber todo sobre desenfoques gaussianos, transformaciones y espacios de color? No. Pero necesita saber por qué está utilizando la biblioteca en primer lugar. O la función de clasificación de un marco. ¿Necesita saber el algoritmo de clasificación real utilizado? En la mayoría de los casos, no. Pero sí necesita saber por qué necesita ordenar los datos.

Por otro lado, si está escribiendo un compilador, es mejor que sepa cómo funciona un compilador, ya que esa es su parte en el proceso.

Ciertos marcos como jQuery abstraen mucho. ¿ Necesita saber cómo funcionan exactamente? No. Pero tener una comprensión sólida y fundamental de lo que está haciendo la biblioteca será muy beneficioso para usted al escribir código, porque comprenderá mejor por qué el marco está hecho de la forma en que está, y podrá utilizarlo en todo su potencial. .

Según mi experiencia: como no puede eliminar la dependencia de la biblioteca, usted y su equipo deben saber lo suficiente para resolver el problema.

Como programadores, tenemos poco tiempo, por lo que debemos elegir el que tenga mayor prioridad. El problema debe resolverse lo más rápido y suave posible. Solo esta razón hace que "aprender todo sobre las cosas funcione" algo redundante.

Lo que quiero agregar aquí es "dependencia". Como comunidad, todos dependemos de los demás. Nos apoyamos en los Gigantes para construir nuestra aplicación: Java, .NET, API ... Y confiamos en los Gigantes sobre su trabajo; porque funciona para mucha gente Si tiene un problema con el marco o API, hay una buena posibilidad de que otros lo hayan enfrentado en algún lugar, y hay una solución / solución.

El único problema aquí: tal vez, en algún lugar, en un criterio restringido, los Gigantes colapsaron. Por ejemplo, flash no es compatible con algunos sistemas operativos, y hay muchas cosas que no podríamos hacer sin él. Esta posibilidad es más que cero, pero en este caso tenemos pequeñas cosas que podemos hacer. Solo en estos casos, el conocimiento sobre "lo que está detrás de las capuchas" resulta útil, ya que señala dónde está realmente el problema y puede crear una gran solución; pero no estoy seguro de que el tiempo que invertimos realmente valga la pena.

Para hacer frente a esa posibilidad, creo que hay una solución: porque la mayoría de los programadores pueden captar fácilmente el "trabajo superficial" de una biblioteca, y solo a veces realmente necesitamos a alguien que comprenda muy bien: dejemos dividir al equipo para hacerlo. Tratando de comprender un equipo que cada uno haya experto sobre 1,2 bibliotecas / herramientas útiles / "conjunto de habilidades" involucradas : uno tiene buena experiencia sobre jQuery, uno se ha especializado en la base de datos, ... Esto ayudará mucho a minimizar los riesgos.

Otro punto de vista es la seguridad. Cuando usa una biblioteca de la que no conoce el funcionamiento interno exacto, entonces hace suposiciones sobre lo que está sucediendo exactamente. Cada suposición fallida puede abrir un vector de ataque para un atacante malicioso.

Al llamar a un Quicksort, debe tener en cuenta el peor comportamiento posible. De lo contrario, un atacante puede inyectar datos del peor de los casos y realizar un DoS.

Al llamar a una biblioteca de compresión, debe tener en cuenta que cuando algunos datos se comprimen a menos bytes, debe haber datos que "compriman" a más bytes que el original. Entonces, cuando su suposición es que el búfer de salida solo necesita el tamaño de los datos de entrada porque se comprime [a menos bytes], entonces hay un desbordamiento del búfer a punto de ocurrir.

Debe conocer los fundamentos suficientes sobre las cosas que va a hacer para poder demostrar que sus suposiciones son verdaderas. De lo contrario, la biblioteca debería ocuparse explícitamente de esto, por ejemplo, lanzar una excepción cuando el búfer de salida proporcionado no es lo suficientemente grande.

Está bien no entender todo lo que usa mientras esté seguro de que funciona. Una vez que te pica un error en la biblioteca, hay tiempo para ver cómo funciona, por qué funciona y por qué no. Por supuesto, siempre eres bienvenido y animado a mirar debajo del capó, incluso si no tienes que hacerlo.

Una de las cosas difíciles en la programación es superar la tentación de resolver todos los problemas por ti mismo.

Está bien pero es peligroso. Como práctica general, uno debe saber trabajar de lo que ha desarrollado.

Un poco ...

Está bien siempre que obtenga la idea general de lo que la biblioteca o el marco intenta hacer. En cuanto a las partes internas y lo que no entonces, no. Toma el enfoque pragmático. Funciona, hizo lo que quiero que haga, está bien.

El punto es no empantanarse con un montón de pequeños detalles e implementar su maldita idea ya.

Supongo que el punto es que no vas a saberlo todo. En serio, tienes muy poco tiempo para investigar todo, porque te distraerá de tu objetivo principal de crear esa idea tuya. Poco a poco, tal vez, puede dedicar un tiempo libre durante el fin de semana para leer un capítulo más o menos sobre el tema.

Pero no intentes resolverlo todo, a menos que tengas mucho tiempo libre ... Míralo de esta manera. La razón para los lenguajes de programación es protegernos de hacer código ensamblador, la razón para código ensamblador es protegernos de hacer 1's y 0's. No creo que necesite conocer todos los detalles del mecanismo detrás de él, pero solo conozca la esencia general del mismo. Al igual que un recolector de basura, sé que se ocupará de mis punteros / memoria, no me importa qué algoritmo mágicamente limpio use, solo sé que funciona (para lo que necesito) y no hace nada más. Tal vez la estafa, pero meh. A menos, por supuesto, que esté en el campo donde tiene que lidiar con eso. Entonces no harías esta pregunta de todos modos porque es parte de tu trabajo jaja.