기간 7/6~ 7/28
✏️1주차 PR
1주차는 짝과 페어프로그래밍을 했습니다. 지난번 Todo리스트 만들때 해봤기 때문에 어렵지 않게 개발을 시작할 수 있었습니다.
짝과 돌아가면서 코드를 작성하다 보니 CSS네이밍의 이슈가 있었습니다. 파일을 하나로 관리하고 CSS이름을 각자의 방식대로 짓기 때문에 확인하기가 어려웠습니다.
CSS파일을 분리하고 BEM컨벤션을 이용하여 통일된 방식으로 네이밍을 지울 수 있었습니다.
Block단위로 이름을 짓고 Element와 Modify는 최대한 이해하기 쉽고 계층이 보이도록 작성했습니다.
개발을 하면서 발생한 문제점은 기능만 보고 개발을 시작하니 모든 로직들이 한 파일에 모여있어 가독성이 안 좋아졌고, 유지보수가 어려웠습니다.
✏️2주차 PR
1주차 미션인 페이프로그래밍이 마무리되어 2주차부터 혼자 개발하게 되었습니다.
기능이 늘어남에 따라 기존 한 파일에서 개발하던 로직들을 분리해야만 했습니다. 왜냐하면 코드가 길어져 가독성과 유지보수성이 떨어졌기 때문입니다.
크게 분리해야할 기준을 3가지로 잡았습니다. (이벤트로직, 비즈니스로직, 화면로직)
로직들을 3가지로 분리하고 개발을 진행하니 각 파일에 대해 역할이 분명했지만 데이터와 이벤트를 통신하기 위해서 각 파일별로 import와 export를 남발하기 시작했습니다.
로직을 분리하기만 하면 가독성이 좋아질 것으로 생각했지만 강한 의존성으로 인해 가독성이 떨어질 뿐만 아니라 기능추가시 수정이 어렵게 됐습니다.
✏️3주차 PR
새로운 기능이 계속 나오게 되고 더이상 강한 의존성으로 인해 개발이 불가능하다 판단해서 처음부터 다시 설계에 대한 고민을 시작했습니다.
2주차에 개발한 코드를 분석해보니 MVC패턴이었고 MVC패턴에 단점이 명확하게 보였습니다. 그래서 Store를 추가했고 Vuex를 바닐라로 구현하여 Flux패턴처럼 단방향으로 데이터가 흘러가게 개발했습니다.
데이터 관점으로 코드를 볼 때 유지보수가 편해 보였지만 스토어가 커지면서 스토어 안에 상태를 바꾸는 로직들이 여러게 추가되니 스토어가 커져 관리가 어려워졌습니다.
스토어를 효율적으로 관리하기 위해 스토어를 어떻게 분리할지 생각해 보면 더 좋을거 같습니다.
결과적으로 Vuex스토어를 만들어 Flux패턴을 적용해보니 기존 MVC패턴의 강한 의존성이 없어졌고 기능추가를 쉽게 할 수 있게되었습니다.
✏️4주차 PR
4주차 미션은 옵저버 패턴을 적용하는 것 입니다. 그래서 기존 Vuex스토어에 Observer 클래스를 상속받게 했습니다.
옵저버 패턴을 사용하니 model과 Store간에 느슨한 의존성이 형성되었습니다. 단순히 Model은 Store를 구독하기 때문에 Model과 Store간에 관계가 명확해 졌고 코드 가독성 측면에서도 더 좋아진거 같습니다.
스토어가 커지면서 스토어의 역할이 불분명해 졌지만, 옵저버 패턴추가로 Model부분에서 구독해야할 데이터를 파악할 수 있어 스토어의 역할 파악과 이벤트의 흐름 예측 가능해졌습니다.
Flux패턴과 마찬가지로 데이터의 흐름은 단방향으로 흐르나 옵저버 패턴은 객체의 관계에 집중한 느낌이고 Flux패턴은 데이터 흐름에 집중한 느낌이었습니다.
상황에 따라 적절하게 두 패턴을 활용하면 될거 같습니다.
기능은 어느정도 완성된거 같아 2주차 선택미션인 querySelector API를 직접 만들었습니다.
querySelector를 만들면서 알게된 점은 탐색은 깊이우선depth-first 전위pre-order순회를 한다는 것입니다.
만약 해당 알고리즘 대로라면 root노드부터 순서대로 노드를 탐색하기 때문에 만약 오른쪽 가장 마지막에 있는 리프노드를 찾는다면 효율이 떨어질 수 있다고 생각했습니다.
효율을 높이기 위해 가능 한 탐색범위를 좁게하여 querySelector를 사용해야 하는것을 배웠고, querySelector API를 깊게 이해할 수 있는 시간이었습니다.
2주차🔥 링크
3주차🔥 링크
