¿Cómo se deben manejar los scripts de "descarte útil"?

Ya sabe cómo funciona: hay una pequeña tarea repetitiva para la que encontró una manera de automatizar rápidamente el 95% del trabajo. Creas un script, lo ejecutas, arreglas manualmente la salida y listo. Por supuesto, no confirma el script, ya que no cumple con los requisitos de calidad de la empresa (no tiene documentación ni pruebas).

Algún tiempo después, ves a un colega trabajando en una tarea similar. Usted dice "¡Oye! Hice un guión para eso. Déjame buscarlo. [Mira] Oh, estaba almacenado en mi computadora portátil anterior, así que ya no lo tengo. Lástima".

Estos scripts a menudo pueden ahorrar mucho tiempo y, como líder del equipo, me gustaría que se almacenen en el control de versiones. Sin embargo, si impongo los mismos estándares rigurosos que el resto del código base a estos scripts, me temo que la mayoría de los desarrolladores los guardarán para sí mismos.

La única otra opción que se me ocurre es permitir que los desarrolladores almacenen los scripts en una parte especial del control de versiones, en el que no hay control de calidad (al igual que GitHub Gists). El riesgo es que otros no podrán usar el código porque no pueden encontrarlo o entenderlo.

¿Cómo podría resolverse este problema? ¿O no debería resolverse?

La única otra opción que se me ocurre es permitir que los desarrolladores almacenen los scripts en una parte especial del control de versiones, en el que no hay control de calidad (al igual que GitHub Gists). El riesgo es que otros no podrán usar el código porque no pueden encontrarlo o entenderlo.

¿Cómo podría resolverse este problema? ¿O no debería resolverse?

El problema no puede resolverse.

Hay una gran diferencia entre compartir el código de boca en boca cuando escuchas que un colega enfrenta una dificultad particular y compartirlo simplemente al ponerlo en una biblioteca a la que todos tienen acceso.

La diferencia es que, en el primer caso, está desempeñando el papel del creador y el bibliotecario con conocimiento implícito del problema y el código que tiene que lo resuelve, mientras que en el segundo caso, esos roles no están presentes.

Sus estándares generales de código pueden estar diseñados para eliminar el papel del bibliotecario en su empresa y garantizar que la biblioteca siga siendo accesible para todos los visitantes.

Con un enorme edificio de código de larga duración (como caracteriza a la mayoría de los productos de software centrales), el tiempo y el esfuerzo están justificados para preservar la capacidad de múltiples generaciones de trabajadores para continuar trabajando con todo el edificio. En las empresas con una alta rotación de personal, una "generación" de personal puede ser tan pequeña como cada año o dos.

Pero, por supuesto, alcanzar esos estándares "sin bibliotecarios" tiene el precio de un gran tiempo y esfuerzo para quienes crean la biblioteca en primer lugar, y aún exige mucho tiempo y esfuerzo de aquellos que luego vienen a usar y navegar por la biblioteca (aunque no es el mismo esfuerzo que recrear todo el edificio desde cero, lo que puede haber tomado varias generaciones).

Por otro lado, la mayoría de estos scripts rápidos y sucios se escribirán para que las cosas simples se hagan rápidamente, tal vez de forma puntual. No son creaciones complejas o robustas.

Usted dice que "ahorran tiempo", pero, por supuesto, esto solo sigue siendo cierto cuando no se escriben en el estándar mucho más alto, sin bibliotecario. Son las plantillas de construcción personal de quienes las hicieron: las palancas temporales y el andamiaje del esfuerzo humano, no el producto final duradero.

Debería ser posible registrarlos en el control de versiones, de modo que el creador tenga un lugar para almacenarlos y preservarlos sistemáticamente, pero también debe quedar claro que representan un producto sobre el cual su creador todavía tiene supervisión.

Si puede leer su código e inmediatamente ver lo que hace, mucho mejor. Pero es la biblioteca personal del creador, y no se mantienen en el estándar que otras personas deben poder ver lo que hace sin referencia al creador.

Este no es un "riesgo" a cargo del equipo, como tampoco lo es la disposición de los efectos personales en su casa como un "riesgo" para aquellos que deseen solicitar un préstamo. Por el contrario, tener que indexar todo el contenido de su casa, organizarlo de manera establecida y proporcionar un manual de instrucciones para cada artículo, es un riesgo grave para su uso eficiente y continuo de la casa.

