¿Dónde debe comenzar mi equipo para convertirse en "moderno"? [cerrado]

106

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.

WannabeCoder
fuente
92
"moderno"? Elimine esa palabra de moda "ágil" de su lista y solo puedo ver cosas con una edad de más de 20 años.
Doc Brown
10
¿Quizás "moderno" en el sentido de que la adopción generalizada de ellos es moderna, no los genes de las ideas, entonces? Tampoco soy un experto en este tema, esta es solo mi impresión.
WannabeCoder
41
Le aseguro que las pruebas unitarias, el registro, la normalización de la base de datos, las guías de estilo de codificación, las inspecciones de código (= revisiones) son todas mayores de 30 años. El término "refactorización" tiene al menos 15 años (Fowler escribió su libro en 2000). Y no tener documentación formal o requisitos escritos no es "una técnica moderna", es en mi humilde opinión ni siquiera una "técnica".
Doc Brown
69
@DocBrown admítelo, acabas de enviar a Marty a tiempo para crear todas estas cosas antes de hacer tu comentario.
nulo
17
Me preocupa más que su universidad no esté enseñando esas cosas por adelantado: he estado fuera de la escuela más de 15 años y la mayoría de esas cosas se cubrieron bastante temprano. (Menos las palabras de moda, por supuesto).
Allen Gould

Respuestas:

165

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.

Jaydee
fuente
35
Más o menos. En parte desde un punto pragmático de tener que comenzar en algún lugar y en parte desde un punto de reputación que si puede solucionar un problema para el equipo, pueden estar más dispuestos a escuchar otras sugerencias. También tenga en cuenta que esta compañía estaba haciendo dinero antes de que usted llegara con sus métodos existentes, por lo que lo que tiene que implementar tiene que aumentar la capacidad de hacer dinero de la compañía.
Jaydee
66
Aceptando esto, pero agradecería un seguimiento para abordar los riesgos de esto profesionalmente (por ejemplo, "mi currículum tendría más cosas, pero mi antiguo trabajo no
abarcaba
44
@WannabeCoder: debes comenzar a usarlo antes de que seas competente. Todavía puede poner código en producción. A veces la codificación es como ser un médico. Todos seguimos practicando.
JeffO
55
Gran respuesta. Solo debe implementar estas cosas para resolver problemas, no para fabricar problemas.
Kik
55
@WannabeCoder Es importante darse cuenta de que ninguna de estas metodologías se creó en el vacío. Se están extendiendo ampliamente porque ayudan a resolver problemas . Si intenta implementarlos y no ayudan a resolver los problemas que enfrenta su equipo, entonces no ha logrado nada y posiblemente haya malinterpretado y abusado completamente las prácticas. Tu enfoque como desarrollador debe ser resolver problemas en cada acción que tomes. Busque pequeñas victorias donde poner en práctica estas prácticas un poco más mejorará la situación. Esto ayuda a construir un caso para expandirlos.
jpmc26
77

¿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.

gbjbaanb
fuente
44
Muy buena respuesta (+1), especialmente el último párrafo. Un libro muy moderno (moderno en el sentido en que lo encuentro muy relevante hoy) que estoy leyendo recientemente es SICP.
Giorgio
1
+1 por la mención de la rapidez con que cambian estas palabras de moda y los idiomas populares. Un buen desarrollador que publica un buen código triunfa sobre cualquier metodología. ¡Haz lo que funciona y funciona bien!
WeRelic
2
Si bien tiene razón en que estos deben usarse correctamente, no estoy de acuerdo con la idea de que "no son tan importantes como usted piensa actualmente". Bien, claro, eso podría ser cierto para algunas prácticas (soy algo escéptico de las pruebas unitarias), pero otras son extremadamente valiosas. Tuve la oportunidad de comenzar a hacer una gran cantidad de CI y automatización y un buen uso del control de fuente desde el principio, y ahora trabajando en un proyecto donde esos no están presentes, veo todos los problemas que queríamos resolver en acción: errores, inconsistencias , nadie sabe qué código es dónde, funciona. Esas prácticas hacen una gran diferencia.
jpmc26
66
Nadie dice "no resuelvas problemas", el problema es cuando se introducen soluciones buscando problemas para resolver. No son tan importantes como muchos piensan, los cultistas de carga piensan que las herramientas son la parte importante, donde en realidad son solo herramientas. Lo que importa es el profesional, y cualquier herramienta que funcione en los lugares correctos es la que debe elegir. mi punto es nunca elegir una herramienta simplemente porque está en la caja de herramientas.
gbjbaanb
2
Un tonto con una herramienta sigue siendo un tonto.
Pete Becker
40

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').

DrewJordan
fuente
66
Dudo que quisieras decir mucho con eso, pero me molesta un poco la burla de los desarrolladores como yo sin una educación universitaria. Mi experiencia (desafortunadamente) ha sido que la educación universitaria tiene poca correlación con la calidad del desarrollador. Y hasta ahora en mi carrera, he sido uno de los que defiende e implementa las mejores prácticas. Sin embargo, tu consejo es genial.
djeikyb
55
En realidad, lo dije de otra manera: el OP se sorprendería de cuántos buenos desarrolladores hay sin educación formal. Muchos puestos tecnológicos se abrieron en los últimos 20/30 años que fueron ocupados por personas dispuestas a aprender en lugar de niños con un título. Y mis hallazgos reflejan los suyos: la experiencia siempre es mejor que la educación. Es por eso que el OP debe ir despacio ... empujar a un equipo a adoptar nuevas prácticas demasiado rápido hará que se sientan resentidos con él, y no tendrá la experiencia para moderar esas actitudes. También es importante darse cuenta de que algunos equipos nunca usarán estas herramientas; ahí es cuando obtienes un nuevo trabajo.
DrewJordan
1
"Muchas empresas están estancadas de esta manera; incluso podría sorprenderse al descubrir que algunos de sus colegas 'desarrolladores' son autodidactas y se convirtieron en desarrolladores sin antecedentes formales". Estos a menudo resultan ser los desarrolladores más valiosos debido a su experiencia en el dominio.
pmf
Bien, estoy totalmente de acuerdo. Reescribió el primer párrafo para que suene menos condescendiente. Solo quería asegurarme de que OP supiera que una buena parte de la fuerza laboral no tiene una formación formal. Mala elección de palabras de mi parte.
DrewJordan
18

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 1 ); 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

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

