Han pasado casi dos años y medio desde que entré al front end de boxes En estos dos días, de repente pensé en una pregunta del entrevistador durante la primera entrevista: ¿cómo entiendes el trabajo del front end?
Para mí, como un novato en ese momento, era completamente una tontería, y las palabras no expresaban el significado, lo que hizo que el entrevistador pareciera confundido. Ahora piénselo, puede que se llame chat incómodo ... Después de dos años de rastreo constante sobre esta cuestión Con mi nuevo entendimiento, no aproveché nada en la mañana para escribir este blog, donde pensé en escribir, y hablar sobre el front-end como lo entiendo.
Aspectos técnicos:
Fase 1 (pueblo de novatos)
Un principiante de front-end debe dominar las habilidades básicas HTML, CSS y JavaScript. Estos tres son el soporte técnico inferior del front-end. Si miras la respuesta hace unos años, debería haber otro jquery, pero yo personalmente creo que es en esta etapa. El círculo de front-end jquery no se puede utilizar como una habilidad necesaria. Aunque Jquery es muy amigable para los recién llegados, ahora el marco mvvm está volando por todo el mundo. Vue, Angular y React son tres partes del mundo. Es mucho más cómodo de usar que jquery que opera directamente dom. Por supuesto, es una base en esta etapa. El marco del escenario, la biblioteca de clases, etc. pueden avanzar. Native Js es siempre la máxima prioridad. Solo utilizará el marco para no comprender los principios subyacentes y nunca será competente. Recomiende la programación avanzada de Red Book Javascript, aprenda el Libro Rojo y establezca una base sólida antes de aprender otros marcos, mamá lo hará nunca No te preocupes por tu estudio. A continuación, hay una habilidad adicional PhotoShop. Necesita saber que PS se puede hacer sin hacerlo, pero debe saberlo, y en algunas empresas pequeñas, la interfaz de usuario solo le dará un PSD. No hay nada como Sketch, y no una ayuda. Si corta la imagen, debe manejarla usted mismo, por lo que ps es una habilidad adicional necesaria.
La segunda etapa (mazmorra abierta)
Ingrese a la etapa de crecimiento revelador y comience a luchar contra monstruos y actualizaciones. Esta etapa es la que dura más. Durante este período, debe escalar innumerables pozos, acumular varias experiencias de fallas y escanear un nivel. Con respecto a HTML y CSS, necesita conocer el uso de varios marcos de interfaz de usuario, como BootStrap, ElementUI ..., sobre los estándares de formato de diferentes imágenes, la compatibilidad del navegador, la diferencia entre dispositivos móviles y PC, diseño receptivo, diseño flexible, diseño de cuadrícula y la mejora de la estética del diseño ... Y así sucesivamente para las diversas habilidades para mejorar la eficiencia del desarrollo de su página, el marco de interfaz de usuario es más una selección variada de lo que le interesa.
En el lado de Js, puede comenzar a elegir un marco de trabajo convencional para el aprendizaje. Los mencionados Vue, Angular y React son todas buenas opciones, y para programación orientada a objetos, encapsulación de objetos, herencia de prototipos, cierres, diferencias sincrónicas y asincrónicas, A La serie de conocimientos avanzados de js debe entenderse en profundidad y, al mismo tiempo, debe comprender el estándar es6. Puede consultar la introducción del profesor Ruan Yifeng a es6. El libro contiene varias características nuevas de es6, parámetros predeterminados, expresiones de plantilla, y varias líneas. Cadenas, expresiones de descompresión, expresiones de objetos mejoradas, funciones de flecha = &>, Promesa, alcance a nivel de bloque de let y const, clases de clase, modularización y otras características comunes. Puede encapsular componentes usted mismo y escribir mantenibilidad Alta, código legible. Y en tiempos normales, debe leer el código escrito por otros, aprender de las ventajas de los demás y leer mucha literatura técnica. Lo más importante es resumir sus propios problemas. Por ejemplo, si se encuentra un error, si está confundido, puede resolverlo. La próxima vez que encuentre el mismo problema, podrá ver si hay un resumen de los problemas anteriores en este momento.
Etapa 3 y superior
Comprenda varios patrones de diseño, comprenda el código fuente de varios marcos, tome los extremos frontal y posterior, y puede escribir el marco js usted mismo ... Bueno, no escribiré antes de esta etapa ... ....
trabajando
Un flujo de trabajo completo debería ser:
Establecimiento del proyecto, discusión del proyecto, confirmación de la demanda, prototipo del producto, desarrollo de fondo mientras el diseñador obtiene el prototipo para el diseño de la interfaz de usuario, desarrollo de la interfaz de usuario, prueba, cambio de error, error, repetición n veces - Aceptación del producto
Lo anterior es solo un conjunto de procesos generales. Al menos en la interfaz, necesitamos resolver la lógica empresarial y comprender la lógica empresarial. Esto es muy útil para su desarrollo futuro. Al mismo tiempo, puede elegir la aplicación tecnología y dividir la estructura del proyecto según sus necesidades. La división de módulos de demanda y la construcción de proyectos completos. Por supuesto, ahora hay muchas herramientas de construcción automatizadas que pueden ahorrarle mucho tiempo. El desarrollo de front-end de hoy ya no es sólo el desarrollo de páginas web estáticas. La tecnología de front-end en constante cambio ha hecho que la lógica del código de front-end y Los efectos interactivos se vuelvan cada vez más complejos y más difíciles de administrar. El marco de preprocesamiento y desarrollo modular divide el proyecto en varios módulos pequeños, lo que aumenta la dificultad del lanzamiento final Sin un estándar unificado, la estructura del proyecto de front-end es extraña. La construcción de automatización de front-end se está volviendo cada vez más importante en todo el desarrollo del proyecto, pero los principiantes aún deben intentar construir un proyecto por sí mismos poco a poco. Cuando haces algunos proyectos más, se siente molesto repetir de esta manera cada vez, y, naturalmente, ingrese. Después de todo, esto le dará una comprensión más profunda de por qué debería usar la compilación automatizada ... Por ejemplo, nuestra pila principal es vue, y la más utilizada es vue-cli. Hay muchas opciones para herramientas de automatización como como Bower, Gulp, Grunt, Node, yeoman, debemos elegir el más adecuado para estudiar de acuerdo a nuestras necesidades.
comunicación
El front-end es la persona que debe aprender a comunicarse más en el equipo. Si hay un problema con la interfaz, debe comunicarse con la IU. Si hay un problema con los datos, debe comunicarse con el backend . Si hay un problema con la función, debe comunicarse con el producto. Cuando esté probando un error, debe comunicarse con la prueba ... emmm cansado
Interfaz de usuario de comunicación
El front-end es la persona más cercana al usuario. Los sentimientos más intuitivos del usuario sobre un sitio web y un software se reflejan en el front-end. Tal vez dirías que el más intuitivo no debería ser un diseñador de UI. Tienes que saber que Soy el front-end y hablo en nombre del diseñador. !!!
Al comunicarnos con la interfaz de usuario, no debemos implementar pasivamente el diseño de la interfaz de usuario en el trabajo, sino que debemos racionalizar nuestras propias ideas; de lo contrario, la reelaboración en el futuro desperdiciará el tiempo de ambas partes, como cuando llegamos por primera vez a la empresa, en el proyecto. Las imágenes de Sprite todavía se usan para imágenes de algunos íconos pequeños, pero es obvio que con el mejor y mejor soporte de los navegadores, los íconos svg y de fuentes están ocupando gradualmente la corriente principal.Creé un proyecto en la biblioteca de íconos de Alibaba para extraer la interfaz de usuario. Ingrese, la interfaz de usuario agrega directamente los íconos que usó al proyecto, y el front-end genera directamente íconos de fuentes del proyecto para importarlos al proyecto. Es absolutamente necesario cortar la imagen lentamente, deducir el ícono y fusionar el Sprite image. Es mucho más fácil, y también es más fácil de usar. Es realmente genial, cambia el color si quieres. Por otro ejemplo, si necesita hacer un gráfico y usar echarts, puede dejar completamente los estilos de diseño de la interfaz de usuario basados en echarts, en lugar de dejarlo jugar libremente allí, porque nunca se sabe cuánta creatividad está instalada en la mente del diseñador, que ahorra Es el momento de dos personas, no habrá vergüenza de que él haga un buen estilo y tú no puedas lograrlo.
Productos de comunicación
En términos generales, es la comunicación más difícil entre programadores y gerentes de producto. Solo hay muerte y no amor. Después de todo, Zi dijo una vez: "Esta demanda es muy simple.
Cito un artículo de Lensuntop a continuación , creo que está muy bien escrito
Recuerda que hay un párrafo:
Producto Wang: Programador, ¿implementaremos una necesidad urgente?
Programador: Por favor hable.
Producto Wang: tenga en cuenta el color de inicio de la aplicación de acuerdo con el color de la carcasa del teléfono.
El programador se ha estropeado con el viento. . .
A partir de este párrafo, puede reflejar las diversas "chispas" de pasión entre productos y tecnología. Los requisitos simples a los ojos de los gerentes de producto son imposibles en nuestra opinión. Y los programadores no pueden entender por qué los gerentes de producto quieren lograr tal demanda. Entonces, ¿cómo debe comunicarse con los gerentes de producto desde la perspectiva de un programador?
1. Una comprensión profunda de las necesidades, aclarar la motivación y las razones de las necesidades.
Nuestros programadores deben preguntarse por qué el gerente de producto quiere realizar dinámicamente el color de la APLICACIÓN cuando comienza de acuerdo con el color de la carcasa del teléfono. Ya que desea escuchar el análisis, no se apresure a decir sus propias conclusiones, ¡no es técnicamente posible! Dado que existe una duda, primero resuelva su propia duda.
2. Empatía
El producto tiene una perspectiva de producto. ¿Qué perseguimos como programadores? La lógica es correcta, más rápida y más fácil de expandir. ¿Qué persigue el producto? Para ser honesto, yo mismo no he pensado profundamente en este problema. Pensando desde la perspectiva de la inercia, uno puede pensar: por qué existe un producto, qué problemas puede resolver su existencia y si su experiencia de usuario es buena. Estos son los valores fundamentales que determinan un producto. Después de todo, la naturaleza del trabajo afecta la lógica de pensamiento de una persona, por lo que en este momento, es especialmente importante para nosotros pensar en cada necesidad desde la perspectiva de un producto.
3. No te pierdas todos los detalles
Como programador, debo estar profundamente de acuerdo con esta frase. Debido a un error de puntuación o de tipo, se producirá un error inesperado. Al diseñar un producto, el gerente de producto siempre piensa en el problema desde la dirección general, la dirección general no es incorrecta y los detalles no pueden separarse de la dirección general. Eso es lo que piensan. Pero para el programa, es absolutamente imposible. Porque una lógica detallada a menudo determina la dirección general. Por ejemplo: hay una demanda, el trabajo del usuario debe enviarse para su revisión y luego todos pueden verlo. Cuando el gerente de producto le dio esta demanda, ¿puede detectar algún problema? Aquí hay varios detalles: 1. Una vez que el usuario envía para revisión, el usuario ya no puede editar el trabajo; 2. Si el trabajo se revisará varias veces; 3. Necesita registrar el historial de revisión; 4. Si el trabajo del usuario necesita control de versión, si desea generar una versión, ¿cómo surgió la versión? 5. Después de pasar la revisión, el usuario puede modificar el trabajo nuevamente, si no, entonces el trabajo del usuario es invisible para otros ... ¡un simple requisito lógico! Pero hay demasiados detalles involucrados. A menudo no podemos escribir cuando codificamos, porque los requisitos dados son demasiado vagos y no lo suficientemente detallados.
4. Diga "no se puede lograr" de otra manera
No se puede realizar, debemos decir esta frase a menudo. Pero hablar directamente con el gerente de producto, podría volver loco al gerente de producto. Porque les haremos sentir que cualquier exigencia que presenten no puede ser realizada por nosotros. Pero este no es el caso, porque está condicionado a que no se pueda realizar, como por ejemplo, tiempo insuficiente. Por lo tanto, primero debemos estar de acuerdo con el punto de vista del gerente de producto ("alcanzable") y luego proponer las condiciones para lograr sus necesidades. Porque la realidad es que los gerentes de producto no suelen hacer tonterías y a menudo proponen algunos requisitos irrazonables, pero ante los requisitos, debemos evaluar el tiempo para lograrlo, y este tiempo no es tan fácil de evaluar con precisión.
5. Cuando se encuentre con necesidades irrazonables, busque activamente alternativas
Tome las necesidades en el párrafo, proporcionemos varias máscaras de aplicaciones para que los usuarios elijan, lo que definitivamente es más fácil de lograr que las necesidades originales y es más humano. Para contar otra historia, hay una empresa de hogares inteligentes que quiere implementar un grifo de cocina, según voces humanas, la temperatura del agua puede llegar a varios grados. Piénselo desde otro ángulo, ¿sentiría la diferencia de temperatura entre 40 grados y 45 grados? Y según el juicio de la voz humana, esto implica un sistema de reconocimiento de voz. ¿Con cuántos idiomas desea ser compatible? De hecho, creo que el cambio de izquierda a derecha es bastante inteligente, no hay necesidad de hacerlo tan complicado. Por lo tanto, los programadores deben encontrar una forma mejor y más fácil de implementar. No le dé al gerente de producto una mera suposición.
6. Debe seguir el espíritu del documento.
Durante el desarrollo, a menudo tenemos discusiones detalladas con el gerente de producto. Sin embargo, no registramos los resultados de esta discusión en el prototipo del producto ni en la lista de requisitos. Pero después de unos meses, nosotros mismos tendemos a olvidar por qué discutimos ese detalle en primer lugar. Entonces todas las necesidades deben basarse. Por otro lado, también protege los intereses de ambas partes, no esperes a que algo salga mal y no sepas quién es el responsable, en este sentido los programadores suelen sufrir mucho.
6. Tenga un corazón artístico para sus propios procedimientos.
Alguien dijo una vez que cuando los requisitos afectan la escalabilidad del código, los requisitos se cortarán primero, ¡no el código! Hasta cierto punto, estoy de acuerdo con esta frase. En mi opinión, un programa es un trabajo ideológico, para llegar al ámbito del arte debe ser razonable en función, experiencia y lógica. Al igual que una obra de arte, ¡parece natural! Porque un trabajo que parece "feo" no debe ajustarse a la lógica y los hábitos humanos.
Al final de la escritura, siento que estoy de vuelta con el programador mismo. De hecho, al comunicarse con los gerentes de producto, lo más importante es entender: ¡estamos resolviendo problemas, no creando problemas! Principalmente sosteniendo este núcleo, todos los problemas se pueden resolver fácilmente
En términos generales, no hay tantos problemas para comunicarse con el fondo. Una vez que haya acordado las reglas, en términos generales, se comunica a través de la API, pero cuando depura la interfaz, hay algunas incógnitas y siente que no es así. su propio problema, de manera oportuna La comunicación entre bastidores es la más sensata.
División de responsabilidades
Creo que todo el mundo está profundamente conmovido en este punto, porque el front-end es el último nivel, y todas las necesidades se convierten en un producto específico en las manos del front-end, lo que también hará que te conviertas fácilmente en un back pot, liderando al proyecto Hay muchos casos de aplazamiento. Los dibujos de diseño no son oportunos, los datos de fondo tienen problemas y el producto debe cambiarse temporalmente. Si no puede probar que estos problemas han causado que el proyecto se posponga, sin duda recordará esta olla. La única forma es -confirmación verbal- -àEnviar un correo electrónico al encargado para la confirmación - àNotificar al superior, no crea que esto es problemático, cuando algo sale mal, será más problemático que esta,
No puedo escribirlo. Lo anterior es una comprensión de la parte frontal después de que subí al hoyo (ps: aunque todavía estoy en el hoyo), también se puede considerar como un resumen de mi trabajo. La escritura es más verbal . Si no te gusta, no rocíes. Finalmente, les deseo a todos la promoción 2018 y aumento de salario, busquen novia !!!
Escanee el código para ver las preguntas de la entrevista de front-end