이 게시물은 원본 아티클인 Advice for Junior Developers 를 한글로 번역한 게시글입니다. 게시물 내용의 저작권은 원작자 Jeroen De Dauw 에게 있습니다.

15년 이상의 개발 경력 동안, 제 효율성을 크게 향상시키는 몇 가지 원칙을 배웠습니다. 이번 게시글에서는 이 것들을 같이 이야기해볼까 합니다.

차례:

• 기초적 조언 -- 이후 내용을 위한 중요한 맥락 및 동기
• 기술적 조언 -- 핵심 내용
• 추천 내용 -- 시작할 때 유용할 높은 퀄리티의 책 또는 블로그 링크 (역주: 여기에는 작성하지 않습니다.)

이 글은 알맞게 판단하고 자세히 탐구할 가치 있는 개념들을 언급하고 링크합니다.

주니어들에게 주는 기초적인 조언

1. 코드가 중요한 게 아니다.

개발자로써, 우리는 코드를 작성하는 것을 좋아합니다. 대부분의 경우, 애매하지 않은 작업을 받기를 원합니다. 세상의 다른 부분에 신경 쓰지 않고 해결해야 할 재미있는 기술 퍼즐입니다.

해결해야 할 올바른 문제를 해결하는 데 합당한 노력을 기울이세요. Peter Drucker 인용: 전혀 해야할 필요가 없는 걸 효율적으로 하는 것 만큼 필요없는 건 없다. 조기에 그리고 자주 피드백을 수집하세요. 일반적으로 실제 사용자에게 지속적으로 전달해 피드백을 받습니다. 애자일하게 행동하세요.

소프트웨어 개발은 비용이 많이 들며, 실제 프로젝트에서는 대다수의 노력이 유지보수에 투입됩니다. 여기에서 사용자/비즈니스 결과를 목표로 설정할 때 가장 좋은 코드는 종종 코드가 없는 것입니다. Bill Gates 인용: 코드의 줄로 프로그래밍 진척도를 측정하는 것은, 비행기 제작 진척도를 무게로 측정하는 것과 같습니다.

여기에서도 볼 수 있습니다 : YAGNI, KISS, The Last Responsible Moment

2. 소프트웨어 디자인은 중요하다.

제가 개발자 경력이 5년째 되었을 때, 소프트웨어 디자인은 소프트웨어 아키텍트나 특별한 역할을 맡은 사람에게만 필요하다고 생각했습니다. 저는 그저 "이 일을 끝내야해"에만 집중했고, 소프트웨어 디자인 같은 관행이나 테스트 작성은 방해요소라고 생각했습니다. 제 코드는 동작했고, 많은 작업을 해내고 있는 것 같았습니다. 하지만 그게 전부라고 생각했습니다.

그 후 저는 Robert C. Martin의 Clean Code를 읽었습니다. 이 책은 소프트웨어 디자인에 관심을 갖도록 동기부여하며, 예시와 다양한 기술적 휴리스틱을 제공합니다. 책에서 중요한 결론은 **"빨리 진행하는 방법은 제대로 하는 것이다"**입니다. 다른말로는, 만약 엉망으로 만들면, 느려지게 될 것이다 가 있습니다.

여기에서도 볼 수 있습니다 : TradableQualityHypothesis, DesignStaminaHypothesis

잘 설계된 깨끗한 코드를 작성하는 방법을 배우려면 시간과 노력이 필요합니다. 그리고 시작할 때는 더 느리고 실수할 수 있습니다. 단순함은 쉬운 것이 아닙니다.

3. 모범 사례를 사용하라.

테스트를 작성하는 것은 이점이 있습니다. 예외가 있을 수 있지만, 대부분의 경우에 자동화 된 테스트를 작성하는 것은 매우 유용합니다. 테스트를 작성하는 것은 모범 사례의 한 예입니다.

