주니어 개발자를 위한 조언

#초보자 #생산력

본 글은 아래 3가지 내용을 담고 있습니다.

• 기술 조언에 대한 중요한 맥락과 동기
• 기술 조언
• 추천 읽을거리 시작하기에 좋은 고품질 책과 블로그에 대한 링크

주니어를 위한 일반적인 조언

1. 코드가 포인트가 아니다

개발자로서 우리는 코드 작성을 좋아합니다. 우리 대부분은 명확하고 멋진 작업을 원하고, 다른 세계에 관심을 기울이지 않고, 풀 수 있는 재미있는 기술 퍼즐입니다.

올바른 문제를 해결하고 있는지 확인하기 위해 합리적인 노력을 해야 합니다. Peter Drucker의 말을 인용하자면: 전혀 하지 말아야 할 일을 효율적으로 하는 것만큼 쓸모없는 것은 없습니다. 일반적으로개발 초기에 실제 사용자에게 지속적으로 피드백을 수집합니다.

무엇이 중요한 문제인가?
올바른 일을 하는 것과 일을 제대로 하는 것 사이에 놓인 효과와 효율성의 혼란에서 모든 문제는 비롯된다. 확실한 것은 하지 않아도 될 일을 효율적으로 하는 것 만큼 쓸모없는 일은 없다는 것이다.

• 피터 드러커

소프트워어 개발은 비용이 많이 들고, 실제 프로젝트의 대부분의 유지보수 비용으로 사용됩니다. 이를 시용자/비즈니스 결과라는 목표와 결합하게 되면, 좋은 코드는 대부분 없는 경우가 많습니다
소프트웨어 개발은 유지 관리 비용이 들어가는 실제 프로젝트의 노력의 대부분과 함께 비용이 많이 듭니다. 이것을 사용자/비즈니스 결과라는 목표와 결합하면 최상의 코드는 코드가 없는 경우가 많습니다. Bill Gates의 말을 인용하자면 "코드로 프로그래밍 진행 상황을 측정하는 것은 항공기 제작 진행 상황을 무게로 측정하는 것과 같습니다."

2. 소프트웨어 설계 문제

개발 경력의 첫 5년 동안 저는 소프트웨어 설계가 소프트웨어 설계자나 특별한 역할을 맡은 다른 사람들을 위한 것이라고 생각했습니다. 나는 "일을 끝내는 것"에 집중했고, 소프트웨어 디자인과 테스트 작성과 같은 관행이 방해가 된다고 생각했습니다. 내 코드는 작동했고, 많은 일을 하고 있었습니다. 많은 일을 하고 있다고 생각했습니다.

그런 다음 Robert C. Martin 의 Clean Code 를 읽었습니다 . 이 책은 소프트웨어 디자인에 관심을 갖도록 동기를 부여하고, 예제와 많은 기술적 발견을 포함하고 있습니다. 가장 개념적인 테이크어웨이는 "빨리 가는 유일한 길은 잘 가는 것"입니다. 즉, 엉망으로 만들면 속도가 느려집니다.

잘 설계된 깨끗한 코드를 작성하는 방법을 배우는 것은 물론 시간과 노력이 필요합니다. 그리고 시작하면 속도가 느려지고 실수를 하게 됩니다. 단순한 것은 쉽지 않습니다.

3. 모범 사례 사용

테스트 작성은 유익한 경향이 있습니다. 예외가 있지만 대부분의 경우 자동화된 테스트를 작성하는 것이 좋습니다. 테스트 작성은 모범 사례의 한 예입니다.

테스트 작성이 처음이라면 모범 사례를 따르고 모든 것에 대한 테스트를 작성하십시오. 시작할 때 맹목적으로 모범 사례를 따르는 것이 자신의 미숙한 판단을 따르는 것보다 낫습니다 . 시간이 지남에 따라 테스트를 효과적으로 작성하는 방법을 배우고, 테스트를 작성하는 것이 가치가 없는 상황과 엉망인 상황을 구분할 수 있게 될 것입니다. 또한 디버깅 세션의 감소와 테스트에서 활성화된 걱정 없는 리팩토링을 경험함으로써 테스트가 보다 본능적인 수준으로 가져오는 가치를 이해하기 시작할 것입니다. 판단력을 개발한 후에는 모범 사례를 초월할 수 있습니다 .

이 조언은 당신이 2학년인 모든 영역의 모범 사례에 적용됩니다. 자동화된 테스트는 하나의 예일 뿐입니다.

한 가지 큰 문제는 합리적인 모범 사례와 무의미하거나 심지어는 역효과를 낳는 것과 구별하기가 쉽지 않다는 것입니다. 이것은 대부분의 기존 코드가 엉망이고 "숙련된" 및 "선배" 개발자를 포함하여 대부분의 개발자가 소프트웨어 설계 기본 사항을 모르기 때문에 더 복잡해집니다. 이것은 좋은 멘토를 갖는 것을 매우 가치있게 만듭니다. 그것을 제외하고 내 자신의 경험에 기반한 조언 중 하나는 귀하의 언어 또는 프레임워크 커뮤니티에 특정한 모범 사례를 주의하라는 것입니다. 수십 년 동안 주변에 있었던 상록 조언을 찾으십시오.

주니어를 위한 기술 조언

1. 테스트 코드 작성

자동화된 테스트를 작성합니다. TDD( Test Driven Development ) 를 통해 코드보다 먼저 테스트를 작성할 수 있습니다. 이렇게 하면 반복 가능한 방식으로 코드가 올바른지 쉽게 확인할 수 있으므로 수동으로 재시도하거나 세션을 디버깅하지 않아도 됩니다.

