Write in front

This article was not intended to write, until after several code review meetings, I realized that their own coding way is not systematic, still need to learn systematically, mastering the most applicable laws summed up by seniors is undoubtedly a good way. It so happens that a long time ago I collected this code neat way, so I decided to take advantage of the leisure time to read the summary, if you want to learn systematically, it is recommended to read, this document is only used as their own records.

A person’s professionalism is reflected in the way to solve the problem, the steps and the degree of reflection, not in the difficulty of the problem itself. Think about a question: What qualities should a technical person have to be considered a professional? If it does not yet have what needs to change in order to be considered a professional?

Clean code

  1. Why write bad code?
    Everyone has their own reasons, and I’m sure many of you are thinking of waiting to optimize your code if you have time, but remember the saying: later equals never.

  2. the cost of messy code?
    It is difficult to maintain and modify, and productivity and time show a negative correlation.

  3. what is neat code?
    Clean code does only one thing well: each class, each function, each module is focused on one thing, completely free of interference and pollution from surrounding details.
    A more comprehensive overview is: reduce repetitive code, improve the power of expression, and build simple abstractions early.
    For a more concrete implementation: read on!

Better variable naming

  1. See the name and know the meaning

  2. the abstract factory: interface do not name IShapeFactory, the leading letters for the user is actually interference, the user only needs to know that is an abstract factory, it is recommended to use CShapeFactory may be a better experience

  3. the class name to use nouns, methods to use verbs, similar words get, fetch such words should not appear together, you can add the suffix getNumber, fetchData to achieve the same effect

  4. don’t be afraid of long names: use descriptive names, even if they are longer than the short and confusing names

Better functions

  1. the structure of the function should essentially be short and short again, to not accommodate if/else if/else nested structures as the goal

  2. only do one thing: as said earlier, the function only do one thing well enough, the sign is “to see if a function can also be split, the function is not only simply reinterpretation of its implementation”

  3. each function an abstraction level: the code is generally “top-down” reading order, each function should be followed by the next abstraction level of the function
    [abstraction level: getHtml function is located in the higher abstraction level, pagePathName = pathParser.render(pagePath) is located in the middle abstraction level, .append(“\n”) is located in the lower abstraction level]

  4. switch statement: born to do N things, but can be placed in the lower abstraction level, but when a new type will violate the “single authority and responsibility principle, the principle of open closure”, it is best to create polymorphic objects

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
//In the original article: for each case branch for separate processing, adding new types without modifying the original code to add a new processing class can
function getName(name){
    switch(name){
        case 'ming':
            return new ClassMing(name);
        case 'hu':
            return new ClassHu(name);
        case 'uzi':
            return new ClassUzi(name);
        default:
            throw new ClassCommon(name);
    }
}

//Another way: the modification only needs to be modified in the object, and it improves the simplicity of the function
const nameCollectionUtils = {
    ming：new ClassMing('ming');
    hu: new ClassHu('hu');
    uzi: new ClassUzi('uzi');
}
function getName(name){
    return nameCollectionUtils.hasOwn(name) ? nameCollectionUtils[name] : new ClassCommon(name)
}

  1. function parameters up to two: including input parameters and output parameters

  2. no side effects: do not make changes inside the function that are not expected, do not have an impact on the outside

  3. use exceptions instead of returning error codes: use try…. .catch instead of multi-level if nesting, always walk on the main road, do not think too much about the boundary, so you can always keep thinking coherent

  4. error handling separate extraction: this one I think can depend on the situation, after all, extraction is only for aesthetic purposes

  5. do not repeat: multiple functions using the same logic of the code must be extracted, you can refer to the object-oriented base class, front-end development of component-oriented programming, module-oriented programming is also this idea

Notes & Format

Everyone has their own habits, just adopt some general guidelines

Error Handling

There is no fixed protocol either, it is better to take try… .catch first principle

Boundaries

To summarize, use code that you can control

Unit Testing

Nowadays, the majority of Internet companies are agile developers, and very few companies can comply with test-driven principles, and very few technical teams will require unit testing in order to ensure progress.

Class
  1. Class organization: In the following order, do not expose the internal properties and use the methods to achieve the same purpose
1
2
3
4
5
6
7
8
9
10
11
12
13
class DemoOrganization{
  static sname = 'sname'
  private pname = 'pname'
  private _pname = '_pname'
  protected tname = 'tname'

  public getPublicName(){
    return this.pname
  }     
  private _getPrivateName(){
    return this._pname
  }
}

  1. the principle of single authority and responsibility (SPR): the class or module should have and only one reason to modify, the implementation of this principle of the class is more likely to be reused

  2. maintain cohesion: the variables defined in the class should be used by as many methods as possible, if not satisfied, then the use of variables to the function split into smaller classes

  3. the open and closed principle (OCP): the class should be open to expansion, closed to modification, by subclassing means to achieve the addition of new functions while not touching other classes

  4. Dependency inversion principle (DIP): the class should depend on the abstraction rather than on the concrete details

  5. decoupling: different methods and modules do not affect each other, that is, “divide and conquer”, “whole into zero”

System

  1. Separate construction and use: the details of the construction should be isolated from the application code, and the user can only get what the constructor wants the user to get

  2. the design should be able to meet the update iteration from simple to complex

Iterative progression

To summarize the above, an iterable program with good design can be obtained by adhering to the following principles.

  • Run all tests
  • Is not repeatable
  • Expresses the programmer’s intent
  • Minimize the number of classes and methods
  • The above rules are listed in order of importance
Concurrent Programming

First of all, it is important to understand the concept of “threads”: the smallest unit of CPU scheduling, as opposed to “processes”, which are the smallest unit of resource allocation. See the table below for the difference.

Classification Data Sharing Consumption of resources Does it affect sister programs Maximum Scalable Dimension Whether there is a lock
Process Difficult Multiple No Multiple machines Yes
Threads Simple Less May affect the process in which it is located Multicore No

If objects are the abstraction of processes, threads are the abstraction of scheduling

The front-end use of js language is a browser scripting language, the most important use is to interact with the user and manipulate the DOM, which determines that js can only be single-threaded or will create complex synchronization problems, but js can still simulate concurrent execution, the specific implementation of their own query related information

Currently, we have not learned the language of concurrent programming, and we will add learning later

Reconfiguration

This module I think is the most important module, even more important than how to write a new program, because the number of deposition projects in a company is huge, and it is likely that several of them or even more will be refactored (or because the previous code is too badly written to maintain), so the points that need attention in refactoring should also have a clear perception.

There is only one principle to follow: the code that is signed in is neater than the one that is signed out.