Soy un desarrollador relativamente nuevo, recién llegado de la universidad. Mientras estaba en la universidad y durante la búsqueda de empleo posterior, me di cuenta de que había muchas metodologías de desarrollo de software "modernas" de las que carecía mi educación: pruebas unitarias, registro, normalización de bases de datos, desarrollo ágil (frente a conceptos genéricos ágiles), estilo de codificación guías, refactorización, revisiones de código, sin métodos de documentación estandarizados (o incluso requisitos), etc.

En general, no vi que esto sea un problema. Esperaba que mi primer trabajo abrazara todas estas ideas y me las enseñara en el trabajo. Luego obtuve mi primer trabajo (desarrollo web full stack) en una gran corporación y me di cuenta de que no hacemos ninguna de estas cosas. De hecho, yo, el menos experimentado en el equipo, soy el que encabeza los intentos de poner a mi equipo al día con técnicas de programación "modernas", ya que me preocupa que no hacerlo sea un suicidio profesional en el futuro.

Primero comencé con el software de registro (log4J), pero luego pasé rápidamente a escribir mi propia guía de estilo, luego la abandoné por la guía de estilo de Google, y luego me di cuenta de que nuestro desarrollo web Java utilizaba controladores frontales escritos a mano, así que presioné para nuestra adopción de Spring, pero luego me di cuenta de que tampoco teníamos pruebas unitarias, pero ya estaba aprendiendo Spring ... y como pueden ver, se vuelve abrumador demasiado rápido, especialmente cuando se combina con el trabajo de desarrollo normal. Además, es difícil para mí ser lo suficientemente "experto" en estas metodologías para enseñar a alguien más en ellas sin dedicar demasiado tiempo a una sola, y mucho menos a todas.

De todas estas técnicas, que veo como "esperadas" en el mundo del desarrollo de software actual, ¿cómo las integro en un equipo como un jugador nuevo sin abrumar tanto a mí como al equipo?

¿Cómo puedo influir en mi equipo para que sea más ágil? está relacionado, pero estoy no un desarrollador ágil como el autor de la pregunta aquí, y estoy mirando a un conjunto mucho más amplio de metodologías que ágil.

Me parece que estás poniendo el carro delante del caballo.

¿Cuál es el principal problema que enfrenta su equipo y qué tecnologías ayudarían a solucionarlo?

Por ejemplo, si hay muchos errores, particularmente errores de tipo regresión, entonces las pruebas unitarias pueden ser un punto de partida. Si su equipo carece de tiempo, quizás un marco puede ayudar (a mediano y largo plazo). Si las personas tienen dificultades para leer el código de los demás, el estilo puede ser útil.

Recuerde que el propósito del negocio para el que trabaja es ganar dinero, no hacer código.

¿Java? ¡¿Moderno?! Has fallado en el primer obstáculo. Si quieres ser verdaderamente moderno y evitar el "suicidio profesional", debes escribir el código Rust. ¡Por supuesto, la próxima semana, todo cambiará y tendrás que aprender algo aún más nuevo para mantenerte al día!

O bien, puede aceptar que ninguna cantidad de tecnologías de boga o metodologías o marcos o cualquier otro du jour cambiará el hecho de que usted quiere construir productos de calidad que funcionan. No importa si no usa Agile si está produciendo con éxito la salida correcta. Por supuesto, si no lo está, es posible que desee cambiar las cosas, pero es probable que ninguna práctica en particular solucione los problemas. Seguirán siendo problemas humanos que se pueden solucionar de muchas maneras diferentes.

En cuanto al suicidio profesional, si sabes lo que estás haciendo y eres flexible, entonces no necesitas nada de lo que mencionaste. La gente continuará ideando nuevas formas de hacer el trabajo anterior y usted siempre se pondrá al día. O simplemente puede usar cualquier técnica que su compañía actual use independientemente. Cuando cambia su empresa, simplemente aprende y utiliza las técnicas que utilizan.

Demasiados niños se obsesionan con todas las nuevas herramientas que podrían usar, olvidando que estas herramientas no tienen valor en manos de un novato. Primero, aprenda la práctica, una vez que sea un desarrollador experimentado puede comenzar a "arreglar" las prácticas de desarrollo con "cosas nuevas y geniales", pero para entonces se habrá dado cuenta de que no son tan importantes como cree actualmente, y solo para usarse cuando realmente se necesitan.

