程序员团队里有很多[差不多]先生：只要代码写好，能用；只要开发环境能用；只要开发环境可用；这很烦人，而且对产品质量和团队合作非常有害，尤其是在启动项目中。今天只讲代码，为什么捏？因为有槽，所以不能快速吐出来！笔者见识了点世面，却仍感懊恼。据说笔者最近分配了一份工作，需要使用NetSuite的API将网站客户自动导入到NetSuite系统中进行管理。NetSuite在CRM系统中也是比较知名的大牌。据说是Oracle传授的管理经验，功能确实强大。然后笔者开始研究SuiteTalkPHPToolkit，看了半天文档，大概了解了一些业务流程，做了一些准备，就等着用这个API来进行神圣的第一次WebService交互了。雄辩地写下一些调试代码并开始试验。你可以想象，我疯了。一个开源库有3个文件，一个config，一个基础类加工具函数，最后一个是一个php文件，代码近14W行，大小2MB多。几乎所有的类都写在一个文件中。其实这样也好，不就是看代码会很费事吗。重点是：请注意这个库没有命名空间，类名也没有任何前缀。敢问猴子们，有多少项目没有Customer类？引入外部库是为了给自己的类改名吗？当然，如果你的项目本身引入了命名空间，这个问题影响不大；但是你维护的项目大部分都有几年以上的历史代码，也就是大概率没有namespace的。后来笔者为了解决这个命名冲突的问题，找到了专门的程序员。他帮助将此API组织成命名空间+composer安装(https://github.com/ryanwinchester/netsuite-php)。缺点是没有实现TokenBasedAuthentication，没关系，继承添加即可。哎，上次说了不要随便用private会员（http://zhuanlan.51cto.com/art/201606/513531.htm），我又遇到了。为了顺利继承，只好将所有私有成员Once复制到自己写的继承类中。笔者明白，猴子的成长需要一个过程，九阴白骨爪的修炼需要不断的试错。因为我也是这么过来的，虽然我现在还没有白骨爪子，但是我倒是有一双豆豉凤爪。不过像NetSuite这样的大品牌能搞出这样的绿色库，还真是少见。以上描述略显夸张，开心就笑吧。话虽如此，[几乎]先生和NetSuite都可以来看看代码的组织方式是否足够。说到今天流行的几种方法，PSR系列（PHPStandardsRecomendations）。PSR-0已于2014年10月21日标记为过时，现在推荐PSR-4，我们看到composer仍然保留对PSR-0的支持。PSR-0，AutoloadingStandard文件的结构是Vendor\(Namespace)*\ClassName.php；每个命名空间的最顶层空间必须是Vendor，例如对于NetSuite，NetSuite应该是它最顶层的命名空间；中间可以有无数层命名空间；查找对应的class文件时，命名空间的分隔符会转换为系统的文件夹分隔符；类***的下划线_对应更深的文件夹层级，但不影响命名空间；PSR-4，这里Autoloader的类指的是class、interface、trait等类似结构；namespace和file对应的结构与PSR-0相同，只是下划线在本标准中没有特殊作用，namespace和Filenames区分大小写；自动加载器实现不得抛出异常、错误或返回任何值。命名空间主要是为了解决命名冲突的问题。合理使用命名空间可以使你的项目具有可扩展性和可维护性。仓促实施只会让后期的开发和维护成本越来越高。即使现在你不需要自己实现Autoloader，使用强大的composer并遵循相关概念也能让你事半功倍。PSR-1，BasicCodingStandard指的是一些通用的代码标准，可以让团队协作更加顺畅。只使用
