Hace aproximadamente un mes comencé a desarrollar un programa en Java para uno de mis compañeros de trabajo. Soy el único que trabaja en esto y este es mi primer proyecto serio (lo que significa que alguien lo usará, no solo por diversión o en la escuela).
Mi compañero de trabajo está tomando información sobre el programa de otra persona fuera de la empresa (Llamémosle Bob) y me la pasa (Bob será quien use el producto, así que en realidad estoy creando el programa para él), lo que crea algunos malentendidos a veces, pero nada demasiado grande, todo es absolutamente reparable.
El problema es que a veces me dice que implemente algunas funciones para las que necesito cambiar muchas líneas de código. Al principio, cuando escribí alrededor de 100 líneas, no era gran cosa, pero ahora definitivamente requiere mucho tiempo y esfuerzo (visto que tengo alrededor de 500 líneas y en este punto necesito cambiar alrededor de 60 y agregar alrededor de otras 500 ). Sé que si lo hubiera tenido claro desde el principio (y tal vez arreglado una reunión con Bob) no habría habido problema.
Mi pregunta es: ¿debo informarle sobre esto y tener una idea mejor y finita de lo que tengo que hacer antes de comenzar a trabajar nuevamente?
Cosas para considerar:
Sí, debe tratar de obtener la mejor información que pueda, tan pronto como pueda, cada vez que comience a desarrollar algo. Además, si tiene algún obstáculo que cree que está afectando su productividad, debe tratar de remediarlo. ¡Es una señal de profesionalismo buscar ayuda, si no puede ayudarse a sí mismo!
Hay un dicho en el mundo de la programación:
¡Semanas de programación pueden ahorrarle horas de planificación!
Así que esto es bastante común. También es común que no pueda obtener toda la información y tenga que comenzar con algo. ¡Pero hacer lo mejor que pueda y discutir esto con su compañero de trabajo definitivamente está en orden!
No existen los requisitos perfectos. Cambian en todos los proyectos a medida que avanzan las cosas. Siempre habrá una necesidad de volver a trabajar las cosas que estaban terminadas. Esto es parte de la profesión y debes acostumbrarte.
Los requisitos también suelen pasar por un filtro de una o, más a menudo, más personas, ya que a los desarrolladores generalmente no se les permite hablar directamente con las personas que crean los requisitos, especialmente los desarrolladores junior.
Sin embargo, puede minimizar los cambios a través de buenos requisitos y retrocediendo en lugar de hacer suposiciones cuando no comprende completamente un requisito.
Esta es una de las razones por las que es fundamental comenzar a desarrollar una buena comprensión del dominio comercial en el que está trabajando. Le ayudará a identificar cuándo falta algo o algo está mal en los requisitos del proyecto. Cuanto más pueda identificar que necesitan aclaración antes de comenzar a codificar, más rápido irá la codificación y menos cosas necesitarán reelaboración (pero nunca ninguno porque algunos usuarios no son buenos para visualizar los resultados y no sabrán que algo no funciona). para ellos hasta que lo vean).
Lo que debe hacer con cada requisito que recibe es buscar agujeros en él. ¿Hay lugares donde hay puntos de decisión pero solo te dijeron qué hacer para un camino posible? ¿Hay lugares en los que no está claro lo que significa? ¿Qué suposiciones estás haciendo? Borre cualquier suposición como correcta antes de comenzar a codificar.
¿Hay cosas que faltan, como una descripción de lo que se debe generar después de que los datos se coloquen en la base de datos o una descripción de qué seguridad de datos se debe implementar si se colocan datos personales en una base de datos? ¿Mencionaron los niveles de rendimiento necesarios?
¿El requisito utiliza palabras con las que no está familiarizado (búsquelas primero)? Si la definición no tiene sentido en el contexto, solicite una aclaración. A menudo, hay palabras específicas del dominio comercial y pueden tener significados tácitos para todos los que están familiarizados con el dominio. Al preguntar qué querían decir, es posible que descubras algunas cosas que asumieron que todos sabían. La mayoría de las peores desconexiones en los requisitos que he visto se reducen a que el usuario hace suposiciones sobre cosas que "todos" saben pero que el desarrollador no sabía.
Puede proponer a su compañero de trabajo que lo incluya en su interacción con Bob en relación con el software, ya sea mandándole CC en los intercambios de correo electrónico o invitándolo a las reuniones. Tenga en cuenta que puede haber una razón por la que él no está haciendo esto, así que infórmele a su compañero de trabajo que al hacer esto podría evitar malas interpretaciones con respecto a los requisitos de Bob.
Definitivamente, siempre debe solicitar la mayor cantidad de información posible sobre los requisitos. ¡Incluso organice una reunión con su compañero de trabajo y Bob una vez a la semana o cada dos semanas para obtener información directa y una demostración del producto actual!
Una delgada que sugeriría investigar es Clean Code de Robert C Martin. Si ha extraído su funcionalidad en diferentes clases y métodos, en lugar de cambiar 60 líneas de código, solo necesitará cambiar algunas a la vez. Como desarrollador, sugeriría que se mantenga alejado de una clase que tenga 500 líneas, intente mantener las clases haciendo solo una cosa, que limitará sus líneas a menos de 200, por ejemplo.
cdkMoose
Daniel
laurent s.