만약 테스트를 작성하는 게 처음이라면, 모범 사례를 따라서 모든 것에 대해 테스트를 작성하세요. 시작할 때는 자신의 미숙한 판단보다는, 맹목적으로 최선의 방법을 따르는 것이 더 좋을 것입니다. 시간이 지나 효과적으로 테스트를 작성하는 법을 배우게 되며, 실수한 부분과 테스트를 작성하지 않아도 되는 상황을 구분할 수 있게 될 것입니다. 또한 디버깅 횟수가 감소하고, 리팩토링에 걱정이 없어지는 경험을 통해 테스트에 대한 가치를 더 직관적으로 이해하기 시작할 것입니다. 자신의 판단을 발전시킨 후에는, 모범 사례를 넘어서는 능력을 갖출 수 있게 될 것입니다.

이 조언은 당신이 초보인 어떤 분야에서도 최상의 방법론으로 적용됩니다. 자동화 테스트는 그저 예시일 뿐입니다.

여기서 중요한 건 현명한 모범사례와 현명하지 않거나 오히려 역효과를 내는 것과의 차이점을 구별하는 것이 쉽지 않다는 것입니다. 이건 기존 코드 대부분이 엉망이고, "시니어"나 "경험있는"개발자를 포함한 대부분의 개발자들이 소프트웨어 디자인의 기본을 모르기 때문에 더 복잡해집니다. 이러한 상황에서는 좋은 멘토의 가치가 큽니다. 그렇지 않다면, 제 경험에 바탕을 둔 한가지 조언은 자신의 언어나 프레임워크 커뮤니티의 특정 모범 사례를 조심해야 한다는 것입니다. 오랫동안 지속되어 온 조언을 한번 찾아보세요.

주니어들에게 주는 기술적 조언

이번에는 기술적 주제에 집중해 보겠습니다. 그러나 건강, 행복, 경력, 소프트 스킬 같은 다른 부분도 중요합니다. 기술적인 함정을 피하는 방법을 알더라도, 수면 부족으로 지치고 독재적인 상사가 잘못 된 문제를 작업하는 경우에는 도움이 되지 않을 겁니다.

4. 테스트를 작성하라.

자동화 테스트를 작성하세요. 테스트 주도 개발 (TDD) 같이 코드를 작성하기 전에 테스트를 작성하는 것이 도움이 될 수 있습니다. 이렇게 하면 코드가 정확한지 반복적으로 확인하기 쉬워져 수동으로 반복 테스트를 진행하거나 디버깅 횟수를 줄일 수 있습니다.

테스트를 작성하는게 어렵다고 생각하시나요? 디버깅 후 시도해보세요.

어쩌면 더 중요한 것은 코드를 리팩토링 할 때 테스트가 안전 장치가 되어 준다는 것입니다. 그리고 지속적인 리팩토링은 코드를 깨끗하게 유지하는 데 꼭 필요합니다. 의지 할 수 있는 테스트 모음 없이는 코드가 부패 할 가능성이 높아집니다.

만약 상속을 사용해 코드를 재사용하거나, 정적 함수를 사용하는 등 코드의 디자인이 엉망이면 테스트를 작성하기 어렵습니다. 반면에 만약 전역 의존성 없이 SOLID 원칙을 사용했다면 좋은 테스트를 작성하는 건 어렵지 않을 것입니다.

테스트 디자인은 중요합니다. 잘못 작성된 테스트는 작업을 느리게 할 수 있습니다. 테스트를 작성할 때 테스트 대상 코드의 구현 세부사항이나 시스템의 구조에 결합시키지 않는 것이 좋습니다. 목(Mock)의 남용을 줄이고 더 좋은 테스트 Double을 작성하세요.

5. 코드 재사용을 위해 상속을 사용하지 마라.

이는 "모범 사례 사용하기" 섹션을 떠올리게 하는 모범 사례 중 하나입니다. 처음 시작할 때는 코드 재사용을 위해 상속을 절대 사용하지 않는 것이 좋습니다. 이는 드물게 옳은 선택이지만 많은 피해를 줄 수 있습니다. 상속보다는 컴포지션(composition)을 사용하세요.

6. 객체 지향 코드를 작성하라.

STUPID 말고 SOLID코드를 작성하세요. 이러한 원칙과 안티 패턴을 이해하는 것은 굉장히 큰 가치가 있습니다.

