라이브러리를 자제하여 사용한다
자신의 역량으로도 충분히 개발할 수 있는 기능인데 굳이 라이브러리를 가져다가 사용하는 경우가 있다. 바로 라이브러리를 가져다가 사용하면 시간적인 효율성은 증가할 수도 있지만, 나중에 그 라이브러리를 사용하는 코드에 큰 에러라도 난다면, 아니면 프로젝트의 필수적이고 핵심적인 기능을 하는 로직과 라이브러리를 사용한 로직에 충돌이 일어나게 된다면, 정말 힘들어질 수 있다. 간단한 기능을 하는 라이브러리라면 라이브러리를 사용하지 않고 기능을 구현하는 것이 장기적인 효율적 측면으로 좋다고 생각한다.
다른 사람의 코드를 많이 읽는다
나는 이 부분이 굉장히 중요하다고 생각된다. 나는 요즘 @velopert 님의 사이드 프로젝트인 velofolio의 코드를 읽고 있다. 이처럼 다른 사람의 코드들을 많이 읽게 된다면 나의 코드 스타일도 좋아질뿐더러 프로그래밍 실력도 같이 증가하게 된다.
코드에 주석을 많이 작성해둔다.
나는 정말 깔끔하게 코딩하는 것을 좋아해서 주석을 많이 작성하지 않았다. 그런데 이번에 프로젝트를 조금 수정하려고 하니 뭔지 하나도 몰라서 정말 다시 코드를 작성하고 있는 상황이다. 이처럼 필요한 주석을 많이 작성해둔다면 프로그래밍을 할 때도, 협업을 할 때도 정말 도움이 된다.
## 코딩 이외의 것은 신경 쓰지 않는다
이 것은 Ryan Dahl의 I hate almost all software의 글을 읽고 실행하게 된 것 중 하나인데, 그냥 개발자는 코딩만 잘하면 되고 그 이외의 것을 신경 쓰지 말라고 하는 글이었다.
나도 원래는 VSCode를 꾸미고, .vimrc 파일을 꾸미는 걸 좋아했는데, 이 글을 읽고 이제는 코딩에 외의 부가적인 것은 하지 않으려고 노력하는 중이다.
컴포넌트 중심으로 코딩한다
모든 것을 컴포넌트로 나누고, 체계적으로 개발하게 된다면 새로운 기능을 추가할 때나 버그를 고칠 때에 상당히 구조상으로 유용할 수 있다.
클린 코드를 나중에 한다.
만약 당신이 클린코드의 대해 비숙련자라면, 처음 어떤 기능을 개발할 때는 막코딩으로 개발해야 한다. 너무 막코딩 하면 안되겠지만은 일단은 흐름대로 코딩을 하는 것이 시간적으로나 기능적으로 효율적이다.
이유는 만약 당신이 클린 코드와 프로덕트 개발을 병행하여 한다고 생각해 보자. 현재는 프로덕트의 기능적인 구조도 잡히지 않은 상태이다. 먼저 당신은 그 프로덕트의 기능 구현을 위해 코드를 작성할 것이다. 하지만 그 구현을 하는 도중에 클린 코드가 필요한 부분이 있다면, 당신은 시간을 들여서 기능 구현을 위한 코드에 클린 코드를 할 것이다. 이 과정이 구현하는 중에 몇 번만 반복될 때, 당신이 일반적으로 클린 코드의 형태로 코딩을 잘 한다면 괜찮을 것이다. 하지만, 당신이 클린 코드를 잘 모르고, 어떻게 클린 코드의 형태로 코드를 작성하는지 모른다면, 당신은 기능 구현이 아닌 클린 코드를 위해 더 많은 시간을 쓰게 될 것이다.
이처럼 클린 코드에 대해 비숙련자라면 나는 병행하여 클린 코드를 하는 것은 추천하지 않는다. 왜냐하면, 지금 코딩하는 원래의 목적인 기능 구현이 아닌, 기능 구현을 위한 코드를 수정하는 것을 더욱더 중요하게 생각하여 코딩하기 때문이다. 만약 이런 식으로 코딩을 계속한다면, 당신은 기능 구현의 대한 본질이 흐려 저서 원래 생각한 기능 구현도 잘 못하게 될뿐더러, 클린 코드 한 코드도 만족스럽지 않은 두 마리의 토끼를 잃게 될 것이다.
그래서 나는 클린 코드에 대해 비숙련자라면, 조금의 기능을 구현할 때는 흐름대로 코딩하는 것이 맞는다고 본다. 그래야 결과물도 만족스럽고 효율적인 측면에서도 만족스럽기 때문이다.
마크업을 최대한 체계적으로 작성한다
이는 클린 코드를 할 때의 과정이며, 프로젝트의 마크업을 체계적으로 변경해야 프로그램에 CSS를 수정하거나 다시 마크업을 수정할 때 굉장히 편하게 수정할 수 있다. 나 같은 경우에는 마크업을 그냥 프로그램의 로직만 잘 굴러가면 됐지 왜 굳이 마크업까지 체계적으로 해야 해? 그냥 로직만 잘 동작하면 되는 거 아냐? 라고 생각하며 코딩했는데. 굉장히 큰 오산이었다. 마크업은 로직을 구성하는 것만큼 중요하다.
최대한 코드의 형식으로 값을 표현하지 않는다
만약 당신이 어떤 input 엘리먼트에서 입력하고 있는 값을 출력하고 싶다면 대략 이런 식으로 코드를 구성할 것이다.
const inputElement = document.querySelector('input');
const printElement = document.querySelector('div');
inputElement.addEventListener('keydown', e =>
printElement.innerHTML = e.target.value;
);그런데 이 코드는 나중에 수정이 필요할 때 힘들어 질 수 있다.
만약 가져오는 값이 e.target.value 가 아니라 div 엘레멘트의 key 값 라면 어떻게 할 것인가? e.target.attributes.key.value 처럼 작성해야 하는데, 이같이 처음 볼 때는 뭔지도 모르겠는 코드로 표현된 값을 작성하게 된다면, 나는 나중에 알아볼 수도 있겠지만 다른 사람이 이 값으로 다른 기능을 추가하기도 한다면, 만약 그 사람이 자바스크립트를 잘 다룰 수 없다면 이 코드를 해석하는데 많은 시간이 소요할 수도 있을 것이다.
그렇지만, 당신이 e.target.attributes.key.value 라는 코드적인 값을 const divKeyValue = e.target.attributes.key.value 로 어떤 변수에 선언만 해준다면, 그 사람은 변수명을 읽고 이 값으로 다른 기능을 빨리 추가할 수 있을 것이다.
이 처럼 코드적인 값으로 많은 기능을 추가하고 선언하다 보다면 나도 헷갈릴 수도 있고, 협업의 과정에서도 어려움이 생길 수도 있다. 그러니 웬만하면 코드적인 값은 변수에 담아서 사용하는 것이 좋다.
최대한 사용자의 관점에서 바라보고 개발한다
개발은 내가 구현하고 싶은 로직을 구현하고 싶어서 개발하는 것이 아니다. 또 내가 편하게 스타일 로직을 구현하고 싶어서 쉽게 마크업을 구성하는 것은 개발이 아니다. 그것은 그냥 내가 구현하고 싶은 기능과 레이아웃이며 사용자를 위한 로직과 레이아웃이 아니다. 모든 기능과 레이아웃 들은 사용자를 위해 개발되어야 한다. 만약, 사용자를 무시한 채로 개발된다면 그 프로덕트는 성공하지 못할 것이다. 만약 그 프로덕트가 성공하였다고 해도 그것과 기능적인 측면은 비슷하지만 사용자 친화적인 다른 프로덕트로 사용자들은 언젠가 넘어갈 것이다.
요 스웩~