유데미(Udemy) 개발자영어 - 수강후기

 

 

1. 서론

개발자에게 있어 영어는 아주 중요한 영역이라고 생각합니다. 

코드 작성 뿐만 아니라, 문서, 검색, 질문, 답변 등 모든 영역들이 영어와 밀접하게 연결되어 있습니다.

[ 개발자 영어 ] 강의에서 언급하고 있는 내용들을 정리해보도록 하겠습니다.

(내용이 많으니 궁금하신 부분들을 목차를 활용해서 보시는 것을 추천드립니다.)

 

 

---

 

 

2. 개발자에게 영어란?

2.1 개발자에게 영어가 중요한 이유

• 지식과 정보의 보고
  • 대다수 최신 정보는 영어
  • 남들보다 한 걸음 앞서는 토대

• 프로그래밍 언어
  • 영어권에서 개발
  • 의사 소통을 위해 작명 관례가 중요
  • 변수 이름을 gab(값)으로 하면?
  • 깨끗한 코드의 중요성

• 의사 소통 도구
  • 공동체 참여(특히 오픈 소스)
  • 묻고 답하기(Stack Overflow, Quora)/메일링 리스트 등에서 질문과 대답을 위한 공용어

 

※ 주의 사항 : 문해력의 중요성

• 한글은 읽기가 쉽지만 이해를 담보하지는 않는다!
• 하지만, 영어를 사용한다고 해서 저절로 소프트웨어 개발이 쉬워지거나 품질이 향상되지는 않는다.
• 제대로 학습하고 제대로 사용해야 한다.

---

2.2 영어 학습 방향성

깨끗한 코드는 잘 쓴 문장처럼 읽힌다. 깨끗한 코드는 결코 설계자의 의도를 숨기지 않는다.
- 그레디 부치 (객체지향 대가)

코드가 그 문제를 풀기 위한 언어처럼 보인다면 아름다운 코드라 불러도 되겠다.
- 워드 커닝엄(위키 창시자, 피트 창시자, 익스트림 프로그래밍 창시자)

 

• 가장 먼저 읽기에 투자
  • 기술 자료와 코드를 읽을 수 있으면 된다.

• 읽기 다음 쓰기에 투자
  • 아주 복잡한 논문을 쓰기 위한 수준은 필요하지 않다.
  • 실무에 적합한 수준을 달성하면 된다.

• 어휘력은 기본 중의 기본으로 생각해야 한다.
  • 특히 기술 용어에 익숙해져야 한다.
  • 기술 자료에 사용되는 영어 단어는 생각보다 어렵지 않다.

 

---

 

 

3. 효율적인 영어 독해 방안

3.1 독해 역량 향상을 위한 팁

영문 독해를 구성하는 4대 기초 : 어휘, 문장 구조, 문해력, 전문 지식

---

( 3.1.1 ) 4대 기초를 튼튼히 하는 방법

• 어휘
  • 외운다, 또 외운다.
  • 읽는다, 또 읽는다.

• 문장구조
  • 5형식만 알면 어느 정도 직독직해가 가능하다.

• 문해력
  • 많이 읽고, 많이 생각하기 → 인내심
  • 영어 책이 어렵다면 한글 책도 어려울 가능서이 높음 → 호기심과 상상력

• 전문 지식
  • 평상시 열심히 공부하고, 책과 온라인 자료를 읽자(한글/영어 무관) → 시간 투자

---

( 3.1.2 ) 영어 빠르게 읽기

정확하게 읽는 것도 중요하지만 시간이 부족한 경우 빠르게 읽을 수도 있어야 한다.

• 영어 어순 이해 : 한국어로 번역하는 대신 영어 어순 그대로 이해
  • 끊어 읽기를 잘 활용

• 몇 개 단어 단위로 끊어 읽기 : 의미를 파악하는 단위(주로 구와 절)
  • 전치사와 접속사에 주목

• 스캐닝 : 문서 전체를 처음부터 다 읽는 대신 원하는 정보만 골라서 읽기
  • 목차와 검색을 활용

• 스키밍 : 상위 수준에서 문서 전체 요점을 파악
  • 뉴스 기사는 두괄식으로 전개
  • 가장 끝부분에 요약 정리가 있는 경우에는 이를 활용

• 그림 활용 : 아키텍처 다이어그램 등이 있는 경우 머리 속에 그림을 넣고 본문을 읽기 시작

---

( 3.1.3 ) 복잡성에 겁먹지 않기

• 닭이 먼저냐 달걀이 먼저냐?
  • 현상: 단어를 모르니 문장이 눈에 들어오지 않고, 문장 구조를 모르니 단어 뜻을 유추하기가 어렵다. 그냥 복잡해 보인다.
  • 모국어로 표현하기 어려운 단어/개념이 문제!
  • 고급 표현은 시사성 강한 글에서 습득할 필요가 있음

• 복잡성을 다루는 해법
  • 문장 구조를 튼튼히 익힘
  • 자신이 잘 아는 분야의 글부터 읽기 시작 (어휘 문제라는 장벽 넘기)
  • 다양한 책과 기사를 읽어 전반적인 문해력 강화

---

( 3.1.4 ) 문서 유형

• 튜토리얼
  • 학습 중심
  • 신입 대상
  • 번역이 잘 되어 있음
  • Ex) 아이들용 요리책

• 설명서
  • 이해 중심
  • 배경 지식과 맥락 제공
  • 책인 경우 번역서가 잘 나오는 펀임
  • Ex) 요리 역사서

• How to
  • 목표 중심
  • 특정 문제에 대한 해법
  • 일련의 단계
  • 인기 주제는 번역이 되어 있음
  • Ex) 전문 요리책

• 참조 문서
  • 정보 중심
  • 동작 방식 기술
  • 정확하고 완벽함
  • 번역이 잘 안 되어 있거나 구 버전인 경우가 많음
  • Ex) 백과 사전

 

 

※ 참고 자료

• 개발 문서 유형과 특성 : https://documentation.divio.com/

