내가 만들지 않은 시스템을 확장한다는 것

오픈소스 학습관리 시스템 위에 기능을 붙이는 일을 하고 있다. 코드가 전부 있으니 마음대로 손댈 수 있는데 그러면 안 된다.

Open Table of contents

제약 — 고칠 수 있는데 고치면 안 된다

처음에는 이해가 잘 안 됐다.

코드가 여기 있는데 왜 못 고치는지가 몇 주 지나서야 이해됐다. 보안 수정이 올라오는데 우리가 손대 놓았으면 그것을 받을 때 충돌하고 충돌을 하나씩 풀다 보면 결국 못 받게 되어 취약점을 안고 간다.

어디를 손댔는지 기억하지 못한다는 것도 있었다. 급할 때 한 줄 손보고 넘어가면 몇 달 뒤에 아무도 모르고 원본과 비교해야 알 수 있는데 파일이 수만 개다.

다행히 이 시스템은 plugin 으로 붙일 자리를 마련해 두고 있었다.

정해진 폴더에 정해진 형식으로 두면 core 를 안 건드리고 기능이 는다.

문제는 기존 동작 자체를 바꾸기 줄이었다. 요구사항 중에 이 조건일 때는 다르게 동작해야 한다는 것이 있었는데 그런 자리가 없었다.

hook 으로 안 되는 것을 만났을 때 세 방법을 놓고 봤다.

하나  원본을 고친다
둘    앞이나 뒤에서 처리한다
셋    그 기능을 안 쓰고 따로 만든다

대부분 둘 로 해결됐다.

목록 순서를 조건에 따라 다르게 하는 것은 core 가 준 결과를 우리가 다시 정렬하면 된다. 원본이 하는 일은 그대로 두고 그 전이나 후에 개입하는 방식이라 원본을 안 건드린다.

셋 은 한 번 쓰고 후회하는 중이다. 우리 것과 원본 것이 따로 놀아서 데이터가 두 곳에 생겼다.

방법이 없어 core 에 손대야 하는 경우가 남는다.

수정한 파일 목록
- lib/xxx.php  : 조건 추가 (우리 요구사항 A 때문)
- mod/yyy.php  : 함수 하나 교체 (원본 함수명 바꾸고 우리 것 추가)

lib/xxx.php 처럼 손댄 것을 이런 목록으로 남긴다.

core 와 우리 것의 경계를 알 수 있게 앞뒤에 주석 표시도 둔다. 한 줄로 될 것을 열 줄로 손대지 않는데 다시 붙일 때 적을수록 낫다.

이렇게 해도 부담이다. 새 판을 올릴 때 이 목록을 들고 하나씩 다시 봐야 한다.

코드보다 DB 쪽이 더 어려웠다.

core 표에 컬럼을 더하는 쪽이 편하지만 새 판이 그 구조를 바꾸면 어떻게 되는지 모른다. 그래서 우리 표를 따로 두고 core 표의 식별자로 잇는 구조로 간다.

조회할 때 JOIN 이 하나 늘지만 core 와 분리된다. 어디까지가 원본이고 어디부터가 우리 것인지가 구조로 드러나는 것도 이 방식의 이점이다.

남은 것도 있다.

새 판을 아직 안 받아 봤다
확장 폴더에 있어도 원본 내부 함수를 부르는 코드가 있다
우리 코드만 따로 시험하기 어렵다

지금 방식이 맞는지는 실제로 새 판을 받아 봐야 안다.

plugin 폴더에 두었어도 core 내부 함수를 부르면 그 함수가 없어질 때 우리도 깨진다. 이것이 원본에 손댄 것과 무엇이 다른지는 아직 잘 모르겠다.

core 표에서 행이 사라지면 우리 표에 고아가 남는 것도 남아 있다. 정기적으로 정리하는 것이 필요한데 아직 못 했다.