들어가며

데브코스에는 크게 세가지의 큰 프로젝트가 있다.
개인프로젝트, 팀프로젝트, 백엔드 협업 팀프로젝트.
그중에 개인프로젝트로 노션을 클로닝하는, 그러니까 노션을 카피하는 프로젝트를 최근에 진행했었다.

개발 취준생 특 : 카피닌자임

사실 노션을 그대로 만들줄 알면 내가 서비스를 출시했을 것이지만.... 현실은 그렇지 못하기 때문에... 선택과 집중을 해야했다.

우선 vanilla js를 잘 다루는게 목적이었기 때문에, css를 다뤄서 노션 페이지와 흡사하게 구현하는 것 보다는, 최대한 내가 만든 노션이 오류없이 잘 작동하도록 하는 것에 집중을 했던 것 같다.

keep

우선 만족했던 부분은 vanilla js로 프로그램을 작성하는데에 대한 숙련도가 많이 올랐다.

이걸 단편적으로 알 수 있었던 부분은 노션 클로닝을 하기전에 진행하던 개인 프로젝트를 노션 클로닝이 끝나고 다시 손봤을 때였다.

노션 프로젝트를 하기 전에는 js로 앱을 만든다고 했을때, 주먹구구식? 그냥 작동하기만 하면 된다고 생각을 하고 코드를 짰었다. 그러다 보니 코드를 수정해야 할 일이 생기면 전체의 절반을 싹 다 수정했어야 하는 일도 생겼었고, 주석을 달아놔도 코드를 이해하는데 큰 시간이 소요가 됐었다.

왜 이런일이 벌어졌나? 생각을 해보면 '뭣이 중헌디'에 대한 고민이 없었던게 큰 이유였던 것 같다.

코드를 짜면서 무엇이 중요한가에 대한 생각을 가진게 가장 큰 배움이었다.

결국 코드라는 것은 나중에는 여러 사람들이 열람을 해야하고, 수정을 해야한다. 그렇기 때문에 가독성과 유지보수성이 크게 중요할 수 밖에 없다.

그렇다면 어떻게 가독성과 유지보수성을 챙길 수 있을까...

• 가독성은 글이 잘 읽히는 정도라고 생각을 한다. 긴 글보다 짧은 글이 읽히기 쉽듯이 코드도 긴 코드보다 짧은 코드가 읽히기 쉬울 것이다.

• 그리고 코드의 구성요소들이 서로에게 영향을 미치지 않는다면, 어떤 수정사항이 생겨도 수정이 필요한 부분만 고칠 수 있을 것이다. 다른 구성 요소들에게는 영향이 가지 않기 때문에.

만약 중앙에서 앱이 동작하는데 필요한 정보들을 관리하고, 그걸 각각 필요한 곳에 뿌려준다음, 그 뿌려준 곳에서 변경이 일어날 때, 다시 중앙으로 변경을 업데이트 해주고, 다시 중앙에서 그걸 다시 필요한 곳에 뿌려준다면 위의 두가지 요구사항을 만족하는게 아닐까?

이러한 '중요한 생각'을 리액트에서는 props, state 등등으로 구현하는 듯 하다.

딴길로 갑자기 얘기가 샌듯 하지만 결국 중요한건 코드를 작성하는데에 어떤 특정 '시각'을 가졌다는것? 그래서 '시각'을 기반으로 나만의 '원칙'을 세우고 그 '원칙'을 기반으로 코드를 작성했다는 것일 것이다.

problem

하지만 새로운 시각을 가졌다고 코드를 멋들어지게 쓸 수 있는건 아니었다.

내가 프로젝트를 진행하면서 생겼던 문제점들은

• 내가 집중력을 유지 할 수 있는 크기보다 코드가 커지면 에러가 뿜어져 나와도 그걸 고칠 엄두가 나지 않았다는 점

• 얕은 depth에도 불구하고 컴포넌트의 상태관리 동작을 파악하기가 힘들었다는 점

• 거대해진 중앙집중처리소에 대한 가독성이 현저히 떨어졌다는점

• 기능을 하는 코드들의 순서가 일관되지 못했다는 점 ex) a파일에서는 상태 업데이트 코드가 위에 렌더링 코드 아래 b파일에서는 렌더링 코드가 위에 상태 업데이트 코드가 아래 이런식

이정도가 있었다.

문제는 위의 모든 사항들이 현업에서는 굉장히 치명적일 수 있다는 점이다.
결국 계속 언급을 하게 되지만, 다수가 읽고 고쳐야하는 코드를 짜게 된다면...?
이라는 시각에서 보았을 때 문제점이 더 부각이 될 것이다.

코드가 이따~만큼 엉켜있다 이말이에요

try

해결책은 다음과 같이 정리 할 수 있을 것 같다.

• 코드를 작성하다 집중력이 흐려지면 코드가 어떻게 작동이 되는지 파악하는 능력이 현저히 떨어지므로 코드가 작동하는 흐름을 그림으로 그려놓고 계속 의식하면서 코드를 작성할 것.

• 컴포넌트형 사고를 자주 해보는것? 익숙하지 않은 것을 익숙하게 만드는 과정은 항상 어렵다...

• 중앙처리소에 대한 문제를 해결할 방법을 생각해봐야겠는데, 우선 앱의 크기가 그렇게 크지 않을 경우 연습한다 생각하고 계속 중앙에서 상태를 관리하면 좋겠다는 생각이다. 하지만 크기가 커질수록 디자인 패턴을 쓰면 좋을 것 같다는 생각이 있다.

• 코드를 짜기 전에 고민을 어느정도 할 것? 예를 들면 어떤 식으로 렌더링을 하고 상태를 업데이트 할 것인지 같은것? 코드를 짜면서 생각을 하면 코드 작성 순서가 좀 깨지는 경우가 있는 것 같다.

위에 나열한 사항들이 개인적으로는 추상적이라고 생각한다. 뭔가 수치적으로 개선 될 수 있는 부분은 아니니까. 굳이 따지자면 에러가 뿜여지는 횟수가 얼마나 줄었는가...? 수치적인 개선은 항상 어렵다...

앞으로 vanilla js로 교육과정중에 뭔가를 만드는 일은 없겠지만, 개인프로젝트로 하고있으므로 개인프로젝트 중간중간 회고를 짧게 하면서 위의 사항들이 잘 지켜지고 있는지 확인 할 수 있을것이다.

+ vanilla js 소감

포토샵 쓰지 말고 그림판으로 그림 그려봐라~ 하는 느낌이었다...

동료수강생들이 그림판으로 그린 그림

내가 싼 똥