Asesoramiento / Enfoque para destilar código homogéneo y construir código común para un equipo

Yo trabajo para el estado de California. En mi opinión, nuestro equipo de programación no es realmente un 'equipo' en el sentido de que generalmente trabajamos solos en proyectos a lo largo del ciclo de vida completo de la aplicación / sistema.

El resultado final es que muchos desarrolladores están 'reinventando la rueda' ... escribiendo sus propias capas de datos, a pesar de que la gran mayoría de nosotros trabajamos en el mismo Oracle DB ... escribiendo sus propias cosas de seguridad ... la lista continúa en.

No puedo cambiar la mentalidad de mis empleados, y no tengo ambiciones realistas con respecto a cambiar el proceso de nuestro equipo ... pero mi objetivo es lograr que nuestro equipo trabaje juntos un poco más, al menos para construir un edificio común bloquear piezas que todos podemos usar para la funcionalidad repetitiva.

Los beneficios obvios son que las pruebas y el soporte son mucho más fáciles de mantener cuando todos nuestros usuarios están familiarizados con una pieza común, el tiempo de producción es menor cuando no está escribiendo el mismo repositorio que otra persona ya lo hizo, y podemos centrarnos en proporcionar mejores soluciones a los problemas únicos que nuestras aplicaciones deben resolver ... etc.

Estoy predicando al coro, estoy seguro.

El truco es que al Estado no le gustan los cambios, tampoco a sus empleados. Los gerentes a menudo ignoran las nuevas ideas simplemente porque les gusta evitar la fricción y prefieren continuar como están.

Hay preguntas similares por ahí, pero lo que estoy buscando es asesoramiento sobre cómo alguno de ustedes se ha enfrentado a una situación similar, y cualquier dirección para obtener un tipo de esfuerzo de "base" va a ser más fácil acercarse a la administración.

EDITAR: Solo para aclarar algunas cosas:

• El alcance que estoy buscando está dentro de la tienda de TI de mi Agencia Estatal. No estoy tratando de coordinar entre varios departamentos. Tengo que sacar a la gente de las ruedas de entrenamiento antes de pedirles que conduzcan motocicletas.

• La seguridad no es una gran preocupación, la mayoría de nuestras aplicaciones son internas y están escritas en Windows Forms distribuidos en Citrix (ugh.) Y casi todas usan las mismas tablas empresariales en Oracle ... muy pocas si alguna aplicación está "clasificada" para hablar. No debería obstaculizar la colaboración.

• He ido tan lejos como para configurar un feed NuGet, con un par de piezas de código empaquetadas, y escribí algunos repositorios para Oracle, envié algunos correos electrónicos, pero recibí pocos comentarios. Tengo aproximadamente 1/3 de nuestro equipo usando ReSharper, y envío correos electrónicos de vez en cuando con consejos ... nuevamente, no hay muchos comentarios.

El problema es...

los beneficios obvios

puede no ser tan obvio para las personas que te rodean, especialmente si no son desarrolladores. He trabajado tanto para los gobiernos estatales como para el gobierno federal para poder empatizar con su situación. En mi experiencia, debes mostrarles el dinero . Comience a equiparar los cambios a los números ( por ejemplo, métricas ) y luego equipare las métricas a dinero. Me doy cuenta de que esto no es divertido y me doy cuenta de que tú tampoco deberías haberlo hecho, pero a menudo esto es lo que ocurre. Todos los estados están en una crisis presupuestaria y mostrándoles cómo pueden satisfacer mayores demandas sin necesitar más dinero, más atractivas pueden ser sus ideas.

En el camino, puede encontrar que algo que desea hacer suena ( o se siente ) mejor, pero los números no lo apoyan. Si eso sucede, es posible que se embarque en un debate religioso sobre tecnología que realmente puede molestarlo; o descarrilar por completo; otro progreso que estás haciendo. En ese caso, ríndete y pasa a la siguiente idea. Vuelva a esos una vez que todos estén más abiertos a los cambios.

