본문 바로가기
바닐라코딩/Boot Camp

바닐라코딩 3주차 정리

by Dev_Dank 2021. 11. 20.

강의

이번주의 강의 내용은 기본적인 정렬알고리즘과 프로그래밍 패러다임에 관한 내용이었습니다. 

출처: programiz

Bubble Sort
- 총 n개의 입력이 주어졌을때 n-1, n-2,....,1 만큼 자기옆의 원소와 비교연산을 수행하여 정렬을 수행합니다.
- 위의 과정때문에 시간 복잡도는 O(n^2)입니다.
- 장점
in-place 방식 이기 때문에 별도의 메모리 공간을 차지하지 않습니다.
인풋이 이미 정렬된 상태일경우 시간복잡도가 O(n)이기 떄문에 정렬이 이미 되어있던 정도를 확인 가능합니다.
-단점
시간복잡도가 O(n^2)으로 느립니다. 

출처: geeksforgeeks

Insertion sort
- 버블 소트와 마찬가지로  현재 선택된 원소를 원쪽의 원소들과 비교해 나가며 올바른 자리에 삽입 하는 정렬 방식입니다. 
- 위의 과정때문에 시간 복잡도가 O(n^2)입니다. 
- 장점
in-place 방식 이기 때문에 별도의 메모리 공간을 차지하지 않습니다.
-단점
시간복잡도가 O(n^2)으로 느립니다. 

출처: techdelight

