Project review

New project review

(1) look at the overall style of the next page is unified: what is the main color; Page background color is consistent; Whether the button of the same function has a unified standard style. Making sure the style is consistent helps us extract similar and identical content later.

(2) understanding demand: analysis and design, to guess products and the intention of the designers, why want to do so, for what purpose do this have what effect, users will be what kind of experience, when we see a design draft, is about to get into the habit of such thinking, and timely communication with designer products.

(3) Attach importance to interaction design: interaction design is sometimes not reflected in the design draft, such as the small animation effect, it is best to design product reconstruction here can make a GIF or video or flash to show the effect to be achieved. And then, after the validation, we have to decide whether this is done with refactoring or with the front end.

(4) Whether to do media query: If you do media query, you need to confirm with the designer the range of media query resolution and the corresponding prototype diagram.

Revision project review

(1) Confirm which pages are newly added and which modules are newly added.

(2) Browse the old published projects to better understand the requirements of the revised projects.

Communicate with the designer

(1) Browse the designer’s list of requirements.

(2) Check the cutting diagram: when cutting some vector ICONS in SVG format, check whether the white space around the icon is too large or the left and right white space is inconsistent. Because sometimes unreasonable white space can lead to page confusion.

(3) It is best to save a design draft in their own local, subsequent new design draft can be classified according to the date to continue to save, and to browse the revised requirements list under the design, determine which project, which location.

planning

(1) Directory structure/file distribution: design the directory structure according to the number of pages and the size of resource files.

(2) Extensibility: Extensibility can be understood as adding new modules without much impact on the original code.

(3) Reusability: code that is used many times is extracted (or extracted into sASS variables, or a component, or a common style file).

(4) Page performance: Refer to page performance optimization for details.

(5) Define a set of refactoring specifications and follow them.

Start refactoring the page

(1) Write the big frame of the page first, then use the common component, with the big frame of the page to wrap the common component and private style. From big to small, step by step.

(2) pay attention to the named DOM structure, and semantic tags (until I didn’t realize the importance of semantic label, until the teacher told me, when a page loading problems CSS no load came in, if we do the label semantic web page display is not very bad, because the semantic label their own style, So the page is neat).

(3) Be careful to write some notes appropriately.

check

(1) Check whether font size, color, spacing and so on are consistent with the design draft.

(2) Check whether the writing and display of some pseudo elements are reasonable.

(3) check whether there is a word limit (more words omitted), if not sure of the word limit range, be sure to confirm with the designer product.

(4) whether the text in the button is centered horizontally and vertically.

(5) DOM structure simplification (as a reconstruction, be sure to pay attention to the pathological size of the file, the lighter the better, of course, in the project will not be a problem under the premise).

(6) Check whether the dist directory is abnormal.

(7) Check whether compatibility meets the requirements.

(8) Delete a module test to see if the page will be confused. (Because the page in the reconstruction side is static, but in the front end, some modules may be triggered before the display, so in our own test, we need to try to delete a module page will be normal display).

(9) The title (page title) of each page is correct.

(10) If PC is used, add “cursor: pointer; (Little finger) “.

(11) Pay attention to word-break, word-wrap, white-space.

(12) Avoid style conflicts.

(13) Check that each element is not stealthily deformed.

(14) Check the code to see if it conforms to W3C standards.

Submission & Handover

(1) Save, compile, submit, upload and accept. (2) Confirm the front end and close the demand list.

After the release of

After the release of the test environment or the official environment, go to the test network, live network check.