---

3.2 기술 뉴스 읽는 방법

시의성이 강한 형태

아주 자세히 파고드는 내용보다는 최신 흐름을 파악할 수 있게 설명

 

특징

• 폭넓은 화제와 다양한 어휘
  • 기술 뿐만 아니라 비즈니스와 업계 동향까지 소개하므로 어휘 폭이 넓음
• 구조가 정형화되어 있음
  • 개요 다음에 세부 설명으로 이어짐
  • 시간이 없을 때는 마지막 요약 설명에 집중
• 제목이 중요함
  • 한번에 많은 기사 제목 중에서 눈에 띄어야 하므로 강조와 생략이 들어감
• 뉴스는 최신 기술 동향을 빠르게 따라가기 위한 길라잡이다
  • 최신 소식을 모아서 보여주는 사이트를 적극 활용하자
  • 관심있는 분야의 전문 뉴스 사이트도 기억해놓자
  • 시사성 있는 용어가 많이 나오므로 난이도는 결코 쉽지 않다.

 

 

※ 참고 자료

• 해커 뉴스 : https://news.ycombinator.com/
• 레딧 : https://news.ycombinator.com/
• 아난드텍 하드웨어 뉴스 : https://www.anandtech.com/
• 톰스 하드웨어 : https://www.tomshardware.com/

---

3.3 튜토리얼 읽는 방법

처음 제품이나 서비스에 접하는 사용자를 위한 길라잡이

따라하면 맛보기가 가능한 방식으로 구성됨

 

특징

• 가장 기초적인 내용을 일목요연하게 정리
  • 설치법, 사용법, 작동 방법을 하나의 문서로 설명
• 다양한 환경에 대응
  • 여러 운영체제/개발 환경을 고려함
• 장황하게 모든 내용을 설명하는 대신 하나의 과업을 완성할 수 있게 기술
  • 대신 깊이가 얕으므로 본격적인 문제를 해결하려면 매뉴얼이 필요함

 

※ How to 문서

• 실제 세계의 문제를 해결하기 위한 방법
• what은 알지만 how를 모르는 경우에 유용
• 실용적인 성격이 더 강함

 

 

※ 참고 자료

• 파이썬 디버깅 튜토리얼 : https://github.com/spiside/pdb-tutorial

---

3.4 매뉴얼 읽는 방법

제품이나 서비스의 사용법을 설명

매뉴얼은 사용자, 운영자, 개발자 등 다양한 청중을 대상으로 작성됨

 

특징

• 목차와 찾아보기가 존재하므로 필요에 따라 원하는 부분을 확인
  • 목차로는 요점을 파악하고, 찾아보기로는 정보를 검색
• 순차적인 서술 방법을 따름
  • 설치법, 사용법, 작동 방법 등 실무에 필요한 내용이 순서대로 기술되어 있음
• 전문 용어가 많이 나옴
• 매뉴얼은 어느 정도 기술을 이해한 다음에 응용/활용 과정에 도움을 준다.
  • 처음부터 끝까지 읽는 대신에 필요한 부분을 중심으로 읽자
  • 목차를 머리 속에 잘 넣어두면 도움이 된다.
  • 자주 변경되는 소프트웨어를 다루는 경우에는 버전 확인과 호환성 확인에 각별히 주의

 

 

※ 참고 자료

• AWS : https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html
• Spring Boot : https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/

---

3.5 기술 블로그 읽는 방법

개발자가 작성하지만 다양한 소재를 다룸

다이어그램, 소스 코드, 명령어 등이 포함될 수도 있음

 

특징

• 구조가 정형화되어 있지 않음
  • 따라서 제목과 태그를 활용해 어떤 내용이 전개될지 파악해야 함
• 전문 작가의 작품이 아닐 수도 있음
  • 편차가 심하기 때문에 자신에게 맞는 블로그를 구독하는 방법을 추천함
• 참고 자료도 활용
  • 마지막에 참고 자료가 있을 경우 확인할 필요가 있음

---

3.6 기술 사양서 읽는 방법

정형적인 형태

따분하고 지루하지만 모호함은 적음

 

특징

• 제품이나 서비스가 충족해야 하는 요건과 기준을 설명
• 구조가 정형화되어 있음
• 예제가 별로 없음
• 특정 기술에 대한 표준안을 담고 있다.
  • 정확하고 포괄적이다.
  • 하지만 학습 목적으로는 부적절하다.
  • 표준안에 맞는 서술 방식에 대해 숙지하고 있어야 한다.
• 조동사에 유의
  • must/shall(절대적인 요건)
  • must not/shall not(절대적인 금지)
  • should(권장)
  • should not(미권장)
  • may(임의적)

 

 

※ 참고 자료

• W3C(World Wide Web) : https://www.w3.org/standards/

 

---

 

 

4. 코드 문서화

4.1 오해 없는 이름 짓기

프로그래밍 과정에서 이름이 인지 부하에 미치는 영향은 매우 높다.

좋은 이름과 나쁜 이름에 대한 차이를 인식해야 한다.

오해할 수 없는 이름을 피해 이해하기 쉬운 이름을 어떻게 만들어낼지 고민해야 한다.

 

페이텔슨의 3단계 모델

1. 이름에 포함할 개념을 선택한다.
2. 각 개념을 나타낼 단어를 선택한다.
3. 이 단어를 사용해 이름을 구성한다.

 

 

※ 참고 자료

• 작명을 도와주는 사이트 : https://www.curioustore.com/

---

4.2 영어로 이름 짓기

( 4.2.1 ) 기본 원칙

• 서술적인 이름을 사용하라.
• 적절한 추상화 수준에서 이름을 선택
  • 구현을 드러내는 이름을 피하자
  • 작업 대상 클래스나 함수가 위치하는 추상화 수준을 반영하는 이름을 선택하자