Quick Sort
- 피벗을 선택후 해당 피벗을 기준으로 작은숫자는 피벗의 왼쪽 큰 숫자는 피벗의 오른쪽으로 정렬합니다. 
- 위의 과정을 재귀적으로 반복합니다. (Divide and Conquer)
- 장점
이름처럼 평균적인 시간복잡도가 빠른 편입니다. (피벗을 항상 중간 값으로 잡으면 시간 복잡도는 O(nlogn)이 됩니다. 
in-place로 구현하여 추가 메모리를 사용하지 않을 수 있습니다. 
- 단점
피벗을 항상 큰숫자나 작은 숫자로 잡을 경우 시간 복잡도가 O(n^2)으로 느려집니다. 
따라서 이미 정렬된 데이터에 퀵소트를 적용시키면 비효율적입니다.

출처: geeksforgeeks

Merge Sort
- 데이터를 각 원소가 1개인 리스트가 될때 까지 쪼갠후 다시 차례대로 합쳐 나가는 정렬 알고리즘입니다. 
- 퀵소트와 마찬가지로 Divide and Conquer에 해당합니다. 
- 장점
최악의 경우에도 시간 복잡도가 O(nlogn)입니다. 
-단점
원소의 갯수 만큼 추가적인 메모리 공간을 소비해야합니다. (데이터가 각 1개가 될때 까지 쪼개기 때문에 담아둘 공간이 필요합니다.)


과제

이번주의 과제는 학습한 정렬 알고리즘을 MVC 패턴을 이용해 시각화 시켜보는 것 이었습니다.

과제 자체의 구현은 시간에 맞추어 끝냈으나.... 사실 MVC 패턴을 적용해보는게 처음이라 너무 헷갈리는 부분도 많았고 코드도 너무 지저분하고 가독성이 좋지않게 작성된것 같습니다 ㅜㅜ

먼저 회고를 하기 전 MVC 패턴이 뭔지 다시 한번 상기해보도록 합시다. 

https://developer.mozilla.org/ko/docs/Glossary/MVC

 

MVC - 용어 사전 | MDN

MVC (모델-뷰-컨트롤러) 는 사용자 인터페이스, 데이터 및 논리 제어를 구현하는데 널리 사용되는 소프트웨어 디자인 패턴입니다. 소프트웨어의 비즈니스 로직과 화면을 구분하는데 중점을 두고

developer.mozilla.org

출처: MDN

MVC 패턴이란 Model / View / Controller 로 프로그램의 구조를 나누는 것을 의미하며 그렇게 하는 이유는 유지보수를 쉽게 하기 위해서입니다. 

- 모델
비즈니스로직에서 데이터를 저장 하는 역할을 맡습니다. 
"무엇"을 할지 정의합니다. 
컨트롤러와 뷰에대하여 알지 못하며 분리 되어있습니다. 

-컨트롤러
모델과 뷰를 연결시켜주는 역할을 합니다. (중간 다리 역할)
모델과 뷰에게 직접적으로 지시를 내리는 역할을 하는 부분으로 생각할 수 있습니다. 
"어떻게" 할지 정의 합니다. 

-뷰
사용자에게 직접 보여지는 부분을 맡습니다. 
"화면"을 보여주는 기능을 합니다. 
컨트롤러와 모델에 대해 알지 못하며 분리되어있습니다. 

위의 내용을 바탕으로 코드를 분리시키려 노력해봤는데.... 인터넷 아티클과 멘토분들마다 자신이 생각하는 MVC의 정의가 달라서 너무 혼란스러웠습니다. 

예를 들어 이번과제르 진행하면서 html 폼에서 submit 이벤트가 발생하면 addeventlitener를  통해 입력값을 받아오는 로직이 필요했는데 이 경우 addeventlitener를 컨트롤러에서 해야할지? 아니면 뷰에서 해야할지? 의견이 멘토분들마다 달랐습니다. 

저는 결국 addeventlitener를 view 에서 달고 view 에서는 데이터가 들어오면 이벤트를 발생시켜 컨트롤러에게 전파(dispatch)하는 형태로 구현했는데  이유는 다음과 같습니다. 

addeventlitener를 컨트롤러에서 처리할경우....
-> DOM 과 관련된 요소의 작업(view의 작업)을 컨트롤러가 관리하게됨.
-> 그경우 view와 controller의 결합도가 높아지면서 차후 관리가 어려워 질것 같음.

addevent listener는 전부 뷰에서 처리하는 대신 뷰에서 이벤트를 발생시킬 수 있는 addEvent와 dispatch기능을 만들고
컨트롤러에서 뷰에서 발생하는 이벤트에 따라 콜백을 등록할 수 있게 해봤습니다. 

사실 아직까지도 이게 최선이었는지 잘 모르겠습니다. 왜냐하면 결국 뷰에서  등록된 이벤트가 발생되면 뷰에서 콜백을 실행 시키는데 이는 결국 또 뷰가 컨트롤러에서 넘겨준 로직을 실행 시키는 것 같고 컨트롤러와 뷰가 분리가 된 건지??? 좀 애매한 느낌이 듭니다.

코드리뷰에서는 "괞찮게 했다" 정도의 피드백을 받았는데 흠.....뭔가 석연치 않은 기분입니다.

현업에가서 실제로 대규모의 앱을 만들어 보면 조금더 감이 오지 않을까 싶습니다.  

이번과제에서 또 한가지로 너무 부족했던 부분은 그놈에 코드 가독성과 유지보수성입니다....

이번 알고리즘 시각화에서 애니메이션효과를 욕심부려서 내려고 했더니 html요소를 자바스크립트로 일일히 가져오게되어 뷰가 겉잡을수 없이 방대해졌습니다. 

가져오는 html요소는 왜이리도 많은지....
즉석에서 만드는 html요소는 왜이리도 많은지....
위치좌표를 얻기위한 계산은 왜이리도 많은지....
이렇게 피드백이 올걸 예상했지만 결국 시간내에 코드 가독성을 높이지 못했다 ㅜㅜㅜㅜㅜ

그렇게 되다 보니 만약 현재의 코드가 나중에 확장되어야 한다면 정말 너무 복잡해졌을 것 같습니다. 차라리 해당 엘리먼트들은 미리 HTML파일에 요소로 만들어 놓고 display:none 속성을 주어 필요할때만 가져오는 방식으로 했어야 할 것 같습니다. 

또한 이번에 한 멘토분께서 "고수들은 코드사이에 개행을 하지않는편이다. 왜냐하면 그편이 오히려 코드가 응집성있어서 보기가 좋다" 라는 말을 들어서 일부로 개행을 최대한 줄여봤는데 오히려 코드리뷰를 해주신 분께서는  로직실행의 "문맥"이 바뀔때마다 개행을 해주는 것이 더 가독성이 좋다 라고 조언해주셨습니다. 

개인적으로도 후자의 경우가 더 맞는 것 같아서 후자의 방향으로 가려합니다. 

그리고 이번 과제에서 너무나도 부끄러웠던 점은 세미콜론과 객체 리터럴작성시 띄어쓰기와 같은 기본적인 부분을 너무나 많이 지적 받았다는 점입니다. 

1, 2 주차때는 과제에 emmet이 기본 개발 dependency로 설정이 되어있어서 저장할때 마다 자동 포매팅이 되어서 좋았는데 알고보니 자동 포매팅기능을 사용하면 안된다고 3주차때 알게되어 3주차때는 자동포맷팅을 껐는데 이런일이 발생했습니다. 

아직 저는 초보이기 때문에 자동 포매팅으로 그냥 넘어갈 경우 모르고 넘어가게되는 기본적인 코드 작성법들이 많기때문에 끄고 연습하는것이 맞겠지요. 그리고 그 예상은 적중하여 이번 3주차에 후폭풍으로 날아왔습니다 ㅎㅎㅎㅎㅎㅎㅎ

아...ㅋㅋㅋ

 

음...
????
ㅗㅜㅑ
ㅜㅜㅜㅜ

그리고 변수명이 너무 두루뭉술한 경우도 있엇고 함수명이 동사로 시작하지 않는 경우도....

분명 전부 프렙때 한번씩 지적 받았던 부분들인데 본과정에서 로직구현에 정신을 집중하다보니 또 놓치게 된것 같습니다.

켄님이 2주차때 언급하셨던 부분.... 노력이 부족했다 ㅜㅜ

아직 노오오오오력이 많이 부족했던것 같습니다. 다음주차에는 제발 이런실수를 발생시키지 않아야 합니다...


부족하다고 느낀부분

너무나도 기본 사항을 지키지 못한점이 자동 포멧팅을 쓰지 않자 바로 드러났습니다. 다음주에는 이런 부분이 없어야합니다.
코드가독성을 반드시 높여야 합니다. 코드는 나만 볼것이 아니며 협업을 하면서 공유되기때문입니다. 
변수명, 함수명은 구체적으로 꼭 만들어 줍시다. 다른사람도 이해가 가능해야합니다. 
상수는 대문자와 스네이크케이스를 주로 이용합니다. (THIS_IS_CONSTANT)
반복되는 상수는 따로 변수로 빼서 관리합시다. (문자열 포함! "bubble_sort" >const BUBBLE_SORT = "bubble_sort")
직접적인 인라인 스타일 조작보다는 classList를 활용하려 해봅시다. 
less 파일이 있었음에도 변수활용을 하지 않았었습니다. -> 쓰라고 준 기능은 활용해야합니다. 

'바닐라코딩 > Boot Camp' 카테고리의 다른 글

Geospatial data and B-Tree  (0) 2022.03.31
바닐라코딩 6주차 정리  (0) 2021.12.12
바닐라코딩 5주차 정리  (0) 2021.12.05
바닐라코딩 2주차 정리  (0) 2021.11.14
바닐라코딩 1주차 정리  (0) 2021.11.06

댓글