Para las métricas ... comience con los clásicos, funcionan bien en la mayoría de los casos.

• Hora / Horarios ( podría incluir el rendimiento del sistema )
• Dinero ( gastado y ahorrado )
• Material
• Defectos ( tasas, gravedad, visibilidad para los usuarios finales )
• Fiabilidad ( en términos gubernamentales, esto es Ao [Disponibilidad operativa] y MTBF Tiempo medio entre fallas )

¡Buena suerte!

¿Podría considerar asociarse con uno o dos de sus compañeros de trabajo para ayudar a comenzar a construir un marco común? Esa sería mi sugerencia para un punto de partida, ya que necesitarás aliados y algunos de los beneficios pueden revelarse después de un tiempo trabajando juntos para que las cosas no estén tan aisladas. Es posible que tenga que tener algunas conversaciones con sus compañeros de trabajo para ver cuán receptivos son algunos a estas ideas y cuáles son los primeros en adoptar que podría utilizar para hacer que esto despegue.

Mi tema principal sería considerar pequeños pasos aquí. Pequeños cambios periódicamente pueden funcionar bien.

El primer paso será anunciar (entre cualquier persona interesada y que trabaje para el mismo empleador) lo que tiene .

Al igual que las oficinas de la facultad de las universidades, tenga carteles que ilustren la arquitectura, la funcionalidad y los diseños de las piezas que tiene. Este es el "inventario" o "activo" del Estado.

Una segunda pregunta es si los empleadores pueden ver el código fuente de otros. Si esto no está permitido, la colaboración será muy difícil (a menos que pueda obtener apoyo a nivel estatal).

Cuando se trata de seguridad, es probable que el Estado ya tenga algunos mandatos de seguridad de la información que todos los proyectos deben cumplir. Puede ser un buen punto de partida para la estandarización.

Algún tipo de trabajo, especialmente. "proyectos de personalización", siempre serán trabajos en solitario, porque aquí es donde pertenecen.

Comenzaré diciendo que soy un gran defensor y defensor del código reutilizable y que defino bloques de construcción geniales, ingeniosos y potentes que múltiples desarrolladores tienen que usar. Sin embargo, también señalaría que rodar su propio código / bibliotecas / marcos reutilizables a veces puede ser una espada de doble filo muy afilada. Y algo que pensarías que debería ahorrar tiempo, a veces podría hacer todo lo contrario.

Este ha sido el patrón que observé en el pasado: a medida que un desarrollador sigue trabajando en un producto / características / lanzamientos, algunos de ellos (tal vez 10-25%) identificarán algunos componentes reutilizables o algunas clases que serían simplemente tontas para seguir escribiendo una y otra vez. El resto de la gente, continúa copiando / pegando y reinventando la rueda. Olvidemos esos, no eres uno de ellos.

Entonces, cuando identifica un código reutilizable, comienza a crear su propia biblioteca personal de cosas geniales que con el tiempo hacen que su vida sea cada vez más fácil. Es posible que tenga clases de utilidad para ayudarlo a trabajar con XML, subprocesos, registro ... lo que sea. He hecho esto y se lo mostré a cualquiera que esté dispuesto a escuchar y algunas personas aceptaron con gusto el hecho de que pueden analizar lo que necesitan de un documento XML con 6 líneas de código. Otras personas se fijan en sus formas y les encanta codificar cientos de líneas de MSXML directo.

Mis hallazgos:

1. Con el tiempo, a medida que su biblioteca mejore, otros comenzarán a usarla gradualmente.

2. a medida que otros comienzan a usarlo, ahora se convirtió en la persona de soporte técnico en cualquier momento que tengan un problema y sospechen que es su código. A veces encuentran un error en su código porque usan la API de forma ligeramente diferente a cómo la usó, a veces el error está en su código porque no entendieron cómo usar la API y, a veces, el error no está relacionado, pero la carga está sobre porque están convencidos de que antes de agregar su biblioteca todo funcionaba.

