Over the past years I had the opportunity to work on some interesting projects, complex in nature with an ongoing development, constantly upgrading, refactoring and adding new features to them.

在过去的几年中，我有机会从事一些有趣的项目，这些项目本质上是复杂的，并且不断开发，不断升级，重构并向其中添加新功能。

This article will cover the biggest coding oversights most PHP developers make, when dealing with medium and large projects. Oversights such as not differentiating between development environments or not implementing caching and backup.

本文将介绍大多数PHP开发人员在处理大中型项目时所做的最大编码监督。 诸如不区分开发环境或不实施缓存和备份之类的监督。

The examples below are in PHP, but the idea behind each problem is generic.

下面的示例在PHP中，但是每个问题背后的想法都是通用的。

The root of these problems lies mainly in developers’ knowledge and experience, especially the lack of it. I’m not trying to bash anybody, I do not consider myself the perfect developer who knows everything, so bear with me.

这些问题的根源主要在于开发人员的知识和经验，尤其是缺乏知识和经验。 我并不是要抨击任何人，我也不认为自己是了解所有事情的完美开发者，所以请耐心等待。

In my experience we could categorize these problems in three main groups: design level, application level and database level oversights. We’ll break down each one separately.

以我的经验，我们可以将这些问题分为三个主要类别：设计级别，应用程序级别和数据库级别的监督。 我们将分别分解每个。

应用程序级别监督 (Application Level Oversights)

开发时报告错误 (Developing with error reporting off)

The only question I can ask is: why? Why do you not turn error reporting on when developing an application?

我唯一要问的问题是：为什么？ 为什么在开发应用程序时不打开错误报告？

PHP has many levels of error reporting, and it ALL should be turned on in the development phase.

PHP具有许多错误报告级别，并且应在开发阶段将其全部打开。

If you think errors will never occur, you are coding for the ideal scenario, which only happens in an ideal world.

如果您认为错误永远不会发生，那么您就是在为理想的情况编写代码，而这种情况只会在理想的情况下发生。

Error reporting and displaying those errors are not the same either. error_reporting() sets the level of errors (e.g. notice, warnings, fatal errors) and display_errors controls whether these errors will be outputted or not.

错误报告和显示这些错误也不相同。 error_reporting()设置错误级别(例如，通知，警告，致命错误)，而display_errors控制是否输出这些错误。

Error reporting should always be at the highest setting in development: error_reporting(E_ALL); and ini_set('display_errors', true);

错误报告应始终处于开发中的最高设置： error_reporting(E_ALL); 和ini_set('display_errors', true);

Note: E_ALL is the highest since PHP 5.4+, because E_STRICT errors became part of E_ALL in PHP 5.4. If you use an older PHP version than 5.4 use error_reporting(E_ALL | E_STRICT); to include strict error warnings too.

注意：由于PHP 5.4中E_STRICT错误已成为E_ALL的一部分，因此E_ALL是自PHP 5.4+以来的最高水平。 如果您使用PHP版本低于5.4，请使用error_reporting(E_ALL | E_STRICT); 也包括严格的错误警告。

抑制错误 (Suppressing errors)

Suppressing errors using the @ operator is even worse than not turning it on at all, because you’re consciously sweeping dirt under the carpet. You know the error is happening, you just want to hide it, close the task and go home early. What you don’t realize is that building something on a shaky foundation will have much bigger consequences later on.

使用@运算符抑制错误甚至比根本不打开错误更糟糕 ，因为您有意识地将地毯下的污垢清除了。 您知道错误正在发生，您只想隐藏它，关闭任务并提早回家。 您没有意识到的是，在摇摇欲坠的基础上构建某些东西以后会产生更大的后果。

You can read an in-depth explanation on this here.

您可以在此处阅读有关此内容的详细说明。

无需在代码中的任何地方记录日志 (No logging anywhere in the code)

Developing a project has to happen with logging in mind from the start. You can’t just bolt on logging at the end.

开发项目必须从一开始就考虑登录。 您不能只在结尾处添加日志。

Most of the developers do use logging one way or another, but almost none of them take the time to actually verify those logs for errors. What’s the point of logging if nobody looks at the logs?

