7가지 상위 1%의 프로그래머들의 습관

컴퓨터가 아닌 인간을 위한 코드

"어떤 바보라도 컴퓨터가 이해할 수 있는 코드를 작성할 수 있습니다. 좋은 프로그래머는 사람이 이해할 수 있는 코드를 작성합니다."
- 마틴 파울러

코드는 컴퓨터만을 위한 것이 아닌 인간을 위한 것입니다.

코드는 코드를 읽고 관리하고 이를 기반으로 구축하는 팀의 엔지니어를 위한 것입니다.

코드는 휴대전화를 사용하는 어린이, API 요청을 하는 개발자, 나 자신 등 사용자를 위한 것입니다.

최고의 엔지니어들은 제품을 중시합니다. 인간의 문제 해결을 제일 먼저 생각합니다.

최고의 엔지니어들은 항상 그들의 코드의 가치를 사용자들을 위해 평가했습니다.

사용자들중 한 사람의 목표를 놓친 경우 그 코드는 프로덕션에 적용되지 않습니다. 

 

코드 자체에서 벗어나기

놀라운 엔지니어들은 코드 자체에 얽메이지 않습니다.

코드가 90% 정도 진행되었더라도 최종 결과가 전반적으로 더 좋아진다면 코드를 삭제하고 다시 시작하는 것을 두려워하지 않았습니다.

코드는 개인적인 것이 아니므로 피드백을 적극적으로 받아들였습니다.

코드는 완벽하지 않다. 아무도 완벽한 코드에 관심이 없다. 그들은 변화를 전달하는 코드에 관심이 있습니다.

코드에서 벗어나는 방법을 스스로 배우는 가장 좋은 방법은 20년 안에 코드의 대부분이 기술적 부채가 되거나 더 이상 사용되지 않거나 다시 작성될 가능성이 높다는 것을 깨닫는 것입니다.

 

일관된 표준을 사용하세요

코드를 작성할 때 일관된 표준과 코딩 스타일을 고수하세요. 일관성은 미래의 당신과 팀원 모두가 코드를 더 쉽게 읽고 이해할 수 있게 해줍니다.

일관된 스타일 가이드를 사용하면 팀과 코드베이스 모두 더 쉽게 확장할 수 있습니다. Meta와 Google과 같은 회사가 시간이 지남에 따라서 코드베이스를 읽을 수 없거나 유지 관리할 수 없게 되는 일이 없이 많은 코드를 제공 할 수 있는 방법입니다.

제가 아는 모든 우수한 성과자는 팀의 코드 표준을 내부화하고 그 이점을 알고 이를 최대한 준수했습니다.

• Google에는 깔끔한 코드를 유지하기 위한 가독성 프로세스가 있습니다.

How Google writes clean, maintainable code

 

• Google은 일부 스타일 가이드를 오픈소스로 공개했습니다.

Google Style Guides

 

- tip 아직 linter가 없다면 팀을 위해 linter를 설정하는 것은 시간을 들여 설정할 가치가 있습니다.

 

간단한 코드 작성

내가 아는 모든 엘리트 엔지니어는 작성하기 복잡했을 수도 있지만 결국 읽고 이해하기 쉬운 코드를 생성했습니다.

그들의 코드는 깨끗하고 체계적이며 논리적이었습니다. 코드에서 내린 결정은 의미가 있었고, 그렇지 않은 경우 코드내에 잘 문서화되었습니다.

깔끔한 코드를 작서앟는 좋은 방법은 SOLID 원칙과 같은 원칙을 따르는 것입니다. 그들은 처음에는 객체 지향 프로그래밍을 염두에 두고 설계했지만 일반 프로그래밍으로 확장 가능하게 만들었습니다.

SOLID

- Single Responsibility : 클래스에는 하나의 책임만 있어야 합니다.

- Open-Closed : 소프트웨어 개체(클래스, 모듈)는 확장을 위해 열려있어야 하지만 수정을 위해서는 닫혀 있어야 하며 예측 가능하고 유지 관리 가능한 코드가 가능해야 합니다.

- Liskov substitution principle : 프로그램의 객체는 프로그램의 정확성을 꺠뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다. 

- Interface segregation principle : 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.

