Clean Code의 시작

[왜 Clean Code?]

 

로직을 기가 막히게 짜고, 문제해결 능력이 뛰어난다고 한들 해당 코드가 쉽게 읽히지 않는다면 그것은 좋은 코드일까?

 

  약 9년 동안 코딩을 하면서 단 한 번도 "읽기 쉬운 코드"에 대해 생각해본 적이 없다.

대학생 때 까지만 해도 나는 다음 리스트를 만족하는 코드가 좋은 코드라고 생각했다.

1. 예외 처리가 잘 된 코드
2. 메모리를 절약한 코드
3. 각 언어 특성을 잘 이용한 코드

  운좋게 취업에 성공하고 "학생"이 아닌 "개발자"로서 꽃이 필 무렵 주석과 변수 혹은 Object 명, 함수명 등과 같은 네이밍 이야기를 할 수 있는 기회를 얻었다.

나의 팀장님께서는 이렇게 말씀 하셨다.

 

"가장 좋은 코드는 주석이 없고 변수 명만 봐도 뭐하는 녀석인지 알 수 있는 코드야."

 

위 조건을 만족하면서 로직이 개판이고 굳이 필요없는 메모리를 싹다 끌어와 사용하는 그런 코드가 좋을리가 없다.

곰곰히 생각에 잠겼다. 당황스러웠다.

학교에서는 분명 주석을 잘 사용할 줄 알아야한다고 배웠고 메모리를 잘 사용할 줄 알아야 좋은 개발자가 될 수 있다고 했거늘... (지금 현 시점에서 보았을 때 아주 맞는 말도 아닌 것 같다..)

난 결론을 내렸다.

 

"내가 짠 코드를 분명 다른 개발자도 보겠지? 추가 개발을 하려면 이해를 해야하겠지?

이해를 못하면 나를 엄청 욕하겠지? 아! 이해를 잘 할 수 있게 하는 코드가 좋은 코드구나?"

 

심지어는 내가 회사를 떠나면 물어볼 사람이 없을 수도 있다... 그렇기 때문에 읽기 쉬운 코드가 곧 이해하기 쉬운 코드이고 그 말은 즉슨 좋은 코드로 해석이 되었다.

  나는 바로 실행에 옮겼다. 그러나 쉽지 않았다. 나는 나만의 룰을 세웠다.

• 이름이 길더라도 이해하기 쉽도록 풀네임을 사용할 것.
• 예외를 잘 던지고 잘 받자.
• 프로젝트마다 룰을 파악하고 그 룰에 따를 것.

점차 적응해 나아갈 때 쯤, 한 팀장님께서 나에게 Clean Code 책을 추천해주셨다.

 

꼭 좋은 코드를 작성하는 개발자가 되겠습니다 팀장님!

 

교훈 : 깨끗하고 읽기 좋게 코딩하자!