Hola, me llamo Dmitry Karlovsky y soy ciclista profesional. A lo largo de mi carrera, he hecho un montón de bicicletas: grandes y pequeñas, rápidas y cómodas, torcidas y rectas. Por lo tanto, es bastante salvaje para mí ver programadores inteligentes que hacen aplicaciones grandes y complejas, pero al mismo tiempo conectan otro panel izquierdo al proyecto, en lugar de escribir un par de líneas simples con mis propias manos. La razón de esto es el miedo a las bicicletas en la producción que se ha desarrollado entre los programadores y se apoya a sí mismo.

Evolución del programador

Para simplificar la presentación, distinguimos 3 grupos condicionales de programadores. Condicional, porque no hay un límite claro entre ellos, y la misma persona en diferentes áreas puede pertenecer a diferentes grupos.

Novato

• Todavía tiene poca experiencia y conocimiento, pero rápidamente aprende otros nuevos, ya que todavía no tiene hábitos establecidos.
• Debido al efecto de la novedad, ve bien las deficiencias de las soluciones existentes y tiene un fuerte deseo de hacer lo suyo sin estas deficiencias.
• No sabe cómo y por qué se formaron estas u otras prácticas y principios, y si lo hace, no sintió las razones de su aparición en su propia piel.
• La mayor parte del código escrito por él es desechado o refactorizado más allá del reconocimiento. En el mejor de los casos, con sus propias manos bajo la dirección de colegas más experimentados.
• Es golpeado sin piedad por escribir bicicletas porque es más probable que una biblioteca de terceros sea mejor en términos de muchos criterios.

Especialista

• La gran mayoría de las bibliotecas populares fueron escritas por él en su tiempo libre desde su trabajo principal, ya que todavía golpean las manos tanto para bicicletas como para abrir códigos fuente.
• Como regla general, la calidad de su código corresponde a la calidad promedio del código en el ecosistema. Si todos escriben fideos a partir de devoluciones de llamada, entonces no queda nada para él.
• Como regla general, utiliza código de terceros, ya que el suyo no es mucho mejor, o incluso peor, debido a limitaciones de tiempo.
• En consecuencia, continúa recibiendo bicicletas prácticas explícitamente (en una revisión de código) o implícitamente (informes de errores).
• Cuando algún problema lo atrapa por completo, corta una bicicleta. Y dado que hay una mayoría de tales programadores, resulta que 100,500 bicicletas no son compatibles entre sí, con el apoyo de un desarrollador y medio.

Profesional

• Es capaz de resolver cualquiera de los problemas mejor que el promedio del hospital, pero debido a los recursos limitados, se ve obligado a elegir a qué dedicar tiempo.
• Por costumbre, lo golpearon en las manos. Especialmente si la empresa practica scrum, donde todas las decisiones son tomadas por la mayoría, sujeto al efecto Dunning-Krueger.
• A menudo, debido a los complejos formados en las dos primeras etapas, se limita y cree que no puede hacer nada mejor que una biblioteca de terceros que es "probada", "pensada", "respaldada por un gran número de desarrolladores".

Causas de miedo

Siguiendo la evolución del programador, es fácil notar que al principio tiene pocas habilidades, pero no miedo, y a medida que adquiere habilidades, el miedo a las bicicletas aparece e intensifica. Para hacer frente a este miedo, debe analizar sus causas.

No puedo hacerlo mejor

Un principiante realmente no puede. Debe dirigir sus esfuerzos para explicar la esencia e importancia de los problemas que ve con su nueva mirada a colegas y desarrolladores de bibliotecas más experimentados.

Lo más probable es que un especialista no tenga éxito si conoce bien los problemas y consulta con otros especialistas y profesionales.

Un profesional puede hacerlo mejor en la mayoría de los casos, ya que ya está bien versado en el tema e incluso tiene la habilidad de un análisis exhaustivo. Desafortunadamente, generalmente no hay nadie para consultar con él, ya que hay pocos otros profesionales y se dedican a otros temas. Y los especialistas carecen de horizontes.

No habrá nadie para reparar defectos

Por lo general, el autor de la bicicleta está bien motivado para reparar defectos en su creación. Pero tarde o temprano, esta motivación pasa, si lo hace después de las horas. Y aquí, al parecer, una biblioteca de terceros le permite ahorrar recursos, porque otras personas que no tienen que pagar están comprometidas con su apoyo. Pero no es posible influir en ellos y, por lo tanto, para cumplir con la fecha límite, tendrá que arremangarse y arreglar el defecto por su cuenta, después de lo cual será largo y difícil romper su parche en el repositorio principal, sin ninguna garantía de éxito.

Nadie mejorará y se desarrollará