- dependency inversion : 상위 수준 모듈은 하위 수준 모듈에 의존해서는 안됩니다. 둘 다 추상화에 의존하여 보다 유연하고 분리된 시스템 설계를 촉진해야 합니다.

 

의외성을 허용하지 말자

코드는 놀라움을 선사해서는 안됩니다. 이는 코드 원칙을 따르고 적절한 테스트를 작성하여 실천할 수 있습니다.

좋은 코드는 예측 가능해야 합니다. (predictable)

테스트는 명확성과 예측 가능성을 강화합니다.

테스트의 유형

- Unit test : 개별 구성 요소 및 격리된 기능에 대한 단위 테스트 입니다.

- interation test: 여러 구성 요소 간의 상호 작용에 대한 통합 테스트입니다.

- End to end : 사용자 관점에서 전체 시스템의 기능을 평가하는 테스트입니다.

 

테스트는 단순해야 합니다. 실패한 테스트를 읽을 때 무엇이 잘못되었는지 쉽게 식별할 수 있어야 합니다.

무엇을 테스트하지 말아야 하는지 아는 것도 중요합니다.

예를 들어, 엔드 투 엔드 테스트의 노력이 프로그램의 실제 이점보다 더 큰 경우 테스트는 문서화, 모니터링 및 적절한 사람(예: 코드 소유자)에게 경고하는 것으로 대체됩니다.

또한 테스트에서는 프런트엔드 코드의 특정 CSS 선택기 테스트와 데이터 속성 사용 또는 스크린샷 테스트와 같은 코드 내의 구현 세부 사항을 테스트해서는 안 됩니다.

 

자주 소통하자

휼륭한 시스템은 혼자 구축되지 않았습니다. 휼륭한 엔지니어들은 디자인 검토를 거쳐 피드백을 요청하고 코드에 대한 초기 디자인을 계속해서 반복했습니다.

모든 사람은 자신의 지식에 다른 사람이 채울 수 있는 공백이 있습니다. 새로운 관점은 종종 코드를 더 명확하게 만들거나 이전에 생각하지 못했던 새로운 접근 방식을 제공하는 데 도움이 될 수 있습니다.

최고의 엔지니어들은 의사소통 능력과 협업 능력이 뛰어났으며, 더 나은 결과를 얻기 위해 함께 일하는 데 시간을 들이는 것을 두려워하지 않았습니다.

이는 문서에 대한 빠른 검토를 위해 팀원에게 핑을 보내거나 중요한 pull request에 추가 코드 검토자를 추가하는 것만큼 간단할 수 있습니다.

 

코딩은 빠르고... 느리다

제가 아는 최고의 엔지니어들은 천천히 코딩하여 프로젝트를 빠르게 완료합니다.

위의 모든 원칙과 습관은 코딩의 전반적인 첫 번째 단계에 더 많은 시간을 추가합니다. 그러나 이를 통해 엔지니어는 프로젝트 진행 상황을 단계별로 진행 할 수 있습니다.

표준을 사용하고 적절하게 테스트하고 원칙을 사용하고, 자주 의사소통하는 데 시간을 투자함으로써 장기적으로 더 많은 시간을 절약할 수 있습니다.

 

맹목적으로 규칙을 따르지 마세요.

위의 규칙과 원칙은 단지 지침을 뿐입니다.

모든 것이 지침에 깔끔하고 휼륭하게 들어맞을 수는 없습니다.

때로는 작성 중인 코드가 원에 맞지 않는 사각형인 경우가 있습니다.

이 경우 코드가 특정 방식으로 작성된 이유를 문서화하세요

그렇지 않다면 미래의 당신과 같은 누군가가 미래에 와서 코드를 보고 "와, 그때는 내가 멍청했구나." 라고 생각할 수도 있습니다. 이것이 왜 우리 표준을 따르지 않는 걸까요?”

그런 다음 이전과 동일한 결론에 도달하기 위해 표준에 맞게 다시 코딩하는 데 20시간이 소요됩니다. 익숙한 것 같나요?

소프트웨어 개발의 현실은 모든 코드가 깨끗하거나 규칙을 완벽하게 따를 수는 없다는 것입니다.

그러나 그것이 일관되고, 깨끗하고, 이해하기 쉽고, 테스트 가능하고, 가치가 있을 수 있습니다.

 

 

이 글은 아래글을 번역한 글입니다.

7 simple habits of the top 1% of engineers