大多数开发人员确实以一种或另一种方式使用日志记录，但是几乎没有开发人员花时间来真正验证那些日志中的错误。 如果没有人看日志，日志的目的是什么？

PSR recommendations do exist for logging, PSR-3 to be exact, and this excellent article explains how to implement PSR-3 logging.

确实存在用于日志记录的PSR建议，确切地说是PSR-3 ，这篇出色的文章介绍了如何实现PSR-3日志记录。

没有实现缓存 (Not implementing caching)

Caching can be done in many different ways on multiple levels in an application, such as on a server level, application level, database level, etc.

可以在应用程序的多个级别上(例如在服务器级别，应用程序级别，数据库级别等)以多种不同方式完成缓存。

Caching, too, should be implemented from the start. You can always disable it in development, but make sure everything works once it’s pushed to a production environment.

缓存也应该从一开始就实现。 您始终可以在开发中禁用它，但是确保将其推送到生产环境后一切正常。

On a server level you can use Varnish, which is a reverse HTTP proxy, it stores files in memory and it should be installed in front of the web server.

在服务器级别上，您可以使用Varnish (这是反向HTTP代理)，它将文件存储在内存中，并且应将其安装在Web服务器的前面。

To speed up PHP, you can install/enable an opcode cache, which optimizes the compilation into byte code of PHP scripts. For PHP 5.5 and later an opcode cache is already compiled in the core called OpCache.

为了加快PHP的运行速度，您可以安装/启用操作码缓存，以优化将PHP脚本编译为字节码的过程。 对于PHP 5.5和更高版本，已经在名为OpCache的内核中编译了操作码缓存。

You can read about it in-depth in this article: SitePoint PHP – Undestanding OpCache.

您可以在本文中深入了解它： SitePoint PHP – Undestanding OpCache 。

Before PHP 5.5, you could use APC, which has user cache functionality too.

在PHP 5.5之前，您可以使用APC ，它也具有用户缓存功能。

On an application level, you can use APCu which is the user cache extracted from APC, Yet Another Cache which has similar functionality as APCu, or Memcached which is a distributed caching system and it has solid PHP support. Memcached can also be used to cache database queries.

在应用程序级别上，您可以使用APCu(这是从APC中提取的用户缓存)，Third Another Cache(其功能与APCu类似)或Memcached(它是一种分布式缓存系统，并且具有可靠的PHP支持) 。 Memcached也可以用于缓存数据库查询。

There are a couple of techniques when implementing caching in an application. A good practice is to cache data which doesn’t change very often, but is queried repeatedly.

在应用程序中实现缓存时，有两种技术。 一个好的做法是缓存不经常更改但会反复查询的数据。

Cache database queries heavily, because the database is always the biggest bottleneck in every PHP application.

高速缓存数据库查询量很大，因为数据库始终是每个PHP应用程序中的最大瓶颈。

忽略最佳做法和设计模式 (Disregarding best practices and design patterns)

How many times did you see someone implement his own password encryption algorithm? Sadly, this still happens today, because the lack of knowledge or more dangerously, because of an “I know it better” attitude.

您看到某人实施了自己的密码加密算法多少次？ 可悲的是，由于缺乏知识或更危险，因为“我知道得更多”的态度，这种情况在今天仍然会发生。

Well, I hate to bring you the bad news, but 99% of the time you don’t know it better.

好吧，我不希望给您带来坏消息，但是99％的时间您对它并不了解。

These best practices and design patterns were thought of and created for a reason by software engineers way smarter than you and me, the developer’s sole job is to pick the right pattern for the job.

这些最佳实践和设计模式是软件工程师想到的，并且是出于某种原因而创建的，原因是软件工程师比您和我都聪明，开发人员的唯一工作就是为工作选择正确的模式。

There are many books and resources on this subject. I’ll mention two:

关于此主题有很多书籍和资源。 我会提到两个：

1. Patterns of Enterprise Application Architecture by Martin Fowler

   Martin Fowler 的企业应用程序架构模式

2. PHP Objects, Patterns, and Practice by Matt Zandstra

   Matt Zandstra撰写的PHP对象，模式和实践

不使用自动化测试 (Not using automated tests)

Tests should be added for every feature of the web application, but tests are good for nothing, just like logs, if nobody is looking at them and actually running the test code to see if something breaks.

