작은 웹앱은 곧잘 만드는데요.. 덩치가 좀 커지니까 버그들이 너무 많이 생깁니다.
한참을 걸려 간신히 잡았는데, 그 과정속에서 난도질을 해놓아.. 버벅이고 엉망이네요.
오류나 문제점, 보완할 점들을 개선하라고 했더니, 또 다른 버그들을 만들어 잡는데 한참걸립니다.
클로드에게 코딩정리하라니까 이게 문제네 저게 문제네 하면서 패치를 해주었습니다.
이걸로 바꿨더니.. 와.. 버그 없이 깔끔하게 잘 돌아가네요.
너무나 괘씸해서 제미나이에게 클로드코딩 (코드1)과 제미나이코딩 (코드2)를 비교해 달라고 했습니다.
복슬복실 : 두 코드를 분석해서 어떤 코드가 어떻게 더 좋은지 분석해봐
제미나이 :
코드 1(Source 1)이 코드 2(Source 2)보다 비교할 수 없을 정도로 완성도와 안정성이 뛰어난 코드입니다.
코드 2는 정규표현식 오류로 인한 데이터 왜곡, 날짜 하드코딩, 시트 수식 파괴, 동시성 충돌 등 실제 서비스 운영 시 즉각적인 장애를 유발할 수 있는 치명적인 결함들을 다수 포함하고 있습니다. 반면 코드 1은 이러한 결함들을 전부 수정하고 캐싱과 락(Lock)을 적용한 엔터프라이즈급 실무 배포 코드입니다.
두 코드의 구체적인 차이와 코드 1이 더 우수한 이유를 항목별로 분석해 드립니다.
1. 치명적 버그 수정
....
결론적으로 실사용 및 배포에는 모든 면에서 보완된 코드 1(Source 1)을 채택해야 합니다.
그래서 한번더 물어보았죠.
복슬복실 : 너가 코드를 만든다면 코드1과 같이 만들 수 있을거 같아 아니면 코드2와 같이 만들 수 있을거 같아?
제미나이 :
제가 코드를 작성한다면 주저 없이 코드 1과 같은 형태로 만듭니다.
코드 2는 머릿속의 아이디어를 빠르게 확인해보는 초기 프로토타입(PoC) 수준에 가깝고, 코드 1은 실제 환경에서 사용자가 매일 오류 없이 쓸 수 있도록 다듬어진 프로덕션(상용 배포) 수준의 코드이기 때문입니다.
구체적으로 코드를 구현할 때 지키는 기준은 다음과 같습니다.
...
따라서 제가 직접 코드를 구성한다면 초기 요구사항 정의 단계부터 코드 1의 예외 처리, 동시성 락, 동적 스캔, 캐싱 구조를 기본 뼈대로 잡고 작성합니다
ㅎㅎㅎ
초기부터 엉망으로 만들어놓고... 대답은 1등입니다.
