코드 라인 수가 적으면 무조건 좋다는 당연히 아닌거군요.

오늘 제가 만들어 사용하는 애드온에 우연히 코어에서 동작하는 것과 완벽한 일치가 안되는 것 하나가 발견되어 해당 부분을 보완하면서 코드를 추가해서 문제가 될만한 소지를 없애는 작업을 했습니다.

애드온의 기능은 댓글이 추천을 받으면 그 댓글 작성자에게 사이트에서 포인트로 교환이 가능한 스티커를 일정 매수를 지급하는 애드온 입니다.

그런데 애드온으로 만들다 보니 추천 작업 후 스티커가 지급 되게 되어있습니다. XE 애드온의 구조가 그렇습니다.

그래서 코어에서 댓글 추천하는 금지하는 사례를 나름 꼼꼼히 카피하여 적용하였다고 생각하고 스티커 지급 직전에

리턴코드 1

리턴코드 2

리턴코드 3

리턴코드 4

이렇게 추천 작업 후 추천할 수 없는 응답이 나올 수 있는 것에 스티커 지급도 되지 않도록 조치를 하였죠.

나름 꼼꼼히 했다고 생각했는데 의외 케이스가 오늘 발견이 되었습니다. 물론 코어는 꼼꼼히 막는다고 막아서 이런 결과가 나오는 것일 텐데요. 간단히 설명드리면 로그인 상태가 유지되면서 뭔가 변화가 생길때 의외의 추가적인 조치가 필요한 것 입니다.

결국 저는 완벽히 코어와 일치시키려면 코어의 모든 것을 똑같이 적용하기 보다는 

추천 직전 댓글의 추천수 = 추천 직후 댓글 추천 수 

위와 같은 등식이 성립된다면 스티커를 지급하지 않는 것으로 오늘 코드를 추가했습니다.

결과만 본다면 어떤 사유로 코어에서 막았던 추천수가 증가하지 않았다는건 스티커도 지급하지 않아야 한다는 것 입니다.

그럼 여기서 제가 제목에 적은 코드 라인수가 적으면 무조건 좋은게 아닐거라는 생각을 하게 된게 바로 아래 내용입니다.

처음 이 코드를 넣으면서 위에 리턴코드1,2,3,4 를 없애도 되겠군! 이라는 단순한 생각을 했습니다.

그런데 더 생각을 해보니..

추천 직전 댓글의 추천수 = 추천 직후 댓글 추천 수 

를 비교하는 작업이 위 리턴코드 1,2,3,4 에 비해 더 자원을 사용하게 될 것입니다. 왜냐면 리턴코드 1,2,3,4 는 별다른 추가작업 없이 바로 확인 가능한 값을 사용하는 코드입니다.

하지만 마지막에 추가한 코드는 나름 추천 직후에 또 한번 추천수를 db에서 한번 가져오는 아주 약간의 자원 사용이 더 있는 코드 입니다.

마지막 코드가 사용될 확율은 극히 적습니다. 아마 거의 사용되지 않을 겁니다. 굉장히 특이한 케이스의 다중 아이디로 시도할때 취약점이라 사실 그냥 둬도 될 만한 정도 입니다. 

따라서 아주 간단히 처리할 수 있는 리턴코드 1,2,3,4 를 유지해 줘서 마지막 최후 방어선인 코드가 동작할 기회를 주지 않는게 더 좋다는 생각을 하게 되었습니다. 

개발자 분들이야 당연히 이런 것을 고려해서 코드를 유지하고 코드의 순서도 부하의 순서에 맞춰 배치하시리라 생각되지만 야매가 이런 것 까지 신경을 쓰지 않으면 똑같은 동작을 하는 자료라도 어느 것은 매번 무겁고 어느 것은 가벼운 그런 차이가 나는 자료가 될 수 도 있다는 생각을 하게 되었네요.

오늘도 지루하고 재미없는 글 작성하고 갑니다.