应该为Web应用程序的每个功能添加测试，但是如果没有人看着它们并实际运行测试代码以查看是否出现问题，那么就像日志一样，测试毫无用处。

Running tests manually is a tiresome process. Fortunately, there “is an app tool for that”. In fact, there are lots of tools that can help automate your tests, a whole practice called Continuous Integration.

手动运行测试是一个烦人的过程。 幸运的是，“ 应用程式 工具”。 实际上，有很多工具可以帮助您自动化测试，这称为“ 持续集成” 。

One such tool that widely used in the PHP community is called Jenkins, which is a CI server and can do a lot more than just test an application. Sebastian Bergmann created an excellent template for Jenkins specifically constructed to work with PHP projects.

Jenkins是在PHP社区中广泛使用的此类工具之一，它是CI服务器，除了测试应用程序外，还可以做很多其他事情。 塞巴斯蒂安·伯格曼(Sebastian Bergmann) 为詹金斯(Jenkins)创建了一个出色的模板，专门为与PHP项目一起使用而构建。

If you find this too overwhelming, then at least write unit tests for your application using PHPUnit, Behat or PHPSpec. It may seem a lot of work at first, but it’s proven countless times that tests are helping projects in the long run.

如果你觉得这太强烈，那么至少写单元测试使用应用程序PHPUnit ， 贝哈特或PHPSpec 。 乍一看似乎有很多工作要做，但是从长远来看，无数次测试证明对项目有帮助。

不审核/审核代码 (Not reviewing / auditing code)

Working in a team can be challenging, especially if every team member is used to different styles of programming, and without good specification a project can go sideways real fast.

在团队中工作可能具有挑战性，特别是如果每​​个团队成员都习惯于不同的编程风格，并且没有良好的规范，则项目可能会很快就无法实现。

If you’re in a team and not inspecting each others’ code, you should really do it. Just like unit tests, it helps a project stay clean and consistent.

如果您在团队中而不检查彼此的代码，则应该真正做到这一点。 就像单元测试一样，它可以帮助项目保持整洁和一致。

The difference between review and audit is the time when you inspect the code. Review usually happens before any code is merged to the code base and audit after the code is merged in.

审核与审核之间的区别在于您检查代码的时间。 审核通常在将任何代码合并到代码库之前进行，并在合并代码之后进行审核。

Review is a much much better thing to do, because you have the opportunity to talk about the code, suggest improvements or fixes before it gets merged with the other team members’ code.

复审是一件好得多的事情，因为在将其与其他团队成员的代码合并之前，您有机会谈论代码，提出改进或修正建议。

The disadvantage of reviews is that it’s blocking development, because before every merge (after all tests are green) at least two developers need to discuss the code, and this is where audit comes into play.

审查的缺点是，它阻碍了开发，因为在每次合并之前(所有测试都变成绿色之后)，至少有两个开发人员需要讨论代码，而这正是审核工作的地方。

Audit happens post merge, and it’s non-blocking, but it’s significantly less powerful, because it misses the opportunity of catching bugs early on.

审核是在合并后进行的，并且它是非阻塞的，但是功能却很不强大，因为它错过了尽早发现bug的机会。

Audit is still better than not inspecting code at all.

审计总比根本不检查代码要好。

To help this process go as smooth as possible, you can use the tool called Phabricator, which was created specifically for this purpose by the good engineers at Facebook. It supports both code inspection strategies.

为了使此过程尽可能顺利，您可以使用称为Phabricator的工具，该工具是专为Facebook的优秀工程师而创建的。 它支持两种代码检查策略。

理想情况下的编码 (Coding for the ideal scenario)

Ever find yourself in or heard about cases where some insignificant, boilerplate code was merged in and all hell broke loose? I sure did.

是否曾经发现自己或听说过一些微不足道的样板代码被合并而整个地狱都崩溃了？ 我确定

Most of the time this happens because developers are lazy and write code for the ideal scenario, where database fails, PHP fatal errors and server hacking are non-existent.

大多数情况下，发生这种情况是因为开发人员很懒惰，并且不为理想的情况编写代码，在这种情况下，数据库故障，PHP致命错误和服务器黑客攻击都不存在。

