Trabajo como programador, principalmente como desarrollador web, para una empresa que utiliza un lenguaje de programación de nicho que tiene mala reputación.
Básicamente, los desarrolladores que dejaron la empresa han hecho
R: Código no documentado (sin siquiera comentarios sobre las clases que han hecho, así que por qué algo que registra la búsqueda se llama JBFX en lugar de la BÚSQUEDA intuitiva que nunca sabré)
B: sistemas altamente acoplados y estáticos
(Las consultas SQL se "inyectan" en la aplicación, siendo su argumento que es la forma más rápida de desarrollar sin preocuparse por los procedimientos almacenados, etc.)
(En lugar de un servidor que puede atender diferentes "Sitios" de la empresa a través de un campo (es decir, tablas que tienen una columna de área que contendría si los registros son para "Manila" o "Dubai") cada sitio tiene su propio servidor , y por lo tanto no pueden relacionarse entre sí a menos que sea un middleware para cada tabla en particular)
C. Se recomienda que las aplicaciones web sean de naturaleza POST en lugar de receptivas. Ya que es como han estado haciendo desarrollo web. Intenté mostrar una página web que es ASINCRÓNICA por naturaleza y fui discriminado por ello, diciendo que había hecho las cosas complejas y que los clientes no notarían las páginas que tienen POSTBACK. (Sospecho que están acostumbrados a desarrollar el lenguaje de nicho en forma de POSTBACK tanto que no quieren molestarse en estudiar sobre async)
D. No hay plan de desarrollo de software, y la gestión predeterminada es que (usted hace este proyecto durante 3 meses) sin ningún tipo de plan. Sin uso de AGILE o SCRUM. Y el resultado es que, en el momento de la presentación, se agregan MÁS requisitos que estropean la configuración actual de la solución con un tiempo dado para que usted cambie las cosas (3-4 días solo PORQUE la gerencia considera que es un cambio pequeño)
Independientemente del nicho que pueda ser el lenguaje ( pista ), sentí que podría salvarse si cambiábamos nuestras técnicas de desarrollo. El problema es que los desarrolladores con los que trabajo actualmente no quieren solucionar ninguno de los problemas existentes y se desarrollan de esta manera. Aún no documentarán, aún crearán código que no es de naturaleza SÓLIDA, aún no estudiarán cómo es AJAX incluso si es tan simple con jQUEry (y les he mostrado cómo se puede hacer con dicho lenguaje de nicho.) y no muestran ningún deseo de hacer ninguna planificación de desarrollo de software, discriminando la idea misma ("un buen programador debe adaptarse" dicen. Yo digo "Nunca sabré qué es exactamente lo que esperas de mí a menos que tú dime cuáles son esos")
Sospecho que no quieren adaptarse debido al trabajo y esfuerzo adicional de aplicar todo esto, y que cualquier cosa que hagan funciona. Como resultado, estamos atrapados en un sistema que falla cada cierto tiempo (todos los días hay una falla) y estamos llamados a apoyarlo.
Mi pregunta es, ¿cómo puedo hacer que vean la luz, que estas técnicas no son solo un trabajo adicional, sino que, en última instancia, serán para el bien del equipo? ¿Se puede cambiar una cultura tan profundamente arraigada? ¿O debería simplemente irme porque siento que esta es una mala experiencia para agregar en mi currículum (no poder cambiar o emplear ninguna estrategia de desarrollo moderna, malas prácticas, tecnología demasiado especializada que debería desecharse por otras mejores)?
Esta pregunta y esta están relacionadas, pero aquí hay diferencias: A. Estoy en un nivel de "supervisión", pero todos los demás en mi equipo también lo están. Puede sonar tonto, pero es verdad. No tengo gente debajo de mí. Tenemos un gerente por encima de nosotros a quien debo seguir.
B. Soy cordial con el equipo, estoy en buenos términos con cualquier otra conversación. pero cuando se trata de asuntos como este, el tema a menudo se deja de lado / se descarta (y encuentro que esto me deprime y desmotiva todos los días).
C. No he insultado a nadie por cómo codifican, de hecho trato de elogiarlos un poco ("wow, ese es un buen método que has hecho allí") y luego trato de inyectar un consejo ("¿y si empleamos inyección de dependencia para que este método pueda usarse nuevamente para..."), pero la mayoría de las veces me encuentro con una risa y luego se descarta el tema.
Esta pregunta también está relacionada, pero estoy en el extremo opuesto del autor de la pregunta. Yo "quiero" apoyar las ideas de este jefe proponiendo la idea (si fuera un compañero de trabajo)
Veo mucha confusión entre "mejores prácticas" y "creo que esta es la mejor manera de hacer las cosas". Una persona informada y razonable podría estar en desacuerdo con muchos de los puntos que ha planteado.
Sus compañeros de trabajo tienen razón cuando dicen que la programación ajax asíncrona es difícil y agrega mucha complejidad. También tiene razón cuando dice que la programación ajax asíncrona puede agregar mucho valor a un sistema. Nadie está demostrablemente "equivocado" aquí; es sólo una cuestión de preferencia y prioridades.
Le sugiero que se tome más tiempo para tratar de entender por qué las cosas son como son, porque francamente el texto de su pregunta no parece mostrar mucha comprensión de las posiciones de sus compañeros de trabajo. Tus compañeros de trabajo pueden estar "muy arraigados" en su forma de hacer las cosas, pero ¿has considerado que tú también puedes estar "muy arraigado" en tu forma de hacer las cosas? Hay más formas de despellejar a un gato y hay más de una forma de desarrollar un buen software.
Si desea cambiar las cosas, todo lo que puede hacer es explicar cuáles podrían ser las ventajas de la "técnica X" sobre la "técnica Y". Muestre cómo ahorrará tiempo al desarrollador, mejorará la estabilidad o mostrará alguna otra ventaja concreta de la empresa. No mencione cosas como "mejores prácticas", "mejor para el equipo" o incluso "más elegante". No van a convencer a nadie. Es importante ser pragmático; no estás creando una obra de arte, estás creando una herramienta para resolver problemas.
Parece que ya lo has intentado y has fallado cada vez. Parece que tendrás que elegir entre intentar más, quedarte y "aguantarlo", o decidir que no encajas bien en este equipo y seguir adelante.
Sospecho que no quieren adaptarse debido al trabajo y esfuerzo adicional de aplicar todo esto, y que cualquier cosa que hagan funciona. Como resultado, estamos atrapados en un sistema que falla cada cierto tiempo (todos los días hay una falla) y estamos llamados a apoyarlo.
Eso no suena muy bien, pero cuanto más vaya a cambiar, más fallas obtendrá. Hay una razón por la cual los bancos todavía usan COBOL y las plantas de energía nuclear todavía funcionan con ensamblaje PDP-11.
Trataré de abordar cada práctica que mencionas:
R) Sí, esta es una mala práctica, pero lamentablemente también es común. No vale la pena dejar tu trabajo
B) Puede haber razones legítimas para este diseño. Si bien puede haber un argumento con respecto a la inyección de SQL, ese punto es básicamente discutible si el equipo de desarrollo web ha hecho su tarea básica y está filtrando correctamente cualquier comando con el que se encuentre.
Ciertamente puedo ver por qué pueden tener diferentes servidores para diferentes países, ya que, por una posible razón, diferentes países tienen diferentes leyes de TI, muchas de las cuales entran en conflicto entre sí y puede ser casi imposible (o increíblemente complicado) para un solo servidor unificado. servidor para cumplir con todos ellos.
C) ¿Tu forma de hacer las cosas es una mejora o simplemente otra forma de hacer las cosas? ¿Qué está realmente mal con lo que están haciendo?
D) ¿Qué le hace estar tan seguro de que no existe un plan o una metodología? AGILE y SCRUM no son el todo y el final de todos los procesos de desarrollo de software. Y aunque entiendo que algunos ejecutivos intentarán poner límites de tiempo severos en una nueva función que consideran indulgente, depende de usted, como experto, señalar las dificultades y que es posible que necesite más tiempo. A menos que sus ejecutivos tengan experiencia personal en programación, encontrará esto mucho en cualquier lugar de trabajo.
Ahora no me malinterpreten, puede o no haber algún beneficio objetivo en sus caminos. No lo sé, ya que soy un aficionado a la programación en solitario y no un profesional. Y las personas que no son realmente conscientes de sus formas de hacer las cosas pueden no saber los beneficios que aportan. Por el contrario, puede haber personas que SÍ conozcan sus formas de hacer las cosas, pero que también sean conscientes de los inconvenientes de los que usted no es consciente.
Por último, cambiar el funcionamiento fundamental de un programa de una forma a otra es casi siempre un trabajo muy duro. Es probable que esto se duplique para el trabajo profesional, ya que significa la posibilidad de introducir nuevos errores y que tanto los programadores como los evaluadores trabajen horas extra. Necesita un caso comercial realmente bueno (por ejemplo: el rendimiento en el cliente o en el servidor mejora significativa y notablemente, permite a la empresa desarrollar un fuerte argumento de venta único, entiende la idea) para justificarlo
una empresa que hace uso de un lenguaje de programación de nicho
A partir de aquí veo un problema, repites esta palabra a menudo, parece que no te sientes cómodo con la pila con la que trabajas, si esta tecnología no es de tu agrado, además de las prácticas que no te gustan, será una experiencia realmente mala o agotadora y yo. sugiera encontrar un trabajo con su tecnología deseada. Lo que dijo sobre las inyecciones de SQL es realmente una mala práctica, toda la lógica debe agregarse a los procedimientos almacenados tanto como sea posible, esto se aplica a cualquier pila.
El resto de su pregunta también parece que domina esta tecnología, ¿es así? Si es así, entonces no tiene sentido trabajar con tecnología que ya dominas cuando cambias a un nuevo trabajo. Creo que aprender es más importante que buscar un salario más alto.
Mi pregunta es, ¿cómo puedo hacerles ver la luz?
No puede, hay una razón por la que lo hacen de esta manera y cuesta dinero retrasar las entregas y es una mala idea intentar imponerles sus prácticas, incluso si fuera un líder o un mensaje privado, sería una experiencia dolorosa para todos. cuando trabajas con un equipo nuevo, eres tú quien necesita adaptarse al equipo y a tu jefe
Así es como veo las cosas:
- Si dominas la tecnología, entonces es un posible trabajo sin salida, entonces deberías estar en un lugar de trabajo cómodo con prácticas que disfrutes
- Si tu nuevo trabajo usa tecnología que quieres aprender que te permitirá llegar más alto pague entonces creo que está bien sacrificar un poco, como malas prácticas, modelos obsoletos o cualquier disfunción que pueda ocurrir, yo personalmente aceptaría incluso menos paga si trabajan con tecnología Quiero aprender
Tengo que estar de acuerdo en que mucha gente en la industria del software confunde las "mejores prácticas" con la programación absoluta. Las mejores prácticas son una introducción, pero si su equipo está de acuerdo con lo que está en marcha ahora, eso es suficiente. Si es nuevo en la organización, verán sus sugerencias como innecesarias, especialmente si necesita ayuda para "navegar" el código. Serás visto como alguien difícil de trabajar contigo.
Solo mostrar que las páginas funcionan de la manera en que lo hacen con las "mejores prácticas", pero sin ningún beneficio adicional, excepto que se considerará que una gran cantidad de trabajo es innecesario. Imagínese si llama a un pintor y le dice que es difícil trabajar con su pared, pero le muestra una pieza de madera contrachapada que compró en Home Depot y lo fácil que es pintar con ella. ¿Estaría de acuerdo en dejar que el pintor derribe todas sus paredes para poner una capa de pintura fresca cuando sabe que alguien más puede trabajar con la pared que tiene actualmente?
Tendrás que recordar que es:
luego
luego
Brandín
Walfrat
La defensa del sonido
gordito
gordito
julia hayward
Martín Tournoij
gordito
Martín Tournoij
Mawg dice que reincorpore a Monica