1.1코드에 신경 쓰기

평범한 프로그래머와 훌륭한 프로그래머의 차이는 '태도'다. 회사에서 일어나는 다양한 제약과 압박 속에서도, 프로다운 접근 방식을 취하고 최고의 코드를 작성하려는 태도로부터 훌륭한 프로그래밍이 태어난다.

좋은 코드를 작성하고 싶다면 코드에 신경을 써야 한다. 이 말은 다음과 같은 의미이다:

1. 단지 작동만 하는 코딩은 거부해야 한다: 프로그래머는 올바르게 작동하는 훌륭한 코드를 짜도록 노력해야 하고, 올바른 작동을 증명하는 테스트 능력도 갖추어야 한다.
2. 의도가 드러나는 코드를 작성해야 한다: 다른 프로그래머들이 쉽게 파악하고 이해할 수 있어야 한다.
3. 유지 보수가 가능해야 한다: 자신이나 다른 프로그래머들이 이후에 쉽게 수정할 수 있어야 한다.
4. 정확해야 한다: 문제를 풀었음을 증명하는 모든 단계를 통과할 수 있어야 한다.
5. 협업을 중시해야 한다: 다른 프로그래머들도 읽기 쉬운 코드를 작성하고, 자신의 능력을 강조하기보단 팀원들과의 협업, 팀성과에 주안점을 두어야 한다.
6. 그 어떤 코드든 간에 해당 코드를 만지기 전보다 더 나아지도록 해야 한다: 더 나은 구조, 더 나은 테스트, 더 쉬운 이해

---

🥸 생각해보기

1. 코드에 신경 쓰는가? 자신이 만든 결과물에서 그 점이 어떻게 드러나는가?

물론 코드에 신경을 쓰려고 한다. 다만, 처음부터 완벽한 코드를 쓰려다간 아무것도 쓰지 못할것이라는 조언도 있어서 우선은 작동하는 코드들부터 쓰기 시작했다. 그렇게 몇 번의 프로젝트를 하다보니 이전의 코드들이 나중에 나와 동료들에게 미치는 영향에 대한 이해가 늘었고, 계속 주의하려고 하지만 가끔은 정말 엉터리 코드를 쓸 때도 있다. 주로 시간 압박에 의한 경우였다고 변명하고 싶다.

내가 만든 결과물에서 이 점이 드러나는 것은... 스스로 말하기는 사실 어려운 부분이지만 굳이 뽑자면 어떤 프로젝트에서도 일관성을 유지하는 것이라고 말하고 싶다. 특정 스타일을 고수하기보단 가급적 기존 프로젝트의 코드 스타일이나 내가 처음에 쓰던 스타일을 유지하려고 꽤 많이 노력을 하기 때문에, 회사 프로젝트에서도 내가 쓴 코드들이 동료가 쓴 코드에 비해 크게 다르다는 느낌보다는 익숙한 느낌을 줄 수 있도록 작성하려고 노력했다.

또, 변수명에 꽤 신경을 많이 쓰는 편인데 처음에 많은 시행착오가 있었고 지금도 사실 있겠지만 나름대로 다른 사람들이 봐도 이해하기 쉬운 변수명을 쓰고 있다고 생각한다.

2. 프로그래머로서 더 나아지고 싶은가? 가장 노력해야 하는 부분은 어떤 부분인가?

굉장히 그렇다. 다른 분야도 잘하면 좋겠지만 우선 프론트엔드 분야에선 장인이 되고 싶다는게 현재의 목표이다.

가장 노력해야 하는 부분은 하면 할수록 기본적인 부분에 대한 이해다. 그저 작동하는 코드는 이제 AI를 통해서 얼마든지 쓸 수 있다. 하지만 특정 라이브러리의 선택이나 DB구조 디자인, 보안, 성능, 깔끔한 코드 등은 모두 기본적인 내용에 대한 깊은 지식에서 온다고 생각한다.

이를 위해 관련된 기본 CS 지식을 계속 공부하고 있고, 적더라도 주말에도 코딩을 하려고 노력한다. 물론 부끄럽게도 많은 시간은 딱히 코딩 실력이 늘것 같지 않은 코딩을 하고 있긴 하다. 이 부분은 향상심과 끈기를 가지고 힘들어도 한 발 더 내딛는게 필요할 것 같다.

3. 코드에 신경 쓰지 않는다면, 왜 이 책을 읽고 있는가?

코드에 신경을 쓰기 때문에 이 책을 읽고 있는 그 외의 이유를 대자면...

'더 나은 프로그래머'라는 용어가 단지 코드에만 묶여있는것이라고 생각하지 않기 때문이다. 태도, 다른 사람들과의 협업, 마인드셋, 그리고 공부, 습관 등 다양한 요소가 더 나은 프로그래머를 만들지 않을까? 선배의 조언을 듣고 싶다는 마인드로 이 책을 집었다.

4. 좋은 프로그래머가 나쁜 코드를 만들 수도 있는가? 어떻게 그럴 수 있는가?

좋은 프로그래머는 다양한 요소가 있겠지만 어쨌든 좋은 코드를 쓰는 사람이라고 생각한다. 하지만 고의적으로나 비고의적으로나 나쁜 코드를 만들 수도 있을것 같다.

예를 들면 시간에 쫓긴다거나, 금전적 제약 때문에 고의적으로 나쁜 코드를 만들 수도 있을것 같다. 시간에 쫓겨 좋지 못한 변수명을 쓴다거나 보안이 덜 철저한 코드를 쓸 수도 있지 않을까? 서버 트래픽 제한이 있어서 의도적으로 타임아웃을 둘 수도 있을것 같다.

비고의적으로는, 서비스 자체가 많이 바뀌면 기존의 좋았던 코드가 나쁜 코드가 될 수도 있을것 같다. 개발 당시에는 윗선의 절대라는 말을 듣고 안 바뀐다고 확신하고 이렇게 코드를 썼는데, 이후에 근본적인 기능을 바꿔야한다거나 뭔가를 추가해야한다거나, 같은 컴포넌트의 다른 매개변수로 처리하면 될거라고 생각했는데 완전히 달라진다거나 하면 나쁜 코드가 되어 버릴 수 있을것 같다.