One, foreword

Hello everyone, I am a junior student who loves front end. From the beginning to learn the front end to now have a year or so of time, some time ago ended in a network security company internship. This is my first internship. Although I had some personal project experience in school, IT was still difficult for me to deal with many things at the beginning of the company. After several months of internship, I have something to summarize for you, hoping to give some help to students who have not had internship experience. This summary is mainly related to the use of tools and skills, and may pick some problems encountered after the summary, the big guys lightly spray ha.

Ii. Project environment

For just entered the company generally will issue a computer, some big factories will even send MBP (real name envy), the first day we generally install a development environment. For example, node, NPM, git and VScode are familiar, so I won’t go into details. After that, someone will pull you into the gitLab project, you can pull the code to the local, you can start to familiar with the project according to the documentation.

1. Environmental classification

The development of a project in a company may have a local environment, a test environment, a formal environment, and even a pre-release environment.

  • Local environment: Services that you start on your computer, of course
  • Test environment: Every time you commit code and merge it, your submitted code is generally accessible in the test environment, which is mainly used by testers for daily requirements development tests.
  • Pre-release environment: In the company where I worked as an intern, the code of the test environment was merged into the pre-release environment for the final test before the official release.
  • Formal environment: The code will not go live until there are no problems at the end.

2. Project configuration

In project development, you are not the only one to access the local environment. In school, it is ok to use localhost for the local service address of your personal project, but in the company, your environment should also be accessible to colleagues’ computers, and you can change the background at any time.

  • When one of your requirements is done and the project manager wants to check it on his computer to see how it works, he needs you to give him the address of your front-end service, solocalhostCertainly not.
  • During project development, we usually connect with the backend students, but the backend students are also developing at the same time. The backend we connect is not necessarily the online backend address, but the local service of the backend students. At this time, we need to be able to dynamically change the backend address.

Create a new.env.local file in the outermost directory of the project and add the following configuration.

LOCAL_URL = 192.168.109.153 PORT = 8000 BACK_END = 192.168.109.153:3000 BACK_END = 192.168.109.153:3000 BACK_END = 192.168.109.100:3000Copy the code

Vue. Config. Js configuration

module.exports = {
  devServer: {
    host: process.env.LOCAL_URL,
    port: process.env.PORT,
    proxy: {
      "/api": {
        target: `http://${process.env.BACK_END}`}}}}Copy the code

Companies are generally developed in the Intranet, local services can fill in their own COMPUTER assigned IP address, so that colleagues can access each other.

The function of a proxy in devServer is to be able to proxy all request addresses in a project starting with/API to the address corresponding to target.

For example, the following code in the request address will be acting to http://192.168.109.153:3000/api/lookup/testinfo

// Take the Vue project for example
<script>
import axios from 'axios'
export default {
  name: 'EnvTest'.data() {
    return {
      list: []}},mounted() {
    axios.get('/api/lookup/testinfo').then(res= > {
      if (res && res.success) {
        this.list = res.data.data;
      }
    })
  }
}
</script>
Copy the code

Is http://192.168.109.153:8000/api/lookup/testinfo, but in fact in the browser request service address homology with front end, so it can also avoid cross domain problem.

This is implemented using devServer’s proxy in the local environment, and nginx is generally used as the reverse proxy after the project goes live.

For more information on how to configure environment variables, you can also see the official Vue Cli documentation: stamp here

Plug-ins and techniques

1. Vscode plug-in

(1) Eslint

Those of you who develop with Vscode are no strangers to plugins and have to configure whatever functionality you want to use, but I want to mention the Eslint plugin in particular. I don’t know how many of you feel constrained and uncomfortable using Eslint in your personal development projects. I even disabled it. However, to the company development it is certainly essential, multi-person development project style must be as unified as possible, but also convenient for others. You can imagine how uncomfortable it would be if someone didn’t use Eslint and stuck to their own style, and the editor went up and down while they were developing and maintaining the code themselves. So, you need to get used to it in your normal development. There are many Eslint configurations available online for reference.

(2) Gitlens and Git History

After installing the plug-in, you can see the actions in the upper-right navigation bar and right-click the code area

In a company where many people collaborate, it is sometimes necessary to view the logs of code submissions. It is very convenient to view them in the current code, saving a lot of time to view them in other tools and improving development efficiency.

Here are a few useful features:

Click on each line of code to see who committed the code, when it was committed, and commit information. Hover the mouse over this information to display a more detailed submission record.

You can quickly find the culprit when you find a problem in your code. You can’t escape it, so you have to write it carefully. For which piece of code they do not understand the place can also be convenient to find write it to ask the elder brother.

2. Click “Open Changes with Previous Revision” to see the code Changes compared to Previous versions

3. Click “Toggle File Blame” to view all historical submission records for a File.

In addition to these plug-ins, there are a lot of everyday use, I will not go into the use of these plug-ins can really improve the efficiency of development.

2. Vscode skills

(1) Shortcut keys

1. Find the correlation