Aquí la situación es la misma que con los defectos. Pero si con defectos generalmente está claro para todos que necesitan ser reparados, entonces la visión sobre la dirección del desarrollo es diferente para todos. Un desarrollador externo desarrollará su biblioteca donde la necesite, y no para usted. A la velocidad que sea conveniente para él y no para ti. Entonces, si se requiere un vector específico de desarrollo, su bicicleta le brinda control y previsibilidad, dos cualidades que son mucho más importantes para la administración que el tiempo y el dinero.

No puedo usarlo en ningún otro lado

Si desea utilizar la bicicleta fuera de la empresa, deberá desarrollarla en su tiempo libre o acordar la apertura de la fuente, que generalmente es más difícil, pero bastante posible. Después de todo, la compañía recibe relaciones públicas casi gratis entre los empleados potenciales, así como los beta testers gratuitos (o incluso los contribuyentes, pero no debe confiar en esto) en la persona de otros usuarios de bicicletas.

Se desperdiciará tiempo y dinero

Aquí, antes que nada, vale la pena compararlo con alternativas. Si no hay ninguno, entonces no hay otra opción: debe cortarlo. Si hay alternativas, entonces vale la pena comparar en términos de dinero y tiempo:

• El costo de escribir su bicicleta es de buena calidad. Esto incluye el tiempo real de escribir el código, así como escribir pruebas y transferir el proyecto a una bicicleta, y evaluar el costo de los defectos introducidos.
• Los beneficios que brinda una bicicleta. Esto puede ser un ahorro debido a ciertas características, cada vez menos defectos y otros factores.
• El costo de integrar una solución de terceros. Nuevamente, incluida una evaluación del costo de las pruebas y los defectos introducidos.
• Restricciones impuestas por una solución de terceros. Puede resultar que una solución de terceros no encaje en absoluto. O que ralentizará el desarrollo 2 veces.

También vale la pena evaluar por separado el costo de cambiar de una solución de terceros a una bicicleta, si de repente resulta que algunas de las restricciones son más inaceptables. A menudo sucede que ahora es más rentable implementar una solución de terceros y luego transferirla rápidamente a su bicicleta cuando (y si) la necesita, que pasar tiempo en la construcción de bicicletas ahora.

Esta evaluación ayuda tanto a comprender si el juego vale la pena como a explicar a la gerencia por qué vale la pena escribir el suyo propio y no tomar el de otra persona (o viceversa).

Seré maldecido como maldecí a mi predecesor

Es dudoso que la bicicleta ocupara una parte significativa del proyecto. Entonces maldecirán más por el resto del código. Por lo tanto, la bicicleta debe hacerse al menos no peor. Y aún mejor si nadie tuviera el deseo de reemplazarlo con una biblioteca de terceros u otra bicicleta. Para hacer esto, necesitas:

1. La presencia de una ventaja clara e importante para el proyecto.
2. Una interfaz de uso simple para que no tenga que hacer sus envoltorios.
3. API flexible para que no tenga que ver una bicicleta nueva con un pequeño cambio en los requisitos.
4. Buena cobertura de prueba, que permitirá menos flasheo en los informes de errores y revivirá bien la refactorización.
5. Documentación completa para que no necesite buscar al autor de la bicicleta para comprender cómo montarla.

No quiero asumir la responsabilidad

Es normal que no te importe el proyecto en el que estés trabajando. Si realmente no te importa a qué dedicas un tercio de tu tiempo en un día, entonces debes defender tu punto de vista. Y cuanto más alto sea su estado, más responsable será acercarse a qué decir. De hecho, no solo cómo trabajas, sino cómo trabajarán los demás, y dónde irá el proyecto en su conjunto, depende de tu voz.

Recomendaciones

Espero haber podido mostrar los temores infundados de las bicicletas. Cuanto más te acerques a la profesionalidad, más ambiciosas serán las bicicletas. Es mejor comenzar con bicicletas más pequeñas, que tienen menores riesgos, pero que brindan bastante experiencia en este campo. Y con esta cartera, adquiere más y más cosas interesantes e interesantes. Es importante no olvidar que un verdadero profesional no solo hace cosas geniales, sino que también sabe cuándo abandonar su creación. Por lo tanto, siempre realice un análisis que le brinde la confianza de que está haciendo todo bien, y la administración estará de su lado, y aquellos que lo busquen entenderán qué tipo de bicicleta es, por qué está aquí y por qué era imposible de lo contrario.

Bueno, para ayudarlo con el análisis de bibliotecas de terceros, durante la noche escribí una aplicación que le permite estimar el tiempo para resolver los problemas de los proyectos en GitHub . Cuanto mayor sea el número, peor será el proyecto con soporte y más tiempo tendrá que esperar para encontrar una solución a su problema. Por ejemplo: una comparación de Angular, VueJS, React y, por supuesto, el $ mol en el que está escrita esta bicicleta. Tenga en cuenta que el último enlace es de una sola vez, ya que bombear todos los problemas abiertos de Angular se come todos los límites de GitHub, lo que demuestra elocuentemente que sus mantenedores no pueden hacer frente al apoyo del monstruo que engendraron.