• 가능하다면 표준 명명법을 활용
  • 프로젝트에 유효한 의미가 담긴 이름을 많이 사용할수록 독자가 코드를 이해하기 쉬워진다.
  • Ex1) DECORATOR 패턴을 활용한다면 장식하는 클래스 이름에 Decorator라는 단어를 사용해야 한다.
  • Ex2) 클래스에서 구현부를 분리할 경우 1mpl을 붙인다.
• 명확한 이름
  • 파일, 네임스페이스, 클래스, 함수, 변수의 목적을 명확히 밝히는 이름을 선택한다.
  • Ex) doRename → renamePageAndOptionallyAllReferences
• 긴 범위에서는 긴 이름을 사용하자
  • 이름 길이는 범위 길이에 비례해야 함
  • 범위가 5줄 안팎이면 i, j, k도 좋음
  • 이름이 짧은 변수나 함수는 범위가 길어지면 의미를 상실함
• 이름으로 부수 효과를 설명하자
  • 클래스, 함수, 변수가 하는 일을 모두 기술하는 이름을 사용하자
  • 이름에 부수 효과를 숨기지 않는다.
  • Ex) getOos → createOrReturnOos

---

( 4.2.2 ) 작명 규칙

• 이름에 정보를 담자
  • 단어를 잘 선택해야 한다.
  • stop() → 다시 되돌릴 수 없으면 Kil(), 다시 되돌릴 수 있으면 pause()가 더 좋은 이름
  • send() → dispatch()(편지/메시지 전송), route()(최적의 경로를 선택해 보냄), announce()(어떤 (변경) 사항을 공지)
  • find() → search()(데이터베이스에서 검색), extract()(정보 등을 추론함), locate()(위치를 찾음)
  • start() → launch()(프로그램을 시작), create()(프로세스를 생성)
  • make() → build()(소스 코드에서 목적 파일을 생성), generate()(비즈니스에 필요한 결과물을 생성), compose()(기존에 존재하는 구성요소로 뭔가를 조립)
• 보편적인 이름 피하기
  • Ex) tmp, retval, gap과 같은 이름은 회피해야 함
  • 검색도 어렵고 이해도 어려움
• 추상적인 이름 대신 구체적인 이름 활용
• 추가적인 정보 덧붙이기
  • 접두사나 접미사를 활용
  • Ex) 평문 암호인 경우 password → plaintext_password
• 눈에 잘 띄게 만들기
  
  • camelCase : 자바 등에서 활용하며, 첫 단어를 제외한 나머지 단어의 첫 글자를 대문자로
  • snake_case : C와 파이썬 등에서 활용하며, 단어와 단어 사이에 밑줄(_, underscore)이 들어감
  • PascalCase : 단어의 첫 글자를 대문자로 시작함
• 클래스 이름은 명사구
  • 좋은 예 : Customer, Employee, WikiPage, Account, AddressParser
  • 나쁜 예 : Manager, Processor, Data, Info
• 메서드 이름은 동사나 동사구
  • 접근자(Accessor) : 값 앞에 get을 붙임 → employee.getName()
  • 변경자(Mutator) : 값 앞에 set을 붙임 → customer.setName("jay")
  • 조건자(Predicate) : 값 앞에 is를 붙임 → if (paycheck.isPosted()) ...
• 한 개념에 한 단어만 사용
  • 똑같은 메서드를 클래스마다 fetch(), retrieve(), get()으로 제각각 부르면 혼란이 온다
• 한 단어를 두 가지 목적으로 사용하지 마라
  • Ex) add() 메소드를 여러 클래스에서 사용할 경우 매개변수와 반환값이 의미적으로 같아야 함
• get() vs find()
  • get() : 실패가 없고 인출이 아주 짧은 경우 사용(비즈니스 논리 없이 단순 값 반환)
  • find() : 실패할 수 있으며 실행 과정에서 시간이 걸리는 경우 사용

---

4.3 주석

( 4.3.1 ) 코드 주석

코드 주석의 목적 : 코드를 읽는 사람이 코드를 작성한 사람만큼 코드를 잘 이해하기 위해 돕는다.

코딩을 수행하면서 머리 속에 들어있는 정보를 정리한다.

 

코드의 how를 설명하는 대신, 

핵심 요약이나 why, 배경 맥락을 설명해야 한다.

 

※ 주의

나쁜 코드에 주석을 달지 마라. 새로 짜라.
- 브라이언 W.커니핸, P.J. 플라우거

 

 

주석으로 설명하면 좋은 경우와 말아야 하는 경우

• 설명하면 좋은 경우
  • 코드가 특정 방식으로 작성된 이유
  • 코드에 담긴 결함이나 향후 할 일: TODO:, XXX: (IDE가 인식함)
  • 어떤 상수가 특정 값으로 정해진 이유
  • 평범한 사람이 예상치 못한 특이한 동작
  • 파일/클래스 수준에서 '큰 그림'을 설명하는 주석
• 설명하지 말아야 하는 경우
  • 코드만 보면 누구나 알 수 있는 내용
  • 나쁜 함수/변수명을 설명하려 드는 내용 → 코드를 수정하세요!

---

( 4.3.2 ) 주석과 관련된 스타일 가이드

• 2인칭이 아닌 3인칭 사용
  • Gets the label. (preferred)
  • Get the label. (avoid)
• 메소드 설명은 동사구로 시작
  • Gets the label of this button. (preferred)
• 클래스/인터페이스/필드는 주어 생략
  • A button label. (preferred)
  • This field is a button label. (avoid)
• 현재 클래스에서 생성된 객체를 지칭할 때는 "the" 대신 "this" 사용
  • Gets the toolkit for this component. (preferred)
  • Gets the toolkit for the component. (avoid)

 

 

※ 참고 자료

• Javadoc 도구 사용 방법 : https://www.oracle.com/technical-resources/articles/java/javadoc-tool.html

---

4.4 커밋 메시지

( 4.4.1 ) 커밋 메시지 기초

