Error: reinventar la rueda, alimentado por el síndrome de superhéroe y el síndrome de no inventado aquí.
Hace unos años, cuando estaba muy ocupado con los trabajos de desarrollo independiente, necesitaba una forma de dar cuenta y reportar mis horas de trabajo. Entonces, encendí mi editor de código y creé una pequeña herramienta ingeniosa que registraba las horas de inicio y finalización para cada cliente.
Luego, descubrí que para muchos proyectos web utilicé las mismas funciones y clases una y otra vez. Decidí ponerlos en un marco, y pensé mucho en el diseño estructural del mismo.
- ¿Qué idioma se usa para desarrollar juegos móviles (tanto en iOS como en Android)?
- ¿Cuál es la mejor estrategia de adquisición de usuarios a largo plazo para juegos móviles casuales?
- Cómo construir una aplicación móvil con una inversión mínima
- ¿Cómo se implementa el control de calidad en las aplicaciones móviles?
- ¿Cuáles son los mejores directorios para encontrar empresas de desarrollo de aplicaciones móviles de Oriente Medio?
Entonces, uno de mis clientes necesitaba un back-end API REST de HTTP. Acababa de leer sobre el mapeo relacional de objetos y decidí que debía escribir un contenedor entre MySQL y los objetos PHP nativos, para facilitar el guardado y la edición de objetos.
Por supuesto, aprendí mucho, pero no pude ver una falla personal: no quería usar el trabajo de código abierto de otra persona, porque pensé que podía hacerlo mejor. La costumbre siempre triunfaba sobre el trabajo estándar, pensé.
Síndrome de superhéroe y síndrome de no inventado aquí
Ambos síndromes son iguales. El Síndrome de superhéroe significa que no delegas el trabajo, porque crees que puedes hacerlo mejor que aquellos a los que delegarías. Síndrome de no inventado aquí significa que no usará algo que no hizo, porque siente que debe haberlo hecho usted mismo para que sea bueno.
¿Cómo se aplica esto a los desarrolladores de aplicaciones?
Bueno, para crear una aplicación para iPhone, todo lo que necesitas es Xcode. Técnicamente, puede crear una aplicación desde cero sin descargar una biblioteca.
Lo mismo no siempre se aplica a otros entornos de desarrollo. Para crear una aplicación web Bootstrap o trabajar con AngularJS, React o Node, ya ha descargado una docena de bibliotecas y marcos a través del administrador de paquetes. La mayoría de las veces, estos SDK ya funcionan con sus propios marcos y también facilitan / obligan a trabajar con ellos.
Para el desarrollo de aplicaciones nativas de aplicaciones, ese no es siempre el caso: puede salirse con su propia forma limitada de pensar y programar.
Sin embargo, una desventaja de usar demasiadas bibliotecas es que pierdes el significado intrincado y el funcionamiento interno de los productos que usas. Eso te hace flojo como desarrollador y más ingenuo. El uso de funciones más altas significa una regresión a la media, y eso causa más programadores promedio.
Una solución
Entonces, ¿cómo resuelve este desequilibrio? La solución se esconde en la balanza: use tantas bibliotecas para no inventar todo usted mismo, pero aún invente lo suficiente como para comprender el funcionamiento interno de una biblioteca que usa.
Considere esto como un ejercicio: antes de resolver un problema de programación estructural (es decir, ¿cómo analizo este JSON?), Investigue al menos 3 bibliotecas diferentes que puedan resolver su problema. Pídalos por complejidad, personalización y si son parte de un marco más grande que necesita o no. Elija uno o dos, trabaje con ellos y finalmente resuelva su problema.
Solo entonces, ha utilizado un marco sin reinventarlo usted mismo, sin saber cómo funciona.
Reinder, LearnAppMaking.com