The company’s projects are often very many files, a file also contains many lines of code, their eyes to find one by one is often particularly troublesome, master these shortcut keys can quickly find the document or text they want.

  • ctrl + f– Search text. Select the text to be searched and press Enter to search for all matched text.
  • ctrl + h– Replace text.
  • ctrl + p– Searches for specified files in the project by filename.
  • Vscode left toolbar Search – Search text or files. This is different from the shortcut key, it will search all files in the project by filename and file content, it is very comprehensive search.

2, edit related

  • CTRL + D – Select the same text to edit at the same time. Place the cursor at the end of the text you want to edit, then press this shortcut key several times to select and edit simultaneously.

  • Shift + Alt + up/Down – Quickly make multiple copies of a single line of text.

  • Alt + up/down – moves code up and down. Let me give you an example of how this might work. For example, in Vue, when I need to pass multiple attributes to a component or element, each attribute is usually a single line. Sometimes when DEBUGGING, I want to comment out an attribute to see what effect it has.

(2) Use Source Control

In addition to the Gitlens plugin mentioned earlier, vscode also has its own Source Control in the left toolbar, which is somewhat useful for git manipulation. Here you can directly view the status of the modified files, and directly use the GUI to operate Git. After clicking file, you can also pop up the comparison between the file after the current change and the file before the change. It is recommended that you check all your change records before submitting the code in this way to avoid unnecessary changes or errors.

(3) Use vscode built-in terminal

Press CTRL + ‘to open the built-in terminal.

Don’t know if you have and I liked it before each launch by CMD to open a variety of service and operation, result in the task bar every time a lot of things, very not easy to manage, so that through the built-in terminal to start the service and some of the operation is more convenient, and it can directly input Chinese and also some relatively good.

3. Chrome

(1) Plug-ins

The first thing to recommend are the developer tools for each framework, such as vue.js devTools and React DevTools.

1, Vue. Js devtools

This section uses vue.js devTools as an example. This plug-in allows you to view component structure, state management, routing, events, and more, making it very user-friendly for project debugging. Today I’m going to focus on the Open in Editor function. This feature may not be noticeable in small projects, but in corporate projects, the introduction of directory structures and components is often complicated, and it is difficult to find them manually. After selecting a component through this plug-in, you can quickly jump to the relevant component code in Vscode.

To implement this feature, you need to do some configuration.

(1) Install launch-editor-Middleware first

(2) Perform some configuration in vue.config.js

const launchMiddleware = require('launch-editor-middleware')

module.exports = {
  devServer: {
    before (app) {
      app.use('/__open-in-editor', launchMiddleware())
    }
  }
}
Copy the code

(3) Finally, press CTRL + Shift + P to open the Command Palette, enter shell Command, and click “Install ‘code’ Command in PATH”. (Windows users seem to add code to the environment variable by default when they install vscode.)

When I was configuring, I found that the environment variable could not be found when there is a space in the path name, because Vscode is installed in a directory called Microsoft VS Code by default. Please note that there is no space in the file name.

I’ll talk a little bit more about finding files and pages here:

When I first entered the company, I was not familiar with the code and page of the project, and it was quite difficult to find the specific page or relevant code according to the code when making some requirements. Let me talk about some skills I gained.

  • Find code by page: The open in Editor plug-in mentioned earlier is useful, but for some JS files it is difficult to find. First, it is easiest to find the keywords on the page, and then use these keywords to search in vscode. After finding the matching file, use the outer file to find the specific file through its import path. The important thing to note here is that mixins like Vue2, sometimes you find that a method is being used for no apparent reason but you can’t find a place to define it, so it is usually defined in the mixin file.

    Some of the content is output by the back-end interface, so the keywords don’t work, so you can start by looking at the page URL to find where it is defined in the routing file, and then route to find the component to look up.

  • According to the code to find the page: then this is just the opposite of the above, from the inside out to find, by searching the file path to find it into the upper layer of the file, when you find the component basically by name you know it roughly corresponds to which page, if it is still not clear or can use the route to find the relevant URL. It should be noted that some files may omit the suffix of.vue or.js, so do not match too much in the search, and try to use relative paths. You can try some relative paths of different lengths. If you look up and find that you don’t feel referenced by any file, you can determine this by deleting the file first and then checking to see if the started service has been updated, and if so, it is definitely referenced.

2, FeHelper

The plugin has many extensions, such as JSON beautification, code beautification, regular expressions, and more.

Such as this JSON beautification tool for the front-end students is very practical, for the back-end interface we sometimes want to change different parameters to test the interface returned data can be directly viewed in the browser. Of course, you still need to use Postman for some other types of requests.

(2) Code debugging

I don’t know how many students and I used to debug the code every time to hit a console.log() and then check the console, such efficiency is extremely low, it is necessary to master the browser’s own debugging tools.

In the browser’s console menu bar, find Sources, press CTRL + P to search for the file you want to debug, hit the breakpoint, and then refresh the page. When the breakpoint is executed, it will stop automatically and the page will stop rendering. At this time, you can view the current value of the variable by placing the mouse pointer on the variable you want to view. Like many debugging tools, the tools in the upper right corner can control how code is executed by skipping to the next breakpoint, functions, and so on. It can also look at listeners and listen for specific variables and so on, so you can look it up online and learn more about it.