Code should be written with the exact opposite scenario in mind, developers should write code for the worst possible scenario that they can think of, and even then the code won’t cover some obscure corner case where the user types in a $ sign and has instant full administrator access.

在编写代码时，应牢记与之完全相反的情况，开发人员应为他们可能想到的最糟糕的情况编写代码，即使这样，该代码也不会涵盖用户输入$符号并带有即时的完全管理员访问权限。

Assuming that your server won’t be hacked or your code won’t break at some point and your database will always be up and running is just wrong. Production code should cover these scenarios and log errors accordingly.

假设您的服务器不会被黑客入侵或代码不会在某一时刻中断并且您的数据库将始终处于运行状态，这是错误的。 生产代码应涵盖这些情况并相应地记录错误。

In PHP, it is so easy to commit errors without even realizing it. This is mainly because of poor language design decisions that were made in the past and not corrected in time.

在PHP中，即使没有意识到也很容易提交错误。 这主要是由于过去做出的糟糕的语言设计决策没有及时纠正。

PHP wants to make it easy for developers not to think about security, encodings and corner cases, where in fact developers should be very aware of this and always practice defensive programming.

PHP希望使开发人员可以轻松考虑安全性，编码和极端情况，实际上，开发人员应该非常了解这一点，并始终练习防御性编程。

没有正确使用OOP原则 (Not using OOP principles correctly)

Most PHP developers new to PHP are not using object oriented programming in their code, because the concept is a little bit hard to grasp at first. OOP was first used in the 1960s and constantly refined over the years, there is a ton of information about it on the Web.

大多数不熟悉PHPPHP开发人员都不会在代码中使用面向对象的编程，因为起初这个概念有点难以理解。 OOP于1960年代首次使用，并在随后的几年中不断完善，Web上有大量有关它的信息。

Also, OOP is a lot more than just procedural code organized in classes.

而且，OOP不仅仅是在类中组织的过程代码。

The concept of objects, properties, methods, inheritance, encapsulation, etc. are all an integral part of OOP.

对象，属性，方法，继承，封装等的概念都是OOP不可或缺的一部分。

A developer who uses these principles correctly knows about OO design patterns, SOLID principles (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion) and how to write clean code in general, code that is flexible, doesn’t have hard coded dependencies and is easy to extend and build upon.

正确使用这些原则的开发人员会了解OO设计模式， SOLID原则 (单一职责，开放式封闭，Liskov替换，接口隔离和依赖反转)以及如何编写一般的干净代码，灵活，没有代码硬编码的依赖项，易于扩展和构建。

Alejandro Gervasio covers these principles from top to bottom.

Alejandro Gervasio从上到下涵盖了这些原则。

It’s never too late to learn about OOP and start writing clean code which doesn’t rely on hard dependencies (looking at you, PHP frameworks).

学习OOP并开始编写不依赖于硬依赖关系的简洁代码(现在看来，PHP框架)永远不会太晚。

“即时”编码 (“On-the-fly” coding)

What most developers do when they get yelled at “Quick, the client needs this feature up and running ASAP.”, is to hack some code together and push it directly to the live server. This is called on-the-fly coding or cowboy coding.

大多数开发人员在大喊“快速，客户端需要此功能并尽快运行”时会做什么。 ，是一起破解一些代码，并直接将其推到直播服务器。 这被称为即时编码或牛仔编码 。

As in every other industry, in software development too, workflows and sane processes should be implemented in order for a project to succeed.

与其他所有行业一样，在软件开发中，也应实施工作流和合理的流程，以使项目成功。

PHP and dynamic languages in general encourage rapid changes to the codebase, seeing the results of the modification instantly, but these changes should be limited in a production environment.

通常，PHP和动态语言鼓励对代码库进行快速更改，并立即看到修改的结果，但是这些更改应在生产环境中加以限制。

Only critical bugs should be committed and pushed directly to the production server. For the rest, a workflow should be implemented such as Github’s fork and pull request, or Gitflow. More on workflows using Git can be found here: https://www.atlassian.com/git/workflows.

仅应提交严重的错误并将其直接推送到生产服务器。 对于其余部分，应实现工作流，例如Github的fork和pull请求或Gitflow。 有关使用Git的工作流的更多信息，请参见： https : //www.atlassian.com/git/workflows 。