• 커밋은 작고 한 번에 문제 하나만 다루는 편이 유리
  • HOW 대신 WHAT과 WHY(How는 코드에 녹아져 있다)
  • 제목과 본문으로 구성
  • 긴 라인은 피한다 → 주제 행은 50글자, 본문은 70글자 정도가 적합
  • 티켓, 패턴 페이지, 매뉴얼 페이지 참고 링크가 있으면 좋음
• 커밋 메시지에서 우리가 고민해야 할 사항
  • 이 변경이 필요한 이유
  • 이 문제를 해소하는 방법
  • 변경이 가져온 부작용

---

( 4.4.2 ) 좋은 깃 메시지 작성 원칙

1. 주제와 본 내용 사이에 한 줄을 띄워라.
2. 주제 행은 일반적으로 50글자 이내로 작성한다.
3. 주제 행 첫 글자는 대문자가 되어야 한다.
4. 주제 마지막에 점을 찍지 마라.
5. 주제 행을 명령문으로 만들어라.
6. 본문은 72행에서 행갈이를 하라.
7. 방법이 아니라 이유를 설명하라.

---

( 4.4.3 ) 좋은 커밋 메시지를 위한 영단어 목록

• FIX : 올바르지 않은 동작을 고친 경우
• ADD : 코드나 테스트, 예제, 문서를 추가한 경우
• REMOVE : 코드 삭제가 있을 경우
• USE : 뭔가를 사용해 구현을 하는 경우
• REFACTOR : 리펙토링을 하는 경우
• SIMPLIFY : 코드를 단순화하는 경우(REFACTOR보다 약한 수정)
• UPDATE : 수정/추가/보완하는 경우
• IMPROVE : 호환성/테스트 커버리지/성능/접근성 등 향상이 있을 경우
• IMPLEMENT : 모듈이나 클래스 단위로 코드를 추가한 경우
• REVISE : 문서 개정이 있을 경우
• CORRECT : 문법 오류, 타입 변경, 이름 변경이 있을 경우
• ENSURE : 뭔가를 확실히 보장하는 경우
• PREVENT : 뭔가를 못하게 막는 경우
• AVOID : 뭔가를 회피하는 경우
• MOVE : 코드 이동이 있을 경우
• ALLOW : 뭔가를 허용하는 경우

 

 

※ 참고 자료

• 좋은 커밋 메시지를 위한 영어 사전 : https://blog.ull.im/engineering/2019/03/10/logs-on-git.html
• 깃 커밋 메시지 작성법 : https://cbea.ms/git-commit/

---

4.5 오류 메시지

( 4.5.1 ) 좋은 오류 메시지의 세가지 구성 요소

• 맥락 : 오류를 이끈 원인은? 실패했을 때 코드가 무엇을 시도하고 있었을까?
  
  • 오류 메시지의 경우에는 문제를 일으킨 코드가 실패했을 때 수행하려는 작업을 독자에게 설명한다.
  • 입력/구성 파일과 관련된 경우에는 절대 경로를 출력
  • 파일 내용의 특정 부분인 경우 줄 번호나 줄 자체를 출력
• 오류 자체 : 정확히 무엇이 실패했는가?
  • 문제의 심각성
  • 발생한 문제 소개
  • 문제가 발생한 위치
  • 문제가 발생한 이유
• 오류 완화 방법 : 오류를 극복하기 위해 어떤 일을 해야 하나?
  • 회피하기 위해 취해야할 조치를 설명
  • 오류 코드를 포함하면 더욱 좋다.
  • 오류 코드를 읽은 사용자를 어둠 속에 남겨둬서는 안 된다.
  • "잘못되었습니다" 라는 메시지만 출력하면 당황하기 마련

 

 

---

 

 

5. 검색 엔진 활용 방법

5.1 검색 엔진은 만능이 아니다

• 무작정 검색 엔진에 키워드만 잘 넣으면 해법이 나올까?
  • 내가 원하는 질문을 하는 대신 답이 나올 가능성이 높은 질문을 하자
  • 내가 무엇을 찾는지를 먼저 생각하고, 다른 사람이 이런 정보를 어떻게 표현했을지를 유추하는 습관을 기르자
  • 내 문제를 풀기 위해 자주 사용되는 용어(특히 명사)는 무엇일까? 한국어와 영어가 어떻게 다를까?

---

5.2 개발 관련 검색 힌트

• 오류를 찾을 경우
  • 정확한 메시지를 " "안에 넣는다.
  • 검색 결과가 너무 적으면 " "를 빼거나 특이한 단어를 제외하자
• 소프트웨어 설치 방법이 필요한 경우
  • 정확한 소프트웨어 패키지 이름(예 : Python 3.7)과 버전 이름과 목표 운영체제(예 : MacOS X Catalina)를 기술한다.
• How to, Tutorial 문서를 찾을 경우
  • howto 나 tutorial이라는 단어를 붙인다.
  • "filetype: " 을 사용해 pdf나 pptx 와 같은 문서 형식을 명시적으로 지정한다.
  • "site:"를 사용해 Slideshare(slideshare.net)나 Speaker Deck(speakerdec.com)으로 검색 범위를 한정한다.
• 코드를 검색할 경우
  • 프로그래밍 언어 이름을 명시적으로 붙이는 편이 유리하다. 
  • Ex) 현대적인 프로그래밍 언어 사이에서 유사한 형태가 많다
• 검색 유효성을 판단하는 경우
  • 날짜 정보가 있을 경우 이를 확인하자!
• 개념 정립 과정에서 문서를 검색하고 싶은 경우
  • 이미지 검색에서 마음에 드는 그림을 눌러 해당 사이트로 들어가는 방법도 추천한다
• 다양한 방법을 사용했음에도 불구하고 검색이 되지 않으면?
  • 너무 당연하므로 해당 주제에 대해 아무도 질문하고 대답하지 않는다. → 주변 사람에게 상황을 설명하고 조언을 얻는 방법도 좋다.
  • 정말 나에게만 발생하는 문제다 → 검색이 아니라 질문으로 대응할 필요가 있다.

---

5.3 구글 검색 팁