Muchas compañías están estancadas así; incluso podría sorprenderse al descubrir que algunos de sus colegas desarrolladores son autodidactas y se convirtieron en desarrolladores sin antecedentes formales. Estos desarrolladores a menudo son mejores en sus trabajos, ya que serán los que se sientan impulsados ​​a aprender nuevas habilidades y tener éxito en lugar de simplemente hacer el trabajo. Desafortunadamente, esto también puede significar que, si bien son excelentes en la programación, es posible que no conozcan los beneficios de estas prácticas. El hecho es que estas son mejores prácticas, no prácticas comunes . Los mejores los usan, pero no son en absoluto requisitos para tener éxito, son simplemente herramientas para ayudar a que el éxito sea más fácil.

Tienes toda la razón, va a ser abrumador tratar de implementar todo de una vez. Es probable que se queme (y tal vez a su equipo) tratando de hacerlo, lo que va a desmotivar los esfuerzos futuros para adoptar nuevas metodologías / tecnologías. Lo mejor que puede hacer en una situación como esta es elegir uno(es probable que el inicio de sesión sea un buen comienzo, ya que probablemente tenga un camino difícil por delante para encontrar errores sin iniciar sesión, y seguramente habrá errores) y hable con el equipo al respecto. No tiene que implementar esto sin ayuda; será mucho mejor hablar de los pros y los contras con el equipo (y su jefe, que DEBE estar a bordo de algo como esto) y elaborar un plan para implementarlo. Se va a tener que ser lo menos doloroso posible (recuerde, usted está diciendo a la gente que ahora tiene que escribir extra de código, además de lo que ya lo hacen).

Y déjame decirte otra vez, asegúrate de que tu jefe compre . Esto es crucial; probablemente encontrará que la velocidad de las correcciones / lanzamientos se ralentiza a medida que implementa nuevas cosas. El punto es que estás pagando por adelantado para ahorrar en la línea; DEBEN entender esto y estar de su lado. Si no los llevas a bordo, estás peleando una batalla perdida en el mejor de los casos, y en el peor de los casos, pueden considerar que saboteas activamente al equipo (pregúntame cómo lo sé).

Una vez que traiga estos elementos a la mesa, discútalos con el equipo, planifique cómo implementarlos y realice el segundo, tercer, octavo, etc., será más fácil. No solo eso, existe la posibilidad de que el equipo y su jefe lo respeten a medida que sus sugerencias se implementen y se reconozcan como valor agregado. ¡Excelente! Solo asegúrese de mantenerse flexible: está presionando contra la inercia aquí, y el cambio no es fácil. estar preparado para poco a poco hacer pequeñoscambios, y asegúrese de que puede seguir el progreso y el valor ganado. Si implementa el inicio de sesión en un nuevo proceso y le ayuda a ahorrar horas encontrando un error en tres semanas, ¡haga un gran problema! Asegúrese de que todos sepan que la compañía acaba de ahorrar $ XXX al hacer lo correcto con anticipación. Por otro lado, si obtiene un retroceso o tiene una fecha límite ajustada, no intente forzar el problema. Deje que el nuevo cambio se deslice por el momento y circule hacia atrás. Nunca ganarás al tratar de obligar al equipo a hacer algo que no quieren hacer, y puedes estar seguro de que lo primero que sugerirán dejar es el nuevo trabajo 'extra' (como escribir el registro o seguir una guía de estilo en lugar de simplemente 'hacerlo funcionar').

Espero que no haya presentado los problemas a sus compañeros de trabajo como nos lo hizo en su publicación. ESO sería un suicidio profesional.

El primer problema es que está tratando de enseñar tecnologías y métodos con los que incluso no tiene experiencia a un grupo de programadores que, tal vez estén un poco desactualizados, pero que "hagan" el trabajo. Las posibilidades de ese contratiempo son infinitas y probablemente traerán mucha alegría a sus compañeros de trabajo. Es interesante y admirable que desee mejorar usted y su departamento, pero evite usar términos como "punta de lanza". Sinceramente, no uses esa palabra.

Como un problema secundario a lo anterior, verifique que esté haciendo algún trabajo . He estado trabajando como un programador de autoaprendizaje solitario durante mucho tiempo, y sé lo fácil que es dejar de lado el trabajo real para explorar marcos prometedores, tecnologías y similares. Asegúrese de que su rendimiento esté dentro de los parámetros esperados (no, a nadie le importa que pase 20 horas investigando Spring si ese informe que le pidieron no se realiza).

