윤혁

처음 프로젝트를 시작했을때는 걱정 반 기대 반이였습니다.
과연 둘이서 2개의 판매처를 추가할 수 있을지의 걱정과 처음해보는 판매처 추가여서 기대되는 그럼 느낌이였습니다.
최초 기획은 신세계와 CJ 두 개의 판매처를 추가할 예정이였지만 CJ의 문제로 인해서 11번가로 대체되었습니다.
프로젝트가 시작하고 처음엔 기존에 작성된 코드들이 있어서 구현하는 부분은 크게 문제가 되지 않았지만, 각 판매처마다 특성도 다르고 기존 코드도 구현한 사람마다 구조가 달라서 저희는 최대한 객체지향적으로 설계를 하고 코드도 최대한 간결하고 보기 좋게 작성을 하려고 노력했습니다.
하지만 코드를 구현하면 구현할수록 각 판매처마다 예외적인 상황이 많아지고 시간도 촉박해서 점점 코드는 처음 의도와는 다르게 작성되기 시작했습니다. 프로젝트의 끝으로 가면 갈수록 일단 기능이 동작되는게 우선이 되는 상황도 벌어졌습니다.
시간이 좀만 더 충분했다면 코드도 기능도 더 완벽하게 구현할 수 있었는데 그 부분은 좀 아쉽습니다.
그래도 프로젝트를 진행하면서 승혁님과 어떻게 하면 코드를 더 잘 짤수 있는지 어떻게하면 더 객체지향적으로 설계를 할 수 있는지 논의를 하면서 개발적 실력은 한층 높아진것 같습니다. 또한 프로젝트를 진행하면서 객체지향적 설계가 왜 중요한지 다시 한번 깨닫게 되는 시간이였습니다.
승혁님께는 저도 판매처 추가가 처음이라서 많이 알려드리지 못해서 죄송하고, 그래도 프로젝트가 잘 진행될 수 있게 최선을 다해주셔서 감사합니다.
다음에도 프로젝트를 같이 진행하게 된다면 더 잘해봐요. 2주동안 수고많으셨습니다~!

승혁

프로젝트를 하면서 분업보다는 협업의 중요성에 대해서 배우게 되었다. 의도치 않게 페어 프로그래밍을 며칠간 진행하였는데, 같이 개발을 하다 보니 나중에 코드에 문제가 생겨도 서로에게 바로바로 도움을 줄 수 있었다.
윤혁님과 함께 클린코드와 객체지향, 의존성 관리의 중요성에 대해 느끼게 되었다. 그러다 보니 신세계와 11번가 API에 대해 모르는 개발자가 보더라도 최대한 이해하기 쉽고 유지보수 가능하도록 만들기 위해 노력했다.

프로젝트의 아쉬웠던 점

주문수집과 취소주문체크의 중복주문체크는 하나의 함수를 타는데 발송 오류 체크 쪽 컨트롤러만 함수가 아닌 컨트롤러 안의 코드로 작성이 되어있다.
당연히 같은 함수를 탈 거라고 예상했던 우리는 예상치 못한 반환 값에 2시간정도 헤메었다.
리포지토리 패턴이 사용 되었지만 컨트롤러와 DB가 여전히 강하게 결합 되어있었다.
테스트코드가 없어서 마이너한 코드 수정 이후에도 올바르게 동작한다는 보장을 할 수 없어서 그거 때문에 오히려 개발시간이 더욱 잡아 먹혀버리고 말았다.