좋은 개발자가 갖춰야 하는 기본 7가지

단지 시간이 흐른다고 해서 초급 개발자를 벗어나는 것은 아닙니다. 초급 개발자 딱지를 떼고 프로페셔널한 개발자가 되기 위해서는 기본적으로 갖춰야 하는 몇가지 코딩 습관이 있습니다. 하지만 가끔 프로젝트에서 기본적인 습관도 갖추지 않은 개발자들을 만날 때가 있는데요. 그런 사람들이 짠 코드를 보면 이기적인 코드라는 생각이 들기도 합니다.

개발자의 코딩 습관은 하루 아침에 고쳐지지 않습니다. 그렇기 때문에 잘못된 코딩 습관을 가지고 있다면 고치는데 많은 시간이 걸리죠. 만약 여러분이 아래에 적어놓은 코딩 습관 가지고 있다면 기본을 갖춘 개발자라고 할 수 있습니다.

1. 의미를 갖는 네이밍을 해라

코드를 짤 때 네이밍하는 것은 은근히 힘든 일입니다. 오죽하면 프로그래머의 힘든 Task 중 1위가 Naming things일까요.

의미있는 이름으로 변수명이나 메소드 이름을 짓는 것은 가장 기초적인 코딩 습관입니다. 따라서 x, y, abc와 같이 아무 의미 없는 이름을 쓰지 않아야 합니다.

그리고 변수명이나 메소드 이름은 영어로 의미가 통용되어야 한다. gubun, saram 같이 한글 발음을 그대로 적은 코드도 있습니다. 개발자에게 영어는 기본인 만큼 귀찮더라도 올바른 영어 단어로 네이밍을 해야합니다. 그리고 주석이나 문서로 변수나 메소드를 설명하기 보다 코드를 통해 바로 뜻을 알 수 있게 명칭을 써야 합니다.

당연한 얘기겠지만 의미있는 변수명을 쓰는 것은 누가 그 코드를 읽던지 가독성을 높여줍니다. 그리고 쓸데 없는 주석을 추가하지 않아도 되죠. 

코드를 통해 의미를 전달하기 위해서 네이밍을 하다보면 이름이 길어지기도 합니다. 하지만 걱정할 필요는 없습니다. IDE를 쓰면 코드 리펙토링 과정에서 얼마든지 효율적으로 간단하게 줄일 수 있습니다.

만약에 네이밍 하기가 너무 복잡하다면 그 변수나 메소드를 생성하기 전에 뒤로 한 걸음 물러서서 다시 생각해봐야 합니다. 메소드가 너무 많은 일을 하는 것은 아닌지, 변수가 너무 많은 것을 담으려고 하는 것은 아닌지 고민해봐야 합니다. 그리고 더 세세한 모듈로 리펙토링할 수는 없는지도 따져봐야 합니다.

2. 적당한 크기의 메소드를 만들어라

적당한 라인 수를 갖는 메소드를 만드는 것은 의외로 중요한 습관입니다. 이 코딩 습관에 대해 구체적으로 말하자면, 메소드 하나의 라인 수는 최대한 20-30 라인을 넘기지 않아야 합니다.

이 습관이 중요한 이유는 모듈화할 수 있는 능력과 연결되기 때문입니다. 만약 코드를 모듈화하는 분석적인 설계를 하지 못하면 엄청난 양의 if문과 for문을 한 메소드에 넣게 됩니다. 이런 코드는 정말 악몽이죠.

이런 코드를 짜는 사람은 처음에는 어떻게 코드가 흘러가는지 알기 때문에 괜찮다고 생각할 것입니다. 하지만 확신하건데 시간이 얼마 지나고 나면 그 코드 때문에 힘겨운 시간을 보내게 될 것입니다. 만약 그런 일이 벌어지기 전에 일을 그만 뒀다면 그 몫은 후임자가 되고, 여러분은 엄청난 욕을 먹게 되겠죠. 

3. 메소드에 너무 많은 인자를 넣지 말라

한 메소드가 너무 많은 인자를 가져야 한다면 이는 리펙토링이 필요하다는 단서가 됩니다. 메소드를 만들 때는 SRP (Single Responsibility Principle)를 염두에 두어야 합니다. 

메소드가 너무 많은 일을 하는 것은 문제가 있다는 의미입니다. SRP에 따르면 가장 효율적이고 깔끔한 메소드는 딱 한가지 일을 하는 메소드입니다. 

Uncle Bob 아저씨가 얘기했든이 한 메소드의 인자는 최대 3개까지만 들어가도록 해야 합니다. 이게 무조건 지켜야 하는 규칙은 아니지만 메소드를 만들 때 생각해볼 수 있는 하나의 기준이 될 수 있겠죠. 메소드의 인자는 적을수록 좋고, 아예 없으면 더 좋습니다. (Rober C. Martin 말 인용)

