Preface: Many people say that program is an art, for this statement, I was difficult to understand before, program is a tool, a knowledge, how can it be an art, later work more in-depth, the more things considered, found that program is indeed an art. What is art? By capturing and mining, feeling and analysis, integration and application, through the form of feeling to show the staged results. Programs don’t just need to be written and run, they need to be felt and analyzed, they need to be integrated, they need to be realized. Obviously, the program is up to the standard of art. In addition to art, art also needs tao. The procedure of the art is everyone can get the consensus, all kinds of articles to improve their technology are everywhere, here we talk about the procedure of the way, that is, the method. This is something that is often overlooked or underappreciated.
As an artist (lol, laughs myself). There are indeed too many things to pay attention to in the work, especially the work method. In the development of this thing, few people usually train themselves or spend time to teach themselves, which needs to be learned and summarized by themselves. The further I go, the more I learn in this aspect. Here I will also talk about the pit I have climbed in my work and the road my companions have crossed.
On development
Comments and code specifications – programs are written for people, machines second
- The difficulty with a code specification is not writing the code specification, but enforcing it. There are only two ways to enforce a code specification:
-
Pass the code review. In fact, it is generally checked by IDE plug-ins, commonly used for javascript jsHint, for Java checkStyle, for.NET StyleCop. Automatic code inspection can detect a limited number of problems, mainly for formatting, comments, naming, etc., but it is efficient and can kill some low-level errors. If you are familiar with secondary development, it is worth spending more time researching customization.
-
Pass a human code review. This is a purely artificial way, some pits are not detected by tools. Such as circular access to the database, circular access to the network, and so on, these need to go to the manual judgment. The way I usually do this is when CVS gets the code, so I can scan through it and find some low-level errors. It’s relatively efficient.
- Don’t say comments affect performance and waste time. The premise of comments must be able to make people understand, others can understand your code, you can save a lot of time, don’t be afraid to comment text, too long. With modern languages and compilers, the performance impact of annotations is negligible.
Exception handling – Program errors exist, all around you
Exception handling is a problem we must face in the development process, but there are often some exception handling methods, are used incorrectly:
- You don’t throw an exception, you confuse people.
try{}catch (Exception ex)
{
return null; }Copy the code
If the test does not produce such a problem, in the production environment absolutely ignorant B, there is no error message, no log, can not find any error message, this seems to be a very low-level error, I have actually been around someone to deal with this, I have seen much better.
Test and development environments that have bugs must be thrown out in detail.
Errors in the production environment should be properly notified and reported, and detailed errors logged.
- Ignore warning messages
Modern compilers generate errors that cannot be compiled, but warnings are ignored by default. If conditions permit, we had better deal with all warnings, not to deal with is to bury their own pit, is likely to erupt in the back.
I have experienced an incident in which.NET called redis using the officially recommended driver library service.stack. redis, but ignored the warning message when using it, resulting in the late version compatibility problems in the production environment. So the problem was dealt with immediately.
If conditions permit, resolve all warnings. If conditions are limited, check warnings frequently and pay attention to new warnings.
Code cleanliness — Code must be perfect
Many of us have experienced the experience of taking over someone else’s code, and there is nothing programmers fear more than reading someone else’s code. Whether it is someone else’s code or your own code, it is customary to refactor. The art of code is not accomplished overnight. It needs to be sculpted slowly. If you find a problem during development, either in your code or someone else’s, be sure to fix it. Code is a process of accumulation. Inappropriate code should be optimized in the early stage. If it accumulates more and more, in the end, there is only the possibility of “no time to optimize” and “dare not optimize”.
In a refactoring process, there are always many reasons why you should not do it. The top two reasons are “no time” and “too risky”. This is why so many companies whose business is stagnant or steadily improving have to redo their systems after less than two years of use.
The end result of the code is the result — always define a deadline
The work will never be finished, but the project must define the deadline, even if there is no clear assessment, we need to define the deadline for ourselves. If a project lasts too long, the weakness of the project will be more and more serious, the cost will be higher and higher, and the coding efficiency of developers will be low. Deadlines must be defined for all development tasks. Another advantage of the definition of deadline is that it can have results to show, which is very important for enterprises. It is very important to realize that technology, knowledge and ability must be turned into ready-made achievements. Even if it is to do technical research, it needs to be demonstrated with achievements instead of dealing with the ongoing state all the time.
About the integration
Testing code saves time, not progress
Be sure to write test cases. Test cases will never waste your time. Test cases will not slow down the project, but speed it up. The progress is not just finished, you need to help test and make sure the project goes live. The progress of the project is the real progress. The hard part about implementing test cases is that they don’t stick. Even if you are responsible for the code you write, get used to writing test cases even if the company doesn’t require it. If you look at the good open source code, you will write your own test cases.
The current development mode is basically the separation of the front and back ends. Whether it is Web or APP, data docking is carried out through API, and it is easier to test test cases. All interfaces need corresponding test cases, and if you are not willing to write code, test tools can replace code programming. For developers, writing code to test may actually be a better experience, faster, testing tools are more oriented to test engineers.
Automated testing is the best way to boost your confidence
-
Automated testing is necessary as the system becomes more and more functional over time, more functional means more risk, more likely to go wrong. As systems grow larger and manual coverage is limited, automated testing is a must.
-
Automated testing should be planned in advance at the early stage, and all tests can be covered basically by manual work. However, in the later stage, more and more functions should be tested. Not only new functions should be tested, but the development of each function should carry out system-wide regression testing. The test cases mentioned above are the basis for automated testing. With a strong accumulation of test cases, it is much easier to build automated tests. Test cases are not something you do when you have time, or when the system gets big. They should be done from the beginning, not when the system gets big and bloated and you have to rethink the business scenario.
The code is always ready to be published
The current development methods tend to agile development, the advantages of agile development will not be described here, but agile development is characterized by high frequency of release, so the code should be ready for release at any time, in fact, this is not very difficult, as long as the proper use of CVS tools can be.
- There is always a version of the online code. Don’t let a version go dark, be sure to be familiar with the role of branches.
- Fix Bug is released by merging independent versions. Adopt minimal publishing, that is, merge as many files as you need.
- Set up a grayscale release environment as a pre-release validation environment, the same as the production environment, only the address is known to internal personnel. Of course, it would be nice if you could control grayscale publishing via Nginx or a gateway.
About the collaboration
Code is shared, and your code should be able to be modified by everyone
As a contributor to the company’s code, whether you are a director, manager, architect or programmer, do not assume that your code cannot be modified by others, the code should be shared, as long as we are authorized by the company, we should be able to modify each other’s modules.
- Modifying each other’s code is actually a process of code review.
- Changing each other’s code makes it easier to get familiar with each other’s business.
There is room for refactoring. Just because you are senior or experienced doesn’t mean you can’t let anyone touch your code. Sure, someone can break your code, but this can be addressed through communication.
Sometimes, we too much attention, the knowledge system of technology itself, but ignored the technical knowledge and better use of themselves to work, to their own systems, because these things, in addition to the skills relevant to the study, is more of a need to sum up, the more ready to wade pit, may summarize the more, Rome was not built in a day, The system is not perfect all at once, and our own knowledge system also needs time to accumulate.
Welcome to pay attention to my public number communication, learning, the first time to get the latest articles. Wechat id: ITmifen