상위 1% 개발자의 7가지 핵심 습관: 코드 품질과 생산성 향상 전략

상위 1% 엔지니어의 7가지 간단한 습관을 참고한 내용입니다.

코더가 아닌 엔지니어가 될 것 (Be an engineer, not a coder)

• 엔지니어링은 문제를 해결하는 것이고, 최고의 엔지니어는 코드를 문제를 해결하기 위한 수단으로 생각한다. 즉, 목적이 없는 코드를 작성하지 않고 사용자의 솔루션을 설계하는 등 목적을 가지고 코드를 작성하여 의미를 부여한다.

• 최고의 엔지니어들은 제품 중심적이며, 무엇보다도 사람을 위한 문제를 최우선으로 여긴다.

이 부분을 읽을 때 정글에서 코치님께서 조언 해 주신 말씀이 떠올랐다. “아직 포기하거나 해결하지 못한 엔지니어링적인 문제는 없다. 개발자는 과학자와 달리 현실적인 수용책을 선택하는 공학인이고, 정석적인 방법으로 문제를 해결할 수도 있지만, 우회하는 등 다양한 방법으로 문제를 풀 수 있으니 포기하지 말고 문제를 풀어내라”

1. 컴퓨터가 아닌 인간을 위한 코드 (Code for the human, not the computer)

“바보라도 누구나 컴퓨터가 이해할 수 있는 코드를 작성할 수 있습니다. 훌륭한 프로그래머는 인간이 이해할 수 있는 코드를 작성합니다.” - 마틴 파울러

• 코드는 컴퓨터뿐만 아니라 코드를 읽고, 관리하고, 활용하는 자신을 포함한 모든 사람을 위한 것이다.
• 최고의 엔지니어들은 항상 모든 사용자를 위해 코드의 가치를 평가한다.

이 부분은 “클린코드” 책에서도 중요하게 다루는 내용이다. 어떻게 하면 더 좋은 코드를 작성할 수 있을까? 끊임없이 고민하고 동료들과 의견을 나누어보자.

2. 코드 자체에서 벗어나기 (Detach from the code itself)

• 뛰어난 엔지니어는 작성한 코드에 집착하지 않고 더 좋은 결과를 위해서라면 90% 정도 완성된 코드라도 삭제하고 다시 시작하는 것을 두려워하지 않는다
• 코드는 개인적인 것이 아니기 때문에 피드백을 적극적으로 받아들인다
• 코드에 집착하지 않도록 스스로를 가르치는 가장 좋은 방법은 “20년 후에 작성한 코드는 더 이상 사용되지 않거나 다시 작성될 가능성이 높다는 것을 깨닫는 것”이다.

“이렇게 하면 깔끔하고 명확해 보이겠지?”라고 생각한 것들이 리팩토링 과정에서 “너무 알아보기 힘든데? 왜 이렇게 작성했지?”라고 느낀 경험이 있다. 이런 부분은 작성한 코드를 아까워 하지 말고 과감히 변화시켜 보자.

3. 일관된 표준 사용 (Use consistent standards)

• 코드를 작성할 때 일관된 표준과 코딩 스타일을 고수할 것
• 일관성(Consistency)을 유지하면 미래의 당신과 팀원 모두가 코드를 더 쉽게 읽고 이해할 수 있게 해준다.
• 일관된 스타일 가이드를 사용하면 팀과 코드베이스 모두 더 쉽게 확장할 수 있다.
• 모든 뛰어난 성과를 내는 기업은 스타일 가이드를 내재화하고 그 이점을 알고 최대한 이를 따랐다.
  • 구글은 일부 스타일 가이드를 오픈소스로 공개했다.
  • 메타는 그들의 일부 오픈소스에 C++ 스타일 가이드가 있다.
• 팁: 팀을 위해서 Linter를 포맷팅하는 것은 확실히 시간을 들여 설정할 가치가 있다.

아직 사내 스타일 표준이 없어, 코드를 작성할 때 혼란스러운 부분이 있다. 또, 더 좋은 코드를 작성하기 위해 코드 스타일을 바꾸어 코드를 작성하는 것이 기존 레거시 코드와의 일관성을 해치는 것이 아닐지? 고민이 될 때도 있었다. 이런 부분은 팀 세미나 주제로 다루어 보는 것도 좋을 듯하다.

4. 간단한 코드를 작성 (Write simple code)

• 엘리트 엔지니어들은 결국엔 읽고 이해하기 쉬운 코드를 작성한다
• 좋은 코드는 미학적으로 만족스럽고, 깔끔하고, 체계적이며, 논리적이다.
• 코드에서 내린 각 결정은 의미가 있었고, 그렇지 않은 경우엔 코드 내에 잘 문서화 해 놓는다.
• 깔끔한 코드를 작성하는 좋은 방법은 SOLID 원칙과 같은 원칙을 따르는 것. 이 원칙은 객체 지향 프로그래밍뿐만 아니라, 일반 프로그래밍에도 확장할 수 있다.
  • Single Responsibility: 한 클래스는 하나의 책임만 가져야 한다.
  • Open-Closed: 소프트웨어 객체(클래스, 모듈 등)는 확장에는 개방적이지만 수정에는 폐쇄적이어야 예측 가능하고 유지 관리 가능한 코드를 만들 수 있다.
  • Liskov Substitution: 하위 유형은 프로그램의 정확성에 영향을 주지 않으면서 기본 유형으로 대체할 수 있어야 한다.
  • Interface Segregation: 코드가 모든 것을 사용하지 않는 거대한 인터페이스에 종속되어서는 안 됨. 대신 패키지는 더 작은 특정 인터페이스를 포함하고 임포트할 수 있도록 허용해야 한다.
  • Dependency Inversion: 상위 레벨 모듈이 하위 레벨 모듈에 종속되어서는 안 되며, 둘 다 추상화에 종속되어 보다 유연하고 분리된 시스템 설계를 촉진해야 한다.

