벨로그 첫 포스팅이다. 마크다운 사랑한다.

notice

한국어 독자 여러분께.
인간(컴퓨터)의 언어란 문법과 질서 그리고 문화의 산물입니다.
가장 좋은 독해는 원문 그대로 읽는 것이며 어떤 글은 반드시 native language로 읽어야만 합니다.
KOR 번역 및 의역을 감안하고 편하게 읽어주시면 감사하겠습니다.😉

원문(알렉스 에벨뢰프)
https://alexewerlof.medium.com/my-guiding-principles-after-20-years-of-programming-a087dc55596c

My guiding principles after 20 years of programming

(by Alex Ewerlöf)

1999년부터 프로그래밍을 해왔고 올해로 공식적으로 코딩만 20년이 넘었다.
나는 Basic으로 시작했지만 곧 Pascal과 C 언어에 뛰어들었고, Delphi와 C++로 OOP(Object Oriented Programming)를 공부했다. 2006년엔 자바를 시작했고 2011년엔 자바스크립트를 시작했다.

로봇, 핀테크, 의료 테크부터 미디어 그리고 통신까지 다양한 비즈니스에서 일했다. 리서처, CTO, TPM(테크니컬 프로덕트 매니저), 티쳐, 시스템 아키텍쳐 또는 테크니컬 리더. 다양한 역할과 직책을 거치면서도 코딩은 놓지 않았다.

수백만 명에게 제공되는 서비스를 만들었던 적도 있고, 어떤 서비스는 릴리즈되기 전에 망한 적도 있다.

나는 컨설턴트로 일했고 내 회사(스타트업)를 운영하기도 했다.

나는 오픈 소스 프로젝트와 Closed source 프로젝트 및 조직 내부 오픈 소스 프로젝트(독점 코드)에 많은 시간을 썼다. 모바일과 데스크톱 앱부터 클라우드 서버, 최근엔 서버리스까지 마이크로 컨트롤러로 다양하게 작업해왔다.

프로그래밍 경력 20년을 맞이해 오랜 기간 소프트웨어 개발 커리어를 쌓으면서 세웠던 가이드과 원칙을 소개하고자 한다.

1. 라이브러리, 프로그래밍 언어, 플랫폼 등 이런 것들과 싸우지 마라.
   가능한 한 많은 native 구조를 사용해보자. 솔루션이 될 기술을 무시하지 마라 그리고 해결해야 할 문제 역시 간과하지 마라.
   작업에 적합한 도구를 골라라, 안 그러면 적절한 도구를 찾기 위해 품을 들여야 할 것이다.

2. 프로그래머는 컴퓨터를 위한 코드를 작성하는 게 아니라, 동료와 미래의 자신을 위해 작성해야 한다(완전히 포기한 프로젝트이거나 어셈블리로 작성하는 경우 제외). 주니어들에게 레퍼런스가 될 것이라 생각하고 코드를 작성해라.

3. 소프트웨어 개발에서 중요하고 보람 있는 경험은 협업에서 나온다. 효율적으로 소통하고 공개적으로 협업하라. 동료를 믿고 그들의 신뢰를 얻어라. 동료가 작성한 코드보다 작성자인 동료를 존중해라.
   솔선수범하고 네가 리드해라. 팔로워(동료)에게 팀 리더 역할을 제안해라.

4. 분할 정복해라.
   커플링이 느슨한 서로 다른 피쳐엔 isolated된 모듈을 작성해라. 테스트는 각 파트를 따로 또 함께. 테스트는 핏하게 할 것 그리고 엣지 케이스 역시 테스트할 것.

5. 자신을 잠시 내려놓아라. 코드만 쫓는 사람이 되지 말아라.
   코드 작성자가 스스로 버그를 찾고 코드에 피쳐를 추가할 수 있도록 최적화하라. 다음 프로젝트와 조직으로 편하게 이동해라.
   프로그래머가 코드를 소유(own)한다면 소유한 코드 이상으로 성장할 수 없을 것이다.

6. 보안은 여러 레이어로 쌓을 것. 각 레이어는 개별적 그리고 전체적으로 평가 받아야 한다. 비즈니스 결정엔 늘 리스크가 있고 취약성과 확률 등의 말이 붙는다. 각 제품과 개발 조직엔 다양한 리스크 감수 기준이 있다(더 큰 성과를 위해 리스크를 감수하는 정도 및 허용 범위).
   UX, 보안, 퍼포먼스 이렇게 세 가지 사안이 보통 자주 충돌한다.

7. 모든 코드에는 생명 주기(life cycle)가 있고 언젠가 죽는다는 걸 인지해라.
   가끔 프로덕트가 릴리즈되기도 전에 어떤 코드는 초기에 버려진다. 신경 쓰지 마라.
   아래 네 카테고리의 각 기능과 차이를 배우고, 프로그래머의 시간과 에너지를 어디에 쓸지 정해라.

• Core: 차의 엔진과 같다. Core가 없다면 프로덕트도 없다.
• Necessary: 차의 스페어 휠과 같다. 잘 쓰이진 않지만 필요시 이 작동이 시스템의 동작을 결정한다.
• Added value: 차의 컵 거치대와 같다. 있으면 좋다 그런데 없어도 작동하는 데 문제없다.
• Unique Selling Point: 경쟁사가 아닌 당신의 제품이 팔리는 주된 이유다. 예를 들어 당신이 만든 차가 오프로드에서 최고라면?

