As programmers must pay attention to the TEN programming taboo!

As a programmer, in addition to good skills, but also pay attention to avoid some mistakes in the process of work, we can learn from the mistakes, but also from the predecessors to get some experience, avoid these we will make common sense mistakes, improve their efficiency.

I. Not upgrading non-technical skills
We believe that non-technical skills are a major factor in project success. These non-technical skills can also be referred to as "soft skills", which, in general, have been proven by the company to be able to manage long-term business relationships between companies and customers, and therefore to determine the path of growth and development of the company. Some of the key soft skills indicators include:

A. Discipline-This is one of the most important features, the lack of discipline that ultimately gives the development team a "lack of confidence" in development capabilities. The correct way to solve this problem is to make a detailed list of to-do every day: fulfill your commitments, do what you start to do, and avoid multitasking, as these tend to confuse your life.

B. The voice of the customer – not placing the customer at the core of the decision will only conflict with the original purpose of your business. If the customer is not happy, even if you have the world's first-class expertise and resources will not play any role. The real value of the project can be demonstrated by maintaining a solution that meets customer expectations and timely delivery.

C. Communication-especially when customers and suppliers are not in the same location, clear and timely communication is an excellent measure to fill the gaps in the service. Focus on these three areas and you will be able to overcome the problem--to discuss the topic, to express clearly, to be concise.

D. Understanding requirements--a crucial distinction between success and failure throughout the development life cycle will be impressive. Through the initial brainstorming method to understand the state of the problem, as well as the subsequent delivery procedures, which should be perfect with the customer. Only in this way, the customer will appreciate your work, give you praise.

Second, the code is not rational
The ancients cloud: Good swimming people drowned, good rider fell. But it is estimated that the vast majority of programmers think their programming techniques are absolutely bull. And it is also true that every code that makes it possible for a different programmer to implement it inevitably finds its flaws. So, only through cooperation on a project, the inevitable friction between programmers to prove who is the best. Healthy competition is good, but it should not be a burden on projects that could have been successful.

Another creative impediment is the inability to use pre-defined templates in a development project that is beneficial to you. Almost all programming languages have a good online/built-in code snippet repository that can patch code and prevent reprogramming. However, if you do not understand the requirements or have a lack of access to the various available libraries/templates, this means that the programmer will eventually inadvertently take the code that was created at the outset. This not only increases the development time, but also increases the overall cost. Another point is that the published code has been tested for quality, so it can only be used as a template for greater value.

Three, not necessarily everything must be understood
What if you are a programmer who has just been transferred to this team and is not familiar with the work at hand? It must be to look at some of the work plans left by the predecessor, if he wrote the details are not good, if the writing is not detailed, estimates will make you more scratching your heads.
Therefore, empathy, in the need to explain the work, it is best to write the task as detailed as possible. This is also a very realistic reason: the ability to solve programming problems, it is best to ensure the use of explanatory language and English pronunciation to represent variables. Some basic pointers can make your program easier to understand, including:

A. Make all parameters, references, methods and variable names as close to English as possible. Keep file names short but useful for understanding features.
B. Using + + to wrap text is a good way to make code and annotations clearer.
C. Keep the written program on a continuous process, especially in languages that are based on OOP: C #, C, and C + +.
D. Use a different description name for different blocks of code.

Iv. without the use of proven tools and techniques
The good and bad of the programmer can be seen from the programming tools and debugging tools he uses. In the case of abnormal tracking, the following are common errors that programmers often appear.
Capturing common cases that may have an impact on other code, dealing with these more common exceptions (rather than special exceptions) means inadvertently removing the residue that suppresses the entire program, so it doesn't affect the code of others.
Perhaps the programmer may have malicious intent to catch all the anomalies, but even if it is captured or not implemented, this is often called "false safety valve", which is a way to compromise the stability and security of the entire software.

V. Poor control version
In any project involving multiple teams, it is a complete sin to not introduce the best practices when it comes to versioning. Version control is designed to ensure that edits or revisions performed by one person do not affect the work of another person.
Versioning not only helps merge edits from two or more programmers, but also helps track the program's change history. So, any development team should do something good to ensure a strong version control, which includes:

Create a "logical unit" for each solution
Develop a descriptive name for the solution
Make sure you're using the most advanced files.
Frequently share your changes with the team

Vi. individuals with the latest information cannot represent the team
It is a relatively interesting point that all commercial products want to impress their customers with their own agile technology and product culture, but few in reality take the time to hone their employees ' skills in introducing product features. Many companies simply provide some basic training, and hope and employees learn more skills in real-life projects. Therefore, the department manager and the direct leadership of the project can improve the employee's performance through the following two ways:
Once a new employee joins, he is immediately forced to attend professional training to let him know what his role is for and to create creativity as early as possible. For example, after a test person joins, he should be introduced to the concept of programming, and then focus on the test practice, rather than continue to explain the importance of programming.
The technology at this stage is more evolved than ever, so keep in mind that regular training is essential, which is creating value for the team. For example, a web designer needs to know the responsive design, providing the designer with an expanding sample of mobile devices that are used daily by a large number of users, in the hope that they will get inspiration.

Vii. Inappropriate testing
Testing is an important element of the entire system development lifecycle (systems development life cycle, or SDLC) and usually does not require the development team to give too surprising results. However, this is not justified if the test does not give proper and appropriate effort. Some of the following methods may be useful to your test team, at least when you deliver a product that gives the user a good explanation.
Unit Test
Physical model
Comprehensive testing

Eight, attention to security loopholes
Sometimes in the software development process, you will meet the following security vulnerabilities:

A, the unexpected interaction between different components: A, input incorrect authentication information, b, SQL data hidden code attack, c, cross-site instruction code, d, command implantation attack, E, cross-site request forgery (CSRF);
B, difficult to implement resource management, including: A, do not respect the free memory buffer, B, foreign control, C, the use of potentially dangerous functions;

Ix. Communication with customers
After the initial contract is signed, the development company often forgets to interact with the customer on a daily basis, so that it needs to be upgraded at the time of delivery. Two key points of communication allow you to maintain a better and longer relationship with your customers:
Before the customer asks, the developer should communicate with the customer.
Maintain periodic communication with customers.

X. Avoiding the imminent deadline for standard practice
Typically, projects are experiencing delays in progress. However, this is not to say that you have reason to cut corners or play tricks in the development or testing phase, untested modules are definitely a hidden danger that will damage your development team's reputation. A better way to manage latency is to inform customers in advance and actively implement deferred plans. As long as the reason for the extension is valid, the customer should understand and will give you extra time to solve the problem.
Obviously, in the project deadline, the quality of the rush to complete the programming is certainly not a special insurance, so after the delivery of the development team overall will spend more time and effort to track maintenance, the cost is also very large, the best way to create a perfect execution plan at the outset. The resources spent on project reengineering may be several times the cost of the project itself, and any company would prefer to spend more time on initial development so that the final product will meet the SDLC standards and have sufficient voice on defects and bad issues. For customers, timeliness can not be at the expense of quality, never.

As programmers must pay attention to the TEN programming taboo!