Critical mistakes in web development

This article summarizes some key mistakes that PHP programmers often overlook in web development, especially when dealing with medium and large projects. Typical errors include the inability to distinguish between various development environments and the failure to use cache and backup.

The following uses PHP as an example, but its core ideas are applicable to every web programmer.

Application level errors

1. Error reporting is turned off during the development phase

The only thing I want to ask is: why? Why should you turn off error reporting while developing?

PHP has many levels of error reporting, and we must turn them all on during the development phase.

If you think errors will not happen, then you are idealizing the program. In the real world, errors are inevitable. error_reporting and display_error are two completely different methods. error_reporting() sets the level of the error, while display_errors sets whether the error message should be output.

During the development phase, the error reporting level should be set to the highest level, such as the following settings: error_reporting(E_ALL); and ini_set('display_errors', true);

2. Flooding errors

Contrary to the previous point, many programs Members like to drown out mistakes. You know that mistakes will happen, but you choose to hide them, and then you can go home early and sleep, not knowing that more serious mistakes will occur in the future.

3. There are no usage logs anywhere in the code

You must keep the usage log in mind at the beginning of software development, and you cannot make up for the log function until the end of the project. Many programmers will use one method or another to record logs, but few people can actually use logs to record abnormal information. What is the use of a log system that no one checks?

4. No cache is used

In our application system, we can use cache at multiple system levels, such as on the server side, application side and database side. Like logging, caching should be applied to the system from the beginning. You can disable caching during development and enable caching after product release.

5. Abandoning best practices and design patterns

How many people have you seen using their own password encryption algorithms? Sorry to tell you, there are a lot of them because they think they will know better about it.

The best practices and design patterns have been created by predecessors. This is often easier and more effective than reinventing the wheel yourself. We developers only need to be proficient in these design patterns and apply them reasonably in the project. For example, some encryption algorithms.

6. No automated testing is used

Tests are used in every web project, just like logs. If no one manages and uses them, then the tests are useless.

Running a test project is a tedious task. Fortunately, there are a series of tools to help us achieve automated testing. In PHP development, there is a good testing tool called Jenkins, which is very convenient to use.

7. No code review

Working in a team is a very big challenge, because each member has his own different working habits and methods. If there are no good specifications, then project development will take many detours.

Every member of the team should review each other's code, just like unit tests, it can help the project become cleaner and more consistent.

8. Programming only considers ideal situations

Have you ever encountered problems or even chaos in your own or other people’s code after it was handed over to the customer? Of course I didn't.

This situation often occurs because developers are lazy and only consider ideal situations, which can lead to database crashes, PHP fatal errors, or even servers being hacked. When writing code, programmers must not only consider the best case scenario, but also the worst case scenario. Only by thinking comprehensively can the code cover all situations.

9. Failure to correctly apply object-oriented programming ideas

Most PHP beginners will not use object-oriented ideas in their code because this concept is difficult to understand at the beginning.

Of course the concept of object-oriented is not simply to organize some classes together.

Objects, properties, methods, inheritance and encapsulation are the most basic concepts in OOP. After developers correctly use the object-oriented design pattern, they will be able to write cleaner and more scalable code.

10. "On-the-fly" programming

Most developers will encounter this situation: "Quick, the customer needs a new feature that can run ASAP", so you are in the source Add some functions to the code and then upload it directly to the running server. We call this programming method "on-the-fly" programming.

When we develop software, especially medium and large projects, we must follow the workflow for analysis, programming and release, which will greatly reduce future software bugs. This "flight mode" is not advisable.

Errors at the database level

11. Failure to separate database reading and writing

In order to run complex systems for a long time, every programmer should consider the scalability of the system. The system does not need to consider it 99% of the time. Expand because there is not such a large amount of traffic.

Why do we need to separate database reading and writing?

In every system, the database will be the first bottleneck to appear. Under the impact of large traffic, the database is likely to be the first to die. So in most cases we use multiple databases to spread the traffic. Developers often use Master-Slave mode or Master-Master mode. Master-Slave is the most popular database pressure sharing mode. It will route the specified select statement to each Slave server, so the pressure on the Master server will be reduced a lot.

12. The code can only connect to one database

This is very similar to the previous error, but developers sometimes need to connect to multiple databases for some reasons, such as user logs, activity information streams, and real-time data Put high-load data such as analysis into different databases to relieve the pressure on the main database.

13. Failure to detect database vulnerabilities

If you do not detect database vulnerabilities, it is equivalent to opening the server's door to most hackers.

Among the many vulnerabilities, database vulnerabilities are the most vulnerable, and the most common one is SQL injection. Therefore, it is still necessary to conduct database vulnerability detection regularly.

14. Do not create indexes in data tables

Indexes play a very important role in data tables. Appropriate indexes can improve the performance of each table. Here is an article that describes how to create indexes and when to create indexes.

15. No transaction mechanism is used

Data integrity is very important to the web system. If an error occurs in data consistency, the entire system will collapse and be difficult to repair. Proper use of the database transaction mechanism will effectively solve this problem. For example, if you want to save user data, there are e-mail, username and password in table1, and first name, last name, and gender age in table2. We can use transactions to ensure that the data is updated at the same time or not at the same time when updating two tables.

16. No encryption of sensitive data

For sensitive information in the database, if you do not encrypt them, or encrypt them with a simple algorithm, then you will definitely encounter some troublesome problems in 2014. Once hackers invade Your database, user passwords or other important information will be at a glance.

PHP5.5 provides a hash encryption method, the use is as follows:

$hash = password_hash( $password, PASSWORD_BCRYPT );

17. No backup

Did you see the picture below? If you encounter such a situation and you don’t have a backup, everything will be over .

18. Without monitoring

Without monitoring, you will not know what will happen next. Regarding monitoring, you should pay attention to the following questions:

How many people can directly access this application service?

Is the server running under high load?

Do we need to expand the system with another database server?

Where is the failure point of the application system?

Is the system currently offline?