Developing robust code-series articles in PHP is about solving real-world problems in medium-to-large applications. This series of articles focuses on the new features available in PHP 4, highlighting a number of tips and tricks to make development work easier. In this series of articles, you'll find many examples and techniques to learn, along with a lot of sample code. In this first article, PHP Master Amol Hatwar from a higher point of view on how to design and write error-free, maintainable code for medium to large WEB applications. If you are a developer building a WEB application and need speed, functionality, and platform Independence (platform-independence), PHP will work for you. And PHP is free, easy to learn and deploy. These are the biggest benefits of making PHP so popular. But these advantages can also become shortcomings. Because PHP is easy to use, developers often try to plug the code into the editor when they should be planning and designing. Moreover, in PHP, there are more than one way to solve the problem, it is easy to make that kind of painful mistake, it is difficult to revise after this mistake. In this series of articles, you will learn how to avoid many errors. Don't be surprised if you don't fall down and stick to the end, and you'll find yourself trying to write code without errors one or two times. I'll also point out the new features available in PHP 4, which make development work easier. Most of the examples I want to cover are practical issues such as script configuration and installation, file handling, and database usage. Even if you are unfamiliar with all this, you will find it easy to understand. However, I assume you have a preliminary understanding of PHP. If you need to review it, you will find the resources listed at the end of this article helpful. (See Resources.) Laying a robust foundation for writing code in PHP is very similar to writing code in C-like languages. Because they are syntactically similar, they can also cause similar code maintenance problems. When you have to develop large applications, you may want to write a lot of code. As time goes by, the code may become unmanageable, and errors will quickly take its turn. No matter where you hear this statement, don't believe it-at least not all. However, the more important fact is that if you find yourself maintaining code too frequently, the design of your application may be very bad first. Designing your code correctly the choices you make initially affect the degree of freedom you will have when you write your code later. This makes the right design an important prerequisite. While the design becomes an extra ritual when you solve a trivial problem, you must at least know that it is the right thing to do. Many people think of design and planning as extra overhead. But starting with a bad design or not having a design at all, the result is always sloppy code. Keep in mind that the smart codingNor can it make up for bad design. While designing your application is beyond the scope of this series of articles, I will also suggest some questions to keep in mind when designing a WEB application. Partitioning and conquest is always preferable by designing and writing large applications with smaller, loosely coupled parts. In this way, each part is maintainable. For example, a content Management system,cms may be distributed across a number of smaller modules such as user authentication, display, content resolution, and view statistics. And, if your module is generic enough, you can reuse the code in other applications that you develop. Programmers often do this, but they still complain. The trick with coding is to have each module have the functionality it absolutely needs and end it. Give a module a lot of functionality, just right. Never think about the page if you are interested in using PHP to make your HTML page more dynamic, this section will work for you. When you want to display the date and time on each page so that it looks up to date, it's usually the beginning of the habit. Each HTML page becomes a small PHP script with a limited number of lines, and the date function is hidden somewhere. If this is what you want, you must recognize that this is the simplest way to make the job implementation. However, imagine what changes you have to make to change the date format that is rendered on the page. You will have to change the code within each page. Obviously, there is a better way to achieve this goal. My favorite way is to use a configuration file and define a constant in the configuration file, which retains the format string of the date () function. You can then use the date () function where you want it. Each page still ends with a script, but you have to thoroughly minimize the places where you have to make changes to a single line of code. Figure 1. Avoid hard coding as shown, you can see changes in the date format on all pages. The idea here is to avoid duplicating code and hard coding. Keep this in mind when writing large applications. Debugging and maintenance becomes easier when you avoid copying code. Reducing client-side requirements The types of WEB pages and applications have evolved in many directions. The first is image and image mapping, followed by Java applets and client-side scripts that implement cool animations. Now it's Flash. It's good to have an impact, but you have to remember that the whole idea behind the Web is to make it accessible to anyone who needs information at any time. If you use technologies that are not supported by all browsers and platforms, people will be denied access to your information. You never know if anyone who doesn't have access to your WEB site could have been your next customer! Your application design should minimize network traffic as much as possible. We often see a lot of Web site traffic is too much and only to the browserA class of cookies that can only be run. Tampering with a large number of cookies not only consumes bandwidth, but also makes it difficult to manage in many ways. Based on experience, if your application sends more than a full KB of data or if your page takes more than 5 seconds to load, it's time to design the application from scratch. Small adjustments everywhere will not last too long. If you look around, you'll find that the most popular and most visited sites are very simple. You should also consider the next wave of mobile devices and the connections they use to access your application. As a best practice, your application must adjust the content based on the client that requested the content. "We can try to keep the size of the HTML document small and we can try to avoid complex HTML such as nested tables (nested table)," says Leon Atkinson, on page No. 720 of his Core phpprogramming, but I We cannot upgrade each of our 28.8 modems. "Separating the code, content, and display is the markup language for displaying content, and PHP is the scripting language for embedding HTML." This does make simple tasks easier-for example, with dates. However, when you want to implement complex requirements, embed PHP into HTML so that the simplicity of the code is lost. It's good to separate the code, the content, and the display as much as possible. Consider the document that you are reading. This document is started to be created as an XML file. HTML and PDF versions are automatically generated using style sheets. The code (the application that displays the page to you), the content (XML document), and the display (style sheet) are different. Just as it is important to encapsulate core functionality in modules and to avoid code duplication, it is also important to display content in separate content source code and in the way required. You've also increased the flexibility of customizing pages based on client and connection speed. It also allows programmers, designers, and authors to work independently-if you're working on a large project, that's a good thing. Don't be afraid to abandon design no matter what others tell you, practice is the best way to learn application design. If you're just starting out, you may make a lot of mistakes-that's the way to learn. Bad design should be abandoned. That's why you have to keep your code, content, and display loosely coupled-discarding bad design as a means of alleviating pain. When you discard stale code and replace it with better code, you can keep the content and display. Now, go back to the question I promised to make your code strong. You must always keep in mind that your code will provide the power for other people's content and display. If your code is not up to the task, no other department can make up for this flaw with more amazing effort. Writing robust code assumes that your code requirements are unchanged,You will not obviously find the need to change the code. In addition to the occasional need for optimization and improvement, your code should run like a lubricating machine. It sounds difficult? That is not the case. Frankly speaking, writing robust code does not require genius. You just need to ask yourself some proper questions when you're unsure, so you don't get off the rails: Is it safe? Is it simple and easy to understand? Is it platform-independent? Is it fast enough? Protect your code any system that satisfies a large number of users must be secure. Although PHP itself is not easily attacked by Black hat (black-hat) hackers, you should not be too sure. PHP 4 before version 4.2.2 has a serious security flaw. Always ensure that sensitive data is stored or transmitted on appropriately encrypted networks. This is more important for applications that process business, store information such as credit card numbers, and transfer confidential data. It is now difficult to trust user-submitted data. Make sure the data is validated and that the data is clean before it is used. Keep in mind that putting your WEB application on the Internet is about publishing your systems, software, data, and business to a huge network. Make sure your code is running safely. Keep your code simple your code should be easy to understand, readable, and well documented. To reduce the time you need to be familiar with your own or someone else's code, use common naming and coding conventions throughout your project. Please invest time to ensure that these aspects are rewarded when you need to maintain your code. You might want to create a document for your code when you are programming. Tools that can parse all of your scripts and create seemingly neat HTML-formatted documents do not exist. If you change the behavior of the code, you need to change the document accordingly. If the code's document does not actually record anything, it is useless to have such a document. Make sure your code is documented, simple, and easy to understand. This will help in the long run. Another issue you must address to make your code platform-Independent is platform independence. Of course, scripts written for PHP on Windows will work for PHP on any other platform: this is how PHP is designed. However, you still need to be careful to compare small inconsistencies. For example, the newline characters are represented in different ways in Windows and UNIX. You must also use extraction when accessing resources, such as a database that is outside PHP. Let's say your application uses MySQL as a database server to cut costs. If you decide to have a richer database later, you must change the code in your application. Making significant changes to your code is always a chore and an error-prone process. Use extraction to isolate changes to parts that are easy to change. You do not have to rewrite the entire application. Make sure that you are writing platform-independent code. This makes your application more adaptable and scalable. The last factor that is worth processing for speed is speed. When your script drags around 300 entries from the database and displays a page, no one wants to keep waiting. It is usually a good idea to put 20 results on 15 different pages, which are quickly moved and mounted on the user's browser. The user understands the faster response time as speed. Another easy mistake is to create pages dynamically every time a user accesses a page. This does ensure that your site is always up to date, but when the number of users increases, PHP is not allowed to do so. You should cache those pages that are used frequently. Caching makes your application faster and reduces the load on the server. Ensure that your generation
http://www.bkjia.com/PHPjc/531720.html www.bkjia.com true http://www.bkjia.com/PHPjc/531720.html techarticle developing robust Code-series articles in PHP is about solving real-world problems in medium-to-large applications. This series of articles focuses primarily on the new features available in PHP 4, highlighting the big ...