4. 한 클래스에 너무 많은 메소드를 넣지 말라

한 메소드에 들어가는 인자가 많으면 안 되듯이, 한 클래스에 들어가는 메소드 수 너무 많으면 안됩니다. 수 많은 메소드를 가지는 거대한 클래스 역시 너무 많은 일을 하는 컴퍼넌트 입니다. 보통 이런 클래스를 God Classes 라고 하는데요. God Classes는 대표적인 안티 패턴 중 하나입니다.

만약 메소드를 너무 많이 가지고 있는 클래스가 있다면 그 클래스의 행동을 바꾸기 위해서 얼마나 많이 그 클래스를 수정하게 되는가를 생각해봐야 합니다. 이런 클래슨느 아마도 Open-closed Principle 을 어기고 있는 클래스 일 것 입니다. OCP에 따르면 클래스, 모듈, 함수 들은 확장을 위해서는 개방되어야 하지만, 수정을 위해서는 폐쇄되어야 합니다.

5. 라이브러리는 항상 안정화된 LTS 버전을 사용하라

서드파티 라이브러니나 프레임워크를 사용할 때는 안정화된 LTS 버전을 사용해야 합니다. 참고로 LTS란 Long Term Support 버전을 의미합니다.

문제를 해결하기 위해 아직 검증되지 않은 서드파티 라이브러리를 쓰면 당장은 편할 수 있지만 이 후 후회하게 됩니다. 특히 후임자나 그 코드를 인수인계 받을 사람이 그 라이브러리 때문에 엄청나게 고생할 수도 있습니다. 따라서 서드파티 라이브러리를 사용할 때는 가장 최신의, 가장 많이 사용하는, 가장 안정적인, 가장 안전한 라이브러리를 사용해야 합니다. 

6. 일반적인 디자인 패턴을 배워라

큰 프로젝트는 하나 이상의 디자인 패턴을 통해 만들어집니다. 디자인 패턴은 컴퍼넌트의 서술, 관계, 추상화 레벨을 정의합니다. 물론 모든 디자인 패턴을 완벽하게 공부해야 하는 것은 아닙니다. 하지만 최소한 어느 정도는 알고 있어야 합니다.

일반적인 디자인 패턴을 알아야 하는 이유는 프로그램을 설계하거나 다른 사람이 만든 코드를 분석할 때 유용하기 때문입니다. 특히 코드 분석을 할 때 디자인 패턴을 알고 있으면 어떤 클래스와 어떤 오브젝트를 먼저 봐야 하는지 알 수 있기 때문에 효율적인 코드 분석이 가능합니다. 

또한 동료들과 커뮤니케이션 할 때도 서로 디자인 패턴에 대한 지식이 있으면 더 원할하게 커뮤니케이션이 이뤄질 수 있습니다.

7. 항상 다음 사람을 생각하자 (미래의 나를 포함해서)

코드를 짤 때는 미래의 당신, 그리고 동료, 심지어 다른 회사의 개발자까지 그 코드와 관계있는 모든 사람을 생각해야 합니다. 학생이 프로그래밍 과제로 개발할 때 처럼 나 외에는 아무도 그 코드와 상관 없는 경우에는 이런 생각을 할 필요가 없겠죠. 하지만, 현업에서 만드는 코드는 나 뿐 만 아니라 내 동료와 회사 그리고 다른 개발자에게 엄청난 영향을 줄 수 있습니다.

따라서 단지 동작하는데만 집중해서 편법적으로 코드를 짜거나 문서화를 게을리 하거나 리팩토링을 전혀 하지 않는다면, 미래의 당신을 포함해서 그 누군가는 그 대가를 톡톡히 치루게 될 것 입니다. 해외에서는 이런 걸 보통 Technical debt이라고 합니다. 이런 빚을 조금씩 쌓다보면 나중에 눈덩이가 되서 엄청난 피해가 되는 것이죠. 

마무리 하며

좋은 개발자가 되는 것은 하루 아침에 이뤄지지 않습니다. 프로그래밍을 할 때 위에 기술한 습관들이 몸에 베어 있어야 합니다. 개발자를 평가하는 요소는 여러가지가 있지만 가장 근본이 되는 것은 결국 코드입니다. 부끄러운 코드를 생산하지 않는 개발자, 다른 사람을 생각하는 이타적인 개발자가 좋은 개발자라고 할 수 있겠죠. 그렇게 좋은 개발자가 되어야 전문가로 인정받을 수 있는 것입니다.

이상 좋은 개발자가 갖춰야 하는 글을 마치며, 이 밖에 좋은 개발자 갖춰야 하는 습관이 있다면 댓글을 통해 얘기 나눠봤으면 합니다. 

번역 및 참고 : The 14 habits of highly effective developers (Part 1)