SOLID 원칙을 잘 지키는지 자문하면 SRP 원칙을 잘 지키지 못한다고 생각한다. 내가 작성한 함수의 의도와 흐름 파악을 위해 더 함수를 나눌 수 있음에도 불구하고 코드를 모아 함수를 크게 작성하고 있었다. 클린코드에서도 간단히 함수를 작성하는 것이 중요하다고 다루고 있으므로 앞으로는 함수를 더 작고, 하나의 책임만 가지도록 작성하도록 주의를 기울여야겠다.

5. 의외성을 허용하지 않음 (Don’t allow surprises)

• 코드는 예상치 못한 결과를 만들어서는 안 된다. 이는 코드 원칙을 따르고 적절한 테스트를 작성함으로써 예측 할 수 있게 할 수 있다
• 테스트는 코드의 명확성과 예측 가능성을 강화하고, 자신감을 준다.
• 몇 가지 테스트 유형
  • 개별 컴포넌트 및 격리된 함수에 대한 단위 테스트
  • 여러 컴포넌트 간의 상호 작용을 위한 통합 테스트
  • 사용자 관점에서 전체 시스템의 기능을 평가하는 엔드 투 엔드 테스트
• 테스트는 간단해야 함. 실패한 테스트를 읽었을 때 무엇이 잘못되었는지 쉽게 파악할 수 있어야 한다.
• 테스트하지 말아야 할 항목을 아는 것도 중요하다.
  • 예를 들어, 엔드투엔드 테스트의 공수가 크다면 문서화, 모니터링 및 관리자에게 알림을 보내는 것으로 대체 할 수도 있다.
  • 테스트는 CSS만을 테스트하거나 데이터 속성 또는 스크린샷 테스트만을 사용하는 것과 같이 코드 내의 구현 세부 사항을 테스트해서는 안 된다.

프로세스 개선 프로젝트를 진행하면서 일정에 쫓겨 작성한 코드를 테스트하지 못해 내가 작성한 코드의 자신감이 낮은 상태이다. 좋은 엔지니어가 되기 위해 꼭 테스트 코드를 작성하는 방법을 배우고, 적용해 봐야겠다.

6. 자주 소통하기 (Communicate often)

• 훌륭한 시스템은 혼자서 만들어지지 않는다. 훌륭한 엔지니어들은 설계 검토를 거치고, 피드백을 요청하고, 코드에 대한 초기 설계를 계속 반복했다.
• 누구나 자신의 지식에는 다른 사람이 채워줄 수 있는 빈틈이 있다. 새로운 관점은 종종 코드를 더 명확하게 만들거나 이전에는 생각하지 못했던 새로운 접근 방식을 제공하는 데 도움이 될 수 있다.
• 최고의 엔지니어들은 더 나은 최종 결과물을 얻기 위해 시간을 들여 함께 작업하는 것을 두려워하지 않고 소통과 협업을 중시한다.

이전 직장의 경험 때문인지 문서화와 소통에는 크게 두려움이 없는 편인 것 같다. 이 부분은 어떻게 하면 “나의 강점으로 삼을 수 있을까?”를 고민해 봐야겠다.

7. 빠르게… 그리고 느리게 코딩하기 (Code fast… and slow)

• 최고의 엔지니어들은 프로젝트를 빠르게 완료하지만, 코딩은 느리게 한다.
• 표준을 사용하고, 제대로 테스트하고, 원칙을 사용하고, 자주 소통하는 데 시간을 할애함으로써 장기적으로 더 많은 시간을 절약할 수 있다.

소통이 부족해서 엉뚱하게 기능을 구현한 기억이 떠오른다. 키보드를 바로 치지 말고 표준을 사용하고, 원칙을 지키며, 소통하는 데 시간을 쏟고 기능을 추가했다면 테스트를 해보자!

맹목적으로 규칙을 따르지 말 것 (Don’t follow rules blindly)

• 위의 ‘규칙’과 ‘원칙’은 단순한 가이드라인일 뿐. 모든 것이 가이드라인에 깔끔하게 잘 들어맞는 것은 아니다.
• 때로는 작성 중인 코드가 원 안에 들어가지 않는 정사각형일 수도 있지만 괜찮다.
  • 이런 경우 코드가 다르게 작성된 이유를 문서화해야 한다
  • 그렇지 않으면 나중에 코드를 보고 “왜 표준을 따르지 않는 거지?”라고 생각하고 누군가 코드를 다시 표준에 맞추려 불필요한 시간을 쏟을 수 있다.
• 소프트웨어 개발의 현실은 모든 코드가 깔끔하거나 규칙을 완벽하게 따를 수 없다.
• 하지만 일관성 있고, 깔끔하고, 이해하기 쉽고, 테스트할 수 있고, 가치 있는 코드는 존재할 수 있다.
• 최고의 엔지니어에게서 발견한 또 다른 패턴들
  • 적어도 한 가지 분야에 대한 깊은 도메인 지식을 가졌다.
  • 자신을 자주 그리고 적절하게 마케팅한다.함께 일하는 모든 사람이 자신의 가치와 전문성을 알고 있었고, 이는 적절한 마케팅과 영향력 있는 프로젝트를 수행한 결과이다.

내가 잘 할 수 있는 한 가지 분야를 찾고 경험을 쌓아보자. 실패를 두려워 하지 말고 영향력 있는 프로젝트를 수행해 PR 해 보자!