Me suena como si estuvieras poniendo el carro delante del caballo.

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

Por ejemplo, si hay muchos errores, en particular errores de tipo de regresión, las pruebas unitarias pueden ser un punto de partida. Si a su equipo le falta tiempo, tal vez un marco pueda ayudar (a medio o 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, podría aceptar que ninguna cantidad de tecnologías, metodologías o marcos de palabras de moda o cualquier otro du jour cambiará el hecho de que desea crear productos de calidad que funcionen. No importa si no usa Agile si está produciendo con éxito la salida correcta. Por supuesto, si no lo está, entonces es posible que desee cambiar las cosas, pero es probable que ninguna práctica particular solucione los problemas. Seguirán siendo problemas humanos que pueden solucionarse de muchas maneras diferentes.

En cuanto al suicidio profesional, si sabes lo que estás haciendo y eres flexible, entonces no necesitas ninguna de las cosas que mencionaste. La gente continuará encontrando nuevas formas de hacer el trabajo anterior y siempre se pondrá al día. O simplemente puede usar cualquier técnica que use su compañía actual independientemente. Cuando cambias de empresa, simplemente aprendes y utilizas 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 ningún valor en manos de un novato. Aprende primero la práctica, una vez que seas un desarrollador experimentado, puedes comenzar a "arreglar" las prácticas de desarrollo con "cosas nuevas y geniales", pero para entonces, probablemente te habrás dado cuenta de que no son tan importantes como crees actualmente. solo para ser utilizado cuando son realmente necesarios.

Muchas empresas están atrapadas de esta manera; es posible que incluso se sorprenda al descubrir que algunos de sus colegas desarrolladores son autodidactas y se convirtieron en desarrolladores sin ningún tipo de formación formal. Estos desarrolladores a menudo son mejores en sus trabajos, ya que serán los que tendrán que 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 estén conscientes de los beneficios de estas prácticas. El hecho es que estas son las prácticas mejores , no las prácticas comunes . Los mejores los usan, pero no tienen ningún requisito 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 a usted mismo (y tal vez a su equipo) tratando de hacerlo, lo que va a desmotivar los futuros impulsos para adoptar nuevas metodologías / tecnologías. Lo mejor que se puede hacer en una situación como esta es elegir una cosa (el registro es probablemente un buen comienzo, ya que es probable que tengas un camino difícil por delante para encontrar errores sin el registro, y seguramente habrá bichos) y hablar con el equipo al respecto. No tienes que implementar esto solo; lo hará mucho mejor al discutir los pros y los contras con el equipo (y su jefe, quien DEBE estar totalmente de acuerdo con algo como esto) y crear un plan para implementarlo. Tendrá que ser lo menos doloroso posible (recuerde, le está diciendo a las personas que ahora tienen que escribir el código extra además de lo que ya hacen).

Y déjame decirte una vez más, asegúrate de que tu jefe compre . Esto es crucial; Probablemente encontrará que la velocidad de los arreglos / lanzamientos disminuye a medida que implementa cosas nuevas. El punto es que estás pagando por adelantado para salvar la línea; DEBEN entender esto y estar de tu lado. Si no los incorporas, en el mejor de los casos estás luchando contra una batalla perdida y, en el peor de los casos, pueden considerarte como un sabotaje activo del 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 siga adelante, el segundo, tercero, octavo, etc. será más fácil. No solo eso, hay un potencial para que el equipo y su jefe lo respeten a usted, ya que sus sugerencias se implementan y reconocen como un valor agregado. ¡Genial! Solo asegúrate de mantenerte flexible: estás presionando contra la inercia aquí, y el cambio no es fácil. prepárese para lentamente hacer pequeños cambios, y asegúrese de poder seguir el progreso y el valor ganado. Si implementas el registro en un nuevo proceso y te ayuda a ahorrar horas encontrando un error en tres semanas, ¡haz un gran negocio al respecto! Asegúrese de que todos sepan que la empresa acaba de ahorrar $ XXX haciendo lo correcto antes de tiempo. Por otro lado, si obtiene un rechazo, o si tiene un plazo ajustado, no intente forzar el problema. Deje que el nuevo cambio se deslice por el momento y haga un círculo hacia atrás. Nunca ganará tratando de forzar al equipo a hacer algo que no quiere hacer, y puede estar seguro de que lo primero que sugerirán es abandonar el nuevo trabajo 'extra' (como escribir registro o seguir) una guía de estilo en lugar de 'hacerlo funcionar').

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

