Bienvenido, les saluda Miguel y para hoy les traigo otro nuevo tutorial.
Resolver el problema incorrecto suele ser más costoso que crear la solución incorrecta.
Como desarrollador de software, soy un solucionador de problemas natural. Echo un vistazo a un problema e inmediatamente empiezo a pensar en cómo resolverlo en mi cabeza. Sin embargo, sumergirse de cabeza en una solución sin ver primero el panorama general suele ser contraproducente.
En este artículo, analizaremos tres prácticas de desarrollo de software que pueden ayudarnos a encontrar el problema correcto para resolver. Pero antes de hablar de codificación, veamos primero una página de la gestión de productos: la profesión se especializa en encontrar problemas.
Índice
¿Qué es el espacio problemático?
El proceso de desarrollo de productos consta de dos etapas: espacio de problemas y espacio de soluciones. El espacio de problemas es donde intenta identificar la necesidad de un cliente. El espacio de soluciones es el producto que responde a la necesidad. Trabajar en un espacio de problemas implica escuchar a los clientes, captar sus necesidades y hacer preguntas para pintar una imagen de su situación.
Un ejemplo rápido sería que al darse cuenta de que sus colegas no han tomado ningún descanso este año, decide tomar la iniciativa de aprender más sobre por qué la gente no está tomando vacaciones. Puede comenzar a entrevistar a sus colegas y hacer preguntas:¿Sabe cuánto tiempo libre pagado le queda este año? ¿Le dijeron que no tomara vacaciones con su gerente? ¿Tiene compañeros de equipo con los que puede contar cuando está ausente del trabajo?
Las observaciones y los hechos que reúna se convierten en el límite alrededor de su espacio de problemas. Forman la base de su hipótesis para abordar las necesidades de un cliente.
Permanecer en el espacio problemático
El beneficio obvio de invertir tiempo en el espacio del problema es que tendrá una mejor idea de cuál es el problema y desarrollará soluciones relevantes. Los desarrolladores de software normalmente no pasan mucho tiempo en el espacio de los problemas, ya que a menudo se nos dice que resuelva los problemas, no que los busquemos.
A continuación se muestran tres de mis prácticas de codificación favoritas para mantenerme conectado a tierra en el espacio de problemas.
Diseño basado en dominio
La filosofia de diseño impulsado por el dominio es que puede gestionar de forma más eficaz la complejidad y la capacidad de mantenimiento de su software si el lenguaje y la estructura de su código coinciden con su dominio empresarial.
Por ejemplo, si tuviera que construir un producto de software que rastrea el saldo de tiempo libre pagado de los empleados durante todo el año, modelaría mi software a partir de una arquitectura de abastecimiento de eventos que realiza un seguimiento de todos los eventos que ajustan el saldo de tiempo libre pagado. de los empleados. Yo nombraría estos eventos acumulación, reinicio y tiempo libre para que coincidan con la terminología real de recursos humanos.Tener estos conceptos de dominio empresarial directamente en el código me facilita asociarme con un experto en el dominio de recursos humanos para desarrollar algoritmos que agreguen y analicen los datos de vacaciones de los empleados.
La capacidad de pensar y hablar el mismo idioma que su experto en el dominio reduce la barrera para que usted ingrese a su espacio de problemas y mejora sus probabilidades de identificar el problema correcto.
Historias del usuario
Una historia de usuario es una unidad de trabajo que describe una función de software desde la perspectiva de un usuario final. Prefiero leer historias de usuarios sobre los requisitos comerciales tradicionales porque capturan el problema que estamos resolviendo para nuestros usuarios finales.
Un requisito comercial o una especificación del sistema puede leerse así:
System should have functionality to calculate employee paid-time-off balance based on a given date range.
No hay nada de malo en esta afirmación; sin embargo, no te dice por qué o para quien está creando esta función. Puede reescribir el mismo requisito en forma de historia de usuario:
As a employee, I would like to know my paid-time-off balance given a date range, so that I can plan for my vacation.
Esta historia de usuario le dice quién va a utilizar esta función y su motivación. Puede sentir empatía por el deseo de esta persona de planificar sus próximas vacaciones e implementar una solución teniendo en cuenta su situación.
Desarrollo basado en pruebas
Cuando practica el desarrollo basado en pruebas, siempre escribe un caso de prueba antes de agregar más código. El proceso de escribir un caso de prueba le da la pausa que necesita para explorar el espacio del problema a fondo antes de sumergirse en los detalles de implementación.
Tome el caso de prueba a continuación como ejemplo:
describe(PTOCalculator, () =>
describe('annual accrual policy', () =>
it('accrues on the first day of the year', () =>
const options =
startDate: new Date(2019, 0, 1),
endDate: new Date(2019, 11, 31),
accruedAmount: 14,
period: 'annually',
accrualDate: 1,
; expect(new PTOCalculator(options).balance()).toEqual(14);
);
);
);
Esta prueba nombra la clase y las variables según sus contrapartes del mundo real. La descripción de la prueba se lee como si estuviera hablando con un usuario final. Escriba una prueba adecuada y encontrará una solución personalizada que se adapte a su problema en poco tiempo.
Vaya más allá de su función
Un consejo que me gusta ofrecer a los desarrolladores que buscan avanzar en su carrera: estudie el dominio de su negocio. Hable con la persona de su producto y póngase en el lugar de sus usuarios finales para encontrar la mejor solución.
Cualquier programador de software común puede codificar una tormenta, pero solo los mejores de nosotros saben cómo encontrar el problema correcto.
Gracias por leer.
Añadir comentario