8. 코드에 개성을 넣을 필요는 없다.
   다른 사람의 코드에 그의 아이덴티티를 넣는 것도 막아라. 우리가 만든 물건과 만든 사람을 분리해라. 코드 리뷰엔 개인적인 비평을 담지 말고 매우 신중하게 해라.

9. 기술 부채는 정크푸드다. 가끔은 일어날 수 있다 하지만 익숙해지면 네 생각보다 더 빠르고 고통스럽게 프로덕트를 망칠 거다.

10. 솔루션을 결정할 때 고려할 것들:

• 보안 > 안정성 > 사용성(접근성 & UX) > 유지보수 > 단순함(개발자 경험 DX) > 간결함(코드 길이) > 재무 > 퍼포먼스
  그렇다고 맹목적으로 위 우선순위를 따르지는 마라, 네 프로덕트의 특성에 따라 조정해라.
  커리어를 경험하면 할수록 각 상황에 맞게 우선순위들에 적절한 균형을 찾을 수 있을 거다.
  예를 들어, 게임 엔진을 설계할 때 퍼포먼스는 최우선순위 조건이다. 만약 뱅킹 앱이라면 보안이 가장 중요한 조건일 거다.

11. Copy & Paste 습관은 버그 제조기다.
    이게 버그가 계속 재현되는 방식이다. 카피한 코드는 항상 읽고, 임포트할 코드를 검사해라.
    버그는 복잡성 속에 숨는다. 마법은 너 혼자만 보는 일에만 써라, 코드 작성엔 안 된다.

12. 긍정 회로만 돌리면서 코드 작성하면 안 된다.
    왜 에러가 났는지에 대한 답과 에러를 어떻게 발견했고 어떻게 해결했는지에 대해 답할 수 있도록 에러 메시지를 기록해라. 유저 인풋을 포함해 모든 시스템 데이터 인풋에 validate해라; 빨리 틀려도 된다 그런데 가능할 때마다 복구해둬라.
    총자루는 유저가 쥐고 있다; 네 머리가 날아가지 않으려면 코드 에러에 충분한 노력을 쏟아라.

13. 프로그래밍에 dependency 쓰지 마라. 임포트, 유지보수, 엣지 케이스와 버그에 대응하고도 결과가 불만족스러워서 리팩토링하는 비용이 네 코드보다 더 크고 크리티컬하다면.

14. Hype Driven 개발에서 벗어나라. 그보다 최대한 열심히 공부해라.
    토이/펫 프로젝트를 시작해라.

15. 아직도 컴포트 존에 있나? 매일 공부해라. 네가 배운 것을 설명해봐라.
    마스터한 분야에 대해선 더 공부하지 않는다. 새로운 언어와 기술 그리고 문화에 너를 노출시키고 늘 궁금해해라.

16. 좋은 코드는 문서를 필요로하지 않는다.
    훌륭한 코드는 이미 충분히 작성되어 있어서 누구든지 이를 발전시킬 수 있고 시행착오를 겪을 수 있으며 요구 사항을 생산적으로 사용할 수 있다. 코드로 작성되지 않은 기능은 존재하지 않는 기능이다. 존재하지 않는 기능은 코드를 가질 수 없다.

17. override와 상속, 함축적인 코드는 최대한 지양해라. 제발 기본적인 기능을 사용해라.
    그게 테스트하고 판단하기 더 쉽다. 퓨어하지 않은 기능은 클래스로 묶어라. 다른 기능을 가진 코드엔 다른 이름을 붙여야 한다.

18. 만약 해결한 문제를 이해하지 못했다면 코드부터 쓰지 마라. 코드 타이핑보다 먼저 문제에 관해 설명 듣고 파악하는 데 시간을 쓰는 게 옳다. 코딩하기 전에 도메인부터 이해하자. 문제는 미로와 같다. 프로그래머는 꾸준히 코딩-테스트-개선 사이클을 밟아야 하고 해결할 때까지 문제를 탐색해야 한다.

19. 존재하지도 않는 문제를 해결할 순 없다.
    분명하지 않은 상태에선 프로그래밍할 수 없다. 확장 가능하고 assumption을 validate할 수 있을 때 코드를 작성해라. 시간이 지나면 코드 썼을 때와는 다르게 문제를 정의할 수도 있다.
    Overengineer가 되지 마라; 문제를 해결하는 일에 집중하고 효율적인 방식으로 실질적인 솔루션을 내놓아라.

20. 소프트웨어는 함께 만들 때 더 재밌다. 지속 가능한 팀을 만들어라.
    동료의 말에 경청할 것. 그들을 격려할 것. 배우고 공유할 것.

소프트웨어 개발론에 대한 어떤 권위에 도전하려는 건 아니다.
위 가이드는 내가 오랫동안 일하며 얻은 지혜고, 다음 20년 후엔 이 지혜가 더 원숙해질 거라 생각한다.

(역자쓺) 건투를 빈다.