Siento tu dolor. Yo diría que tener una parte separada de su repositorio es probablemente la opción para almacenar estos scripts. Sin embargo, esto solo resuelve una parte del problema. Ahora los tiene almacenados en algún lugar, pero no es una buena manera para que sus colegas sepan que están allí.

En mi experiencia como consultor para una empresa donde los scripts son abundantes y escritos para diferentes clientes y generalmente en el sitio, ¡descubrir lo que ya existe es difícil!

Debes encontrar una manera de compartir lo que has construido.

En nuestra empresa, como no somos tan grandes, verificamos cosas como scripts en nuestro repositorio, pero también enviamos un correo electrónico a toda la empresa para informar a nuestros colegas de una nueva solución. De esta manera, al menos todos saben lo que ya existe y con quién contactar si lo necesitan.

Otros ya han explicado cómo y por qué asegurarse de que sus guiones 'útiles de usar y tirar' puedan ser lo suficientemente buenos para ir al repositorio. Solo voy a entrar y decir que es igual de importante asegurar que, si no son lo suficientemente buenos como para ir al repositorio, deben ser descartados.

Para decirlo de otra manera, son lo suficientemente buenos como para ir al repositorio o no lo son y deben ser expulsados. Si no son expulsados, se convierten en una carga de mantenimiento no administrada y eventualmente inmanejable.

Primero comenzaría diciendo que si sus desarrolladores son reacios a contribuir con código debido a sus estándares, sus estándares son demasiado rigurosos o deberían mejorar la calidad y la ética de trabajo de sus desarrolladores. Si se trata de scripts pequeños, no debería haber mucho esfuerzo adicional para poner un par de comentarios. Los desarrolladores deberían escribir código legible de forma predeterminada, y si no lo son, su verdadero problema radica en su personal.

Para responder a su pregunta, tiene algunas opciones:

1. Si los scripts son lo suficientemente genéricos, podría alojarlos en un repositorio separado. Si los scripts están muy centrados en el proyecto, esto puede no funcionar.
2. Aloje los scripts en el mismo repositorio en un directorio propio. Por ejemplo, en mi empresa, nuestros proyectos generalmente tienen un cli/directorio que contiene un puñado de scripts de línea de comandos, generalmente destinados a ejecutarse de forma única para inicializar entornos, importar ciertos datos, etc.
3. Esta podría ser una mala opción dependiendo de cuáles sean sus necesidades, pero si tiene algún motivo no puede comprometer el código que no sigue expresamente sus estándares, y / o tiene desarrolladores que no están dispuestos a escribir scripts si Si tiene que seguir esos estándares, puede alojar los archivos en una unidad compartida o algo similar. Puede que esta no sea la mejor solución si necesita todos los beneficios del control de código fuente; sin embargo, puede ser beneficioso en algunas circunstancias (gracias Doc Brown por esta edición)

Con cualquiera de las dos primeras opciones, puede elegir promulgar más estándares de codificación laxa en el otro repositorio o en el directorio.

Comience a formalizar sus procesos.

No da muchas pistas sobre para qué se utilizan estos scripts, pero supongo que tiene varias tareas de implementación y mantenimiento, o arreglos de datos comunes que se entregan a los desarrolladores porque son los que tienen el conocimiento suficiente para arreglar ¿cosas?

Deberías intentar ser más profesional al respecto.

• Escriba cuáles son estas tareas y los pasos para completarlas.
• Publique ese documento en algún sitio web interno o intranet
• Registre con qué frecuencia se realiza la tarea y cuánto tiempo lleva un sistema de tickets.
• Automatice los pasos manuales con un programa, pero no omita el control de origen, las pruebas, el soporte, etc. Desarrolle una herramienta de administración adecuada.
• Intente utilizar herramientas de terceros en lugar de desarrollar sus propias soluciones siempre que sea posible. Será más fácil para los nuevos empleados

El objetivo es hacer que el proceso sea puramente una función de memoria que cualquiera puede hacer siguiendo el documento o ejecutando la herramienta.

Luego, puede volver a poner a sus desarrolladores en funciones de escritura para su producto y contratar personal de soporte para que se encargue de los problemas cotidianos.

Casi cualquier script puede tener potencial de reutilización de una forma u otra. Pero ese potencial no será aparente inicialmente, razón por la cual se considera desechable en ese momento.