De todo lo anterior, evite ser el maestro (a menos que esté relacionado con un campo / tecnología en el que realmente tenga suficiente experiencia). Una presentación más neutral sería señalar las ventajas de, por ejemplo, las pruebas automatizadas, y dejar que la gerencia elija a quién quieren investigar los pros y los contras de esas prácticas.

Ahora, para presentar esas "mejores prácticas", hay dos formas de explicarlas a su equipo:

• Porque digo que son las mejores prácticas, y eso es suficiente.
• Porque son útiles y ayudan a resolver problemas.

Usando el primer argumento, a menos que usted sea el jefe o un miembro muy importante del equipo, es poco probable que le presten atención. Y "leí un libro de Knuth que lo dice" o "los muchachos de la SE dicen que" no causará ninguna impresión, tampoco ("esos muchachos no trabajan aquí, por lo que realmente no saben lo que es bueno para esta tienda de TI "). Tienen sus métodos, rutinas, procedimientos y cosas "más o menos" que funcionan, entonces, ¿por qué tomar el esfuerzo y los riesgos de cambiar?

Para que el segundo enfoque funcione, debe darse cuenta de que existe un problema . Entonces:

• no se esfuerce día y noche por las pruebas automáticas. Espere hasta que una actualización rompa algunas características, y el equipo tenga que trabajar horas extras para solucionarlo, y luego proponga construir un sistema de prueba automatizado.
• no solicite revisiones de código. Espere hasta que Joe tenga un permiso prolongado y sea necesario cambiar en ese módulo que solo Joe conoce, y señale a su jefe cuánto tiempo se perdió solo tratando de entender el código de Joe.

Por supuesto, el cambio será lento y progresivo (más aún en una gran corporación). Si puede introducir la revisión de código y las pruebas automatizadas en cinco años, debe felicitarse por el trabajo bien hecho. Pero, a menos que haya una reescritura completa debido a causas externas, olvídate de cualquier fantasía de que cambiarán el IS central a, por ejemplo, Spring ( Joel explicó eso de la mejor manera que pude, incluso antes de que nacieras ¹ ); en ese momento, a lo sumo, podría incluir a Spring en la lista de plataformas compatibles para escribir sistemas no críticos.

¡Bienvenido al mundo de TI empresarial, chico! :-pags

¹ : Ok, tal vez estoy exagerando un poco, pero no demasiado.

Deberías comenzar con el libro Trabajando efectivamente con código heredado de Michael Feathers. De la introducción del libro, "Se trata de tomar un sistema enredado, opaco, enrevesado y lentamente, gradualmente, pieza por pieza, paso a paso, convirtiéndolo en un sistema simple, bien estructurado y bien diseñado". Principalmente comienza con las pruebas automatizadas, para que pueda refactorizar de manera segura (sabrá si rompe algo), e incluye muchas estrategias para llevar el código difícil a las pruebas automatizadas. Esto es útil para cada proyecto que todavía está en desarrollo. Una vez que tenga un orden básico, puede ver de qué otras tecnologías modernas podría realmente beneficiarse su proyecto, pero no asuma que las necesita todas.

Si desea aprender un nuevo marco (o algo) por razones profesionales en lugar de porque su proyecto actual realmente lo necesita, entonces debe usarlo en algún proyecto personal (en su propio tiempo).

Fuente de control.

No lo mencionó, con suerte porque ya está en su lugar, pero, en caso de que no lo sea, comience allí.

El control de la fuente tiene el mayor beneficio por inversión, excepto en raras circunstancias que patológicamente necesitan algo más.

Y puede comenzar solo si nadie compra inicialmente.

Una respuesta directa

Otras respuestas hacen buenos 'metapuntos' sobre la adopción de mejores prácticas, pero, solo para darle una orientación directamente relevante, aquí hay un orden aproximado de las mejores prácticas que sugeriría que su equipo (o cualquier equipo) adopte (primero):

1. Fuente de control
2. Seguimiento de problemas (gestión de proyectos y tareas)
3. Construcciones automatizadas ¹
4. Implementaciones automatizadas

^{1 _{Una práctica muy relacionada es automatizar, o al menos documentar , la configuración del entorno de compilación y desarrollo de cada aplicación o proyecto de software que está desarrollando o manteniendo. Es mucho menos útil porque (con suerte) estás haciendo esto con poca frecuencia o rara vez.}}

Todo lo demas

