在web开发领域容易被疏忽的18个关键问题-George Fekete

最新推荐文章于 2019-08-26 00:39:02 发布

hayes_shi

最新推荐文章于 2019-08-26 00:39:02 发布

阅读量1k

点赞数

文章标签： web开发 application 软件开发

过去一些年，我有幸参加了很多有意思的项目。而且伴随着在属性上复杂性不断发展，我们需要定期的更新，重构和向项目添加新的特性。本文将谈论到当处理媒介和大型项目时，很多PHP开发者会遇到的最容易被忽略的地方：如不区分开发者环境或者实现缓存和备份等容易被忽略的问题。下面的列子将在PHP中展开，但是每一个问题的本质是相同的。这些问题的根源主要是由开发者的知识和经验所导致的，尤其是缺乏必要的知识和经验更加会导致这些问题。我并不是因此而抨击任何人，我并不认为自己是全能的完美开发者，所以请大家容忍我吧。以我的经验而谈，我们可以将这些问题分为三个大类：设计层面，应用层面以及数据库层面容易被忽略的问题。我们将独立的一一分析这些问题。

1应用层面上容易被忽略的问题

1.1伴随这错误报告的项目开发

我唯一能问的一个问题是：为什么？当在着手开发一个应用项目时，为什么你不返回错误的报告？PHP有很多的错误报告工具层次，并且其ALL在阶段开发阶段被打开。如果你认为你在理想的状态下编程，错误将永远不会发生，但事实是这只能发生在理想的状态。错误报告和展示错误信息并不是相同的。error_reporting()可以用来设置错误层次（例如：notice,warning,fatal errors）以及用diplay_errors控制这些信息是否将被输出与否。错误报告在项目开发中应该总是处在最高的设置位置：error_reporting(E_ALL);并且设置ini_set('display_errors', true);请注意：E_ALL是PHP 5.4+之后的最高级别，因为E_STRICT错误在PHP 5.4已经成为了E_ALL的一部分。如果你项目开发中使用了5.4之前的老版本,那就请使用error_reporting(E_ALL|E_STRICT);来处理错误警告。

1.2抑制错误

使用@操作符来抑制错误比不将其打开更加糟糕，因为你有意识的在项目里清理错误。你知道错误会发生，但你仅仅想要隐藏这些错误，关闭这些任务以及提早回家。但你没意识到的是在一个不稳定的项目基础上搭建其他东西在随后可能会导致更加严重的结果。更多详情请见http://www.sitepoint.com/why-suppressing-notices-is-wrong/

1.3在代码的任何地方都没有日志输出

在开发项目的一开始，就要有意识的做日志输出，而不是在项目的结尾将日志输出添加上去。绝大多数的开发者采取一种或者另外一种方式去做日志的输出，但是在实际情况中，其中的许多人不会花费大量时间验证这些错误。那么如果没有人不看这些日志输出，那做日志的意义又有什么意义呢？！PSR建议就是为了日志输出而存在，PSR-3更加的精确，更多关于PSR-2的内容请参见http://www.sitepoint.com/logging-with-psr-3-to-improve-reusability/

1.4不实现缓存

在应用中的不多层面上，可以有多种途径来实现缓存，如在服务器层面，应用层面，数据库层面等等。缓存也应该在项目启动的初始就要被考虑进来，你也可以再开发的过程中屏蔽这些缓存，但一旦将这些缓存添加到生产环境中，你要确保每一个组件都能正常工作。在服务器层面上你可以使用Vanish(注：一款开源的HTTP加速器)，这是一款反向的Http代理软件，其能在内存中存储文件并且应该安装在web服务器端的前面。为了使PHP更加迅速，你可以安装/使用一个操作码缓存器，它能优化PHP脚本的字节编码复杂度。对于PHP 5.5以及后面的版本而言，操作码缓存器已在被编译进了PHP核心，其被称为OpCache。更多详情请参考http://www.sitepoint.com/understanding-opcache/在PHP 5.5之前，你可以使用APC，其也已经实现了用户缓存功能。在应用服务层面上，你可以使用APCu（从APC中抽离出来）；yec(github地址：https://github.com/laruence/yac)也有和APCu类似的功能，或者使用Memcached(http://memcached.org/)，其是一个分布式缓存系统并且其有一个很轻大的PHP支持，Memcached还有一个功能就是可以别用来缓存数据库查询。在应用层面上实现缓存还有很多技术，但一个好的实践是缓存的数据不需要经常做改变还要不停反复的返回。数据库缓存很受质疑，因为数据库在每一个PHP项目里总是一个很大的瓶颈。

