1 Write a work log.
I have always had the habit of writing a lot of notes. When programming, I often encounter some troublesome problems, and my ideas are fleeting, so recording all these ideas will become an important source of inspiration in future searches.
My work log usually takes projects as units and contains four important chapters:
Introduction
Design
Project
Journal
1.1 Introduction
Record the summary information of a project, to give a few examples:
Who is the person in charge of the project? Who are the related parties? So that I can quickly find the corresponding person when I encounter problems, especially large factories often have cross-departmental cooperation, and there are many related parties that I don’t know. It is difficult not to record the server connection information, such as the address of the test server, the
access URL, Database, MQ, and various common debugging entrances are worth recording.
Technical document entrances, such as the URL of the project-related wiki in the company's wiki
1.2 Design
Used to record various design ideas. Including large modules after dismantling various parts of the project, interfaces between modules, architecture design, etc.
The design ideas of each part are recorded in multiple subsections. In particular, there are often multiple designs, which can be recorded in another level of directory. Each design will have its own characteristics, and you can also open a table for comparison. For example, the implementation speed of a certain solution is fast, another solution can use mature facilities, the risk of returning another solution is very small, and one solution is very cool and suitable for sharing in the future, etc.
The details of these designs make it possible to quickly find the original ideas when looking for ideas other than codes in the future. After all, many technical details cannot be understood just by relying on code.
1.3 Items
For project progress management, I will make a tree diagram and split each job in sufficient detail. And use color to record the degree of completion of each job. White indicates not started, yellow is in progress, green is completed, and red is failed. For some projects with certain technical risks, there may be several technical solutions for the same functional module, and it is normal for some of them to fail.
In particular, I use SVG diagrams to organize the entire tree diagram. Each node is clickable, and the specific card of the work item in the page is riveted through HTML to see the specific description of the work item. For example, more detailed design ideas, implementation process, research conclusions, etc.
Use the tree diagram method, which is the common WBS method in the field of project management.
Often, after a project is deployed, there will be development goals at various stages. Such as function modification. Then you can open a section for each sub-project, and record the demand side, demand content, etc. this time. In this way, at the end of the year, when you have to sort out the things you have done in a year, you will be very organized.
1.4 logs
Record the work content of each day. One subsection per day, titled by the date.
Sometimes when there are many experiments, multiple cards will be opened in a day, and each card corresponds to the process of an experiment. The front is the control variable, the middle is the experimental results, and the latter is a simple analysis of the experimental results, so that the next experiment can be improved.
Format and search
Friends who are familiar with me know that the format of my notes is reStructuredText, and the compilation tool is docutils with only 2MB. Generate HTML pages, while the source code is managed through git. In this way, the entire note library can be searched efficiently through grep. This is much more convenient than those source files that are in a proprietary format.
2 Plan and organize your code before you start coding
At the beginning of the project, don't write the code directly, you must first determine the layering and structure of the code. The layering and architecture determine the code style and maintainability of the entire project in the future to a certain extent. For the long-term maintenance of the project, the design of the code architecture is a very important thing.
Code architecture can provide better readability and maintainability.
2.1 Avoid repeating code in large blocks, even small blocks
A very good programming practice is to make sure to create functions or classes for your code so that you can reuse it sometimes. When repeated code blocks appear many times in your coding process, which is bloated and tasteless, you should think about whether they should be encapsulated into a function or class.
Dedicated files are built specifically for functionality that can be used over and over again. For example, database calls such as opening a database connection, selecting data, inserting data, updating data, deleting data, and closing the connection should all be converted to functions. It also makes your job easier by not having to rewrite redundant lines of code. All you need to do is call the function, simple, clean, and easy.
2.2 Use an easy-to-read naming convention
No matter what type of code you are developing, naming conventions are important. The more human-friendly you create variable names, function names, class names, and any other program names, the easier it will be for your subsequent development and reference. Because not all code is written on the same day, and a project is often participated by many people, good naming conventions can greatly improve coding efficiency, and can also reduce the degree of stupidity in the minds of your colleagues.
2.3 Comment all code, even if it seems obvious
Even if it is written on the face, it must be commented, commented, commented. Because when you are dealing with code, it must be understandable, otherwise you would not be able to write such code.
2.4 Testing and debugging code at build time
Every time you create a code block, you should test and debug it to make sure it works correctly. Don't cover your head, just write, and then debug when you're done, avoid sifting through hundreds or thousands of lines of code to find bugs. Not only do you need to test and debug your code as you build it, but you also need to make sure you turn on all bug reports so you can actually see bugs in action. Like PHP, you'll also need to make sure these settings are turned on in your php.ini file or user.ini file, which is usually located in the root directory.
3 When encountering unclear or incomprehensible knowledge points, first read the official documents
Many official documents are in English, so you have to read them even if you have to bite the bullet! You get used to it just by looking at it.
It will take time and effort to read English documents at the beginning, but when you look back, you will feel that this is the most appropriate choice.
4 Think hard
1. Have self-requirements for code specifications and coding;
2. Keep thinking, try to tell yourself to think more when describing problems to others, and see if you can find out the deeper reasons;
3. Try to ask others for feedback, especially People who are at a higher level than you.