• 따옴표 사용
  • 오류 메시지와 같이 전체가 묶어져야 의미가 있는 경우에 적극 활용
• "site:" 사용
  • 특정 사이트에서 검색하고 싶은 경우
  • Ex) "mariadb socket authentication" site:mariadb.com
• "link:" 사용
  • 특정 사이트로 가는 링크를 포함한 페이지를 검색하고 싶은 경우
  • Ex) link:jhrogue.blogspot.com
• 와일드 카드 * 사용
  • 검색 엔진에게 자동으로 채워달라는 요청
  • Ex) "Come * right now * me" (비틀즈 노래를 검색함)
• "related:;" 사용
  • 다른 사이트와 유사한 사이트를 검색하고 싶은 경우
  • Ex) related:google.com (구글과 유사한 사이트를 검색함. 주로 검색 엔진)
• OR 사용
  • 여러 단어를 한 번에 검색
  • Ex) ubuntu OR Debian
• .. 사용
  • 숫자 범위 지정 
  • Ex) economic growth 2017..2019
• 검색 단어를 점진적으로 추가
  • Ex) job interviews → prepare for job interviews → how to prepare for a job interview
• 웹사이트가 사용할만한 단어로 검색
  • Ex) "I have a broken computer" → "repair a broken computer"
• 정의
  • 어떤 단어의 정의를 알고 싶다면? → define:Pl
• 철자 자동 교정
  • 어떤 경우에는 잘못된 철자로 검색해야 할 수도 있다.
  • Ex) 프로그래밍 오류 메시지
• 설명적인 단어 사용
  • "How to install drivers in Ubuntu?" → "Troubleshoot driver problems Ubuntu."
• "filetype:"으로 특정 파일 유형 검색
  • Ubuntu installation manual filetype:pptx
• vs 키워드
  • 대안을 자동완성하게 만드는 편법
  • Ex) ubuntu vs

 

 

※ 참고 자료

• 라이프해커에서 소개하는 20가지 구글 검색 팁 : https://www.lifehack.org/articles/technology/20-tips-use-google-search-efficiently.html

 

 

---

 

 

6. 좋은 질문과 대답

6.1 질문과 대답

대답하고 질문하는 행위는 학습의 일부로 봐야 한다.

더 많은 정보를 얻기 위해 질문을 하고 더 많은 정보를 제공하기 위해 답변을 한다.

 

또한 질문과 대답은 사회적 기술의 일부로 볼 수도 있다.

관계를 구축하고 유지하기 위해 질문과 대답을 활용한다.

 

질문에 대한 대답은 질문의 의미를 생각하고, 질문의 의미를 이해하고, 대답을 만들고 표현하는 과정이다.

질문은 묻고 싶은 내용을 생각하고, 마음 속에 질문을 형성한 다음, 실제 질문을 표현하는 과정이다

 

 

( 6.1.1 ) 질문과 대답이 중요한 이유

• 좋은 질문과 대답 역량이 문제 해결 능력을 결정한다.
• 질문
  • 스스로의 궁금증을 풀어준다.
  • 좋은 질문은 공동체에 도움을 주기도 한다.
• 대답
  • 자신이 잘 안다고 생각하는 분야도 대답을 하다 보면 그렇지 않다는 사실을 발견하게 된다.
  • 정리와 발표 능력을 높여준다.

---

( 6.1.2 ) 가설 수립과 증명

• 좋은 대답을 얻기 위해서는 1회성 정답을 요구하는 대신 가설 수립과 증명이라는 큰 틀에서 생각할 필요가 있다.
  • 내가 풀고자 하는 문제를 명확하게 만들고 가설을 세운다.
  • 이 가설을 증명하기 위한 방안을 고민해보고 실천한다.
  • 그 과정에서 일어나는 문제(예: 생각처럼 되지 않거나 화들짝 놀랄만한 결과를 얻거나)를 물어본다.
  • 대답으로부터 가설을 수정하거나 파기하거나 실험 방법에서 잘못을 찾는다.
• 질문 자체가 정량적이면 좋다.
  • 모든 질문이 정량적으로 떨어지지는 않으므로 정성적인 질문을 최대한 평가가 가능하게 만든다.
  • 질문 자체를 생각하는 과정에서 답을 찾아낼 수도 있다. (가설과 증명 과정을 다시 한 번 객관적으로 되돌아보기 때문)

---

6.2 좋은 질문과 좋은 대답

( 6.2.1 ) 좋은 질문

• 내가 묻고 싶은 내용 X, 상대방이 제대로 답할 수 있게 '좋은 질문' O
  • 질문과 대답이 이어지는 과정에서 서로 많은 것을 알게 되어야 한다.
• 먼저 내 상태(맥락)를 정확하게 밝히기
  • 병원에 가면 내 상태가 어떤지 이야기하듯이 개발 관련 질문에는 맥락이 존재해야 한다.
  • 내가 질문하는 내용 중에서 어디까지 이해하고 어디까지 이해하지 못했는지 알고 있어야 하며 그렇게 표현해야 마땅하다.
• 방법보다는 방법 중에서 구체적인 단계를 묻기
  • 개방된 질문을 할 경우 너무 다양한 선택지가 있을 가능성이 높으므로 서로 도움이 되지 않는다.
  • 조금 더 구체적인 질문이 좋다.
• 모른다는 사실을 인정하기
  • 대답을 들으면서 모르는 부분이 나올 때는 모른다고 인정해야 올바른 대답을 얻을 수 있다.
  • 특히 용어와 관련해서는 모르는 용어가 나올 경우 이에 대해 확인을 거쳐야 한다.
• 검색부터 먼저하기
  • 어디까지 검색해봤으며 무엇을 알아냈는지 알려줘야 시간을 낭비하지 않는다.
  • 아는 내용을 다시 설명하면 서로 괴롭다.
• 뻔한 질문하지 않기
  • 숨겨진 가정이나 지식을 어떻게 이끌어낼지가 핵심
  • 질문하는 상황이 정상인지 아닌지를 어떻게 알아냈는지 거꾸로 질문받을 때 갑자기 뭔가 깨닫게 될지도 모른다.