Managers and clients who think these processes are unnecessary should be educated to see otherwise. I’ve never once met a client who couldn’t wait a couple of hours or a day for a little feature to go through the necessary steps in order to be deployed live.

认为不需要这些过程的管理人员和客户应该接受教育，以其他方式查看。 我从来没有见过一个客户，他迫不及待要花几个小时或一天的时间来完成一项小功能，以便通过必要的步骤进行实时部署。

One other thing to note, don’t confuse Continuous Delivery with cowboy coding and chaotic management. Continous delivery is exactly about implementing and optimizing the development workflow so code can be deployed to the production environment as soon as reasonably possible.

要注意的另一件事是，不要将“ 持续交付”与牛仔编码和混乱的管理混为一谈。 连续交付正是关于实现和优化开发工作流程的，因此可以将代码尽快合理地部署到生产环境中。

数据库级监督 (Database Level Oversights)

不能区分读/写查询 (Not differentiating between read / write queries)

To support a long running complex project, scaling needs to be in the back of every developer’s mind. 99% of the time a web application doesn’t need to scale, because it won’t reach that kind of traffic.

为了支持一个长期运行的复杂项目，扩展需要掌握在每个开发人员的脑海中。 Web应用程序99％的时间不需要扩展，因为它不会达到这种流量。

If you know for sure that the web application will be used by many, such as an enterprise application used by hundreds of employees internally in the company, you can make the necessary steps to enable easier scaling for the project.

如果您确定该Web应用程序将被许多人使用，例如公司内部数百名员工使用的企业应用程序，则可以采取必要的步骤来简化项目的扩展。

So why separate read / write queries?

那么为什么要分开读/写查询呢？

The database is always the first bottleneck in every application. It will be the first one to fail under huge traffic. To offload traffic to multiple database servers, developers use either Master – Slave or Master – Master replication. Master – Slave is the more popular one, which says that every SELECT statement needs to be routed to the Slave database server(s), and other ones to the Master in order to balance traffic.

数据库始终是每个应用程序中的第一个瓶颈。 这将是第一个在大流量下失败的人。 为了将流量卸载到多个数据库服务器，开发人员可以使用Master – Slave或Master – Master复制。 主服务器-从服务器是比较流行的服务器，它表示每个SELECT语句都需要路由到从数据库服务器，其他路由到主服务器，以平衡流量。

If your application doesn’t know the separation between read and write queries it won’t know to which database server to connect.

如果您的应用程序不知道读写查询之间的分隔，它将不知道连接到哪个数据库服务器。

Keep this in mind if you know that eventually you will need to setup a Master – Slave replication scheme.

如果您知道最终需要设置主从复制方案，请记住这一点。

仅编码一个数据库连接 (Only coding for one database connection)

This strongly relates to the above oversight, but sometimes developers can have other reasons to connect to multiple databases. For example, if you keep user logs, activity streams, analytics or other data where you know the read/write operations happen often, it’s good to offload this traffic to a different database server.

这与上述监督密切相关，但有时开发人员可能有其他原因连接到多个数据库。 例如，如果将用户日志，活动流，分析或其他数据保存在您知道读/写操作经常发生的地方，那么最好将此流量转移到其他数据库服务器上。

Make sure you use a database library which allows you to connect to multiple database servers and it’s easy to switch between them. A good solution is to implement PDO and use Aura.SQL which extends PDO.

确保使用数据库库，该数据库库允许您连接到多个数据库服务器，并且很容易在它们之间进行切换。 一个好的解决方案是实现PDO并使用扩展PDO的Aura.SQL 。

不测试漏洞利用查询 (Not testing queries for exploits)

This oversight relates to the “coding for the ideal scenario” oversight above. Same thing, different platform.

该疏忽与上述“理想情况下的编码”疏忽有关。 同一件事，不同的平台。

If you don’t test your database (and your application) for exploits, some hacker will, and he may succeed.

如果您不测试数据库(和您的应用程序)是否存在漏洞，那么某些黑客将会，并且他可能会成功。

Databases are vulnerable to a whole range of exploits, the most common is SQL injection attacks.

数据库容易受到各种各样的攻击，最常见的是SQL注入攻击。