El primer problema es que estás tratando de enseñar tecnologías y métodos con los que incluso no tienes experiencia con un grupo de programadores que, tal vez estén un poco desactualizados, pero que hagan el trabajo "hecho". Las posibilidades de ese retroceso 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 "encabezado". Sinceramente, no uses esa palabra.

Como una cuestión complementaria a la anterior, compruebe que está haciendo algún trabajo . He estado trabajando como programador solitario y de autoaprendizaje durante mucho tiempo, y sé lo fácil que es dejar de lado el trabajo real para explorar marcos prometedores, tecnologías y cosas por el estilo. 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 está hecho).

De todo lo anterior, evita ser el profesor (a menos que esté relacionado con un campo / tecnología en el que realmente tengas 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énes quieren investigar las ventajas y desventajas 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 seas el jefe o un miembro muy importante del equipo, es poco probable que te presten atención. Y "leí un libro de Knuth que lo dice" o "los chicos de la SE dicen que" tampoco causarán ninguna impresión ("esos chicos no trabajan aquí, así que realmente no saben lo que es bueno para esta tienda de TI". "). Tienen sus métodos, rutinas, procedimientos y las cosas que "más o menos" funcionan, así que, ¿por qué tomar el esfuerzo y los riesgos de cambiar?

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

• no empieces día y noche para realizar 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 pida revisiones de código. Espere hasta que Joe tenga una licencia prolongada y haya una necesidad de cambiar ese módulo que solo Joe conoce, y señale a su jefe cuánto tiempo se perdió 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 llega a introducir la revisión de código y las pruebas automatizadas en cinco años, debe felicitarse por un trabajo bien hecho. Pero, a menos que haya una reescritura completa debido a causas externas, olvídese de cualquier fantasía a la que cambiará el IS central, por ejemplo, Spring ( Joel lo explicó mejor que nunca, incluso antes de que nacieras ¹ ); en ese tiempo, como mucho, podría obtener a Spring en la lista de plataformas compatibles para escribir sistemas no críticos.

¡Bienvenido al mundo de las TI empresariales, chico! :-p

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

Debes comenzar con el libro Cómo trabajar con eficacia con el código heredado por Michael Feathers. A partir de la introducción del libro, "se trata de tomar un sistema enmarañado, opaco, enrevesado y poco a poco, pieza por pieza, paso a paso, convirtiéndolo en un sistema simple, bien estructurado y bien diseñado". Principalmente comienza con las pruebas automatizadas, de modo que puede refactorizar de manera segura (sabrá si rompe algo), e incluye muchas estrategias para poner código difícil en las pruebas automatizadas. Esto es útil para todos los proyectos que aún están en desarrollo. Una vez que haya implementado un orden básico, puede ver de qué otras tecnologías modernas podría beneficiarse realmente 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).

Control de fuente.

No lo mencionaste, con suerte porque ya está en su lugar, pero, en caso de que no lo esté, comienza por allí.

El control de la fuente tiene la mayor relación calidad-precio, excepto en raras circunstancias patológicamente que necesitan algo más.

Y puedes empezar solo si nadie compra inicialmente.

Una respuesta directa

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

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

^{1 _{Una práctica muy relacionada es automatizar, o al menos documento , configurar el entorno de desarrollo y desarrollo de cada aplicación o Proyecto de software que estás desarrollando o manteniendo. Es mucho menos útil porque está (con suerte) haciendo esto con poca frecuencia o raramente.}}

Todo lo demás

Menciona varias otras buenas prácticas, "pruebas unitarias, registro, normalización de la base de datos, ... refactorización, ... documentación", pero todas estas prácticas pueden y deben adoptarse gradualmente y incrementalmente Ninguno de ellos necesita ser adoptado de una sola vez, y es probable que sea mejor que los adopte en absoluto al adoptarlos con cuidado y atención.

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 en 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ódigos, ... 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?) Posibles prácticas que descubrirá o encontrará.

El desarrollo ágil no es obviamente superior a cualquier otra metodología utilizada. Y muchas personas (incluido yo mismo) han tenido experiencias horribles con esto. Pero a muchas personas realmente les gusta (o les encanta) también. ¡Pruébalo!

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 para aplicar esas pautas y puede que no sea el mejor uso del tiempo de quien lo esté haciendo.