디버그를 실행합니다.

아마도 중요한 것은 테스트를 통해 코드를 리팩토링할 수 있는 안전망을 얻을 수 있다는 것입니다. 그리고 코드를 깨끗하게 유지하려면, 지속적인 리팩토링이 필요합니다. 신뢰할 수 있는 테스트 모음이 없으면 코드가 썩을 가능성이 훨씬 더 높아집니다.

코드 재사용을 위해 상속을 사용하거나 정적 함수를 사용할 때와 같이 코드 디자인이 좋지 않으면 테스트 작성이 어렵습니다. 반면에 전역 종속성이 없는 SOLID 클래스가 있다면, 멋진 테스트를 작성하는 것이 그렇게 어렵지 않습니다.

잘못 작성된 테스트는 속도를 늦추기 때문에 테스트 디자인이 중요합니다. 테스트 중인 코드의 구현 세부 사항이나 시스템 구조에 테스트를 바인딩하지 마십시오. Mocks의 남용을 피하고 더 나은 Test Doubles를 작성 하십시오 .

2. 코드 재사용을 위해 상속을 사용하지 마십시오

이것은 "모범 사례 사용" 섹션을 염두에 두는 모범 사례 중 하나입니다. 내 조언: 시작할 때 코드 재사용을 위해 상속을 전혀 사용하지 마십시오. 그것은 거의 올바른 호출이 아니며 많은 피해를 줄 수 있습니다. 상속보다 구성을 선호 합니다.

3. 객체 지향 코드 작성

STUPID 가 아닌 SOLID 코드를 작성 하십시오. 이러한 원칙과 반패턴을 이해하는 데는 많은 가치가 있습니다.

실제로 개체를 만듭니다. 정적 메서드만 있는 클래스는 OO가 아닙니다. 정적 코드를 완전히 사용하지 마십시오.

참조: SOLID에 대한 나의 방어 .

4. 기능 코드 작성

( 함수형 프로그래밍 은 구조 프로그래밍 과 혼동되어서는 안 됩니다 .)

이 요점은 기능적 언어로 완전히 전환하는 것에 관한 것이 아닙니다. OO 언어에서 기능적 스타일을 사용하면 이점을 얻을 수 있습니다. 특히 변경 가능한 상태를 최소화 하고 함수에서 한 가지 작업을 수행합니다.

5. 정보에 입각한 복제 사용

많은 양의 코드 덩어리를 여러 위치에 복사하여 붙여넣는 것은 현명하지 않습니다. 자존심이 강한 개발자라면 누구나 곧 이것을 배우고 DRY( Don't Repeat Yourself ) 형식을 따르기 시작합니다. 불행히도, 의도적으로 DRY를 추구하면 과도한 엔지니어링과 우발적인 복잡성으로 이어지는 경우가 많습니다. DRY의 대응물인 WET(Write Everything Twice)가 여기에 해당합니다. WET의 기본 개념은 중복이 세 번째 발생하는 경우에만 중복을 제거하는 것입니다.

6. 유형, 이름 및 설명

자체 문서화 코드를 작성하고 주석을 피하십시오.

설명을 작성할 때마다 찡그린 표정을 짓고, 표현력의 실패를 느껴야 합니다. -- 로버트 C. 마틴

코멘트는 거짓말을 할 수 있기 때문에 위험합니다. 코드는 주석이 업데이트되지 않고 변경될 수 있습니다. 주석 바로 아래에 새 코드를 추가할 수 있습니다. 댓글이 처음부터 잘못되었거나 정확하지 않을 수 있습니다. 이런 일이 발생하면 댓글은 쓸모없게 될 뿐만 아니라 오해의 소지가 있습니다.

자체 문서화 코드를 작성하려면:

• 기능에서 한 가지 작업 수행
  • 함수에서 한 가지 작업을 수행하여 명확한 이름을 지정할 수 있습니다.
  • 주석을 추가하여 함수의 다른 섹션이 수행하는 작업을 설명할 필요가 있을까요? 대신, 각 섹션을 고유한 이름의 함수로 추출하십시오.
  • "추출할 때까지 추출": 의미 있는 기능을 추출할 수 있다면 아마도 그렇게 해야 할 것입니다. 작은 기능을 두려워하지 마십시오.
  • 명령 쿼리 분리
  • 클래스 에 대한 단일 책임 원칙 (SOLID의 S)과 유사
• 상태 최소화
• 유형을 사용하십시오 . 코드를 실행하는 테스트 스위트와 결합하여 진실을 말하는 유형에 의존할 수 있습니다.
• 혼합 유형을 피하십시오 . 정수, 부울 또는 문자열이 될 수 있는 매개변수 또는 반환 값을 피하십시오. 이것은 한 가지만 수행하는 집중 함수를 작성하는 경우 자연스럽게 발생합니다.
• 테스트 작성 . 잘 작성되고 포괄적인 테스트 스위트는 프로덕션 코드가 어떻게 사용되며 어떻게 작동하는지 보여줍니다.

Robert C. Martin의 Clean Code 에는 이름 지정 및 주석에 대한 몇 가지 좋은 경험 법칙이 있습니다.

주니어 추천도서

서적

• 클린 코드 , 2007년 로버트 C. 마틴 저서
• 프로그래머의 길 멘토에게 묻다 , 2009년 책
• 레거시 코드 활용 전략 , Michael Feathers의 2004년 책
• 리팩터링: 코드 구조를 체계적으로 개선하여 효율적인 리팩터링 구현하기 , 1999 책
• 소프트웨어 장인 , 2014년 책