Ofrezca a su equipo la solución de repositorios tipo Github Gist, sin ningún control de calidad, para alentar su uso y evitar la pérdida de ese potencial.

Pero también tenga uno o más repositorios para herramientas / utilidades compartidas, con el control de calidad adecuado.

Solo cuando se hace referencia a los scripts almacenados en ese repositorio desechable, su potencial de reutilización comienza a desmoronarse. Es entonces cuando la reutilización formalizada debe iniciarse, ya sea iniciada por desarrolladores individuales que reconocen ese potencial o por usted si las referencias ocurren en un contexto de equipo. Puede suceder en la primera referencia, o tal vez en las posteriores (es decir, cuando se confirma que el potencial de reutilización es mayor), dependiendo de la capacidad, el horario, la carga, etc. del equipo.

El riesgo es que otros no podrán usar el código porque no pueden encontrarlo o entenderlo.

La referencia misma se ocupa del findproblema. El autor del guión y / o la persona que hace la referencia podría ayudarlo con el understandproblema. De lo contrario, el potencial de reutilización no está realmente presente o la comprensión del código sería solo parte del esfuerzo / costo formalizado de reutilización.

Una vez iniciado, el esfuerzo formal de reutilización debe ir en la pantalla de radar del equipo y el resultado finalmente debe aterrizar en el repositorio de herramientas / utilidades compartidas. Es entonces cuando se pueden eliminar los guiones desechables equivalentes a partir de los cuales se originó la reutilización (si su potencial se agotó).

Centrarse específicamente en código mal escrito pero funcional; Hay un argumento muy fuerte para no ponerlos en un repositorio.

Tengo una colección de fragmentos en mi carpeta personal de Dropbox. Contiene cosas que encuentro útiles:

• Un ejemplo genérico de repositorio de EF
• Un simple serializador / deserializador
• Una pequeña aplicación que combina dos archivos CSV y genera un nuevo archivo CSV.

Sin embargo:

• El ejemplo de EF carece de una implementación de unidad de trabajo y no contiene más que las opciones CRUD más rudimentarias.
• El serializador se basa en el antiguo XmlSerializer y es casi imposible cambiarlo por otra cosa. También tiene un problema de referencia circular masivo.
• La aplicación está codificada para buscar a.csv y b.csv en el directorio de la aplicación, y genera un ab.csv codificado en el mismo directorio. No hay verificaciones si existen archivos, no hay manejo de referencia nula.

Si bien sigo usando estos fragmentos regularmente cuando necesito implementar algo rápidamente, de ninguna manera son reutilizables o están bien construidos. Hay muchas razones por las cuales esto no se puede poner en el control de versiones de nuestra empresa:

• No autodocumentado.
• Poco o ningún estilo de codificación que no sea mi propio estilo de hack.
• Sin manejo de errores.
• No todas las trampas son obvias (por ejemplo, las referencias circulares en el serializador)

Pero el rasgo más comúnmente compartido de todos estos fragmentos:

• ¡Incluso si tuviera que crear documentación, probablemente le tomaría más tiempo leerla y comprenderla que hacer algo usted mismo!

Estos fragmentos son buenos para mí, ya que personalmente recuerdo para qué se usaron, cómo usarlos y cualquier dificultad que encontré.
Pero si tuviera que dar acceso a alguien a estos fragmentos, sin que yo esté presente, entonces no van a pensar que estos fragmentos son de alguna manera útiles.

Los fragmentos son solo una extensión de mi experiencia como desarrollador. Sin mí, estos fragmentos son basura. Solo uso los fragmentos porque no puedo recordar la sintaxis de toda una clase hasta el último carácter. Pero sí recuerdo la intención y las trampas, incluso mucho después de haber usado el fragmento por última vez.

Piénsalo de esta manera:

La cinta adhesiva es increíblemente versátil, puede resolver muchos problemas. Sin embargo, las cosas que se han resuelto mediante el uso de cinta adhesiva generalmente se consideran antiestéticas. Si IKEA incluyera cinta adhesiva para conductos en todos sus paquetes planos, aunque en realidad podría ayudar a algunas personas que lo necesitan, también sería una declaración contundente sobre la confianza de IKEA en la calidad de los muebles que le han vendido.

Por la misma razón, las empresas no deberían permitir fragmentos hacky en su control de versiones, ya que pone en duda la calidad del producto en general.