• 유도 신문하지 않기
  • 내가 목적하는 답을 얻으려 질문할 경우에 상대편은 당혹감을 느낄지도 모른다.
  • 내 질문의 의도는?

---

( 6.2.2 ) 좋은 대답

• 질문이 명확하지 않으면 이를 명확하게 만들자
  • 더 구체적인 단어로 풀어내기
  • 나의 용어를 사용해 다시 질문하기
• 상대방이 이미 무엇을 알고 있는지 확인하자
  • 상대방이 X에 대해 질문했는데, Y 사전 지식이 필요하다는 느낌이 들면 Y를 알고 있는지 거꾸로 물어보자.
  • 수준에 따라 대답이 달라질지도 모른다.

• 문제를 설명하는 문서를 알려주자
  • RTFM(Read the F*** Manual)은 좋은 대답이 아님
  • 최소한 어떤 문서에서 출발할지는 알려줘야 하고, 해당 문서의 어느 부분에 나와있는지 힌트를 줘야 한다.
• 당신이 수행한 방법을 알려주기
  • 실제 어떤 과정을 거쳐 어떻게 해결했는지 알려주고 질문자의 방법과 비교해본다.
  • 논의 과정에서 차이가 나는 부분을 찾을 수 있을지도 모른다.
• 기반에 놓인 문제를 해결하기
  • 질문 뒤에 더 큰 문제가 놓여있다는 사실을 알게 되면 이를 파고 들 필요가 있다.
  • 방법이 아니라 하고 싶은 일이 무엇인지를 물어보라! 전혀 엉뚱한 문제를 풀고 있을지도 모른다.
• 확인하기
  • 질문에 대한 대답이 되었는지 다시 한번 물어봐서 보충 설명이 필요한지 확인해야 한다.
• 문서화하기
  • 받은 질문이 정말로 문제가 되며 다른 사람도 알아야 하는 경우라면 문서화하거나 문서를 갱신해야 한다.
  • 자주 나오는 질문은 FAQ로 분리하는 방법도 생각하자!
• 묻고 답하는 훈련
  • 스택 오브 플로우나 서버플트에 들어가서 높은 평가를 받은 질문과 대답을 분석한다.
  • 어떤 공통점이 있는가?
  • 고구마 먹는 느낌의 대답과 질문은 무엇인가?
  • 사이다 마시는 느낌의 대답과 질문은 무엇인가?
  • 스스로가 어떻게 질문하고 대답해야 할지 교훈을 정리한다.

 

 

※ 참고 자료

• 스택오버플로우를 위한 FAQ 색인 : https://meta.stackoverflow.com/questions/251225/faq-index-for-stack-overflow
• 스택오버플로우의 질문 방법 소개 : https://stackoverflow.com/help/how-to-ask

---

6.3 공동체 활용 방법

아마 누군가 당신을 대신해서 이미 질문을 했을 가능성이 매우 높다.

 

• 질문과 대답이 올라온 시간이 중요하다.
  • 기술 관련 내용은 시간에 따라 빠르게 바뀔지도 모르므로 주의 깊게 읽고 최신 자료가 없는지 확인해야 한다.
  • 물론 역사적인 이유나 레거시 때문에 과거 사례를 알고 싶은 경우나 거의 고정 불변의 사실로 알려진 내용에 대해서는 시간이 지남에 따라 신뢰도가 높아지므로 고의로 과거 자료를 찾기도 한다.
• 가장 인기 높은 대답부터 읽지만 경우에 따라서는 전체 답을 뒤져야 할지도 모른다.
  • 아주 특이한 환경이나 특이한 요구 사항으로 인해 절대 다수가 인정한 대답 이외에 소수가 인정한 대답이 당신에게 딱 맞는 정답일 수도 있다.
• 검색 결과가 모순되거나 상충하는 여러 대답이 나올 경우
  • 추가 조사가 필요하므로 구글에서 두 가지 입장을 모두 검색해본다.
• 내가 원하는 검색 결과가 없는 경우
  • 1) 모든 사람이 다 알고 있는데 나만 모른다.(즉 문제가 아니다)
  • 2) 아무도 이 문제에 대해 관심이 없다.(즉 문제가 아니거나, 다른 각도로 문제를 바라 봐야 한다)
  • 주의 : 문제가 아님에도 불구하고 문제라고 생각하면 여기에 대해서는 해법이 없으므로 정말 조심해야 한다.
• 댓글을 유심히 살펴보자.
  • 질문에 대한 대답에 댓글이 달릴 경우가 있는데, 의외로 유용한 정보를 담고 있는 경우가 많았다. (예: 틀린 부분 지적, 보충 설명, 주가 자료).
• 답변 내용을 100% 믿지 마라.
  • 어디까지나 질문한 사람과 답변한 사람 사이에만 유효할지도 모르는(1) 대답이며, 100% 당신에게 유효하다는 보증은 그 어느 곳에도 없다.
• Quora 같은 경우에는 뉴스레터를 구독하면 사람들 관심을 많이 끄는 글을 접할 수 있다.
  • 남들이 많이 읽은 글은 대화의 주제나 소재거리로 활용하기에 적합하므로, 평상시에 이런 글을 틈틈이 읽어두면 무척 유용하다.
• 유익한 대답일 경우
  • 시스템에서 제공하는 기능에 맞춰 피드백(예: 별점, 좋아요)을 해준다.
• 정리, 또 정리
  • 좋은 질문과 답변 등은 북마크, 트위터, 개인 위키, 블로그를 사용해 정리하는 습관을 들이면 남들에게도 도움이 되며 자신의 정리력/기억력도 높일 수 있다.
