작가님의 허락을 받고 번역한 글입니다.(원문)
이 글은 원래 무료 일보 "스타트업과 공학" 에서 소개된 글입니다.
여기서 구독하실 수 있습니다.
어떤 기술이든 전세계적으로 전문적인 성취의 핵심은 제대로된 방식으로 1만 시간 동안 연습하는 것입니다. - Malcom Gladwell in Outsiders
음.. 저는 전세계적인 전문가는 아닙니다. 하지만 꾸준히 프로그래밍에 1만 시간을 쏟아부었습니다. 아래는 제 경험으로부터 얻은 프로그래밍 고찰 31가지 입니다.
이 회고들은 오직 프로그래밍에 관한 것입니다. "프로그래밍은 사람에 관한 것이다"라거나 "시니어 테크 리드가 되는 법"으로 오해하시면 안됩니다.
이 고찰들은 단지 1만 시간 코드 작성에 꾸준히 임했을 때 얻은 것들입니다. 대부분의 초보자들에게 적용되지 않을 수 있습니다. 이 글은 커리어 상담이 아닙니다. 좋은 밴드 멤버가 되는 것이 아닌, 기술적인 기타리스트가 되는 방법 정도로 생각해 주시기 바랍니다. 이것들은 여러분이 더 나은 프로그래머가 되는 법에 관한 것입니다.
- 출처나 원리를 찾는 것이 스택오버플로우 답변을 찾는 것보다 거의 항상 빠릅니다.
- 대부분의 경우, 여러분이 겪고 있는 문제는 인터넷에 답이 없습니다. 그것은 여러분의 문제가 정말 어렵거나 중요하거나 둘다일 경우를 의미합니다.
- 할 수 있는 한 코드를 많이 지우시기 바랍니다.
- Syntactic sugar(가독성만을 위한 구문)은 보통 좋지 않습니다.
- 단순함이 가장 어렵습니다.
- 도구의 다양성을 넓히고, 일에 위해 어떤 것을 사용해야할 지 아시기 바랍니다.
- Git이나 bash와 같이 가장 많이 사용하는 것의 내부를 아셔야 합니다. (저는 대부분 꼬인 git rebase나 merge를 벗어날 수 있습니다.)
- 반복 작업에 대해서는 꼭 툴을 만드는게 좋습니다.. 여러분이 스스로 만든 툴보다 빠른 것은 없습니다.
- 배움은 최고에게서만. 그래서 저는 Go를 배울 때, standard library를 읽었습니다.
- 못생겨보인다면, 대부분 끔찍한 실수를 저지른 것입니다.
- Docstring이 아닌 주석을 써야만 한다면, 아마 리팩토링해야할 겁니다. 주석이 늘어날 때마다, 가능성이 증가합니다.
- 실제 서비스에서 프로그램이 어떻게 동작하는지 모른다면, 그 프로그램을 모르는 것입니다. 제 경험 상, 최고의 엔지니어는 모든 환경에서 그들의 프로그램이 어떻게 동작할지 알고 있습니다.
- 위 규칙은 파이프라인을 제작할 때도 적용됩니다.
- 다른 사람들의 코드를 열심히 사용하시기 바랍니다.
- 추론: 대부분의 코드들은 끔찍할 것입니다. 때때로, 더 나은 버전을 짜는게 더 쉬울 수 있습니다.
- 경험에 따르면, 재작성하고 있는 작은 라이브러리 혹은 작아야 하는 큰 라이브러리에서 직접 의존성은 좋지 않습니다.
- 언제 규칙을 깨야하는지 아셔야합니다. 반복하지 말라는 규칙에 대해서 말하자면, 때때로는 약간의 반복이 디펜던시보다 좋을 수도 있습니다.
- 코드를 모듈이나 패키지, 함수로 만드는 것은 중요합니다. API의 경계가 구체화되는 곳은 예술이라는 것을 아셔야 합니다.
- 가장 효율적인 도구를 고르되, 여러분이 알고 있는 도구도 고릅시다. 아크 리눅스는 현대 개발자들에게 가장 효율적인 운영체제입니까? 저에게는 그렇지만 대부분은 아닙니다. Acme를 써야합니까? 여러분이 Rob Pike라면
- 순환 복잡성은 피해야합니다. 주니어 개발자들은 너무 늦을 때까지 디펜던시 그래프가 얽힌 것을 알아차리지 못합니다.
- 깊은 중첩 조건은 피해야 합니다. Naming 컨벤션과, 조건 테스트에 대한 상식을 가져야합니다.
- 변수 이름은 똑바로 만들어야 합니다. 예술적으로다가 제대로
- 흔치는 않지만, 컴파일러가 문제인 경우도 있습니다. 그렇지 않으면 항상 DNS 문제입니다.
- 난해한 언어의 기능은 최소화하고, 쓰기로 되어 있는 경우에만 사용해야합니다. 그게 포인트 입니다.
- 기술은 동일하게 퍼지지 않습니다. 예를 들면, 저수준 엔지니어로부터 프론트엔드 개발자가 배울 것은 굉장히 많습니다. (특히, 모든 것은 컴파일 되었다는 것). 26. 비슷하게, 자바스크립트 개발자들은 클라우드 엔지니어에게 UX와 사용성 기능에 대해 가르쳐줄 수 있습니다.
- 결과적으로 다른 종류의 엔지니어는 세계를 다르게 봅니다.
- 어떤 개발자들은 다른 사람들보다 10배 더 효율적입니다. 제가 1인분도 못해본적도 있고, 10인분 한적도 있어서 알고 있습니다.
- 10인분 개발자와 10인분 직원 사이에는 상관관계가 없습니다.
- 좋은 API들은 사용하기 쉽고, 오용하기 어렵습니다. 설정 사이클은 하드코딩된 값에서부터 환경 변수, CLI 플래그, 설정 파일, DSL, 일반적인 bash 스크립트, 그리고 다시 하드코딩된 값으로 이동합니다. Heptagon of Configuration에서 어디에 위치하고 있는지 확인하시기 바랍니다.
- 모든 계층에서 추상화는 좋습니다. 벽에 달려들고 싶다면, 때때로 정답은 아래 수준의 추상화로 가면 됩니다. 여러분은 겉표면에 갇히지 않았습니다.
어디에 1만 시간을 쏟았습니까? 저는 프로그래밍을 15년 했습니다. 최근, 저는 구글 쿠버네티스 그리고 블랙스톤이라는 사모펀드에서 전문 개발자로 일하고 있습니다. 그 전에는 대학교에서 수학 증명 대신 내 프로젝트를 위한 프로그램을 짰습니다. 그 전에는, 모든 종류의 것들은 해킹했습니다. RuneScape에서 봇넷도 운영하고, 아이폰에 라틴어 번역 앱도 만들기도 했습니다.
1만 시간동안 무엇을 했습니까? 가장 최근일은 분산 시스템이었습니다. 스택을 넘나드는 코드를 짰습니다. 언어는 PHP, JavaScript, Go, Ruby, Python, C#, Java, Swift. 프론트엔드, 백엔드, 모바일, 커널, 클라우드, 데브옵스 등 저는 쿠버네티스같은 오픈소스 프로젝트에서 거대한 스케일에서 일해봤고, 작은 프로젝트를 운영했습니다. 이를 통해 최고의 엔지니어에게 내 코드를 리뷰받을 수 있었습니다.
Comments