플러그인 엔진 컨셉 중 가장 먼저 언급하고 싶은 것들.
1. PSR 코딩 스탠다드
워드프레스는 나름의 Best Practice와 코딩 스탠다드가 있습니다. 그러나 플러그인 엔진은 PSR 1, 2의 코딩 스탠다드를 더 선호합니다. 사실 이렇게 작성해서 플러그인 제출에 탈락할지 말지는 잘 모르겠습니다만, 엄연히 오픈소스에 커뮤니티 기반의 프로젝트인 워드프레스가 단지 자신들의 스탠다드를 지키지 않았다고 해서 플러그인 제출을 막을 것 같지는 않을 거라 생각합니다.
파일 이름과 클래스 이름 모두 PSR을 따르는데, 이는 Autoloading을 사용할 때 이 쪽의 이름 규칙이 보다 편리하기 때문입니다.
2. Autoloading, Composer
PSR-1, PSR-2에 이어 PSR-4 또한 적극적으로 도입하여 사용합니다. 메인 파일 처음에 들어가는 “require_once vendor/autoload.php” 구문 이외에는 클래스나 함수를 부르기 위해서는 require, include 구문을 쓰지 않습니다. 이렇게 autoloading을 사용하면 코드 작성과 유지가 매우 쉬워집니다.
물론 autoloading을 위하여 컴포저 (composer)를 도입합니다. 컴포저가 있는 만큼 외부 라이브러리 관리도 한결 편리해집니다.
물론 기존의 워드프레스식 파일 이름과 워드프레스식 이름 관례를 쓰더라도 autoloading을 사용하지 못하는 것은 아닙니다. 그러나 워드프레스식 클래스 이름과 파일 이름의 명명법이 다르기 때문에 일일이 파일 이름과 클래스 이름에 대해 문자열 처리를 해야 하는 불필요한 비용이 발생합니다.
예를 들어 클래스 이름이 WP_Member_Contacts 라는 클래스를 만들었다고 합니다. 그러면 이 클래스의 파일 이름은 ‘class-wp-member-contacts.php’ 정도로 될 것입니다. 그러면 WP_Member_Contacts가 class-wp-member-contacts.php 파일에 대응된다는 사항은 ‘composer dump-autoload’ 명령을 통해 autoloading 라이브러리가 미리 잘 캐싱해 둡니다. 여기까지는 좋습니다. 아무 문제가 없습니다.
그러나 엔진을 제작하면서는 약간 고민거리가 생깁니다. 엔진에서는 class-wp-member-contacts.php 파일을 만나게 되면 이 파일은 어떤 클래스를 가지고 있는지를 알아야 할 때가 생깁니다. 아까의 반대입니다. 물론 규칙이 있으니 쉽게 변환할 수 있습니다. class- 접두를 빼고, 모든 하이픈을 언더바로 바꾼 다음 ucfirst를 적용하면 됩니다(사실 PHP FQCN(fully-qualified class name)은 대소문자를 가리지 않으므로 꼭 하지는 않아도 됩니다). 그러나 일일이 파일 이름에 대해 문자열을 계산해야 하는 것이 번거롭습니다.
PSR-4와 PSR-1 규칙에 따라 클래스 이름과 파일이름을 CamelCase로 통일하면 그런 문자열 계산 비용이 사라집니다. 그리고 namespace의 한 마디가 디렉토리 깊이 하나로 매핑되는 구조 또한 매우 합리적입니다.