De-Fi 프로토콜 연동 어댑터를 만들어야 하는데 코드를 보니 DefiAdapter 인터페이스만 있고 구현이 한 줄도 없었다. 조사가 부족해서 못 만든 것으로 보고 프로토콜 명세를 더 조사하는 쪽으로 가려 했다.
Table of contents
Open Table of contents
배경 — 어댑터가 0줄이던 상태
두 가지 방법이 있었다. 명세 조사를 그대로 시작하는 것과, 조사 계획을 세우기 전에 지금 상태를 먼저 확인하는 것이다. 뒤쪽을 골랐다. 이유는 조사가 필요하다는 것 자체가 아직 확인된 사실이 아니어서다. 대신 하루를 상태 확인에 쓰는 것을 감수했다. 프로토콜 명세의 README 와 설계 문서와 실제 코드 세 방향을 병렬로 훑었다.
순차로 보면 앞의 것을 잊은 채 다음을 보게 된다. 대조가 목적이면 병렬로 놓고 교차해서 보는 편이 맞았다.
검증 — 코드가 자인한 미착수
코드 쪽에서 DefiAdapter 정의만 두고 구현체는 이후 단계라고 적힌 // TODO 주석을 발견했다. pom.xml 에도 컨트랙트 호출과 서명에 필요한 web3j 가 아예 없었다.
착수했으면 의존성부터 추가됐을 것이므로 그것 자체가 안 시작했다는 증거였다. 같은 영역의 순수 매핑 로직 ProtocolMapper 는 다섯 프로토콜 전부 완성돼 있고 JUnit 테스트도 통과하고 있었다.
판단 기준 — 조사로 안 풀리는 것을 스코프에 두면
구현이 없는 이유가 조사 부족이 아니라 아직 순서가 아닌 것이었다. 조사를 아무리 해도 DefiAdapter 구현체는 안 생기는데 그것은 조사의 결과물이 아니기 때문이다.
그대로 뒀으면 명세를 더 조사하고도 여전히 구현이 없어서 조사가 더 필요하다는 결론으로 도는 상태가 됐을 것이다. 그래서 web3j 를 붙이는 실제 구현 착수를 조사 스코프 밖으로 명시해 못박았다.
코드가 문서보다 정확했다
대신 이번 조사가 실제로 기여할 수 있는 것을 찾았는데 명세에는 답이 있는데 설계 문서에는 옛 정보가 남은 지점이었다. 그 차이를 정정하는 것이 조사로 닫을 수 있는 일이었다.
어댑터가 막힌 이유도 // TODO 주석에 적혀 있었다. 문서는 쓰고 나서 안 고치지만 코드 주석은 그 코드를 고칠 때 같이 눈에 들어오므로 현재 상태에 대해서는 코드 쪽이 더 정확했다.
막힘과 미착수와 누락
이 건에서 남은 구분이 셋이었다. 막힌 것은 가로막은 것을 치우면 되고 미착수는 순서가 되면 하는 것이며 누락은 지금 하는 것이다.
셋 다 겉으로는 코드가 없다는 같은 모양으로 보인다. 어느 것인지 가르지 않으면 엉뚱한 조치에 시간을 쓴다.
정리
- 구현이 없는 이유가 막힘이 아니라 미착수일 수 있다
// TODO주석이 미착수를 자인하고 있을 수 있다pom.xml에 관련 라이브러리가 없으면 착수 안 한 증거다- 조사로 안 풀리는 것을 조사 스코프에 두면 결론이 돈다
- 명확히 스코프 밖으로 배제하고 할 수 있는 것을 찾는다
- 여러 방향을 병렬로 훑으면 교차 표가 만들어진다
- 현재 상태에 대해서는 코드가 문서보다 정확하다
- 막힘과 미착수와 누락은 다
DefiAdapter구현이 없다로 보인다