Facts
- 페어 프로그래밍
- 프론트엔드 개발자를 꿈꾸게 된 동기를 다시 한번 생각해봄
- MVC모델에 대해서 한번 더 생각해봄
- 페어의 브랜치에서 작업한 것을 가져오기 위해 git을 공부함
Feelings & Findings
월요일이라 오후 1시부터 시작이였지만 페어와 10시에 만나서 페어 프로그래밍을 진행했다.
간단하게 어떤 피드백을 받았는지 확인하고, 피드백을 수정했다.
받은 피드백들은 아래에 정리해두었다.
- js에서는 style이 아닌
class로style을 적용해라. - 테스트 코드는 기능 / 레이아웃으로 나누어라.
private로 사용되는#은크로스 브라우징 이슈가 남아있다. 크로스 브라우징 이슈가 있다는 것만 알아두고사용하는 것은 권장한다.- 상수 파일에 함수를 사용하는 것도 괜찮다. - 질문했던 것임
- e.keyCode는 사용하지 않는다. 사용해야 한다면
e.key를 사용하자. - 항상
reduce가 옳지는 않다.가독성을 위해 복잡한 로직이 아니라면map, filter, sort등을 잘 사용하자. 현재 MVC 패턴에 handlers, listeners가 있는데 컨트롤러가 이 둘에 대해 의존성을 가지고 있고, 이 둘은 컨트롤러에 대해 의존적이면 안된다.하지만 우리의 구성을 살펴보면 반대로 되어있는데, 이렇게 되면 추후 코드 로직이 많아지면 분석이 어려울 수 있다.
차라리 도메인별로 분리하자. - 하나로 합쳐라!
이런 피드백들을 받았고, 대부분은 쉽게 이해하고 수정할 수 있었다. 하지만 마지막 MVC 패턴에 대해서 다시 한번 고민하게 되는 순간이 왔는데, handlers, listeners들을 다시 컨트롤러에 합치게 된다면 컨트롤러가 너무 비대해지는 것이었다. 함수가 너무 많아서 코드를 읽기가 힘들고, 어플리케이션이 더 커진다면 점점 더 힘들어질 것은 뻔했다.
그래서 어떻게 해결할 수 있을까에 대해서 생각하다가 페어가 얻어온 정보를 토대로 service.js파일을 만들어서 그 안에서 컨트롤러의 역할을 대신 수행하도록 했다.
무슨 말이냐면 controller.js에서는 사용자의 요청/정보를 받아서 listeners, handlers 역할만 하고 service에서는 실제로 받은 정보를 모델에게 전달해 업데이트된 상태를 받아서 뷰에게 전달해 화면을 렌더링하는 형태이다.
솔직히 기존과 많이 다르지는 않다고 생각하지만 컨트롤에 모든 로직을 몰아넣는 것에 대해 회의적이라 어쩔수가 없다. 리뷰어분께 질문을 하면서 개선해야겠다는 생각으로 도전해보기로 했다.
난 지금 구조가 한 눈에 보기에 수월하다고 생각한다. 사용자의 요청을 받는 부분은 모두 controller.js에 있고, 그 요청을 처리하기 위해 모델과 뷰에 전달하는 것은 service.js에, 모델에서는 lotto에 대한 비즈니스 로직, 뷰에서는 화면 랜더링만 맡고 있다. 항상 어떤 코드를 짤 때, 자신만의 이유가 있는 것이 좋다고 배웠는데, 지금은 이유가 있기 때문에 맞는 코드라고 생각한다.
그래도 다시 한 번 MVC 패턴에 대해, MVC 패턴 다음 패턴에 대해서 공부를 해봐야겠다.
정말 요즘 느끼는 것은 코드를 짜는 것이 어려운 것이 아니라 변수명, 함수명과 이런 패턴에 대한 고민으로 하루를 보내는 날이 더 많아지고 있다.
실력 향상에 도움이 될지 모르겠지만 페어와 얘기를 많이 나누면서 생각을 많이 하려고 한다.
페어 프로그래밍을 7시 정도까지 했고, 중간에 1시에 데일리 미팅을 했는데 그때 프론트엔드 개발자가 되기로 한 이유를 말하는 시간이 있었다.
그래서 한번 생각해봤는데 살면서 이렇게까지 어떤 것에 대해 길게 설명할 수 있었던 적이 없던 것 같다. 지금까지는 좋아하는 것이 없었고, 있다고 해봐야 노래? 정도였는데 언제부터 좋아했냐고, 왜 좋아하게 되었냐는 질문을 받으면 난 그냥이라는 말밖에 할 수가 없었다.
하지만 프론트엔드 개발자가 되기로 한 이유는 정말 길게 말하면 한시간도 말할 수 있다.
이런 모습을 보고 정말 내가 원하는 것이라는 것을 다시 한번 느낄 수 있었고, 코딩의 즐거움을 잊지 말고 살아야겠다고 생각했다.
마지막으로 페어와 작업한 브렌치에서 내 저장소로 pull을 해오고 싶은데 충돌을 어떻게 없앨 수 없을까에 대해서 고민도 해보고 검색도 해봤지만 충돌을 없앨 수는 없다는 결론이 나왔다. 아직 완벽하게 모든 정보에 대해 조사한 것이 아니기 때문에 충돌을 없앨 수 있는 방법이 있을 수 있지만 그냥 지금은 충돌을 해결했다는 커밋을 남기는 것이 최선인 것 같다.
plans
- 매일 회고를 작성하면서 배웠던 것을 돌이켜보기
- 새롭게 배운 것이 있으면 항상 기록해두기
- 배운 것을 까먹지 않기