실제로 객체를 만들어보세요. 오직 정적 메서드만 있는 클래스는 객체지향이 아닙니다. 가능한 정적 코드를 전혀 사용하지 않도록 노력해보세요.

여기에서도 볼 수 있습니다: my defense of SOLID

7. 함수형 코드를 작성하라.

(명령형 구조적 프로그래밍과 함수형 프로그래밍을 헷갈리지 마세요)

여기서 중요한 것은 함수형 언어로 모든 것을 전환하는 게 아닙니다. 지금 사용하고 있는 언어에서 함수형 스타일로 작성하는 것으로도 이점을 얻을 수 있습니다. 최소상태, 가변 상태 최소화, 함수는 한번에 한가지 기능만 수행 등이 있습니다.

여기에서도 볼 수 있습니다: functional core, imperative shell

8. 정보를 중복적으로 사용하라.

큰 크기의 코드를 여러 곳에 복사-붙여넣기 하는 것은 항상 현명하지 않은 방법입니다. 자부심 있는 개발자는 빠른 시일 내에 자신을 반복하지 마라(DRY) 원칠을 따를 것입니다. 그러나 불행하게도, DRY 원칙의 의도는 좋지만 종종 과도한 엔지니어링과 복잡성으로 이어지기도 합니다. 이것이 DRY의 상반되는 개념인 [모두 두번 씩 작성하라(WET)]이 나오는 곳입니다. WET의 개념은 중복이 세 번째 발생할 때만 중복을 제거하는 것입니다.

중복 제거의 비용과 이점을 더 자세히 살펴보려면 The Fallacy of DRY 를 참고해보세요.

9. 타입, 이름, 그리고 주석

주석을 사용하지 않고 코드 자체가 설명할 수 있도록 하세요.

주석을 작성할 때 마다 당신은 얼굴을 찌푸리며 당신의 표현 능력의 실패를 느껴야 합니다. -- Robert C. Martin

주석은 거짓말 할 수 있기 때문에 위험합니다. 그리고 주석이 업데이트 되지 않더라도 코드는 변경 될 수 있습니다. 또한 주석 아래에 새 코드를 추가할 수 있으며, 주석이 처음부터 잘못되거나 부정확할 수도 있습니다. 이런 경우에는 주석은 쓸모없을 뿐 만 아니라 잘못 이해하게 만들 수도 있습니다.

코드가 직접 설명하게끔 작성하세요.

• 함수가 한가지만 수행하도록 하세요.
  • 함수가 하나의 일만 한다면, 명확한 이름을 지을 수 있습니다.
  • 함수의 다른 부분이 무엇을 하는지 설명하기 위해 주석을 추가하지 마세요. 대신 각 부분을 자체적으로 잘 정의 된 함수로 추출하세요.
  • "추출할 수 있을 때 까지 계속 추출하세요." 의미 있는 함수를 추출 할 수 있다면 추출하는 것이 좋습니다. 작은 함수에 대해 두려워하지 마세요.
• 상태를 최소화하세요.
• 타입을 사용하세요. 코드를 사용하는 테스트 모음과 함께 사용하면, 타입이 진실만을 보여주기 때문에 신뢰할 수 있습니다.
• 혼합된 타입을 피하세요. 정수, boolean, 문자열이 될 수 있는 매개변수나 반환값을 피하세요. 이는 한 가지 일만 수행하는 함수를 작성하는 경우 자연스럽게 하게 됩니다.
• 테스트를 작성하세요. 잘 작성되고 포괄적인 테스트 모음은 제품 코드의 사용 방법과 동작을 보여줍니다.

Robert C. Martin의 Clean Code에는 이름짓기와 주석에 관한 좋은 지침이 있습니다.

역주 의견

여기서부터는 저(himprover)의 의견 입니다.

글의 내용은 좋았지만, 지금까지 번역했던 것 중 가장 난이도가 높지 않았나 싶습니다.

아직 저의 실력이 부족해서 그렇겠지만, 중간 중간 쉼표가 많이 붙어 있어 이해하기가 좀 더 어려웠던 것 같습니다.