SJuan76
fuente
1
Mayormente en desacuerdo. La única forma de lograr algún cambio en un equipo es si alguien está dispuesto a investigar y arrastrar al resto. Por supuesto, debes seguir siendo productivo, pero si todos mantienen la cabeza baja, terminas "un poco desactualizado, pero haces el trabajo". Y completamente quemado por el aburrimiento.
winkbrace
@winkbrace No afirmo que no debas intentar mejorar (de hecho, digo lo contrario). Pero impulsar esos cambios sin el apoyo de la gerencia y sin las autorizaciones de cierta antigüedad puede ser bastante difícil y causar cierta resistencia; Además, el OP no es un experto en sí mismo y puede tener problemas con la implementación real. Sería bueno que el OP pudiera ofrecerse como voluntario en un equipo de investigación / creación de prototipos para introducir los cambios adecuadamente; pero le prohibió tener cuidado al elegir el enfoque correcto para promoverlos y ser paciente.
SJuan76
@winkbrace por aburrimiento, depende de tu personalidad y de lo que buscas en un trabajo. Es sensato tratar de aterrizar en un puesto de trabajo que lo satisfaga, en lugar de ir a cualquier parte e intentar cambiar la organización a su gusto. Y, por lo general, las grandes corporaciones (excepto los departamentos de I + D) no son el lugar para las personas a las que les gusta probar una nueva tecnología cada pocos meses.
SJuan76
Es un poco complicado decir "asegúrate de que realmente estás haciendo el trabajo". Seguro que debe hacer el trabajo, pero también debe pensar a largo plazo y cada día debería estar mejorando. Me llevó 5 meses lograr que nuestro gerente aceptara el hecho de que las pruebas unitarias ayudan incluso cuando estamos tratando de codificar "rápido". Pero necesitaba tomar 10 minutos aquí y allá cada pocos días para que eso sucediera.
Rudolf Olah
@omouse Solo estaba señalando un riesgo que a veces me golpeó a mí mismo cuando investigaba. Ciertamente, no veo ese riesgo en la situación que usted describe, pero la forma en que el OP describe su investigación ("primero comencé con ... luego me moví rápidamente ...") me hizo agregar esa precaución. Tenga en cuenta que no afirmo que el OP no está haciendo su trabajo asignado correctamente (eso es algo que simplemente no sé, y ese es el trabajo de su jefe), solo le advierto que se asegure de que no se deje llevar demasiado. .
SJuan76
12

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).

usuario3067860
fuente
Estoy de acuerdo con los temas en Trabajar eficazmente con código heredado, pero no es muy compacto. Tómelo como referencia y eche un vistazo a los capítulos en lugar de esperar leerlo como una novela.
Lukas
10

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.

Emilio M Bumachar
fuente
1
La mayor inversión por dinero es más como unos pocos ASSERT en los lugares correctos.
Peter Mortensen
@PeterMortensen Cierto, pero solo si sabes cuáles son los lugares correctos.
Emilio M Bumachar
Me ganaste a eso. No importa en qué dirección lleve el OP a su equipo, llegar allí con Git será mucho más fácil y más productivo que sin él.
dotancohen
6

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 1
  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.

Kenny Evitt
fuente
Pondría pruebas de regresión automatizadas a la altura de la compilación y la implementación automatizadas. También tiene la ventaja de que es algo en lo que puede trabajar de forma incremental.
sdenham
La prueba de la unidad debe ser primero, comenzar manualmente siempre ejecutándola localmente (o en cada pago / registro) y luego hacer que el resto del equipo compre las pruebas de regresión automatizadas. Realmente existen desarrolladores que tienen miedo de ejecutar pruebas constantemente por alguna razón.
Rudolf Olah
5

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.

markp3rry
fuente
5

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 .

Jon Hanna
fuente
4

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.

asthasr
fuente
3
Eso es exactamente lo que he hecho. Solo hubo una vez (de ~ 5 intentos en varios lugares) cuando introduje con éxito alguna nueva "buena práctica" o hice un cambio significativo en las prácticas existentes, y fue cuando el equipo estaba fresco y comenzamos la mayoría de los proyectos desde cero . Todas las otras veces, las buenas prácticas se introdujeron desde la parte superior (líderes del equipo) o simplemente fallaron porque nadie más participó. Creo que todo se trata de la capacidad de forzar su decisión al ser un líder / jefe.
scriptin
1

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í .)

wallyk
fuente