好的代码组织方式只是为了更好看吗？

发布时间：2025-11-05 08:14:25 来源：码上建站 作者：数据库

程序猿队伍里面不乏【差不多】先生：代码写出来能用就行了；开发环境能用就行了；上线前随便测测就行了；你要我再给你就行了...这些态度不仅恼人，代码而且对于产品质量、组织团队协作来说都是更好危害甚大，这在初创项目中结果特别明显。代码今天只谈代码，组织为啥捏？更好因为有个槽它不吐不快啊！作者也算见过点世面的代码了，但是组织还是被恼到了。

话说最近作者被派到了一个活儿，更好需要使用NetSuite的代码API来自动将网站的客户导入NetSuite系统里管理。NetSuite在CRM系统里也算个比较知名的组织大牌了，据说是更好Oracle传授的管理经验，功能也着实强大。代码然后作者就开始研究SuiteTalk PHP Toolkit，组织看了半天的更好文档，大概明白了一些业务流程做了一些准备工作，就等着用这API进行神圣的***次Web Service交互。洋洋洒洒写下了一些调试代码开始试验。结果你能想到，我疯了。一个开源库有3个文件，一个config，一个基础类加工具函数，免费源码下载***一个就是将近14W行代码大小2MB多的php文件，几乎所有的类都写在一个文件里面了。其实这也还好，不就是看代码会费事点么。重点是这个：

请注意这个库是没有命名空间的，类名也没有任何的前缀。敢问猴儿们做的项目里，有多少个项目是没有个Customer类？引入外部库是为了改自家的类名么？当然了，如果你的项目里本身就引入了命名空间，这个问题影响不大；但是大家手头在维护的项目里，大多都有超过几年的历史代码，也就是有很大几率是没有命名空间的。

后来作者为了解决这个命名冲突问题找到了一个乐于奉献的程序员，网站模板他帮忙把这个API整理成了命名空间+composer安装的方式(https://github.com/ryanwinchester/netsuite-php)。缺点就是没有实现Token Based Authentication，也没关系，继承一下加进去。哎，上回说到不要随便用private成员(http://zhuanlan.51cto.com/art/201606/513531.htm)，这会又碰到了，为了顺利继承，不得不把所有的private成员都拷一遍到自己写的继承类里。

作者理解猴儿的成长需要过程，需要不断试错方能练成九阴白骨爪。因为自己也是这么过来的，虽然白骨爪还没有，豉汁凤爪倒是有一对。但是像NetSuite这样的大品牌弄出这么青涩的库还真是很少见。

上面的描述略带夸张，开心呢您就笑一笑。话说回来，【差不多】先生和NetSuite都可以来看看关于代码组织方式这件事上，是云服务器不是凑合就可以了。这就要说到现今流行的几种方式了，PSR系列（PHP Standards Recomendations）。

PSR-0在2014年10月21日已经被标志为淘汰过时了，现在推荐的是PSR-4，我们看到composer里面还保留着对PSR-0的支持。

PSR-0，Autoloading Standard

文件的结构为Vendor\(Namespace)*\ClassName.php；每个命名空间的最顶层空间一定是Vendor，例如对于NetSuite来说，NetSuite就应该是它的最顶层命名空间；中间 可以有无数层命名空间；命名空间的分隔符会在找相应类文件时转换为系统的文件夹分隔符；类***的下划线 _ 对应着更深的文件夹层级，但是不影响命名空间；

PSR-4，Autoloader

这里的类指代class，interface、trait和类似的结构；命名空间与文件的对应结构跟PSR-0是一样的，除了在这个标准里下划线没有特别的作用，并且命名空间和文件名是大小写敏感的；Autoloader的实现不可以抛出异常、错误，也不返回任何值。

命名空间主要就是解决命名冲突的问题。合理的运用命名空间，可以让你的项目可具有扩展性，可维护性。寥寥草草的实现，只会让后期的开发维护成本越来越高。甚至现在你都不需要自己实现Autoloader，运用强大的composer，和遵循相关的理念就能让你事半功倍。

PSR-1，Basic Coding Standard

这里说的是一些代码的普遍标准，它可以使得团队相互协作变得更为顺利。

只使用<?php 和 <?= 标签；所有代码文件使用UTF-8编码格式；一个文件要么做声明（类，接口，公共函数等），要么做执行之类的周边工作（view，config等），不要一个文件同时做两样事情；命名空间和类根据PSR-0/PSR-4来组织；类命名首字母全大写，其他字母小写，例如 StudlyCaps；常亮用全大写，用下划线做分隔符；类方法用驼峰式命名，camelCase。

规则里面没有规定变量怎么命名，团队可以根据自己需要制定。小小的规则，却可以让团队，开源项目以一种和谐的方式相互协作，减少因为多样性而导致的内耗是很有实际意义的。如果团队里有程序猿一定要坚持自己的风格，这个猴子的合作精神一定是有待提高的。事实上一个团队各顾各的，失败就是必然的了。

PSR-2，Coding Style Guide

这是对PSR-1补充和扩展。

代码使用4个空格来缩进，而不是tab键（可以在IDE里面设置tab键转换为4空格）；一行的长度推荐80~120字符之间；namespace声明块后面要有一行空白，use声明块后面也要有一行空白；类和函数的花括号都独占一行；所有的类成员和函数都要显示声明可见性（不要省略掉public）；控制结构的关键字后面留一个空格，函数调用后面不要留空（if (x), test()）；控制结构的起始花括号与代码同行，结束花括号新起一行；控制结构的括号不要留空，例如if (x)。

当然还有其他的一些推荐标准，大家可以自行参考http://www.php-fig.org/psr/

说了这么多所谓的标准，目的无非就是为了更好的协作。有人说，我自己一个人做的项目我做主就好了。也没错，不过养成这些习惯也没有伤害，你咋知道你一不小心就做出了点啥可以拿出手的东西，不要等到那个时候再来整理代码来交代吧？

所以说，好的代码组织方式，真的不只是为了好看而已。

相关文章