Las revisiones de código pueden ser muy útiles también. ¿Le 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, ¿tienes alguna? ¡Si es así, bien por ti! ¿Se enfrenta a un montón de trabajo adicional que podría evitarse con (más) documentación "estandarizada"? Si es así, entonces eso es probablemente algo que vale la pena hacer. Sin embargo, diga si su software está siendo utilizado por un pequeño grupo de personas, es posible que no necesite la documentación de cualquier . (O puede incorporar directamente la documentación en su software. Esa es siempre mi preferencia).

Los marcos 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 inmenso proyecto de refactorización (o, más probablemente, reescritura) y ese podría no ser el mejor cambio que podría hacer a su código . Por supuesto no debe escribir todos del software que utiliza: marcos (y bibliotecas) son geniales! Pero tal vez no tiene que usar Spring (o una alternativa) para escribir aplicaciones web excelentes (o buenas).

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?

¿Ha 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 anteriores no han tenido las mismas ideas pero no pueden implementarlas porque la empresa no lo permitirá?

Encuentro que predicar con el ejemplo es una buena manera de avanzar. Las personas son mucho menos resistentes si alguien más ya ha hecho el trabajo y puede mostrarles cómo replicarlo. Introduce TDD en un proyecto en el que estés trabajando. Pídale que haga una presentación al resto del equipo, o incluso a un par de otros, y muéstreles lo que ha hecho. Lo que dijo @DrewJordan sobre cómo comprarle al jefe es más importante de lo que probablemente se dé cuenta.

Encuentra un defecto. Corregir una falla. Mostrar la corrección.

Tomemos la normalización * primero. Y, de hecho, le sugiero que lo tome primero, ya que la falta de normalización probablemente resulte en datos de buggy reales que de otra manera no podrían existir, mientras que el resto son casos en los que las mejores prácticas 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, conocías el segundo error primero, pero el primero es más demostrable y también es algo que está causando un problema real, no algo que teóricamente podría.

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

(Tenga en cuenta, sin embargo, que existen motivos por los que a veces se pueden normalizar algunos datos a propósito. No confunda el incumplimiento de la regla por ignorancia de la regla; si normaliza una tabla que está deliberadamente desnormalizada para la velocidad de búsqueda , no ganará ningún prestigio. Incluso en este caso, desnaturalizar el problema es algo que debe hacerse de manera procesal, por lo que si la tabla desnormalizada no se crea automáticamente en función del contenido de las tablas normalizadas, todavía hay progreso por hacer). / p>

Para el resto, preséntelos cuando ayuden a corto plazo, para luego desarrollarlos a largo plazo. P.ej. Si le dan un pequeño código para construir, escriba una prueba de unidad para ello. Mejor aún, si se le da un error para corregirlo, escriba una prueba de unidad 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 que diga 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 o alguna otra cosa, es que en el momento era una broma tópica para pegar -ization en el Fin de las cosas para burlarse del nombre de la política Vietnamization de Richard Nixon.

Voy a ir contra el grano y decir: encontrar 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. Si bien muchas cosas son "palabras de moda", los problemas como la falta completa de pruebas de unidad son imposibles de resolver para un solo desarrollador, y es probable que si los programadores que trabajan allí no desean realizar pruebas, nunca se compre y hasta se ponga en peligro su posición. en la empresa haciendo que la gente piense en ti como un fanfarrón. Necesitas estar en un lugar donde puedas recibir tutoría, no intentando impulsar la cultura hacia una competencia básica.

Ha habido muchas propuestas para mejorar el paradigma de programación . Las palabras de moda más actuales 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 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.

Hay un paradigma que se introdujo polémicamente en la década de 1960: programación estructurada : solo use construcciones de "alto nivel" como while , for , repeat , if / then / else , switch / case en lugar de la declaración goto muy usada que había sido aceptada por defecto. Hay todavía debates sobre si goto tiene algún uso legítimo.

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

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

La lección más valiosa de Agile, que se conoció 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 gerencia superior.

De un escrito por el dirigente antigoto Edsger Dijkstra:

  

El arte de la programación es el arte de organizar la complejidad, de dominar la multitud y evitar su caos bastardo con la mayor eficacia posible.

     

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