상위 1% 엔지니어의 7가지 간단한 습관
(engineercodex.substack.com)- "엘리트 코더가 다른 코더보다 뛰어난 능력을 발휘하는 방법"
코더가 아닌 엔지니어가 될 것 (Be an engineer, not a coder)
- 엔지니어링은 문제를 해결하는 것
- 최고의 엔지니어는 코드를 목적 달성을 위한 수단으로 생각함
- 코드를 작성하는 즐거움은 있지만 목적이 없는 코드를 작성하는 것은 의미가 없음. 대신 코드는 사용자를 위한 솔루션을 설계하는 데 사용됨
- 코딩은 창의성을 추구함! 창의력은 제약 조건 하에서 많이 발생함. 해결해야 할 명확한 문제라는 '제약'을 추가하면 엔지니어는 자신이 적합하다고 생각하는 방식으로 솔루션을 탐색하고 만들 수 있는 자유를 누릴 수 있음
- 최고의 엔지니어들은 제품 중심적이며, 무엇보다도 사람을 위한 문제 해결을 최우선으로 생각하며, 이는 다음 단계로 이어짐
컴퓨터가 아닌 인간을 위한 코드 (Code for the human, not the computer)
"바보라도 누구나 컴퓨터가 이해할 수 있는 코드를 작성할 수 있습니다. 훌륭한 프로그래머는 인간이 이해할 수 있는 코드를 작성합니다." - 마틴 파울러
- 코드는 컴퓨터뿐만 아니라 인간을 위한 것
- 코드는 그 코드를 읽고, 유지 관리하고, 당신의 코드 위에 빌드하는 같은 팀 엔지니어를 위한 것
- 코드는 휴대전화를 사용하는 어린아이, API를 호출하는 개발자, 본인 등 사용자를 위한 것
- 최고의 엔지니어들은 항상 모든 사용자를 위해 코드의 가치를 평가했음
- 만약 그들이 고객 중 한 명이라도 만족시키지 못하면 그 코드는 프로덕션에 적용되지 못했음
코드 자체에서 벗어나기 (Detach from the code itself)
- 뛰어난 엔지니어는 코드 자체에 집착하지 않음
- 그들은 최종 결과물이 전반적으로 더 좋아질 수 있다면 90% 정도 완성된 코드라도 삭제하고 다시 시작하는 것을 두려워하지 않음
- 코드는 개인적인 것이 아니기 때문에 피드백을 적극적으로 받아들임
- 코드는 완벽하지 않음. 아무도 완벽한 코드에 관심을 두지 않음. 변화를 가져오는 코드에 관심이 있을 뿐
- 코드에 집착하지 않도록 스스로를 가르치는 가장 좋은 방법은 "20년 후에는 당신 코드의 대부분이 기술 부채가 되거나 더 이상 사용되지 않거나 다시 작성될 가능성이 높다는 것을 깨닫는 것"
일관된 표준 사용 (Use consistent standards)
- 코드를 작성할 때 일관된 표준과 코딩 스타일을 고수할 것
- 일관성(Consistency)을 유지하면 미래의 당신과 팀원 모두가 코드를 더 쉽게 읽고 이해할 수 있게 해줌
- 일관된 스타일 가이드를 사용하면 팀과 코드베이스 모두 더 쉽게 확장할 수 있음
- 이게 Meta/Google 같은 회사가 시간이 지나도 코드베이스를 읽을 수 없거나 유지 관리할 수 없게 되는 일 없이 많은 코드를 신속하게 배포하는 방법
- 모든 뛰어난 성과를 내는 기업은 스타일 가이드를 내재화하고 그 이점을 알고 최대한 이를 따랐음
- 구글은 일부 스타일 가이드를 오픈소스로 공개했음
- 메타는 그들의 일부 오픈소스에 C++ 스타일 가이드가 있음
- 팁: 당신의 팀을 위해서 Linter를 포맷팅하는 것은 확실히 시간을 들여 설정할 가치가 있음
간단한 코드를 작성 (Write simple code)
- 내가 아는 모든 엘리트 엔지니어는 생성하기엔 복잡했을 수도 있지만, 결국엔 읽고 이해하기 쉬운 코드를 생성했음
- 이에 대해 내가 한 가장 좋은 말은 그들의 코드가 "미학적으로 만족스럽다는 것"
- 그들의 코드는 깔끔하고, 체계적이며, 논리적(clean, organized, and logical)
- 코드에서 내린 각 결정은 의미가 있었고, 그렇지 않은 경우엔 코드내에 잘 문서화 되어 있었음
- 깔끔한 코드를 작성하는 좋은 방법은 SOLID 원칙과 같은 원칙을 따르는 것. 처음에는 OOP(객체 지향 프로그래밍)를 염두에 두고 설계되었지만 일반 프로그래밍에도 확장할 수 있음
- Single Responsibility: 한 클래스는 하나의 책임만 가져야 함
- Open-Closed: 소프트웨어 객체(클래스, 모듈 등)는 확장에는 개방적이지만 수정에는 폐쇄적이어야 예측 가능하고 유지 관리 가능한 코드를 만들 수 있음
- Liskov Substitution: 하위 유형은 프로그램의 정확성에 영향을 주지 않으면서 기본 유형으로 대체할 수 있어야 함
- Interface Segregation: 코드가 모든 것을 사용하지 않는 거대한 인터페이스에 종속되어서는 안 됨. 대신 패키지는 더 작은 특정 인터페이스를 포함하고 임포트할 수 있도록 허용해야 함
- Dependency Inversion: 상위 레벨 모듈이 하위 레벨 모듈에 종속되어서는 안 되며, 둘 다 추상화에 종속되어 보다 유연하고 분리된 시스템 설계를 촉진해야 함
- 그 예로 이름 짓기(Naming)를 들 수 있음: 좋은 이름에는 마법의 값이 없고, 구분이 명확하며, 설명적인 함수 이름과 이해하기 쉬운 변수를 표현함
의외성을 허용하지 않음 (Don’t allow surprises)
- 코드는 예상치 못한 결과를 만들어서는 안 됨. 이는 코드 원칙을 따르고 적절한 테스트를 작성함으로써 가능
- 좋은 코드는 예측 가능함
- 테스트는 코드의 명확성과 예측 가능성을 강화하고, 자신감을 줌. 우수한 자동화된 테스트를 통해 팀은 보이지 않는 부분을 깨뜨릴 염려 없이 코드를 변경할 수 있음
- 몇가지 테스트 유형
- 개별 컴포넌트 및 격리된 함수에 대한 단위 테스트
- 여러 컴포넌트 간의 상호 작용을 위한 통합 테스트
- 사용자 관점에서 전체 시스템의 기능을 평가하는 엔드투엔드 테스트
- 테스트는 간단해야 함. 실패한 테스트를 읽었을 때 무엇이 잘못되었는지 쉽게 파악할 수 있어야 됨
- 테스트하지 말아야 할 항목을 아는 것도 중요
- 예를 들어, 엔드투엔드 테스트의 수고가 프로그램의 실제 이점보다 크다면 테스트는 신중한 문서화, 모니터링 및 적절한 사람(예: 코드 소유자)에게 알림을 보내는 것으로 대체
- 또한 테스트는 프론트엔드 코드에서 특정 CSS 선택기를 테스트하는 것과 데이터 속성 또는 스크린샷 테스트만을 사용하는 것과 같이 코드 내의 구현 세부 사항을 테스트해서는 안 됨
자주 소통하기 (Communicate often)
- 훌륭한 시스템은 혼자서 만들어지지 않음. 훌륭한 엔지니어들은 설계 검토를 거치고, 피드백을 요청하고, 코드에 대한 초기 설계를 계속 반복했음
- 누구나 자신의 지식에는 다른 사람이 채워줄 수 있는 빈틈이 있음. 새로운 관점은 종종 코드를 더 명확하게 만들거나 이전에는 생각하지 못했던 새로운 접근 방식을 제공하는 데 도움이 될 수 있음
- 최고의 엔지니어들은 더 나은 최종 결과물을 얻기 위해 시간을 들여 함께 작업하는 것을 두려워하지 않고 소통과 협업을 중시
- 문서에 대한 빠른 검토를 위해 팀원에게 핑을 보내거나 중요한 풀 리퀘스트에 코드 검토자를 추가하는 것처럼 간단하게 할 수 있음
빠르게... 그리고 느리게 코딩하기 (Code fast… and slow)
- 내가 아는 최고의 엔지니어들은 프로젝트를 빠르게 완료하지만 코딩은 느리게 함
- 이상하게 들리죠?
- 위의 모든 원칙과 습관은 코딩의 첫 번째 단계에 더 많은 시간을 추가함. 하지만 이러한 원칙과 습관을 통해 엔지니어는 프로젝트의 진행 상황을 한 단계씩 발전시킬 수 있음
- 표준을 사용하고, 제대로 테스트하고, 원칙을 사용하고, 자주 소통하는 데 시간을 할애함으로써 장기적으로 더 많은 시간을 절약할 수 있음
- 인턴과 주니어 엔지니어 시절에 제가 직접 경험했고, 다른 많은 엔지니어들도 마찬가지겠지만, 3보 전진을 서두르다 장애물에 부딪혀 5보 후퇴하게 될 수 있음
맹목적으로 규칙을 따르지 말 것 (Don’t follow rules blindly)
- 위의 '규칙'과 '원칙'은 단순한 가이드라인일 뿐. 모든 것이 가이드라인에 깔끔하게 잘 들어맞는 것은 아님
- 때로는 작성 중인 코드가 원 안에 들어가지 않는 정사각형일 수도 있지만 괜찮음
- 이 경우 코드가 특정 방식으로 작성된 이유를 문서화할 것
- 그렇지 않으면 미래의 여러분과 같은 누군가가 나중에 코드를 보고 "와, 그때는 내가 멍청했었지. 왜 이게 우리 표준을 따르지 않는 거지?"라고 생각할 수 있음
- 그러면 그들은 이전과 같은 결론에 도달하기 위해 20시간 동안 표준에 맞게 다시 코딩하는 데 시간을 소비할 것
- 소프트웨어 개발의 현실은 모든 코드가 깔끔하거나 규칙을 완벽하게 따를 수 없다는 것
- 하지만 일관성 있고, 깔끔하고, 이해하기 쉽고, 테스트할 수 있고, 가치 있는 코드는 존재할 수 있음
- 최고의 엔지니어에게서 발견한 또 다른 패턴들
- 적어도 한 가지 분야에 대한 깊은 도메인 지식을 가짐. 제가 기록했던 모든 엔지니어는 프론트엔드 인프라, 분산 시스템, 깔끔한 UI 등 특정 분야에 집중하여 전문가가 되었기 때문에 현재 해당 분야에서 최고의 자리에 올랐음
- 자신을 자주 그리고 적절하게 마케팅함. 이 엔지니어들은 눈에 잘 띄지 않는 곳에 숨어 있지 않았음. 팀원들과 함께 일하는 모든 사람들이 자신의 가치와 전문성을 알고 있었고, 이는 적절한 마케팅과 영향력 있는 프로젝트를 수행한 결과