Use this cheat sheet and run the queries through your application’s database access library. Write these statements in fields on your front-end like username, password fields on a sign up page.

使用该备忘单，并通过应用程序的数据库访问库运行查询。 将这些语句写在您前端的字段中，例如注册页面上的用户名，密码字段。

If none of the queries go through, you can buy yourself a beer and celebrate.

如果没有任何疑问，您可以为自己买啤酒并庆祝。

不向表添加索引 (Not adding indexes to tables)

Indexes are like the TOC of a table, it’s a performance boost and should be added to every table, to the columns on which the query is performed (e.g. the columns after the WHERE clause).

索引就像表的TOC一样，它可以提高性能，应该将其添加到每个表，执行查询的列(例如WHERE子句之后的列)中。

There’s a whole theory behind database indexes, when to create it, on which columns and what to cover. A whole separate article series was written about that.

数据库索引背后有一个完整的理论，何时创建它，涉及哪些列以及涵盖哪些内容。 关于此的整个单独的系列文章被写成 。

不使用交易 (Not using transactions)

Data integrity is very important for web applications. Whole websites could break if data is handled incorrectly.

数据完整性对于Web应用程序非常重要。 如果数据处理不当，整个网站可能会崩溃。

You use transactions for related data that is handled together, either persisted or deleted together.

您将事务用于一起处理的相关数据，这些数据一起保存或删除。

For example, you save data about a user such as: e-mail, username password in table 1, and profile data like first name, last name, gender age, etc. in table 2.

例如，您在表1中保存有关用户的数据，例如：电子邮件，用户名密码，在表2中保存个人资料数据，例如名字，姓氏，性别年龄等。

Now if a user wants to delete his account, this should be one operation regarding running the SQL query, using transactions. If you don’t use transactions, you risk loosing data integrity, because the operations on the data are running separately.

现在，如果用户要删除其帐户，这应该是与使用事务运行SQL查询有关的一项操作。 如果不使用事务，则可能会失去数据完整性，因为对数据的操作是单独运行的。

If deleting the data from table 1 succeeds, but fails on table 2, the profile data for the user will remain in the database and worse it won’t be connected to anything, it will be orphaned.

如果从表1删除数据成功但在表2上失败，则该用户的概要文件数据将保留在数据库中，并且更糟的是它不会连接到任何东西，它将被孤立。

By using transactions this won’t happen, because the whole operation will succeed only if all the separate operations (e.g. deleting data from table 1 and table 2) in the transaction succeed, otherwise the database will roll back to the previous state.

通过使用事务，这不会发生，因为只有当事务中所有单独的操作(例如，从表1和表2删除数据)都成功时，整个操作才会成功，否则数据库将回滚到先前的状态。

不保护敏感数据 (Not securing sensitive data)

Storing passwords in plain text, or rolling your own encryption algorithm in 2014 is unacceptable. The PHP community has matured enough to know better by now.

在2014年以纯文本格式存储密码或使用自己的加密算法是不可接受的。 PHP社区已经足够成熟，可以了解更多信息。

Still, there are, probably, thousands of databases out there where sensitive data is stored unencrypted begging to be stolen by hackers.

仍然可能有成千上万的数据库存储敏感数据，而这些数据未经加密就被黑客窃取。

PHP 5.5 has already added strong hashing functions just for this, simply calling it Password Hashing. It’s really simple to use – you create a hash from the plain text password with this method:

PHP 5.5已经为此添加了强大的哈希函数，只需将其称为Password Hashing即可 。 使用起来真的很简单–您可以使用以下方法从纯文本密码创建哈希：

$hash = password_hash( $password, PASSWORD_BCRYPT );

Note: There’s no need to salt this password, because it is already handled for you.

注意：无需添加密码，因为它已经为您处理。

Store $hash in the database, then you verify the hash with this method:

将$hash存储在数据库中，然后使用以下方法验证哈希：

if ( password_verify( $password, $hash ) ) { ... }

Note: If you don’t have PHP 5.5 (you really should by now), you can use the password_compat library, which implements the exact same methods.

注意：如果您还没有PHP 5.5(现在确实应该如此)，则可以使用password_compat库，该库实现了完全相同的方法。

