Compartir tecnología

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

He estado trabajando en un proyecto por un tiempo y me gustaría compartir algunos pensamientos y sentimientos personales sobre el uso de mi tiempo después del trabajo o en un momento extraño. Anímelos juntos.

Varias capacidades que debería tener el front-end:

(1) La capacidad de preparar datos falsos (datos simulados), porque a veces la interfaz de back-end no está lista y el front-end no tiene datos, pero el cronograma es ajustado y no puede esperar al back-end. El final debe tener la capacidad de crear datos simulados.

(2) La capacidad de omitir una determinada lógica empresarial. Si un negocio de circuito cerrado requiere 5 pasos para completarse, si 2 están atascados, entonces 345 no puede continuar avanzando. Por supuesto, es una buena manera de molestar al backend. cambiar la base de datos. Es simple. Si es un último recurso y está en un entorno de desarrollo, creo que está bien.

(3) Capacidades de procesamiento de datos A veces, el backend procesa bien los datos y es más fácil para el frontend procesarlos directamente. Sin embargo, si los datos devueltos por la interfaz no se pueden usar directamente, el frontend debe realizar algún procesamiento de datos antes. renderizar la página A veces el procesamiento de datos es La carga de trabajo sigue siendo relativamente grande. Esta es una pregunta relativamente vaga. ¿Es necesario considerar quién es mejor para realizar este trabajo de procesamiento de datos?

(4) Problemas de verificación. La verificación de front-end puede reemplazar la de back-end y ahorrar mucho trabajo de verificación, pero habrá problemas si utiliza directamente la herramienta de interfaz de cartero para realizar la prueba. En algunos escenarios, el problema de verificación se maneja mejor desde el front-end, como la verificación de formularios; en otros escenarios, como los problemas de recuperación repetitiva con grandes cantidades de datos, definitivamente se trata de una verificación de back-end. Todavía es necesario analizarlo en función de escenarios específicos.

(5) Cuando se desarrollan varios proyectos simultáneamente, ¿qué se debe hacer si el funcionamiento del entorno de desarrollo back-end afecta el desarrollo iterativo de diferentes versiones del front-end?

(6) La gestión de ramas de código es especialmente importante cuando hay muchos proyectos o cuando el mismo proyecto necesita iterar varias versiones al mismo tiempo. Los proyectos en los que trabajé antes no estaban estandarizados en este sentido. A medida que se formalizaron más y se escribieron más ramas, gradualmente adquirí una nueva comprensión de que esta área realmente necesita ser mantenida. Si el código se pierde o no se fusiona en la versión del proyecto, será un accidente de lanzamiento grave.

(7) La capacidad de encapsular componentes. Me gustaría compartir algunos de mis propios pensamientos aquí. Según mi experiencia personal, creo que los componentes front-end se pueden dividir simplemente en componentes funcionales generales públicos y componentes comerciales que implementan funciones comerciales. Los componentes son omnipresentes en la implementación de sistemas. Las funciones generales pueden facilitar el desarrollo posterior de negocios funcionales similares. Los componentes comerciales están estrechamente relacionados con nuestro negocio requerido. Los datos y la lógica que contienen están fuertemente vinculados con nuestro negocio y, por lo general, no se pueden utilizar en otras páginas. Una cosa que nuestro front-end realmente necesita y debe considerar al encapsular componentes es tratar de no incluir datos y lógica comerciales en componentes funcionales tan generales. Esto provocará cierto acoplamiento de código. Cuando nuestro proyecto se fortalezca gradualmente, será difícil de operar. otra vez. Por lo tanto, al operar componentes, debemos preparar los datos y la lógica en los componentes comerciales tanto como sea posible. Si tenemos que hacer esto, es mejor escribir notas y tratar de no afectar la lógica del código anterior. Encontré este problema cuando comencé a trabajar en el proyecto. Como resultado, a un componente de tabla que estaba originalmente encapsulado se le agregaron demasiados if y elses, creo que fue porque el acoplamiento con el negocio era demasiado fuerte. esto es por un lado, y por otro lado, el número de iteraciones es frecuente, el ciclo es relativamente largo y hay mucha gente manejándolo, por lo que se vuelve más difícil realizar cambios. Por lo tanto, con respecto al empaquetado de componentes, gradualmente descubrí algunos puntos que se pueden optimizar en el desarrollo del proyecto actual. Luego, si los componentes se empaquetan en iteraciones posteriores del proyecto, se deben evitar algunos problemas tanto como sea posible. También es algo que debe optimizarse aún más si hay suficiente tiempo en el cronograma. Después de todo, esto nos permite utilizar los componentes con mayor fluidez.

continuará...