여기까지는 남이 남긴 확장 지점을 쓰는 이야기였습니다. 우리가 코드를 만드는 쪽이 되면 질문이 바뀝니다 — 어디에 무엇을 남겨야, 남이 우리 파일을 고치지 않고도 원하는 것을 할 수 있는가.
확장 지점이 없는 코드에는 결말이 둘뿐입니다. 포크되거나, 업데이트를 포기하고 직접 수정되거나. 둘 다 우리 코드가 그 사이트에서 더 이상 유지보수되지 않는다는 뜻입니다.
값에는 필터, 사건에는 액션
규칙은 1회차와 같습니다. 우리가 만든 값 중 남이 바꿀 여지가 있는 것은 apply_filters() 로 내보내고, 우리가 하는 일 중 남이 앞뒤로 끼어들 자리가 있는 것은 do_action() 으로 알립니다.
// 값 — 기본값을 두고, 돌아온 것을 검증한다
$fields = apply_filters( 'wper_report_fields', $defaults, $report_id );
if ( ! is_array( $fields ) ) {
$fields = $defaults; // 남이 돌려준 값을 그대로 믿지 않는다
}
// 사건 — 앞뒤로 끼어들 자리를 알린다
do_action( 'wper_report_before_render', $report_id, $fields );돌아온 값을 검증하는 것이 중요합니다. 우리 필터에 걸린 콜백이 실수로 null 을 돌려주면(1회차의 그 실수입니다) 우리 코드가 대신 죽습니다. 남의 실수로 우리가 치명적으로 실패하지 않게 하는 것은 우리 책임입니다.
맥락을 함께 넘겨야 판단할 수 있습니다
필터의 두 번째 이후 인자는 장식이 아닙니다. 받는 쪽이 판단할 근거이고, 이것이 부족하면 필터는 있으나 마나가 됩니다.
이 저장소의 진단 플러그인이 그 예입니다. 채점 카테고리 목록을 필터로 내보내는데, 그 필터에 진단 1건의 맥락을 함께 넘깁니다. 넘기지 않으면 받는 쪽이 “지금 화면 설정” 밖에 볼 수 없고, 그러면 과거 기록을 열었을 때 그때와 다른 구성으로 다시 채점되어 지난 점수가 조용히 달라집니다. 맥락 인자 하나가 “지난 보고서는 그때의 구성으로 채점한다” 는 규칙을 성립시킵니다.
많이 남기는 것이 답은 아닙니다
훅은 한번 공개하면 지켜야 하는 약속이 됩니다. 이름 · 인자 · 호출 시점을 바꾸면 그것에 기대 있던 코드가 깨집니다. 그래서 개수보다 위치가 중요합니다.
좋은 기준 하나는 이것입니다 — 누군가 우리 파일을 고쳐야 할 것 같은 바로 그 지점에 훅을 둡니다. 그 지점은 대개 셋입니다. 화면에 나갈 값이 확정되는 곳, 목록이나 표가 조립되는 곳, 그리고 외부에 무언가를 보내기 직전입니다.
반대로 내부 구현의 중간 상태에는 훅을 두지 않습니다. 그것을 공개하면 구현을 바꿀 자유를 잃습니다. 이름이 바뀌어야 한다면 apply_filters_deprecated() 로 옛 이름을 한동안 살려 두고 알립니다.
이 원칙으로 만든 무료 플러그인들은 무료 도구에서 코드째 볼 수 있고, 확장 지점 설계에 관한 글은 개발 워크플로우 아카이브에 있습니다.
다음 회차
연재의 마지막 회차는 진단입니다. 어떤 콜백이 어느 훅에 몇 번으로 걸려 있는지 실제로 들여다보는 방법과, 원인을 찾아가는 순서를 정리합니다.