3. (en realidad, esto fue de una publicación / blog diferente pero no puedo encontrar el enlace): si escribiste algún "código reutilizable" y te tomó 3 semanas hacerlo. En general, debe pasar otras 3 semanas limpiando para que otras personas puedan consumirlo y proporcionar documentación clara y otras 3 semanas para escribir pruebas unitarias extensas y también cubrir escenarios de uso general, no solo sus escenarios de uso. Otras personas encontraron lo mismo, los frameworks / bibliotecas requieren 3 veces más esfuerzo que el desarrollo original solo.

4. Esperemos que no tengas que enfrentar esto. Parte de mi código se volvió tan reutilizable que la gente realmente comenzó a usarlo en una configuración más amplia. Luego, hace aproximadamente 9 meses, la gerencia decidió dividir nuestro producto en 2 diferentes, cada uno con su propio ciclo de lanzamiento. ¿Qué crees que pasó con ese marco / biblioteca de utilidades? Ambos productos dependen de él, pero ahora debe tener cuidado de cómo se modifica la biblioteca si está desarrollando activamente el producto A mientras el producto B está a punto de ser lanzado. Nuestra solución fue hacer que el framework en sí sea el producto C que tuviera su propio ciclo de lanzamiento independiente. Así que aquí estoy 9 meses después y todavía siento las réplicas de todos los problemas de compilación / integración continua / empaquetado que esto ha causado.

5. Puede ser extremadamente cuidadoso al escribir sus clases de utilidad y comprender todas las implicaciones de hacer este cambio y aquello. Pero una vez que otras personas comiencen a usar su código, en algún momento querrán modificarlo. Si hay otros 20 componentes que dependen de su biblioteca, cuando alguien modifica la biblioteca, puede romper otros 19 componentes (supongo que hicieron el cambio para que su código funcione). A medida que el código se usa más ampliamente, se vuelve mucho más costoso modificarlo.

6. Aunque estoy totalmente de acuerdo con la reutilización, hay días en que a la hora del almuerzo empiezo a desearme a mí mismo que mi biblioteca de servicios personales siga siendo mi biblioteca de servicios personales.

De acuerdo con mi experiencia, algunos consejos que puedo pensar:

1. Busque bibliotecas externas de terceros que hagan lo que necesita y cree sus aplicaciones en la medida de lo posible. Cada una de esas bibliotecas ya tiene un equipo de personas que lo respaldan. Preséntelos a un lugar global en su entorno donde cualquiera pueda acceder a ellos.

2. En lugar de pedirles a todos que usen tus cosas, acércate a tus compañeros de equipo y a otros ingenieros uno a uno y observa quién tiene la misma mentalidad que tú. Estoy seguro de que encontrará algunos otros que compartan sus valores y podría comenzar un equipo central no oficial que trabajaría hacia un bien común.

3. No sé si este funcionará y / o es una buena idea, pero quiero probar esto en mi propia empresa: en lugar de crear marcos / bibliotecas que sean globales y de propiedad / uso de múltiples personas / equipos. Trate todo su código como "código abierto interno". Configure un repositorio similar a github donde diferentes personas / equipos pueden enviar código de biblioteca / utilidad / ayuda. Haga que el repositorio sea visible para todos, de modo que si escribe algo bueno, cualquiera podría tomar su código y usarlo. Si deciden hacer un cambio en su código, al igual que el código abierto, pueden crear su propia rama, que mantendrán, o devolverle el cambio para volver al tronco principal. Si no confía en su trabajo o no está de acuerdo con el cambio, dado que el proyecto sigue siendo suyo, tiene la última palabra si desea aceptarlo. Si algún equipo comienza un proyecto y luego lo abandona pero un equipo diferente lo encuentra útil, pueden ramificarse en el repositorio de su propio equipo y continuar el trabajo. He estado buscando usar Redmine para hacer algo como esto, pero aún no he tenido la oportunidad de configurarlo.