Handling financial data is much trickier, because you need to have PCI compliance on server, application and database levels. A more in-depth article is already written on the subject here: SitePoint PHP – PCI Compliance and the PHP Developer.

处理财务数据非常棘手，因为您需要在服务器，应用程序和数据库级别上具有PCI合规性。 此处已经对此主题进行了更深入的介绍： SitePoint PHP – PCI合规性和PHP Developer 。

应用程序设计监督 (Application Design Oversights)

区分开发环境 (Not differentiating between development environments)

I saw many developers and even small teams setting up poor development environments for themselves.

我看到许多开发人员甚至小型团队都为自己设置了糟糕的开发环境。

For example, working on a new feature or fixing a bug and FTPing the files directly on the live website. This is wrong on so many levels.

例如，使用新功能或修复错误，然后直接在实时网站上通过FTP发送文件。 在很多层面上这都是错误的。

There is an infinite number of workflows that teams can create, but the classical one for web development is to use at least three environments: development, staging and production.

团队可以创建无限数量的工作流，但是用于Web开发的经典工作流是至少使用三种环境：开发，登台和生产。

A development environment can be local for each programmer, staging and production are usually remote and share some parts between them. Development is for coding, staging is for testing and finally production is for consumption.

开发环境对于每个程序员而言可以是本地的，暂存和生产通常是远程的，并且在它们之间共享某些部分。 开发用于编码，暂存用于测试，最终生产用于消耗。

The oversight happens when these environments are not set up the same way. For example each developer running a different version of PHP, or staging configuration differs from production.

如果这些环境的设置方式不同，则会发生监督。 例如，每个运行不同版本PHP或暂存配置的开发人员都与产品不同。

Guess what happens? You’re right. Everything will be working in development and even in staging, and when you push it to the production server all hell breaks loose resulting in long nights and lots of caffeine.

猜猜会发生什么？ 你是对的。 一切都会在开发中，甚至在登台时都可以正常工作，当您将其推送到生产服务器时，一切都会变得松散，从而导致漫长的夜晚和大量的咖啡因。

No wonder the most common phrase in development circles is: “It works for me.”

难怪开发界中最常见的短语是： “它对我有用。”

So what’s the solution? Make sure everything is set up the same way in EVERY environment. The operating system should be the same, PHP, database, web server, all should have the same version across the environments.

那么解决方案是什么？ 确保在每个环境中都以相同的方式设置所有内容。 操作系统应该是相同的，PHP，数据库，Web服务器，并且在整个环境中都应具有相同的版本。

Since the creation of Vagrant, Docker and VirtualBox it is very easy now to create identical environments with the same exact configuration on each one. If you haven’t used these tools before, you should stop whatever you’re doing and start using them immediately.

自从创建Vagrant ， Docker和VirtualBox以来，现在很容易在每个环境上创建具有相同精确配置的相同环境。 如果您以前从未使用过这些工具，则应该停止所有操作并立即开始使用它们。

没有备份 (No backup)

Everything is going well, the website is live, launched on time, everything is up and running, users consume the beautiful data. Nom, nom, nom… Until you receive an e-mail at 3AM.

一切进展顺利，网站正常运行，按时启动，一切正常运行，用户使用了漂亮的数据。 Nom，nom，nom…直到您在3AM收到一封电子邮件。

Backup, just like logging, caching, security and defensive programming should be an integral part when developing a web application, but most developers (or sysadmins) forget to do this.

备份，就像日志记录，缓存，安全性和防御性编程一样，在开发Web应用程序时应该是不可或缺的一部分，但是大多数开发人员(或系统管理员)却忘记了这样做。

Backups should be automated as well, or if that’s not possible, at least a weekly manual backup should do. Any backup is better than no backup.

备份也应自动进行，否则，至少每周进行一次手动备份。 任何备份总比没有备份要好。

Store your code base in version control and use a distributed version control system like Git or Mercurial. This setup makes code bases very redundant, because every developer who’s working on the project has a version of the code base. Likewise, store the code base on Github or Bitbucket, they have backups.

将代码库存储在版本控制中，并使用分布式版本控制系统(如Git或Mercurial) 。 这种设置使代码库变得非常多余，因为每个从事该项目的开发人员都有一个版本的代码库。 同样，将代码库存储在Github或Bitbucket上 ，它们具有备份。