Usted menciona varias otras buenas prácticas: "pruebas unitarias, registro, normalización de bases de datos, ... refactorización, ... documentación", pero estas son todas prácticas que pueden y deben adoptarse de forma gradual e incremental. Ninguno de ellos tiene que ser adoptada a la vez y usted probablemente mejor adoptarlos en absoluto mediante la adopción con cuidado y con atención plena.

Las cuatro prácticas que enumeré anteriormente también harán que adoptar y experimentar nuevas prácticas sea lo más fácil posible. Por ejemplo, las pruebas unitarias pueden incorporarse a sus compilaciones automatizadas y la documentación puede publicarse como parte de sus implementaciones automatizadas.

Algunas de las otras prácticas que menciona - "desarrollo ágil, ... guías de estilo de codificación, ... revisiones de código, ... métodos de documentación estandarizados" y marcos (por ejemplo, Spring) - son realmente opcionales o de dudoso valor. Y eso es cierto para muchas (¿la mayoría?) Prácticas posibles que descubrirá o encontrará.

El desarrollo ágil no es obviamente superior a ninguna otra metodología utilizada. Y mucha gente (incluido yo mismo) ha tenido experiencias horribles con él. Pero a mucha gente realmente le gusta (o le encanta) también. ¡Intentalo!

Las guías de estilo de codificación pueden ser útiles, especialmente para proyectos grandes o en equipos grandes, pero también es mucho trabajo hacer cumplir esas pautas y puede que no sea el mejor uso del tiempo de quien lo hace.

Las revisiones de código también pueden ser muy útiles: ¿ha pedido a sus compañeros de trabajo que revisen su código? ¡Tenga en cuenta que no necesita un proceso formal para adoptar buenas prácticas!

La documentación es excelente, ¿tiene alguna? ¡Si es así, bien por ti! ¿Se enfrenta a un montón de trabajo adicional que podría evitarse teniendo (más) documentación "estandarizada"? Si es así, entonces probablemente sea algo que valga la pena hacer. Sin embargo, supongamos que si un pequeño grupo de personas utiliza su software, es posible que no necesite ninguna documentación. (O puede incorporar directamente la documentación en su software. Esa es siempre mi preferencia).

Los armazones son ... una espada de doble filo (muy afilada). Una solución bien encapsulada y bien mantenida para una característica no central de su software es excelente ... hasta que no lo sea. No estoy seguro de qué son exactamente los "controladores frontales escritos a mano", pero no hay una explicación obvia de por qué son inferiores al código que aprovecha Spring. ¿Ha considerado encapsular la lógica común en todos estos controladores en su propio marco interno? Adoptar Spring y reescribir todo su código existente, podría ser un proyecto de refactorización inmenso (o, más probablemente, reescritura) y ese podría no ser el mejor cambio que podría hacer en su código . Por supuesto, no debe escribir todo el software que usa: ¡los marcos (y las bibliotecas) son geniales!Pero tal vez no tenga que usar Spring (o una alternativa) para escribir excelentes (o buenas) aplicaciones web.

Mira alrededor del equipo del que eres parte. ¿Puede ver alguna evidencia de que el desarrollo basado en pruebas o la normalización de la base de datos mejorará la calidad del software que está escribiendo o hará que las personas sean más productivas?

¿Has intentado hablar con uno de los supervisores de desarrollo al respecto o con el jefe de desarrollo? Un chat realmente informal sería un buen comienzo. ¿Qué te hace pensar que las personas superiores a ti no han tenido las mismas ideas pero no pueden / no las implementarán porque el negocio no lo permitirá?

Me parece que liderar con el ejemplo es un buen camino a seguir. Las personas son mucho menos resistentes si otra persona ya ha hecho el trabajo y puede mostrarles cómo replicarlo. Introduce TDD en un proyecto en el que estés trabajando. Pida una presentación al resto del equipo, o incluso a un par de personas más, y muéstreles lo que ha hecho. Lo que dijo @DrewJordan sobre conseguir que el jefe lo compre es más importante de lo que probablemente te des cuenta.

Encuentra un defecto. Arreglar una falla. Mostrar la solución

Tomemos la normalización * primero. Y, de hecho, te sugiero que lo tomes primero, porque es probable que la falta de normalización dé como resultado datos de errores reales que de otro modo no podrían existir, mientras que el resto son casos en los que las mejores prácticas probablemente podrían ayudar, pero es más difícil decir "Error A fue causado por no seguir la política X ". Si tiene una base de datos que no está normalizada, entonces tiene un lugar donde los datos pueden ser inconsistentes.