• 스택 오버플로우에서 제안하는 좋은 질문 방법
  • 검색하고 연구하라
  • 특정 문제를 요약하는 제목을 붙여라
  • 바쁜 동료에게 질문하듯이 접근하라
  • 코드를 올리기 전에 문제부터 설명하라
  • 다른 사람들이 문제를 재현할 수 있게 도와라
  • 관련된 모든 태그를 붙여라
  • 포스팅 전에 철자 교정기를 돌려라

 

 

※ 참고 자료

• 쿼라 : https://www.quora.com/
• 스택오버플로우 : https://stackoverflow.com/
• 서버폴트 : https://serverfault.com/
• 해커스 뉴스 : https://news.ycombinator.com/

 

 

---

 

 

7. 코드 검토를 위한 고려 사항

7.1 코드 검토란?

코드 품질을 높이고 지식 공유를 전사적으로 수행하기 위한 활동입니다.

 

( 7.1.1 ) 코드 검토 스펙트럼

검토 작업을 위해 얼마나 많은 사람이 준비하고 참여해야 하는가?

코드 스펙트럼

• 팀은 프로젝트에 중요한 것이 무엇인지 식별하고 검토 과정에서 이를 일관되게 검사해야 함
• 코드 검토에 들어가는 시간을 줄이기 위해 형식 지정, 스타일 지정, 일반적인 버그 확인, 일반적인 보안 문제 식별, 자동화된 테스트 실행 등 최대한 자동화 수준을 높여야 함
• 코드 검토는 전투가 아닌 공동 토론이므로 중요한 것과 그렇지 않은 것을 미리 결정해야 함

---

( 7.1.2 ) 설계 관련 고려 사항

• 새 코드가 전체 아키텍처에 어떻게 잘 맞아 떨어질까?
• 코드가 SOLID 원칙, 도메인 기반 설계 원칙 등 팀이 선호하는 설계 원칙과 잘 맞아 떨어지는가?
• 새 코드에는 적절한 디자인 패턴이 사용되고 있는가?
• 코드가 올바른 위치에 있는가?
• 새 코드가 기존 코드에서 뭔가를 재사용했나? 또한 새 코드에 중복이 있는가?
• 코드가 과도하게 엔지니어링되지는 않았나?

---

( 7.1.3 ) 가독성 - verification과 유지보수성

• 필드, 변수, 매개 변수, 메서드, 클래스의 이름이 실제로 나타내는 내용을 반영하는가?
• 코드를 읽으면 코드가 무엇을 하는지 이해할 수 있는가?
• 테스트가 무엇을 하는지 이해할 수 있는가?
• 테스트가 정상과 예외를 모두 다루나? 미쳐 고려되지 않은 사례가 있는가?
• 예외와 오류 메시지를 이해할 수 있는가?
• 코드에서 혼란스러운 부분이 문서화, 주석 처리 또는 이해할 수 있는 테스트(팀 선호도에 따라)로 다뤄지고 있는가?

---

( 7.1.4 ) 기능 - validation

• 코드가 실제로 수행해야 하는 작업을 수행하는가?
• 잘못된 변수를 사용하거나 실수로 or 대신 and를 사용하는 것과 같은 미묘한 버그가 포함되어 있는가?

---

( 7.1.5 ) 양산/서비스 고려 사항

• 코드 변경에 따라 작성자가 공개 문서를 작성하거나 기존 도움말 파일을 변경해야 하는가?
• 사용자에게 표시되는 메시지의 정확성을 확인했는가?

---

7.2 코드 검토 기법

• 스스로 코드를 검토하라
  • 만일 내가 검토자라면?
• 깔끔한 변경 목록 준비
  • 변경에 대한 이유
  • 검색 가능한 문자열
  • 조사 방법에 대한 기록
• 쉬운 작업은 자동화
  • 기계가 잘 하는 일은 기계에게 맡기기
• 코드 스스로가 답해야 한다.
  • 변경 내역을 살펴보고 모든 코드 검토 토론을 읽어야 이해가 되는 코드는 나쁜 코드이다.
• 검토자가 코드 동작 방식에 대해 혼란을 표명하는 경우
  • 해법 : 한 사람이 아니라 모든 사람에게 설명해야 한다.
  • 질문에 답하는 가장 좋은 방법은 코드 리팩터링이다.
  • 이름을 바꾸거나 논리를 명확하게 만들기 위해 재구성이 가능한가?
  • 나쁜 주석을 없애고 그 자리에 좋은 코드를 넣어라
• 기능과 비기능 변경의 분리

 

 

※ 참고 자료 (코드 리뷰)

• https://www.infoq.com/articles/effective-code-reviews/
• https://mtlynch.io/code-review-love/

---

 

 

8. API 참조 코드에 주석을 다는 방법

8.1 API 참조 코드 주석에 포함될 내용

• 클래스, 인터페이스, 구조체
• 상수, enum, typedef
• 메소드(각 매개변수, 반환값, 예외 포함)

---

8.2 기본 지침

( 8.2.1 ) 클래스 / 인터페이스 / 구조체

• 클래스 이름과 서명에서 추론할 수 없는 정보를 기술
• 클래스의 의도된 기능을 간략하게 정리
• 우수 관례와 함정 등을 기록해도 좋음
• 주의 사항
  • 첫 문단에 클래스 이름을 반복하면 안 됨
  • "this class will/does ..."로 시작하면 안 됨

---

( 8.2.2 ) 멤버

• 상수나 필드에 대한 설명은 최대한 간략하게 정리
• 다른 메소드로 연결 고리가 존재한다면 이를 추가

---

( 8.2.3 ) 메소드

• 첫 문단에서 메소드가 수행하는 행동을 간략하게 기술
• 이어지는 문단에서 이 메소드를 사용하는 이유와 방법을 간략하게 기술
• 메소드 호출 전에 선행 조건이 있다면 이를 기술
• 발생할지도 모르는 예외가 있다면 이를 기술
• 관련된 API가 있다면 이를 기술
• 주의
  • 이 메소드 호출에 필요한 의존성이 있다면 이를 기술
  • 의존성이 빠져 있을 경우 메소드가 동작하는 방식을 기술 : Ex) "the method returns null"
