|
34 | 34 | "@type": "Organization", |
35 | 35 | "name": "차한음", |
36 | 36 | }, |
37 | | - "datePublished": "2022-06-05", |
| 37 | + "datePublished": "2025-10-09", |
38 | 38 | "description": "라이브러리를 자제하여 사용한다 자신의 역량으로도 충분히 개발할 수 있는 기능인데 굳이 라이브러리를 가져다가 사용하는 경우가 있다. 바로 라이브러리를 가져다가 사용하면 시간적인 효율..." |
39 | 39 | } |
40 | 40 | </script> |
|
69 | 69 | <main class="post-content"> |
70 | 70 | <header class="post-header"> |
71 | 71 | <h1 class="post-title">힙하게 코딩하는 방법</h1> |
72 | | - <p class="post-date"><time datetime="2022-06-05">2022년 06월 05일</time></p> |
73 | | - <p class="post-category"><a href="/posts/%ed%95%b4%ed%82%b9">[해킹]</a></p> |
| 72 | + <p class="post-date"><time datetime="2025-10-09">2025년 10월 09일</time></p> |
| 73 | + <p class="post-category"><a href="/posts/%ec%97%90%ec%84%b8%ec%9d%b4">[에세이]</a></p> |
74 | 74 | </header> |
75 | 75 | <div class="post-body"> |
76 | 76 | <article class="markdown-body"><h2>라이브러리를 자제하여 사용한다</h2> |
77 | | -<p>자신의 역량으로도 충분히 개발할 수 있는 기능인데 굳이 라이브러리를 가져다가 사용하는 경우가 있다. 바로 라이브러리를 가져다가 사용하면 시간적인 효율성은 증가할 수도 있지만, 나중에 그 라이브러리를 사용하는 코드에 큰 에러라도 난다면, 아니면 프로젝트의 필수적이고 핵심적인 기능을 하는 로직과 라이브러리를 사용한 로직에 충돌이 일어나게 된다면, 정말 힘들어질 수 있다. 간단한 기능을 하는 라이브러리라면 라이브러리를 사용하지 않고 기능을 구현하는 것이 장기적인 효율적 측면으로 좋다고 생각한다.</p> |
| 77 | +<p>자신의 역량으로도 충분히 개발할 수 있는 기능인데 굳이 라이브러리를 가져다가 사용하는 경우가 있다. |
| 78 | +바로 라이브러리를 가져다가 사용하면 시간적인 효율성은 증가할 수도 있지만, |
| 79 | +나중에 그 라이브러리를 사용하는 코드에 큰 에러라도 난다면, |
| 80 | +아니면 프로젝트의 필수적이고 핵심적인 기능을 하는 로직과 |
| 81 | +라이브러리를 사용한 로직에 충돌이 일어나게 된다면, |
| 82 | +정말 힘들어질 수 있다. |
| 83 | +간단한 기능을 하는 라이브러리라면 |
| 84 | +라이브러리를 사용하지 않고 기능을 구현하는 것이 |
| 85 | +장기적인 효율적 측면으로 좋다고 생각한다.</p> |
78 | 86 | <h2>다른 사람의 코드를 많이 읽는다</h2> |
79 | | -<p>나는 이 부분이 굉장히 중요하다고 생각된다. 나는 요즘 <a href="https://velog.io/@velopert">@velopert</a> 님의 사이드 프로젝트인 <a href="https://github.com/velopert/velofolio">velofolio</a>의 코드를 읽고 있다. 이처럼 다른 사람의 코드들을 많이 읽게 된다면 나의 코드 스타일도 좋아질뿐더러 프로그래밍 실력도 같이 증가하게 된다.</p> |
80 | | -<h2>코드에 주석을 많이 작성해둔다.</h2> |
81 | | -<p>나는 정말 깔끔하게 코딩하는 것을 좋아해서 주석을 많이 작성하지 않았다. 그런데 이번에 프로젝트를 조금 수정하려고 하니 뭔지 하나도 몰라서 정말 다시 코드를 작성하고 있는 상황이다. 이처럼 필요한 주석을 많이 작성해둔다면 프로그래밍을 할 때도, 협업을 할 때도 정말 도움이 된다.</p> |
| 87 | +<p>나는 이 부분이 굉장히 중요하다고 생각한다. |
| 88 | +나는 요즘 <a href="https://velog.io/@velopert">@velopert</a> 님의 사이드 프로젝트인 <a href="https://github.com/velopert/velofolio">velofolio</a>의 코드를 읽고 있다. |
| 89 | +이처럼 다른 사람의 코드들을 많이 읽게 된다면 |
| 90 | +나의 코드 스타일도 좋아질뿐더러 프로그래밍 실력도 같이 증가하게 된다.</p> |
| 91 | +<h2>이론과 실전은 함께 가야한다</h2> |
| 92 | +<p>나는 원래 어떤 이론을 배울 때 책이나 강의를 통해서 이론을 배우고, |
| 93 | +그 다음에 프로젝트를 함으로서 실전을 배웠다. |
| 94 | +그리고 다른 사람의 코드를 읽으면서 지식을 확장했다. |
| 95 | +그러나, 요즘에는 코드와 공식문서를 통해 이론과 실전을 함께 배우려고 노력 중이다. |
| 96 | +CS 지식이 아니라면 굳이 다른 강의나 책으로 공부할 필요가 없다. |
| 97 | +코드와 공식문서가 당신의 선생님이다. 이 두 가지 속에 당신이 배우고자하는 모든 지식이 내포되어 있다. |
| 98 | +이런 맥락에서 나는 요즘 <a href="https://github.com/cortesi/devd">devd</a> 코드를 읽으며 |
| 99 | +Golang의 net/http 패키지를 공부하고 있다.</p> |
| 100 | +<h2>코드에 주석을 많이 작성해둔다</h2> |
| 101 | +<p>나는 깔끔하게 코딩하는 것을 좋아해서 주석을 많이 작성하지 않았다.그런데 이번에 프로젝트를 조금 수정하려고 하니 뭔지 하나도 몰라서 정말 다시 코드를 작성하고 있는 상황이다.이처럼 필요한 주석을 많이 작성해둔다면 프로그래밍을 할 때도, 협업을 할 때도 정말 도움이 된다.</p> |
82 | 102 | <h2>코딩 이외의 것은 신경 쓰지 않는다</h2> |
83 | | -<p>이 것은 <a href="https://github.com/ry">Ryan Dahl</a>의 <a href="https://tinyclouds.org/rant">I hate almost all software</a>의 글을 읽고 실행하게 된 것 중 하나인데, 그냥 개발자는 코딩만 잘하면 되고 그 이외의 것을 신경 쓰지 말라고 하는 글이었다.</p> |
84 | | -<p>나도 원래는 VSCode를 꾸미고, <code>.vimrc</code> 파일을 꾸미는 걸 좋아했는데, 이 글을 읽고 이제는 코딩에 외의 부가적인 것은 하지 않으려고 노력하는 중이다.</p> |
| 103 | +<p>이 것은 <a href="https://github.com/ry">Ryan Dahl</a>의 <a href="https://tinyclouds.org/rant">I hate almost all software</a>의 글을 읽고 실행하게 된 것 중 하나인데, 그냥 개발자는 코딩만 잘하면 되고 그 이외의 것을 신경 쓰지 말라고 하는 글이었다. |
| 104 | +나도 원래는 VSCode를 꾸미고, <code>.vimrc</code> 파일로 Vim을 꾸미는 걸 좋아했는데, 이 글을 읽고 이제는 코딩에 외의 부가적인 것은 하지 않으려고 노력하는 중이다.</p> |
85 | 105 | <h2>컴포넌트 중심으로 코딩한다</h2> |
86 | | -<p>모든 것을 컴포넌트로 나누고, 체계적으로 개발하게 된다면 새로운 기능을 추가할 때나 버그를 고칠 때에 상당히 구조상으로 유용할 수 있다.</p> |
87 | | -<h2>클린 코드를 나중에 한다.</h2> |
88 | | -<p>만약 당신이 클린코드의 대해 비숙련자라면, 처음 어떤 기능을 개발할 때는 막코딩으로 개발해야 한다. 너무 막코딩 하면 안되겠지만은 일단은 흐름대로 코딩을 하는 것이 시간적으로나 기능적으로 효율적이다.</p> |
89 | | -<p>이유는 만약 당신이 클린 코드와 프로덕트 개발을 병행하여 한다고 생각해 보자. 현재는 프로덕트의 기능적인 구조도 잡히지 않은 상태이다. 먼저 당신은 그 프로덕트의 기능 구현을 위해 코드를 작성할 것이다. 하지만 그 구현을 하는 도중에 클린 코드가 필요한 부분이 있다면, 당신은 시간을 들여서 기능 구현을 위한 코드에 클린 코드를 할 것이다. 이 과정이 구현하는 중에 몇 번만 반복될 때, 당신이 일반적으로 클린 코드의 형태로 코딩을 잘 한다면 괜찮을 것이다. 하지만, 당신이 클린 코드를 잘 모르고, 어떻게 클린 코드의 형태로 코드를 작성하는지 모른다면, 당신은 기능 구현이 아닌 클린 코드를 위해 더 많은 시간을 쓰게 될 것이다.</p> |
90 | | -<p>이처럼 클린 코드에 대해 비숙련자라면 나는 병행하여 클린 코드를 하는 것은 추천하지 않는다. 왜냐하면, 지금 코딩하는 원래의 목적인 기능 구현이 아닌, 기능 구현을 위한 코드를 수정하는 것을 더욱더 중요하게 생각하여 코딩하기 때문이다. 만약 이런 식으로 코딩을 계속한다면, 당신은 기능 구현의 대한 본질이 흐려 저서 원래 생각한 기능 구현도 잘 못하게 될뿐더러, 클린 코드 한 코드도 만족스럽지 않은 두 마리의 토끼를 잃게 될 것이다.</p> |
91 | | -<p>그래서 나는 클린 코드에 대해 비숙련자라면, 조금의 기능을 구현할 때는 흐름대로 코딩하는 것이 맞는다고 본다. 그래야 결과물도 만족스럽고 효율적인 측면에서도 만족스럽기 때문이다.</p> |
| 106 | +<p>이는 어떤 언어로 프로그래밍하던 활용할 수 있다. |
| 107 | +모든 것을 컴포넌트로 나누고, 체계적으로 개발하게 된다면 새로운 기능을 추가할 때나 버그를 고칠 때에 상당히 구조상으로 유용할 수 있다. |
| 108 | +그리고 모든 컴포넌트는 직교성을 부여해주는 것이 좋다. |
| 109 | +컴포넌트의 직교성이 유지된다면 그 컴포넌트는 하나의 일만 하는 것이 아닌 |
| 110 | +다양한 일을 할 수 있게 되기 때문이다.</p> |
| 111 | +<h2>클린 코드를 나중에 한다</h2> |
| 112 | +<p>만약 당신이 클린코드의 대해 비숙련자라면, 처음 어떤 기능을 개발할 때는 막코딩으로 개발해야 한다. 너무 막코딩 하면 안되겠지만은 일단은 흐름대로 코딩을 하는 것이 시간적으로나 기능적으로 효율적이다. |
| 113 | +이유는 만약 당신이 클린 코드와 프로덕트 개발을 병행하여 한다고 생각해 보자. 현재는 프로덕트의 기능적인 구조도 잡히지 않은 상태이다. 먼저 당신은 그 프로덕트의 기능 구현을 위해 코드를 작성할 것이다. 하지만 그 구현을 하는 도중에 클린 코드가 필요한 부분이 있다면, 당신은 시간을 들여서 기능 구현을 위한 코드에 클린 코드를 할 것이다. 이 과정이 구현하는 중에 몇 번만 반복될 때, 당신이 일반적으로 클린 코드의 형태로 코딩을 잘 한다면 괜찮을 것이다. 하지만, 당신이 클린 코드를 잘 모르고, 어떻게 클린 코드의 형태로 코드를 작성하는지 모른다면, 당신은 기능 구현이 아닌 클린 코드를 위해 더 많은 시간을 쓰게 될 것이다. |
| 114 | +이처럼 클린 코드에 대해 비숙련자라면 나는 병행하여 클린 코드를 하는 것은 추천하지 않는다. 왜냐하면, 지금 코딩하는 원래의 목적인 기능 구현이 아닌, 기능 구현을 위한 코드를 수정하는 것을 더욱더 중요하게 생각하여 코딩하기 때문이다. 만약 이런 식으로 코딩을 계속한다면, 당신은 기능 구현의 대한 본질이 흐려 저서 원래 생각한 기능 구현도 잘 못하게 될뿐더러, 클린 코드 한 코드도 만족스럽지 않은 두 마리의 토끼를 잃게 될 것이다. |
| 115 | +그래서 나는 클린 코드에 대해 비숙련자라면, 조금의 기능을 구현할 때는 흐름대로 코딩하는 것이 맞는다고 본다. 그래야 결과물도 만족스럽고 효율적인 측면에서도 만족스럽기 때문이다.</p> |
92 | 116 | <h2>마크업을 최대한 체계적으로 작성한다</h2> |
93 | 117 | <p>이는 클린 코드를 할 때의 과정이며, 프로젝트의 마크업을 체계적으로 변경해야 프로그램에 CSS를 수정하거나 다시 마크업을 수정할 때 굉장히 편하게 수정할 수 있다. 나 같은 경우에는 마크업을 그냥 프로그램의 로직만 잘 굴러가면 됐지 왜 굳이 마크업까지 체계적으로 해야 해? 그냥 로직만 잘 동작하면 되는 거 아냐? 라고 생각하며 코딩했는데. 굉장히 큰 오산이었다. 마크업은 로직을 구성하는 것만큼 중요하다.</p> |
94 | 118 | <h2>최대한 코드의 형식으로 값을 표현하지 않는다</h2> |
|
0 commit comments