程序猿隊伍里面不乏【差不多】先生：代碼寫出來能用就行了；開發環境能用就行了；上線前隨便測測就行了；你要我再給你就行了...這些態度不僅惱人，而且對于產品質量、團隊協作來說都是危害甚大，這在初創項目中結果特別明顯。今天只談代碼，為啥捏？因為有個槽它不吐不快啊！作者也算見過點世面的了，但是還是被惱到了。

話說最近作者被派到了一個活兒，需要使用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）。

[[170536]]

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/

說了這么多所謂的標準，目的無非就是為了更好的協作。有人說，我自己一個人做的項目我做主就好了。也沒錯，不過養成這些習慣也沒有傷害，你咋知道你一不小心就做出了點啥可以拿出手的東西，不要等到那個時候再來整理代碼來交代吧？

所以說，好的代碼組織方式，真的不只是為了好看而已。