상위 1% 엔지니어의 간단한 습관

본 포스팅은 원글을 번역한 글입니다.

"나는 FAANG과 같은 대규모 기업과 스타트업과 같은 작은 기업에서 뛰어난 엔지니어들과 함께 일한 경험이 있습니다.
이 중 일부 엔지니어들은 자신의 회사를 시작하거나 웹을 변화시키는 개발을 주도했으며(예: Vercel), 오늘날 큰 기술 기업에서 수십 억 달러 가치의 프로젝트를 주도하고 있습니다.
내가 그들과 일하면서 주목한 것은 그들이 생산한 코드에서 일부 중복되는 습관을 가지고 있다는 것입니다."

컴퓨터가 아닌 사람을 위한 코드를 작성하라

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

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

코드는 팀의 엔지니어들을 위한 것입니다. 그들이 코드를 읽고 유지 관리하며 코드를 기반으로 더 많은 것을 구축합니다.

코드는 사용자를 위한 것입니다. 그것이 핸드폰을 사용하는 아이, API를 호출하는 개발자 또는 여러분 자신이 사용하는 모든 사람을 대상으로 합니다.

내가 아는 최고의 엔지니어들은 제품 중심적이며, 먼저 인간을 위한 문제 해결을 고려합니다.

내가 알던 최고의 엔지니어들은 항상 코드의 가치를 모든 대상을 위해 평가했습니다.

하나의 대상을 놓친다면, 그 코드는 제품으로 들어가지 않았습니다.

코드 자체로부터 분리하라

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

그들은 코드를 삭제하고 처음부터 다시 시작해도 두렵지 않았습니다. 결과적으로 전반적으로 더 나아질 경우에는 90% 정도 완료한 상태에서도 그렇게 했습니다.

코드는 개인적인 것이 아니므로 피드백을 수용했습니다.

코드는 완벽하지 않습니다. 아무도 완벽한 코드에 관심을 가지지 않습니다. 그들은 변화를 제공하는 코드에 관심이 있습니다.

자신의 코드에 대한 감정적인 연결을 끊기 위한 가장 좋은 방법은 20년 후에는 대부분의 코드가 기술 부채로 남거나 폐기되거나 다시 작성될 가능성이 높다는 것을 깨닫는 것입니다.

일관된 표준 사용하라

코드를 작성할 때, 일관된 코딩 표준과 스타일을 따르세요. 일관성은 미래의 여러분과 팀원 모두에게 코드를 더 쉽게 읽고 이해하게 만듭니다.

일관된 스타일 가이드는 팀과 코드베이스 모두가 더 쉽게 확장될 수 있도록 합니다. 이것이 Meta와 Google과 같은 회사가 코드베이스가 시간이 지남에도 읽기 어렵고 유지하기 어렵지 않게 빠르게 많은 코드를 배포하는 방법입니다.

내가 아는 모든 최고의 엔지니어들은 팀의 코드 표준을 내면화하고 그 이점을 알고 가능한 한 따르곤 했습니다.

• Google은 깨끗한 코드를 유지하기 위한 가독성 프로세스가 있습니다.
• Google은 일부 스타일 가이드를 오픈 소스로 공개하고 있습니다. (링크)
• Meta는 일부 오픈 소스 코드를 위한 C++ 스타일 가이드가 있습니다. (링크)
• 팁: 이미 설정된 경우를 제외하고 팀에게 코드 포매터(린터, linter)를 설정하는 것은 분명히 가치가 있습니다.

간단한 코드를 작성하라

내가 알고 있는 모든 엘리트 엔지어들은 코드를 생산했습니다. 이 코드는 생산하기는 복잡할 수 있었지만 끝에 이르면 읽고 이해하기 쉬웠습니다. 내가 이것에 대해 가장 좋아하는 말은 그들의 코드가 '미적으로 매력적'이었습니다.

그들의 코드는 깨끗하고 조직적이며 논리적이었습니다. 코드에서 내린 각 결정은 이치에 맞았고, 그렇지 않을 때는 코드 내에서 잘 문서화되었습니다.

깨끗한 코드를 작성하는 좋은 방법 중 하나는 SOLID 원칙과 같은 원칙을 따르는 것입니다. 이 원칙들은 처음에 객체지향 프로그래밍(OOP)을 고려하여 디자인되었지만, 일반적인 프로그래밍에도 확장 가능합니다.

1. 단일 책임 원칙: 클래스는 단 하나의 책임만 가져야 합니다.
2. 개방-폐쇄 원칙: 소프트웨어 객체(클래스, 모듈 등)는 확장에는 열려 있지만 수정에는 닫혀 있어야 하며, 예측 가능하고 유지보수 가능한 코드를 허용해야 합니다.
3. 리스코프 치환 원칙: 서브타입은 그들의 베이스 타입에 영향을 미치지 않고 대체 가능해야 합니다.
4. 인터페이스 분리 원칙: 코드는 사용하지 않는 큰 인터페이스에 의존해서는 안 되며, 대신 패키지는 작고 특정한 인터페이스를 포함하고 가져올 수 있어야 합니다.
5. 의존성 역전 원칙: 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 양쪽 모두 추상화에 의존하도록하여 더 유연하고 결합이 낮은 시스템 디자인을 촉진해야 합니다.