Backing up the database is more important, because it’s user created content. ALWAYS store the actual data and the backup in different places.

备份数据库更为重要，因为它是用户创建的内容。 始终将实际数据和备份存储在不同的位置。

Not backing up data can ruin businesses, and it will do that – see the famous case of Ma.gnolia, one of the better social bookmarking websites back in the day. Wired has a cover story on the whole disaster.

不备份数据会毁坏企业，而且会毁了企业–请参阅著名的Ma.gnolia案例，它是当今最好的社交书签网站之一。 《连线》杂志报道了整个灾难。

无监控 (No monitoring)

“Everything’s amazing and nobody’s happy.” – Louis C.K.

“一切都很棒，没有人高兴。” –路易·CK

You’re not happy, because you don’t know what’s going on. Implementing an intelligent monitoring framework for your application is really important. Monitoring answers the following questions:

您不快乐，因为您不知道发生了什么。 为您的应用程序实现智能监视框架非常重要。 监视回答以下问题：

1. Did somebody access the main application server?是否有人访问了主应用程序服务器？
2. Are the servers under heavy load?服务器是否承受重负荷？
3. Do we need to scale to another database server?我们需要扩展到另一个数据库服务器吗？
4. Where is the application failing?应用程序在哪里失败？
5. Is it offline or not working only for me?是离线还是不只对我有用？

It is important to know the answers to these questions at any given moment, and with real-time monitoring, you will. To make this happen, tools like Nagios or New Relic should be part of your application’s infrastructure.

在任何给定时刻知道这些问题的答案很重要，并且通过实时监控，您会知道的。 为此， Nagios或New Relic之类的工具应成为应用程序基础结构的一部分。

结论 (Conclusion)

Use this knowledge to be a better programmer. Remember these oversights and try not to commit them. The application and database level oversights are the most important ones to remember.

使用这些知识可以成为更好的程序员。 记住这些疏忽，并尽量不要实施。 应用程序和数据库级别的监督是要记住的最重要的监督。

Backup is very important, always practice defensive programming and be prepared for the worst, this is how web development works. Programming is hard, but when done right, a lot of fun.

备份非常重要，始终练习防御性编程并为最坏的情况做好准备，这就是Web开发的工作方式。 编程很困难，但是如果做对了，会很有趣。

检查清单 (Checklist)

Below you’ll find a checklist of all the oversights found in this article. See how many can you cross off right now and always try to cross them all off.

在下面，您将找到本文中发现的所有疏漏的清单。 看看您现在可以划掉多少，并始终尝试将它们划掉。

1. Is error reporting on and display errors on in development and off in production?是否在开发中和生产中关闭错误报告并显示错误？
2. Do not suppress errors in your code.不要抑制代码中的错误。
3. Implement a logging framework.实现日志记录框架。
4. Use a caching strategy.使用缓存策略。
5. Keep in mind and use programming design patterns and best practices.请记住并使用编程设计模式和最佳实践。
6. Use tests in your code and try to automate running these tests every time a change occurs in the code base.在代码中使用测试，并尝试在代码库中每次发生更改时自动运行这些测试。
7. Review or at least audit team members’ code.查看或至少审核团队成员的代码。
8. Practice defensive programming.练习防御性编程。
9. Learn and use OOP principles correctly.正确学习和使用OOP原则。
10. Have a solid workflow and processes for developing and deploying code.具有用于开发和部署代码的扎实的工作流程和流程。
11. Differentiate between read / write database queries.区分读/写数据库查询。
12. Use a solid database library which can connect to multiple databases.使用可以连接到多个数据库的可靠数据库库。
13. Test SQL queries for exploits.测试SQL查询是否存在漏洞。
14. Learn and use indexes on database tables学习和使用数据库表上的索引
15. Use database transactions.使用数据库事务。
16. Secure sensitive data in the database.保护数据库中的敏感数据。
17. Use different coding environments: development, staging, production.使用不同的编码环境：开发，登台，生产。
18. Implement a backup and monitoring strategy.实施备份和监视策略。

翻译自: https://www.sitepoint.com/18-critical-oversights-web-development/