A veces, el pensamiento sobre el producto y el desarrollo tendrá grandes diferencias debido a los diferentes puntos de partida.
Como desarrollo, no solo debe tener su propio pensamiento, sino también comprender el pensamiento del producto, para que pueda ser invencible en la batalla con el producto y salir victorioso.
Por ejemplo:
Por ejemplo, si envía un formulario de solicitud en el sistema, el estado de esta solicitud está pendiente de revisión.
El estado a revisar puede ser aprobado y no aprobado.
El desacuerdo se produce en este momento. Si la revisión falla, la razón es que algo en el formulario de solicitud se ha escrito incorrectamente, en caso de que se deba volver a generar un formulario de solicitud o enmendar el formulario de solicitud que no se aprobó antes y continuar la revisión .
Para ser honesto, también he visto muchos diseños excelentes de productos. Mi primera reacción a este tipo de problema definitivamente es generar un nuevo formulario de solicitud, o nunca pienso en modificar el formulario de solicitud anterior. Tipos de operaciones.
Pero pensamos en el diseño de este compañero de clase de producto que desea modificar el formulario de solicitud anterior. ¿Cuál era la intención original del diseño? Creo que debería ser debido al fracaso de la revisión. Simplemente cámbielo en el formulario de solicitud original y podrá volver a revisarlo. Es más conveniente, cómo decir, esta lógica debería ser lo mismo que cambiar el documento. Si el maestro escribe algún error, simplemente cambie el documento original, y nadie encontrará un nuevo documento y volverá a escribirlo.
El documento se modifica directamente porque es demasiado problemático escribir uno nuevo, pero si el programa está diseñado de esta manera, será un poco incómodo, porque para el programa no es difícil generar un nuevo formulario de solicitud, sino modificarlo directamente , No se trata solo de encontrar un espacio para escribir. Hablaré brevemente sobre la razón por la cual esta situación debería generarse nuevamente en lugar de modificar el formulario de solicitud anterior:
1. El estado es preferiblemente unidireccional y tiene un estado final.
Decimos que cualquier cambio de estado es preferiblemente unidireccional, y hay un estado final, es decir, una vez que se alcanza el estado final, los datos son inmutables. La ventaja de este diseño es que se puede desacoplar en el juicio y el mantenimiento posteriores.Si el estado se puede saltar directamente a voluntad, una vez que el estado se vuelve más, el final es una papilla. Y con el estado final, puedes hacer muchas cosas. Por el contrario, si el estado no ha sido definitivo, nunca sabes en qué se convertirá este estado, entonces muchas cosas estadísticas se volverán particularmente complicadas debido a esto.
2. Es mejor registrar claramente
cada solicitud para cada solicitud. Cada solicitud es un registro. Si la solicitud de reescritura que no se aprueba cada vez es una nueva solicitud, entonces, según el solicitante, puede conocer el registro de operación de esta persona. Por ejemplo, ¿cuándo presentó la solicitud, cuándo fue rechazada, cuándo volvió a enviar la solicitud, etc.? Incluso puede comparar lo que se modificó en la solicitud posterior. Por otro lado, si lo modifica directamente, es equivalente a cubrir la solicitud anterior. Si no aprueba la revisión, debe modificarla, para que nadie sepa qué solicitar al principio.