1.5忽视最好的实践方案和设计模式

你有多少次看见其他人实现自己的密码加密算法？很不幸，在今天还会发生这种情况，因为这些人认为“他们理解的更好”。那好吧，那我要给你带来坏消息了，但是99%的时间里面，你无法做到更好理解这些好的模式。这些最佳的实践方案和设计模式是被一些比我们更聪明的软件工程师设计出来的，开发者要做的单纯工作就是把对工作有用的

模式摘录过来。有许多好的书和资源，我关注了其中的两个：
1)Patterns of Enterprise Application Architecture by Martin Fowler(http://www.amazon.com/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420)
2)PHP Objects, Patterns, and Practice by Matt Zandstra(http://www.amazon.com/Objects-Patterns-Practice-Matt-Zandstra/dp/1430260319/)

1.6不使用自动的测试

web应用的每一个特征都应该添加测试，但是就和日志一样，如果没有人看这些测试以及在实际过程中跑这些测试来检查是否有问题出现的话，那么自动化的测试页就没有意义了。运行测试实际上是一个很无聊的过程。幸运的是，有很多工具可以帮助我们来自动部署我们的测试，这一个整的实践过程被称为“连续整合过程”。有一个在PHP社区广泛被使用的工具是Jenkins,其是一个CI服务器并且可以做很多测试应用项目之外的工作。Sebastian Bergmann为Jenkins构造了一个很优秀的模板用于PHP的开发。如果你发现这是令人难以招架的，那么至少使用PHPUnit、BeHat或PHPSpec来为你的应用项目做一个白盒测试。第一眼看上去它可能涉及到许多工作，但是在经过长期的测试后，证明了测试是有助于项目的开发的。

1.7不回顾/审查你的代码

在一个团队中工作是很有挑战性的，尤其是团队中的每个成员习惯于不同的编码性格，并且如果没有良好的项目规范，开发的项目很可能很迅速的偏离了原有的计划。如果你的团队部尊重相互之间的代码，你就应该去做代码审查。就和单元测试一样，其有助于使项目更加整洁和连贯。当你检查你的代码时，回顾和审查两者的区别就是时间。回顾经常在任何代码合并到已有代码库之前发生，而审查往往是在代码被合并后发生。回顾是一件很有必要做的事情，因为你有机会和代码交流，可以改善或者修复原有其他团队加入的代码。回顾的缺点就是其可能阻碍开发，因为在每一次合并之前，至少有两个开发者需要讨论这些代码（已测试通过），并且代码审查人员也要在其中发挥自己的作用。审查发生在代码合并之后，并且这个是不阻碍项目开发进度的，但是其显然没那么强大，因为审查错过了捕捉早前出现Bugs的机会。审查任然比不做任何代码检查要来的好。如果你想去帮助开发过程尽可能的流利，你可以使用一款叫做Phabricator的工具，这款工具是由Facebook工程师创造出来专门用于实现这一目的的。它支持代码审查策略。

1.8在理想情景中编程

你是否发现自己或者听见这样的例子：在何处有一些没有意义的模板代码被写入项目，使得项目一团糟？我确实这样做过。这种情况发生的绝大数是因为开发者很懒并且在一个理想的环境中写代码，在这个环境中，数据库操作失败，PHP致命错误以及服务器被黑掉的情况不会发生。开发者在写代码时，应该在心中思考那些恶劣的环境所造成的问题，并且甚至要考虑代码不能涉及的不起眼角落，如用户使用了$这个符号并立刻导致获得完整的管理员权限等。假设你的服务器永远不会被黑掉或者你的代码永远不会出错以及你的数据库一直会运行正常的这种想法是有问题的。产品代码应该考虑到所有会出现的情况以及有根据的做日志输出。在PHP，在没有意识到错误的情况下，都可能轻易的提交错误代码。这个主要原因可能是很差的语言设计决定导致的，其在过去可能发生以及在以后可能也无法被及时纠正。PHP想要让开发者上手，而且不需要考虑安全性问题、编码以及边边角角的问题，但实际上，开发者们应该意识到这些问题以及及时制定防御策略。

1.9不能正确的运用OOP原则

对象、属性、方法、继承、封装等等都是OOP的概念。并且，OOP不仅仅是在类上被组装起来的大型编码。一个正确理解这些原则来知道面向对象设计思想、SOLID原则的开发者并且知道在大体上如何编程的开发者，编程是很灵活的、不需要很强的编码功底并且也很容易去扩展和建立项目。Alejandro Gervasio自顶向下的谈到了这些原则。学习OOP永远也不会迟并且开始编写干净的代码并不依赖坚强的编码功底。

1.10“on-the-fly”编程

当有人喊道“快点，客户端需要这些功能，尽快把这些服务搞定！”，大多数的开发者就会把一些代码堆砌在一起并直接放到服务器上，这个就是所谓的“on-the-fly”编程或者是牛仔编程。在每一个产业、也在如软件开发行业中，为了项目能够成功，工作流和理智的过程应该被制定出来。为了看到快速修改的结果，PHP以及其他的动态语言在大体上都支持对代码库做快速的改变，但在生产环境中，这些改变应该被限制。只有关键的Bug要被修改并且把修改后的项目发布到生产服务器上。对于剩余部分而言，一个工作流应该被实现如：Github的分支以及一条pull request，或者是GitFlow。许多实用Git的工作流可以再这里被找到：https://www.atlassian.com/git/workflows.认为这些过程是没有必要的经理和客户们应该看看其他的方面。我曾经不止一次看到因为某些功能需要走必要流程导致某些客户不愿意等几个小时或者一天的情况。在令一方面需要注意到是，请不要混淆连续传输和牛仔编程式的混乱管理。持续的传输是关于实现和优化工作流使得工作流使得编码能尽可能别部署到生产环境中。

2.数据库层面上容易被忽略的问题

2.1读/写查询没有区别

为了能长期运行一个复杂的项目，每个开发者需要考虑需求的扩展。一个web应用项目有99%的时间不需要考虑扩展，因为它不会碰到这类大访问量的问题。如果你知道web应用项目会被很多人使用，如企业应用程序会被数以百计的公司内部员工使用，你可以做一些有必要的步骤来确保项目的易扩展性。那么为什么要独立读/写查询呢？！数据库可能会是每一个应用服务的第一个瓶颈。在巨大访问量下，第一个会出现问题的就是数据库。可以使用多数据库服务器来进行流量的分流，开发者们可以使用主-从或者主-主的拆分模式。主-从模式更加受欢迎，在改模式中，每一个select操作表达都会在从机数据库服务器中实现，并且另外的主机可用于负载均衡。如果你的应用不知道拆分读和写查询，其也不会知道那台数据库服务会被连接。如果你知道最终你会采用主-从拆分模式，那请你记住这一点。

2.2只在一个数据库连接上编程

这与上述会疏忽的问题有很大的关联，但是有些时候，开发者们有其他的理由来连接多数据库。举例来说，如果在你知道读/写操作会经常发生的地方你保持日志记录、活动流、分析或者是其他数据，这有助于将访问量分流给不同的数据库服务器。确保你使用了数据库包，它能容许你连接多数据库服务器并且可以轻易的选择任意一台服务器。一个很好的解决方案就是实现PDO并且使用Aura.SQL(PDO的扩展)。

2.3不进行测试查询

这个容易忽略的问题与上述“在理想情境中编程”有关联。相同的事情，不同的表现而已。如果你不对你的数据库（应用项目）进行测试，有很多黑客就会做这类事情，并且他们有可能会成功。对于整个项目而言，数据库是最容易受到攻击的，最常见的就是SQL注入攻击。使用速查表和通过你的应用服务器来运行查询来确保数据库的访问安全。在前-后端如在注册界面上写用户名、密码来检查这些状态。如果所有查询都很成功，那么为自己买一打啤酒来庆祝吧。

2.4不为表增加索引

索引就像是每一张表的TOC，这是一个提高的性能并且应该在每个查询被执行的地方为每一张表、每个字段增加该属性（如：在where后面的column）。数据库索引后面有强大的理论支持，如什么时候添加这个属性以及如何覆盖。更多详情请查看：http://www.sitepoint.com/series/optimizing-mysql/

2.5不使用事务

数据整合对web应用至关重要。如果数据不能被正确处理，整个网站都可能会损坏。你为相关的被一起处理的数据使用数据，要么一起坚持或者一起删除这些数据。举例来说，你保存了一条关于用户的数据如：在table1中添加邮件、用户名、密码，并且在table2中配置数据如名、姓、性别、年龄等。现在如果一个用户想要删除他的账目，这个操作需要运用事务执行相关的sql查询。如果你不使用事务，你就有可能丢失数据完备性的风险，因为在数据库上对数据的操作时独立的。如果成功从table1中删除了数据，但操作table2却失败了，用户的配置信息任然存留在数据库中并且这些残留信息不与任何数据关联更加糟糕，这些信息将一直残留在数据库中。如果通过事务，上述过程就不会发生，因为只有当所有独立操作都成功时（如从table1和table2中删除信息）整个操作才将会成功，否则数据库会回滚到之前的状态。

2.6不保证敏感信息

在输入栏保存密码或者使用你自己的加密算法是不明智的。PHP社区有比你掌握的更好的加密算法。到目前为止，任然有数以千计的数据库中的敏感信息未被加密保存，这些信息很有可能被黑客盗取。PHP5.5已经添加了很强大的哈希功能。如这个，将它简单的称为Password Hashing。这个方法很容易被使用，你可以调用这个方法来进行文本密码加密。$hash = password_hash( $password, PASSWORD_BCRYPT );注意：这里不需要对密码进行处理，因为已经帮你处理好了。在数据库中存储$hash，那么你可以使用下面这个哈希函数来验证：

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

注意：如果你没有使用PHP5.5（你确实应该使用的），那你可以使用password_compat library,其实现了相同的方法。处理金融数据更加的麻烦，因为你需要知道服务器、应用和数据库层面上的PCI遵从性。更多详情请参见： SitePoint PHP – PCI Compliance and the PHP Developer(http://www.sitepoint.com/pci-compliance-and-the-php-developer/)。

3.应用设计层面容易被忽略的问题

3.1在开发环境中的无区别

我看见了很多开发者甚至是小团队为他们自己搭建了很差的开发环境。举例来说，添加一个新特点或者修复一个bug并且用ftp将这些文件传到网站上，这在很多层面上是错误的。团队可以创造无限制的工作流，但是对web开发而言最经典的方式是创造至少三个环境：开发、暂存和生产。一个开发环境可以被项目的程序员们使用，暂存和生产环境通常是被隐藏的并被其中一部分开发人员共享。开发环境是为了编程的，暂存环境是为了测试的而最终的生产环境是为了最终的消费的。有些容易被忽视的问题发生在当这些环境没有以同样方式被设置。举例来说，每一个开发人员会运行不同版本的PHP，或者暂存来自生产上的不同配置。猜，什么会发生？你是正确的。每一件事物都会在开发环境中或者是暂存环境中运行，但当你将该项目发布到生产服务器上，那么就会发生地狱式的灾难，并会导致你数天的加班和咖啡相伴的日子。难怪在开发者文档里面最常见的短语是：“它为我工作。”那么解决方案是什么呢？确保每一个组件在每一个环境中是以相同的方式配置的。操作系统应该一样，在各个环境中的PHP、database、web服务器版本也都应该一样。自从Vagrant、Docker和VirtualBox的创立，很容易就能生成相同的环境。如果你之前没有使用这些工具，那么你可以停下你所做的一切并且开始立刻使用它们。

3.2没有备份

一切运行都很好，网站也还运行着，准时启动，每一个组件都在运行，用户们正在使用这些漂亮的数据。正常、正常、正常...直到你在早上3点收到一封邮件。备份，当在开发一个web项目时，就像日志、缓存、安全和防御性策略，都是整体的一个部分。但是许多开发者（或者系统管理员）似乎忘了这么做。备份应该也被自动的部署，或者如果这个不可能，那么至少每周都要手动的进行备份。任何备份都要比不备份要好。存储代码库的每个版本控制并且运用版本部署控制系统如Git或者Merchrial。这个配置可能使代码库看起来很多余，因为每一个致力于项目开发者都有每一个版本的代码库。类似的，在Git或者Bitbucket上存储代码库，他们也有备份。对数据库的备份也非常重要，因为数据库的用户在增加其内容。存储实际的数据并在不同地方上做数据备份。没有备份的数据可能会摧毁商业，并且其可能造成像Ma.gnolia的案例，其中最好的方式是每天都对网站数据进行备份。

3.3没有监控