개발자에게 필요한 3가지 원칙

1. 공통 질문

개발자라면 아래와 같은 고민을 언젠가는 한 번 쯤 해보았을 것이라고 생각합니다.

• “개발을 잘한다는 기준은 무엇인가?”
• “좋은 개발자라는 기준은 무엇인가?”
• “나는 실력 있는 개발자인가?”
• “나는 좋은 개발자인가?”

저 또한 거의 매일 같이 스스로에게 이와 같은 질문을 던지고는 하는 편입니다. 여담으로, 위의 3, 4번 질문의 경우, 아직 스스로에게 진지하게 던져볼 수준의 실력은 아니라고 생각합니다. 다만, 단순히 개발 속도가 빠르고, 코드를 많이 작성해 보았다고 해서 좋은 개발자가 될 수는 없겠다는 생각이 요즘 자주 드는 것 같습니다.

• 개발 속도가 빠르지만, 확장성, 유지 보수성, 코드 재사용성이 매우 낮다면?
• 지금까지 작성한 1,000,000줄의 코드가 어떠한 아키텍처 디자인 패턴을 적용하지 않은 스파게티식의 코드라면?

서비스와 개발자의 다양성의 범위가 매우 넓기 때문에 이에 대한 명확한 기준을 세우기는 어렵습니다만, 개발자로써 알고 있으면 좋은 몇가지 원칙이 있기에 이에 대해서 정리해 보았습니다.

2. KISS

“Keet it simple, stupid!”

KISS란, 언제나 단순하게 소프트웨어를 설계하는 것을 말합니다. 프로젝트의 규모가 클수록 복잡하게 설계하기 보다는 단순하게 설계하는 것이 우선이라고도 할 수 있습니다. 이때, “단순함”의 정도는 프로젝트의 설계 구조를 쉽게 이해할 수 있는 그림으로 그릴 수 있을 정도여야 한다고 합니다.

한 가지 주의할 점은 단순한 설계라는 의미 자체가 무작정 단순하게 설계하라는 의미는 아니라는 점입니다. 즉, 설계 대상의 순서를 지키면서 단순하게 설계하여야 합니다.

예를 들어, 계획 도시를 KISS 원칙으로 설계한다고 가정해봅시다. 이때, 고려해야 할 부분으로는 크게 도로와 건물이 있을 수 있습니다. 만약, 건물을 먼저 설계한다면 각기 다른 모양과 크기의 건물로 인해 반듯하지 않고 꼬불꼬불한 형태의 도로가 될 수 있습니다. 이를 바탕으로 실제 계획 도시를 지을 경우, 도로 교통과 관련한 문제를 직접 경험하게 될 가능성이 높아집니다.

3. YAGNI

“You Ain’t Gonna Need it!”

YAGNI는 “정말 필요하다고 느끼기 전까지 그 기능을 구현하지 말라”는 원칙입니다. YANGI를 지키지 않았을 때에 발생하는 사례로 “충동구매”가 가장 먼저 떠오를 정도로 우리 삶에도 그대로 적용되는 것 같습니다.

이와 같이 사용하지 않는 기능이나, 사용하지 않는 데이터가 많아질수록 소프트웨어의 복잡도가 높아지며, 그로인해 유지보수가 어려워질 수 있습니다. 따라서, 코드를 작성할 때 만큼은 “나중에 필요할 것 같은”, “언젠가는 사용할 것 같은” 함수는 작성하지 말고, 미니멀리스트가 되어 “현재 반드시 필요한” 기능을 구현하는데 더욱 집중하여야 합니다.

4. DRY

“Don’t Repeat Yourself!”

DRY는 똑같은 일을 반복하지 말아야 한다는 원칙입니다. 중복되는 기능, 함수, 코드 등이 있다면 이를 여러 조각으로 분리하여 따로 관리할 수 있도록 개선하여야 합니다.

예를 들어, 사용자 정보와 게시글 정보를 관리하는 데이터베이스에서 가입일시와 게시일시의 형식을 yyyy-mm-dd HH:MM으로 바꾸는 함수가 있다고 가정해봅시다.

/* Users.js */

class Users {
  getUser(_id) {
    const user = User.getUser(_id);
    const _date = new Date(user.createdAt);
    const createdAt = [
      dt.getFullYear(),
      '-',
      `0${dt.getMonth() + 1}`.slice(-2) + '-',
      `0${dt.getDate()}`.slice(-2),
      ' ',
      `0${dt.getHours()}`.slice(-2),
      ':',
      `0${dt.getMinutes()}`.slice(-2),
    ].join('');
    user.createdAt = createdAt;
    return user;
  }
}

/* Articles.js */

class Articles {
  getArticle(_id) {
    const article = Article.getArticle(_id);
    const _date = new Date(article.createdAt);
    const createdAt = [
      dt.getFullYear(),
      '-',
      `0${dt.getMonth() + 1}`.slice(-2) + '-',
      `0${dt.getDate()}`.slice(-2),
      ' ',
      `0${dt.getHours()}`.slice(-2),
      ':',
      `0${dt.getMinutes()}`.slice(-2),
    ].join('');
    article.createdAt = createdAt;
    return article;
  }
}

만약, 중복된 코드를 별도의 조각으로 분리해놓지 않은 상황에서 임의로 9시간을 더해야 하는 상황이라면 Users.js와 Articles.js 파일을 각각 수정해주어야 합니다. 뿐만 아니라, 관리해야 할 파일의 수가 많아질수록 각각의 파일을 수정하는 과정에서 발생하는 또 다른 이슈(Side Effect)와 마주칠 확률이 급격히 높아질 수 있습니다. 따라서, 아래와 같이 중복된 부분을 찾아서 별도로 관리하도록 개선하여야 합니다.

/* utils.date-formatter.js */

const dateFormat = (date) => {
  const dt = new Date(date);
  return [
    dt.getFullYear(),
    '-',
    `0${dt.getMonth() + 1}`.slice(-2) + '-',
    `0${dt.getDate()}`.slice(-2),
    ' ',
    `0${dt.getHours()}`.slice(-2),
    ':',
    `0${dt.getMinutes()}`.slice(-2),
  ].join('');
};