English text: My guiding principles after 20 years of programming
From 1999, I began a career in programming, this year has been 20 years. First, I start from Basic, Pascal and soon transferred to the C language, and then learn object-oriented programming languages Delphi and C ++. In 2006, I started using Java, 2011 began to use JavaScript.
I participated in the various sectors of software development, from robotics, financial technology, healthcare and communications to the media. I also worked as a researcher, CTO, TPM (technical product manager), teacher, system architect and technical director, but in any case, I have been programming.
In the project I worked on them, and some provide services to millions of people, some just failed before publishing. I have done a consultant, had also founded his own company. I spent a lot of time on open source projects, and internal closed source project open source projects, from the microcontroller to mobile applications, desktop applications, to cloud services and non-server architecture.
I put some of the most important programming principles accumulated over the past 20 years are summarized below.
- Do not struggle with tools - whether it is the library, programming language or platform. Use as native member. Do not distort technology, and do not distort the problem itself. To solve the problem of selecting the right tools, or you want to rearrange your work as a tool of your choice.
- You write the code is not to look at the machine, but to the future of your colleagues and you see (unless you write a one-time code or assembly code). Write the code to consider the primary developers, they will pass on your code as a reference.
- Excellent software is the result of collaborative development. Effective communication, be open collaboration. Trust others, and allow others to trust you. Respect for others than to respect the code. Lead by example, to your followers become leaders.
- Divide and rule. Low separately developed as separate modules coupled concern. A separate module testing and integration testing. As far as possible in accordance with the actual situation of testing, but also to test various boundary conditions.
- Do not put yourself bundled with the code, find a way to let other people be able to modify your code or add new features, so you can more easily get out to participate in other projects, or to other companies. Do not bundle yourself, otherwise you can hardly grow.
- Security is layered, each layer requires a separate assessment, while related to the whole. Risk is a business decision, there is a direct relationship between vulnerability and probability. Each product or organization has a different risk preferences (in order to obtain greater benefits, they are willing to take risks). Usually there is conflict between these three points concern: the user experience, security and performance.
- Be aware that each line of code has its life cycle, they will eventually die. Sometimes, some of the code is dead before publishing, so learn to let go. Code can be divided into three types: one is the core code, like a car engine, without it, the product would be meaningless; one is the necessary code, like a car's spare tire, usually with less, but if necessary, it determines the success or failure of the system; one is the value of the code, like the cup holder of the car, if it is very good, but if not it will not affect the product.
- Do not put your personal identity into the code, and the code should be separate. Do not put others are saying about you in touch with the code itself together, we must be very careful in the evaluation of other people's code.
- Technical debt is like fast food, and occasionally a little technical debt owed is acceptable, but if you get used to this, it will ruin your product (and this is the way to let you surprise).
- In the search for solutions, follow this priority decisions: Security> availability (accessibility and user experience)> maintainability> simplicity (developer experience)> simplicity (the amount of code)> Performance. But not blindly copy, but to be made based on the characteristics of the product. The more experience you accumulate, the more able to make a trade-off between these factors. For example, in the design of the game engine, performance has the highest priority, but in the development of banking applications, security is most important.
- Copy and paste is a hotbed of breeding bug. It is reviewed on what you copy or import, bug usually hide in the complexities in. Complex dependency does not matter, but it can not exist in the code.
- Do not just write the normal code, the code that handles should make a write. So that people understand why an exception occurs, how to detect and how to solve. Performed for all system inputs (including user input) verification: fail as soon as possible, and as far as possible to recover from the error. We must assume that the user a gun in his hand: your efforts to let the user enter something else, instead of letting their bullet in your forehead.
- Do not use dependency, much lower than the cost of using them unless you write your own code costs. Because the use of dependencies to import, maintain, process bug, but also for reconstruction when necessary, these are the costs.
- Away from the "hype-driven development," but you need to understand them, to do something to try.
- Out of the comfort zone, learning every day. I learned to share out. If you call themselves masters, they are not learning. Reach more programming languages, technology, culture, maintain a curiosity.
- Good code does not need comments, and good code provides a good comment, let any one person not originally involved in the evolution of the code, the process of trial and error and needs easier to read, modify it.
- Try to avoid using heavy-duty, inheritance and implicit intelligence. Use pure function, they are easier to test and diagnose, otherwise it will use the class. Function to achieve different functions you want to use a different name.
- Before a thorough understanding of the issues do not hurry to write code. To much time on code time spent listening to and understanding of the issues usually written than spent. Before writing the code must first understand the problem domain. Questions like a maze, you should be gradual and repeated "coding - Test - improvement" until the problem is resolved.
- Do not try to solve a problem that does not exist. Do not speculative programming. Only after determining the code really needs is scalable just let the code is scalable. Under normal circumstances, when the code is extended, you will find that the problem will grow with the original thought is not the same.
- We develop software together will be more interesting. Build sustainable communities. Listen, inspiration, learning, sharing.
I am not the authority of software development, but these are my principles summed up along the way. I believe that, 20 years later, these principles will change, become more mature.
Readers welfare
Share byte-beating surface finishing resolve questions PDF, classified, step by step, from basic to in-depth, from easy to Jane.
We will sort out the contents into five chapters, basic computer face questions, questions surface data structures and algorithms, Java interview questions, Android interview questions, interview questions other extensions, a total of five non-technical questions section 354.
Each issue is accompanied by a reference standard answer is trial and error digestion (really spent a lot of time), it feels good to write articles as the answer.
Save time we all go to the search, time spent on the right things. .
Also finishing a full set of resume writing, spring recruit confused, HR interview and other issues to resolve reference proposal.
Interview Zhenti resolve & Byte beating PDF templates can resume production ** private letter I [beat] byte ** free access!
Share easy! Like friends do not forget to praise the next point concerns + support!
