내가 아는 최고의 엔지니어들의 7가지 간단한 습관

아래 내용은 엔지니어 코덱스에서 가져온 글 입니다. (https://read.engineerscodex.com/p/7-simple-habits-of-the-top-1-of-engineers)

--------------------------------------------------------------------------------

저는 FAANG과 같은 대기업과 스타트업과 같은 소규모 기업에서 뛰어난 엔지니어들과 일했습니다. 그들은 저에게 신화적인 "10배" 엔지니어에 대한 눈을 뜨게 했습니다. 그들은 실제로 현실에 존재했습니다!

이 엔지니어 중 일부는 자신의 회사를 시작하거나, 우리가 아는 웹의 모습을 바꾸는 개발을 주도하거나(예를 들어 Vercel!), 오늘날 대형 기술 회사에서 수십억 달러 규모의 프로젝트를 주도하는 인물로 성장했습니다.

그들과 일하는 동안 저는 그들이 만든 코드에서 모두 겹치는 습관이 있다는 것을 알게 되었습니다.

"어떤 바보라도 컴퓨터가 이해할 수 있는 코드를 쓸 수 있다. 훌륭한 프로그래머는 인간이 이해할 수 있는 코드를 쓴다." – 마틴 파울러.

코드는 컴퓨터만을 위한 것이 아니라 사람을 위한 것입니다.

코드는 여러분의 팀의 엔지니어를 위한 것입니다 . 엔지니어는 여러분의 코드를 읽고, 유지관리하고, 이를 기반으로 코드를 개발합니다.

코드는 사용자를 위한 것입니다 . 휴대폰을 사용하는 어린이이든, API를 호출하는 개발자이든, 당신 자신이든 말입니다.

코드에는 세 가지 독자가 있습니다. 인간 독자, 기계 독자, 사용자입니다.

제가 아는 가장 뛰어난 엔지니어는 제품 중심적입니다. 즉, 인간 의 문제를 먼저 해결하는 것을 생각합니다.

내가 아는 가장 뛰어난 엔지니어들은 언제나 모든 대상을 위해 자신이 만든 코드의 가치를 평가했습니다.

청중 중 하나라도 목표를 달성하지 못하면 해당 코드는 프로덕션에 적용되지 않습니다.

코드 자체에서 분리

뛰어난 엔지니어는 코드 자체에 얽매이지 않습니다.

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

코드는 개인적인 것이 아니므로 피드백은 적극 수용되었습니다.

코드는 완벽하지 않습니다. 완벽한 코드는 아무도 신경 쓰지 않습니다. 그들은 변화를 제공하는 코드를 신경 씁니다.

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

출처: Visualize Value

일관된 표준을 사용하세요 

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

일관된 스타일 가이드는 팀과 코드베이스가 더 쉽게 확장할 수 있도록 해줍니다. 이것이 Meta와 Google과 같은 회사가 시간이 지남에 따라 코드베이스가 읽을 수 없고 유지 관리가 불가능해지지 않고 많은 코드를 제공하는 방식입니다.

내가 아는 모든 뛰어난 엔지니어는 팀의 코드 표준을 내면화하고 최대한 밀접하게 따랐으며, 그 이점을 알고 있었습니다.

Google은 깔끔한 코드를 유지하기 위해 가독성 프로세스를 사용합니다.

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

Meta에는 일부 오픈 소스 코드에 대한 C++ 스타일 가이드가 있습니다. (링크)

팁 : 팀을 위한 린터를 포맷팅하는 것은 이미 린터가 없다면, 설정하는 데에 시간을 투자할 만한 가치가 분명히 있습니다.

간단한 코드를 작성하세요

내가 아는 모든 위대한 엔지니어는 복잡하게 만들었을지 몰라도, 결국 읽고 이해하기 쉬운 코드를 만들어냈습니다 . 이에 대해 내가 할 수 있는 가장 좋은 말은 그들의 코드가 미적으로 즐거웠다 는 것입니다 .

그들의 코드는 깔끔하고, 체계적이고, 논리적 이었습니다 . 그들의 코드에서 내린 각각의 결정은 의미가 있었고, 무언가 의미가 없을 때는 코드 내에서 잘 문서화되었습니다.

깔끔한 코드를 작성하는 좋은 방법은 SOLID 원칙과 같은 원칙을 따르는 것입니다. 이 원칙은 원래 OOP(객체 지향 프로그래밍)를 염두에 두고 설계되었지만, 일반 프로그래밍으로 확장할 수 있습니다.

단일 책임 : 클래스는 하나의 책임만 가져야 합니다.

개방-폐쇄 : 소프트웨어 객체(클래스, 모듈 등)는 확장에는 개방적이어야 하지만 수정에는 폐쇄적이어야 하므로 예측 가능하고 유지 관리 가능한 코드가 가능합니다.

리스코프 대체 : 하위 유형은 프로그램의 정확성에 영향을 주지 않고 기본 유형을 대체할 수 있어야 합니다.

인터페이스 분리 : 코드는 모든 것을 사용하지 않는 거대한 인터페이스에 종속되어서는 안 됩니다. 대신 패키지는 작고 구체적인 인터페이스를 포함하고 이를 가져올 수 있도록 허용해야 합니다.

종속성 반전 : 상위 수준 모듈은 하위 수준 모듈에 의존해서는 안 됩니다. 둘 다 추상화에 의존해야 하며, 이를 통해 보다 유연하고 분리된 시스템 설계가 가능합니다.

이것의 한 예는 명명 입니다 . 좋은 명명에는 마법의 값이 없고, 명확한 구분, 설명적인 함수 이름, 이해하기 쉬운 변수가 있습니다.

놀라움을 허용하지 마세요

코드는 놀라움을 만들어내서는 안 됩니다. 이는 코드 원칙을 따르고 적절한 테스트를 작성함으로써 이루어집니다.

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

테스트는 코드의 명확성과 예측 가능성을 강화합니다. 테스트는 자신감을 제공합니다. 우수한 자동화 테스트를 통해 팀은 보이지 않는 것을 망가뜨릴까 걱정하지 않고 코드를 변경할 수 있습니다.

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

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

개별 구성 요소와 분리된 기능에 대한 단위 테스트 .

여러 구성 요소 간의 상호 작용에 대한 통합 테스트 .

사용자 관점에서 전체 시스템의 기능을 평가하는 종단간 테스트

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

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

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

테스트에서는 프런트엔드 코드에서 특정 CSS 선택기를 테스트하는 것과 데이터 속성을 사용하거나 스크린샷 테스트만 하는 것 등 코드 내의 구현 세부 사항을 테스트해서는 안 됩니다.

자주 소통하세요

위대한 시스템은 혼자 만들어지지 않습니다. 위대한 엔지니어는 설계 검토를 거치고, 피드백을 요청하고, 코드에 대한 초기 설계를 계속 반복했습니다.

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

최고의 엔지니어는 의사소통과 협력을 모두 잘합니다. 더 나은 최종 결과를 위해 함께 일하는 데 시간을 들이는 것을 두려워하지 않습니다.

이는 문서를 간단히 검토해 달라고 팀원에게 핑을 보내거나, 중요한 풀 리퀘스트에 추가 코드 검토자를 추가하는 것만큼 간단할 수 있습니다.

빠르게 코드 작성…그리고 느리게 작성

제가 아는 가장 뛰어난 엔지니어들은 느리게 코딩해서 프로젝트를 빠르게 완료합니다.

이상하게 들리죠?

위의 모든 원칙과 습관은 코딩의 전반적인 첫 번째 패스 에 더 많은 시간을 추가합니다 . 하지만 엔지니어가 프로젝트의 진행 상황을 단계적으로 진행할 수 있도록 합니다.

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

제가 인턴과 주니어 엔지니어였을 때 직접 경험한 대안은 다른 많은 사람들과 마찬가지로 3걸음 앞으로 달려가서 방해물에 부딪힌 다음 5걸음 뒤로 물러나는 것입니다.

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

위의 “규칙”과 “원칙”은 단순한 지침입니다. 

모든 것이 가이드라인에 깔끔하고 딱 들어맞는 것은 아닙니다.

가끔 당신이 쓰는 코드는 그 원에 맞을 수 없는 정사각형일 수도 있습니다. 괜찮습니다.

때로는 경계를 넓혀야 할 때가 있습니다.

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

그렇지 않다면 미래의 당신 같은 누군가가 미래에 코드를 보고 "와, 그때 나는 멍청했구나. 왜 이게 우리 기준을 따르지 않는 거지?"라고 생각할지도 몰라요.

그런 다음 그들은 표준에 맞게 다시 코딩하는 데 20시간을 보내서 이전과 같은 결론에 도달합니다. 익숙한 소리인가요?

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

하지만 일관성 있고, 깔끔하며, 이해하기 쉽고, 테스트 가능하며, 가치 있는 것이 될 수 있습니다.