Soy pasante de ingeniería de software en una gran empresa.
Hace unas semanas, me dieron una tarea simple para hacer, imitando el comportamiento de otro componente.
Al leer el código, encontré que la implementación actual es bastante defectuosa. Estaba introduciendo un acoplamiento estrecho entre los componentes, y el esfuerzo puesto en él parecía bastante redundante: las adiciones al código base darían como resultado la duplicación del trabajo.
Se me ocurrió una solución alternativa, usando una biblioteca diferente, que reduciría extremadamente la repetición futura, a su propio costo:
Estoy bastante seguro de que esta implementación ahorraría meses de esfuerzo del desarrollador, pero también me siento mal por retrasar el trabajo de 3 días (aunque no parece que tengamos una fecha límite estricta para el cliente).
¿Cómo me acerco a mi equipo para mejorar la calidad del código? Quiero que esto funcione, pero asegúrate de haber considerado al resto del equipo.
Realmente necesita preguntarle a su equipo y/o gerente .
Los miembros de su equipo tienen que decidir si la mejora vale la pena para comprender y mantener la nueva biblioteca.
Como regla general, si usted es el único que puede mantener su código (por cualquier motivo, bueno o malo), no está mejorando las cosas.
Parece que has encontrado una buena solución. Espero que puedas convencer a tu equipo.
@Brandin sugirió que complete la tarea asignada primero, luego presione para la nueva biblioteca como un proyecto separado. Esto tiene mucho sentido: le dará algo de credibilidad y hará que sea más fácil para los demás creer en sus sugerencias.
En cuanto a 'cómo puede un interno convencer al equipo de probar algo nuevo', estaba seguro de que había otra pregunta para eso aquí o en Programmers.SE (donde ahora estaría fuera de tema) pero no he encontrado ninguna.
La respuesta corta es ganar algo de credibilidad como sugirió @Brandin y luego ofrecer la sugerencia de una manera que reconozca el trabajo previo y la experiencia del equipo.
Al leer el código, encontré que la implementación actual es bastante defectuosa.
Cada vez que mira otra base de código, es fácil pasar por alto el simple hecho de que lo que está mirando probablemente nunca se "supuso" que tuviera el aspecto que tiene. Probablemente nadie se sentó y lo diseñó para tener un acoplamiento estrecho y muchas repeticiones "redundantes" (más sobre esto a continuación).
Más bien, cuando el código se escribió por primera vez, probablemente se planeó y ejecutó según las mejores prácticas, siguiendo un diseño simple y limpio. Lo que está viendo podría ser el resultado de múltiples cambios y parches diseñados para dar cuenta del cambio en los requisitos que ocurren naturalmente en cualquier componente empresarial.
Al abordar sus inquietudes específicas, el acoplamiento estrecho por sí solo no es necesariamente algo malo. En ciertas situaciones, esperaría, incluso preferiría, que ciertos componentes estuvieran estrechamente acoplados. Por ejemplo, si un componente solo va a ser llamado por otro componente, entonces no hay necesidad de abordar este acoplamiento como una preocupación constante.
El código redundante o repetitivo tampoco es necesariamente malo y, de hecho, reducir la redundancia promoviendo la reutilización de componentes tiende a aumentar el acoplamiento, en lugar de disminuirlo. SECO (no se repita) es solo un principio, y puede ser contrarrestado en muchos lugares por HÚMEDO (escriba todo dos veces).
No estoy diciendo que esto definitivamente se aplique a su situación, y para un nuevo componente no necesariamente quiere imitar las fallas de uno viejo. Sin embargo, sospecho que existe el riesgo de que esté intentando mejorar algo que no comprende completamente, y si se acerca a su equipo, tenga mucho cuidado al expresar sus opiniones sobre el estado actual del código si no lo hace. Comprender completamente y poseer el proceso comercial o la función que el código está diseñado para respaldar.
Brandín
BeboyConozcoCosas