• 메소드 설명
  • 기본 원칙은 모든 설명을 현재형으로 기술
  • 메소드가 연산을 수행하고 데이터를 반환한다면, 연산을 설명하는 동사를 포함한다. 
  • getter 메소드에서 부울 값을 반환하면 "Checks whether ...."로 시작한다
  • getter 메소드에서 부울이 아닌 값을 반환하면 "Gets the ..."로 시작한다
  • 반환값이 없다면, 다음을 따른다
    • 설정: "Sets the ..."
    • 갱신: "Updates the ...."
    • 삭제: "Deletes the ...."
    • 콜백 등록: "Registers ...."
    • 클래스 객체를 만들 경우: "Creates a ....
• 매개변수 설명
  • 기본 원칙은 첫 단어를 대문자로 마지막 문단이나 문장은 .으로
  • 부울이 아닌 매개변수의 설명은 가능할 경우 "The" 또는 "A" 로
  • API가 무엇을 할지 하지 말지를 알려주는 부울 매개변수인 경우, 매개변수가 true일 때와 false일 때 API가 무엇을 하는지 기술
    • Ex) enableCertificateValidation: If true, validates the SSL certificate before proceeding. If false, trusts
      the certificate without validating it.
  • 이미 확정된 뭔가의 상태를 선언하는 부울 매개변수인 경우, "True if .. false otherwise." 형식을 사용
  • 기본 동작 방식이 존재하는 매개변수인 경우, 값이나 값의 범위에 대한 동작 방식이 어떻게 되며, 기본 값이 무엇인지를 설명하고, 기본값을 위해서는 "Default: " 형식을 사용함
• 반환값 설명
  • 반환값 설명은 최대한 단순하게
  • 반환값이 부울이 아닌 다른 타입이라면, "The ..."로 시작
  • 반환값이 부울이라면, "True if m; folse othervise"를 사용
• deprecate 설명
  • 뭔가 더 이상 지원을 하지 않겠다고 결정되면, 사용자에게 대안을 제시해야 함
  • 버전 번호를 추적하고 있다면, 처음으로 지원이 중단되는 버전 번호를 언급함

 

 

---

 

 

9. RESTful API 자원 명명법

9.1 Resource (자원)

• Singleton vs Collection
  • customers vs customer
  • customers 컬렉션 URI : /customers
  • customer 단일 자원 : /customers/(customerld}
• Collection vs Subcollection
  • 특정 customer의 accounts : /customers/{customerld}/accounts
  • 여기서 다시 단일 account : /customers/{customerld}/accounts/{accountld}

---

9.2 규칙

• 자원 사이에 / 사용
• 가장 끝에 따라오는 / 제거
• 가독성을 위해 하이픈(-) 사용
• 밑줄(_) 사용 금지
• 소문자 사용
• 파일 확장자 사용 금지
• URI 이름에 CRUD 사용 금지
  • 대신 HTTP 동사 사용
  • GET(Read)
  • POST(Create)
  • PUT(Update/Replace)
  • PATCH(Update/Modify)
  • DELETE(Delete)
• URI 컬렉션 필터를 위해 질의 구성 요소 활용
• 직관적인 이름 사용
• 약어 사용 금지

 

 

---

 

 

10. 이해하기 쉬운 오류 메시지 작성 방법

10.1 좋은 오류 메시지의 장점

( 10.1.1 ) 좋은 오류 메시지

• 오류 원인을 정확히 파악하는 메시지가 좋다.
• 사용자의 유효하지 않은 입력을 파악해서 알려주는 메시지가 좋다.
• 요구사항과 제약사항을 정확하게 명세하는 메시지가 좋다.
• 예제를 제공하는 메시지가 좋다.

---

( 10.1.2 ) 좋은 오류 메시지의 장점

• 최상의 사용자 경험을 제공함
• 실행 가능함
• 보편적으로 접근할 수 있음
• 사용자가 스스로 해결할 수 있음
• 지원 업무량이 줄어듦
• 문제들 더 빠르게 해결함

---

10.2 잘 구성된 좋은 오류 메시지 작성 방안

• 간결하게 작성하자
  • 오류 메시지는 간결해야 하며, 불필요한 부분을 잘라내어야 한다.
• 이중 부정을 피하자
  • 이중 부정은 부정적인 단어를 두 번 포함한 형태
  • 독자들은 이중 부정을 읽기 어려워한다.
• 해당 사용자를 위해 기술하자
  • 해당 사용자에 맞는 맞춤형 오류 메시지가 중요하다.
  • 해당 사용자에게 적합한 용어를 선별해야 한다.
  • 해당 사용자가 알고 있는 사안과 모르고 있는 사안을 염두에 둬야 한다.
• 용어를 일관성있게 사용하자
  • 단일 제품/서비스 영역 내에서는 모든 오류 메시지에 일관된 용어를 사용해야 한다.
• 오류 메시지를 제대로 포맷팅하자
  • 가독성을 높이기 위해 형식에도 신경을 써야 한다.
• 올바른 어조를 선택하자
  • 긍정적인 표현을 사용한다.
  • 과도한 사과를 피해야 한다.
  • 유머를 자제해야 한다.
  • 사용자를 비난하지 말아야 한다.

 

 

※ 참고 자료

• 유용한 오류 메시지 작성 방법 : https://developers.google.com/tech-writing/error-messages

 

 

---

 

 

11. 정리

해당 [ 개발자 영어 ] 강의는 생각이상으로 많은 도움이 되었습니다.

당장에 기술적인 부분을 공부하는 것은 아니지만,

[ 개발자 영어 ] 강의를 통해 앞으로의 협업과 학습 속도가 향상될 것이라고 생각합니다.

 

해당 강의를 수강하려고 고민하시는 분들이 있다면, 추천드리고 싶습니다!

 

 

해당 콘텐츠는 유데미로부터 강의 쿠폰을 제공받아 작성되었습니다.

https://www.udemy.com/course/devenglish