Es una buena apuesta que podrá encontrar un caso real de datos inconsistentes. Ahora has encontrado dos cosas:

1. Un error en sus datos.

2. Un error en los esquemas de su base de datos.

En realidad, sabía primero sobre el segundo error, pero el primero es más fácil de demostrar y también es algo que está causando un problema real, no algo que en teoría podría.

Desafortunadamente, una de las razones reales para resistir la normalización de la base de datos denormalizada es que la cuestión de qué hacer con estos datos con errores no siempre es fácil, pero habrá encontrado un error real.

(Sin embargo, tenga en cuenta que hay razones por las que a veces se puede desnormalizar algunos datos a propósito. No confunda el incumplimiento de la regla con el desconocimiento de la regla; si normaliza una tabla que está deliberadamente desnormalizada por la velocidad de búsqueda, ganó No gane ningún elogio. Incluso aquí, sin embargo, desnormalizar estar lleno es algo que debe hacerse de manera procesal, por lo que si la tabla denormalizada no se crea automáticamente en función del contenido de las tablas normalizadas, todavía hay progreso por hacer).

Por lo demás, preséntelos cuando ayuden a corto plazo, para luego desarrollarlos a largo plazo. Por ejemplo, si se le da un pequeño código para construir, escriba una prueba unitaria para ello. Mejor aún, si se le da un error para corregir, escriba una prueba unitaria que falle debido al error y luego, cuando haya solucionado el error, mencione el hecho de que pasa cuando cierra los errores (o envíe un correo electrónico diciendo que está solucionado) , o lo que sea).

* Por cierto, no muy moderno. La razón por la que se llama normalización y no normalización u otra cosa, es que en ese momento era una broma de actualidad el adherirse al final de las cosas para burlarse del nombre de la política de Vietnamización de Richard Nixon .

Voy a ir contra la corriente y decir: encuentra un nuevo trabajo después de pasar un tiempo en este para construir un poco tu currículum. Apunta por un año más o menos. Aunque muchas cosas son "palabras de moda", los problemas como la falta total de pruebas unitarias son intratables para un solo desarrollador, y es probable que si los programadores que trabajan allí no desean probarlos, nunca recibirán una compra e incluso pueden poner en peligro su posición. en la empresa haciendo que la gente piense en ti como un duro. Debe estar en un lugar donde pueda obtener mentoría, no tratando de impulsar la cultura hacia la competencia básica.

Ha habido muchas propuestas para mejorar el paradigma de programación . Las palabras de moda más populares ahora parecen ser una programación ágil y orientada a objetos. ¿O son? Ambos se han desvanecido sustancialmente en comparación con lo que eran hace solo cinco años.

Puede estar bastante seguro de que cualquier metodología implementada está tratando de lograr el mismo resultado final: ayudar a los ingenieros a producir económicamente un producto final que sea lo suficientemente bueno.

No es un paradigma que se introdujo polémica en los años 1960: Programación estructurada : Sólo para uso de "alto nivel" construye como while, for, repeat, if/ then/ else, switch/ casedeclaraciones en vez de la muy usada gotocomunicado que había sido aceptada por defecto. Hay todavía se debate acerca de si gototiene cualquier uso legítimo en absoluto.

Acepto que minimizar el uso de gotoes algo bueno, pero como todas las cosas buenas, es posible ir demasiado lejos.

Mencionas las agilemetodologías como algo positivo. Estuve en un equipo de desarrollo durante aproximadamente seis meses que siguió intencionalmente un régimen ágil prescrito. Descubrí que es como las metodologías de gestión de proyectos ilustradas de hace décadas, excepto que todo cambia de nombre. Quizás al agrupar y revender ideas para comunicar a alguien se gana la vida y las empresas pueden sentirse bien por "ver" la ropa nueva del emperador .

La lección más valiosa de Agile, que se conocía hace mucho tiempo, es que la flexibilidad para encontrar un mejor camino hacia el producto terminado es algo bueno y la capacidad de encontrar ese camino puede provenir de cualquier persona, no solo de la alta gerencia.

De un escrito del cabecilla anti-goto Edsger Dijkstra:

El arte de la programación es el arte de organizar la complejidad, dominar la multitud y evitar su caos bastardo de la manera más efectiva posible.

—Dijkstra, en: Dahl, Dijkstra & Hoare 1972, pág. 6. (vea la página 6 aquí .)