지금까지 본 Bad Code중 가장 큰게 뭔가요?
(news.ycombinator.com)"2500만 라인짜리 Oracle Database 12.2 코드요"
HN에서 올라왔던 질문에 예전 오라클 재직자가 남긴 답
"상상할수 없는 공포죠. 1000개의 기존 테스트를 통과하지 않고는 한줄의 코드도 작성이 불가능해요.
손으로 노트에 적어가며 풀지 않으면 알 수 없는 신비한 매크로가 있어서, 매크로 기능을 실제로 이해하는데 하루에서 이틀정도 걸려요.
때로는 코드가 서로 다른 상황에서 어떻게 작동할지 예측하기 위해 20가지 플래그의 값과 효과를 이해해야 합니다.
가끔 100개 넘을때도 있어요. 과장 아님.
이 제품이 여전히 살아남고 작동하는 유일하는 이유는 말 그대로 수백만개의 테스트 때문 입니다."
오라클 DB 개발자의 삶
1. 새 버그 작업 시작
2. 이 버그를 유발하는, 신비한 방식으로 상호작용하는 20개의 서로 다른 플래그를 이해하기 위해 2주 소요
3. 새로운 특수 시나리오를 처리하기 위해 플래그를 하나 더 추가. 이 플래그를 체크하기 위한 코드를 몇줄 더 작성하고, 문제상황을 해결하고 버그를 방지하는 몇줄의 코드 추가
4. 코드 변경 한 걸 100~200대로 구성된 테스트팜에 서브밋. 그러면 새로운 오라클 DB를 빌드하고 수백만개의 테스트를 분산해서 실행
5. 집에 감. 다음 날 와서 다른 작업 시작. 테스트는 완료되는데 20~30시간 필요함
6. 집에 감. 다음 날 와서 테스트 결과 확인. 좋은 날엔 실패한 테스트 100개쯤. 나쁜 날엔 1000개쯤 실패. 이 테스트중 몇개 골라서 내 가정이 뭐가 틀렸는지 알아보기. 아마도 버그의 본질을 알기위해 고려해야 할 10개정도의 플래그가 더 있을 거임
7. 이 이슈를 해결하기 위해 몇개의 플래그를 더 추가. 다시 변경 테스트팜에 서브밋. 다시 20~30시간 기다리기
8. 2주동안 이 플래그 조합들이 잘 동작하도록 수정하고 반복
9. 마침내 '어느 좋은 날' 모든 테스트가 실패하지 않게 됨
10. 내가 만든 변경에 대해 백개 이상의 테스트를 추가해서, 운 나쁜 다음 개발자가 이 수정사항을 깨뜨리지 못하게 함
11. 마지막 테스팅을 위해 다시 서브밋. 그리고 리뷰를 위해 서브밋. 리뷰는 다시 2주에서 2달정도 걸릴수 있으니 다른 버그로 옮겨서 작업시작.
12. 2주에서 2달후, 모든게 끝나면 코드가 메인브랜치에 머지
이게 버그를 수정하는 오라클 프로그래머의 삶입니다. 과장 없음.
그럼 새로운 기능을 개발하는 것은 어떤 공포가 될지 상상해 보세요.
하나의 작은 기능을 개발하는데 6개월에서 1년, 때로는 2년까지 걸립니다. (Active Directory 인증과 같은 새로운 인증을 추가한다거나 하는 )
이 제품이 작동한다는 건 기적입니다.
난 이제 오라클에서 일하지 않고, 다시는 오라클에서 일하지 않을꺼에요
Test Cycle 은
1. Write Code
2. Write Test
3. Refactor Code , go to 1
그런데 1,2 에 시간이 너무 걸리다보니, 3번이 계속 누락되는 결과의 합이군요.
이쯤에서 다시 보는 마틴 파울러의 강연. Oracle Database는 ‘내적 품질’(Internal Quality)이 좋지 못한 모양이로군요.
https://news.hada.io/topic?id=2752
뭐 오라클 입장에선 뭔가 당연해 보이고, 오히려 해당 소프트웨어가 역시 엔터프라이즈용이구나...싶을 정도로 신뢰가 가네요.
근데 저 글 처럼 저기서 일하고 싶진 않네요.
전 오히려 테스트 중심의 개발문화 때문에 개발 프로세스가 망가진건 아닐까 하는 생각이 드는군요.
모로 가도 테스트만 통과하면 된다는 식으로 개발이 이루어지고... 아마 저런 환경이면 리팩토링은 꿈도 못 꾸겠죠.
테스트가 문제라기 보다는, 기능 수정/추가를 위해 20~100개의 플래그를 고려해야 하도록 만든 설계적 문제가 더 크지 않을까요?
DBMS의 복잡성 때문에 어쩔 수 없을 것 같긴 하지만요.
테스트도 결국에는 개발자가 작성하는 코드니까요. 생각난 김에 테스트에 관한 글을 하나 소개했습니다.
https://news.hada.io/topic?id=2883
프로젝트가 저정도가 아니면 테스트가 인터페이스를 뜯어 고쳐도 예전과 같다는 걸 지속적으로 보장 시켜줄 수 있어서 오히려 리펙토링에 용기가 생길 것 같습니다. 제가 요즘 만드는 에뮬레이터에 파라미터를 BYTE 값에서 Enum Value로 뜯어 고치는 일을 했는데. 빌드는 성공하는데 테스트는 실패하여서 테스트 없었으면 어떻게 했을까. 한번 식겁했던 적이 있었네요.
저정도 코드 베이스면 리펙토링을 할까.. 고민을 해도 너무 거대해서 포기하게 되고, 코드는 더 얹어지고.. 아마 그런 무한 루프에 빠진게 아닌가 조심스럽게 추측해봅니다.
저 분이 힘들었던 것도 이해가 가는데,
역설적으로 "테스트가 이 만큼 중요하구나" 라는 생각이 들게 만드는 글이어서 번역해봤습니다.
이 답변의 원 질문글에는 총 578개의 답변이 달렸는데요.
Ask HN: What's the largest amount of bad code you have ever seen work?
https://news.ycombinator.com/item?id=18442637
1레벨 답변들만 봐도 재미납니다. 사람사는데 다 똑같다는 생각이..