이것의 한 예는 네이밍(naming)입니다. 좋은 네이밍은 마법스러운 것이 아니라, 명확한 구분, 설명적인 함수 이름 및 이해하기 쉬운 변수를 가져야 합니다.

의외성을 허용하지 마라

코드는 놀라움을 일으키지 않아야 합니다. 이는 코드 원칙을 따르고 적절한 테스트를 작성함으로써 이루어집니다.

좋은 코드는 예측 가능합니다.

테스트는 코드의 명확성과 예측 가능성을 강제합니다. 그것은 신뢰를 제공합니다. 좋은 자동화된 테스트는 팀이 보이지 않는 것을 망치지 않고 코드를 변경할 수 있도록 해줍니다.

일부 테스트 유형은 다음과 같습니다.

1. 개별 구성 요소 및 격리된 함수에 대한 유닛 테스트
2. 여러 구성 요소 간의 상호 작용을 검사하는 통합 테스트
3. 사용자 관점에서 전체 시스템 기능을 평가하는 엔드 투 엔드 테스트

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

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

예를 들어, 엔드 투 엔드 테스트의 노력이 프로그램의 실제 이점을 초과하면, 해당 테스트는 신중한 문서화, 모니터링 및 코드 소유자와 같은 적절한 사람에게 경보를 대체해야 합니다.

또한 테스트는 코드 내의 구현 세부 정보를 테스트하지 않아야 합니다. 예를 들어, 프론트엔드 코드에서 특정 CSS 선택기를 테스트하는 대신 데이터 속성을 사용하거나 스크린샷 테스트를 수행하는 것과 같이 코드 내의 구현 세부 정보를 테스트해서는 안됩니다."

자주 소통하라

위대한 시스템은 혼자서는 구축되지 않았습니다. 우수한 엔지니어들은 설계 검토를 거치고 피드백을 요청하며 코드의 초기 설계를 계속해서 개선했습니다.

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

최고의 엔지니어들은 의사소통과 협업 능력을 모두 가지고 있었으며, 더 나은 최종 결과를 위해 함께 일할 시간을 아낄 염려가 없었습니다.

이것은 동료에게 문서 검토를 요청하거나 중요한 풀 리퀘스트에 추가 코드 리뷰어를 지정하는 것과 같이 간단한 일로 할 수 있습니다.

빠르게... 그리고 느리게 코딩하라

내가 아는 최고의 엔지니어들은 빠르게 프로젝트를 완료합니다. 느리게 코딩해서요.

이상하게 들리죠?

위의 모든 원칙과 습관은 코딩의 전체 첫 번째 단계에 더 많은 시간을 추가합니다. 그러나 이러한 원칙을 따르면 엔지니어들은 프로젝트의 진행을 단계별로 나아갈 수 있습니다.

표준을 사용하고 적절한 테스트를 수행하고 원칙을 사용하고 자주 의사소통하는 시간을 들이는 것으로 자신들을 장기적으로 더 많은 시간을 절약합니다.

제 개인적인 경험으로 말하자면, 인턴과 주니어 엔지니어로 일했을 때 경험한 대체 방법은 3단계를 빠르게 나아가려다가 장애물에 부딪혀 5단계를 되돌아야 했습니다. 아마도 많은 다른 사람들도 비슷한 경험을 했을 것입니다.

맹목적으로 규칙을 따르지 마라

위의 '규칙'과 '원칙'은 그저 지침일 뿐입니다.

모든 것이 깔끔하고 완벽하게 지침에 맞지 않을 수 있습니다.

가끔 작성 중인 코드는 그냥 그 원을 맞출 수 없는 사각형일 수 있습니다. 괜찮습니다.

그 경우, 코드가 특정한 방식으로 작성된 이유를 문서화해야 합니다.

그렇지 않으면 미래의 여러분과 같은 누군가는 코드를 나중에 보고 '와, 나는 그 때 멍청했군. 왜 이것이 우리의 표준을 따르지 않는 걸까?'라고 생각할 수 있습니다.

그런 다음 그들은 표준에 맞게 다시 코딩하기 위해 20시간을 소비하고 결국 이전과 동일한 결론에 도달할 것입니다. 익숙한 일이죠.

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

그러나 그것은 일관되고 깨끗하며 이해 가능하며 테스트 가능하며 가치 있게 될 수 있습니다.

---

최고의 엔지니어에게서 발견한 또 다른 패턴들:

• 하나 이상의 분야에서 깊은 도메인 지식. 내가 메모한 모든 엔지니어는 프론트엔드 인프라, 분산 시스템 또는 깨끗한 UI와 같은 특정 분야에서 집중하고 전문가가 되어 현재는 자신의 분야 최상위에 있습니다.
• 자주 그리고 적절하게 자신을 마케팅. 이러한 엔지니어들은 전혀 감추지 않았습니다. 그들의 팀 구성원과 협업한 모든 사람은 그들의 가치와 전문성을 알고 있었습니다. 이는 적절한 방법으로 자신을 마케팅하고 고영향 프로젝트에 참여함의 조합을 통해 나타났습니다.