First published on personal blog

Summarize the problems caused by some project specifications in the process of developing and reviewing colleagues’ code and think the best solutions; Due to the limited personal experience and cognitive level, the following only represents my personal concept, welcome you to give me more suggestions;

Take a project I wrote recently (technology stack: Meteor + React + MongoDB) as an example

The use of the readme

Because a project often requires a lot of people to help develop it, and there are always new people to take over, it’s important to have as little information as possible in a READme

• Project start command
• Code specification
• Commit Message writing specification
• Naming: class naming, variable naming, function naming, component naming, etc
• component
• The directory structure
• Common problems and solutions

You can also add some documentation links to the design encountered in the project

Code specification

eslint

Use ESLint to constrain team uniform code rules

Eslint rules are defined in.eslintrc.js. If you feel that a rule is unreasonable, you can discuss with your team members to ban it, or add it if you have good suggestions. Pay attention to the following:

• Indent code with 4 Spaces
• Statements must be followed by semicolons by default
• Use single quotes
• Delete or comment out console.log statements before submitting code (otherwise it will affect other developer debugging)
• Disallow var, use ES6 let,const declaration variables

There are also cases where you don’t need to check for third party libraries, frameworks, components, UI libraries, etc. You can put these files in.eslintignore files and ignore esLint’s checks

To disable the esLint rule for an entire file, add the following line at the top of the file

/* eslint-disable */
Copy the code

The use of the pre – commit

Usage method 1. Install it on the CLI

npm  i --save-dev pre-commit
Copy the code

2. Configure it in package.json

{
    "scripts": {
        "eslint": "eslint ./ --ext js,vue --ignore-pattern .eslintignore --cache --fix"."lint-message": "Echo 'starts ESLint checking, rejects commit if error exists '"
    },
    "pre-commit": [
        "lint-message"."eslint" // EsLint checks and automatically fixes simple formatting errors],}Copy the code

Code review will be enforced before submission, and code that does not conform to the specification will not be allowed to submit

Git commit -m ‘XXX’ –no-verify or git commit -n ‘XXX

Tip -vscode can configure save to automatically fix eslint errors

Vscode installs the ESLint plugin, as shown in the configuration

{
     "eslint.autoFixOnSave": true."eslint.enable": true."eslint.options": {
        "extensions": [".js".".vue".".jsx"]},"eslint.validate": [{"language": "vue"."autoFix": true
          },
          {
              "language": "javascript"."autoFix": true
          },
          {
              "language": "javascriptreact"."autoFix": true}}],Copy the code

Commit Message writing specification

Writing a Commit Message needs to follow a certain paradigm, and it should be clear and clear, indicating the purpose of the Commit and making it easy to track down problems later.

Feat. Fix bugs. Docs style. Refactortest: Adds a test chore: changes to the build process or helperCopy the code

named

The semantics of naming is really important, even if you don’t know what the English word is, you should look it up. Never name a, B, or C without any semantic meaning. I’ve never noticed this before, but lately I’ve been looking at my colleague’s code and some of the code I wrote before refactoring, and I can’t make out what this variable means. Anyway, it’s so painful to look at this code

Header, footer, container, main, content, aside, page, section Region, block, box class: hd, BD, ft, top, bottom, left, right, middle, col, row, grid, span Primary, secondary, sub, minor: s, M, L, XL, large, small Active, current, checked, hover, fail, success, warn, error, on, off Nav, Prev, next, breadcrumb, forward, back, Indicator, Paging, first, last Tips, Alert, Modal, POP, Panel, Tabs, Accordion, Slide, Scroll, Overlay, Star class: Rate, STAR segmentation class: Divider group, seperate, divider, etc. : full, half, third, quarter table class: TABLE, TR, TD, cell, row Img, Thumbnail, Original, album, Gallery Language: CN, EN Forum: FORUM, BBS, Topic, POST direction: up, Down, left, right btn, close, ok, cancel, switch; link, title, info, intro, more, icon; form, label, search, contact, phone, date, email, user; view, loading…

Variable naming: Use a name that accurately describes what the variable represents. For example, use the user ID as userId, not just user

Function naming suggestions: Common verb conventions can be used

Verb meaning get Gets a valuesetSets a value is to determine whether it is a value has to determine whether a value existsCopy the code

The following rules are used in this project, depending on the team’s code habits:

1. The component name and the filename in which the component resides use the big camel shape
2. CSS class names use lowercase words and are separated by a line (-)
3. Dom nodes start with $

component

1. Each component occupies one file
2. Components that do not contain state should be written as stateless components
3. Non-stateless components are optimized with pure-render-decorator

The directory structure

├ ─ ─ client │ ├ ─ ─ main. The HTML to the client page template │ └ ─ ─ the main, js client entrance ├ ─ ─ imports │ ├ ─ ─ client │ │ ├ ─ ─ App. The top-level components JSX │ │ ├ ─ ─ the components │ │ ├── ├─ ├── All of your exercises, please contact us Util utility functions ├ ─ ─ packages custom meteor packages ├ ─ ─ public client resources └ ─ ─ server ├ ─ ─ main. Js service side entrance └ ─ ─ and user interfaceCopy the code

The use of free

Project will always encounter a lot of strange questions, was impressive, after a period of time, have forgotten the specific problems and solutions, although can commit to fix records at a time, but a great trouble to find that our project is to use gitlab to host, can be a reasonable reason to free tricky problems every time “, can mention a issues, such as later to solve the problem to close the issues, and write the cause of the problem and solution analysis

Added below are some of the specifications developed for the back end of Meteor in the project

The database

The Collection definition

All Collection definitions are placed in the imports/ Schema directory, and each Collection must define a schema to constrain the fields

Schema definition

Schema definition using SimpleSchema, data must pass Schema verification before being inserted into the database.

Filter Collection field

By default, the data query will return all fields, such as memette.users.find ({}) will return the user’s password and token, which is not secure or correct. The second parameter of find/findOne is the query option. The fields field controls the return fields, for example:

Meteor.users.find(
    { },
    {
        fields: {
            username: 1.profile: 1,}});Copy the code

The query returns the _id, username, and profile fields, where _id is returned by default

Customize the Populate method (retrieve associated data)

Reywood: publish-Composite does not automatically update data when adding new friends to a group, so you will define methods on the client side The benefit of this is to solve the bug that fetching associated data will not be updated automatically, but it is a bit troublesome that the method must be called on the client side every time the associated data is needed. I am considering whether there is a better solution

import { Meteor } from 'meteor/meteor';

const PopulateUtil = {
    group(group) {
        if (group) {
            group.members = Meteor.users.find({ _id: { $in: group.members } }).fetch();
            group.admin = Meteor.users.findOne({ _id: group.admin });
        }
    },
    groups(groups) {
        groups.forEach(group= >PopulateUtil.group(group)); }};export default PopulateUtil;
Copy the code

Because this project needs to design the database by myself and define the back-end methods by myself, I didn’t have any experience before, but NOW I have summed up some lessons:

• Database design must be based on the specific business logic (must communicate clearly with the product logic before starting the design)
• Do not let the front end pass data that can be retrieved from the back end when the interface is defined

In the end, it feels like the logic on the back end is really complicated, requiring all kinds of judgment and thinking about all kinds of situations

I recommend taking a look at this code book (2nd edition) and refining this article after reading this book

reference

• How to name a class more formally
• Complete Code (2nd edition)
• Commit Message authoring Guide

About

github blog