Iv. Development specifications

1. Code specification

Companies have their own code conventions for things like hump naming, indent Spaces, single or double quotes, etc. These are pretty much reflected in Eslint, they’ll go red if they’re not correct, and companies will have documentation that I won’t go into. Here are some of the things I think are important.

  • During development, there will be some existing components or encapsulated methods. Do not write duplicate code, refer to the previous usage, which can not only improve the development efficiency but also ensure the uniformity and maintainability of the code.

  • All kinds of variables or component names should be named as far as possible semantic, write more notes, convenient for others and convenient for themselves. Think about how hard it looks to get a project to begin with with almost no notes. It’s important to get into the habit of writing comments.

  • For some commonly used CSS styles are usually defined in the public file, such as some color, font size, etc., do not directly write their own values, need to reference the public file has defined variables (using SASS or LESS preprocessor), which is conducive to code maintenance. For example, if you want to change the theme color in the future, you can easily change it directly in the public file instead of having to change it in different places.

    Variable definitions (SRC /styles/_variables.scss)

    / / color
$white: #fff! default;$gray-100: #f8f9fa! default;$gray-200: #e9ecef! default;$gray-300: #dee2e6! default;$gray-400: #ced4da! default;$gray-500: #adb5bd! default;$gray-600: #6c757d! default;$gray-700: # 495057! default;// Font size
$font-size-base: 1rem! default;// Assumes the browser default, typically `16px`
$font-size-lg: $font-size-base * 1.25! default;$font-size-sm: $font-size-base*.875! default;$font-size-root: null ! default;Copy the code

    Use (need to import the above style file into the entry file first)

    .box {
	width: 100px;
	height: 100px;
	color: $gray-300;
	font-size: $fony-size-sm;
}
Copy the code

    Mixin definitions (SRC /styles/_mixin.scss)

    Multiple styles that need to be reused are defined in mixins

    @mixin button-size($padding-x.$padding-y.$font-size.$border-radius) {
  padding: $padding-y $padding-x;
  font-size: $font-size;
  border-radius: $border-radius;
}
Copy the code

    use

    .btn-sm {
  @include button-size($btn-padding-x-sm, $btn-padding-y-sm, $btn-font-size-sm, $border-radius-sm)
}
Copy the code

    The above are some of the SCSS writing methods, you can go to SCSS or LESS official website for more detailed study.

Git specification

  • Most of the code repositories used in the company should be GitLabs, with names, id numbers, email addresses and so on configured. Each time a requirement is developed, a new branch is created. It is usually named after the requirement name and its initial (for example, feature-project-filter-tc), and the initial of the project is added to prevent it from having the same name as someone else’s branch.
  • Remember to pull the online code before submitting the code every time, otherwise you will see how many branches lag behind in gitLab, and even conflict with colleagues, which cannot be merged automatically.
  • Commit specification: Commit messages usually start with a fixed format, so colleagues can see at a glance what your commit is doing. Different companies may have different specifications, generally have the following categories you can refer to.
    • Feat: Added new features
    • Fix: Fixes bugs
    • Docs: document
    • Style: Format changes do not affect code execution changes
    • Refactor: Refactoring code (i.e., code changes that are not new features or bug fixes)
    • Test: Adds a test
    • Chore: Changes to the build process or helper
  • You cannot directly merge your code into the main branch after pushing your own branch, nor do you have the right to merge your code. Once you have submitted your code, go to Gitlab and create a merge request to merge into the main branch. Someone will review your code, check for logic issues, code specifications, etc. If there is a problem, the owner will give you some comments, and you need to modify the code again based on the comments, and then resubmit. Only when the problems are resolved will your code be merged into the main branch, and your work is done.

5. Experience and suggestions

  • Every intern will be guided by a mentor. At the beginning, I’m sure there will be a lot of problems. If you have any problems, you can ask your mentor, even if you feel the mentor is busy, or ask your colleagues.
  • Most of the people working with the front end are the back end, the project (product) manager, and the UI (interaction) designer. Communicate with them during normal development, and while you may sometimes disagree with them, it’s always good to discuss them. For example, when docking with the back end, the interface and the parameters must require the back end to give a good document, as far as possible to explain each parameter in detail, to avoid a lot of unnecessary communication.
  • Development will most likely require maintenance of previous code or the development of new features on top of it. Make sure you fully understand the meaning of the previous piece of code, and consider that the change may cause problems in other files that reference the code, or it may cause new bugs.
  • Finally, in the process of the internship should also do more summary, for some difficulties or problems encountered in the project to record. The internship is also for learning and self-improvement. It is not just for the sake of making demands, but also a valuable asset in the future interview. I hope you can find a satisfactory internship, and quickly adapt to the company’s project development.

I am also the first internship, may say some places are not necessarily correct, you have any questions can comment to tell me.