<aside> ⭐ 학습목표

• Coding Convention
• README.md
• 이력서 피드백 </aside>

<aside> 💬 TIL

마지막 시간에는 코딩컨벤션과 ReadMe 파일에 대한 이야기를 잠깐 나누고, 나머지는 이력서 피드백 시간을 가졌다.

• 코딩 컨벤션은 회사마다, 개인마다 지향하는 바가 다를 수는 있지만 대부분의 개발자들에게 이미 익숙한 컨벤션을 따름으로써 새로운 개발자의 코드 이해도가 빨라지고, 가독성과 유지보수성을 높일 수 있다.

• ReadMe 파일 또한 새로운 개발자가 투입되었을 때, 문서화된 파일을 읽음으로써 온보딩을 빠르게 할 수 있다는 장점이 있다. 이번 이력서 피드백 때도 ReadMe의 중요성을 자주 강조하시곤 했었다. 나 또한 잘 정리된 문서가 일의 효율성을 높여준다고 생각하기 때문에 ReadMe를 잘 작성해야 한다고 생각하는데, 어떠한 사항들이 포함되면 좋을지는 잘 몰랐었다. 현업에서 일을 하는 입장으로써 생각해볼 기회가 없었기 때문이다. 이번 강의를 통해 ReadMe에 무엇을 넣으면 좋을지도 알게되었다.

  지금까지는 Github은 사이드 프로젝트 또는 스터디 용으로 사용했었기 때문에 ReadMe에 무엇을 써야할지 깊게 고민해본 적은 없었던 것 같다. 부트캠프 팀 프로젝트의 ReadMe는 정말 간단히 프로젝트 설명과 팀원과 역할, 기술스택, 화면이 어떻게 나오는지, 그리고 외부 링크(API 문서, 디자인파일 등) 등만 넣었었는데, 그 외에도 실행환경과 버전, 실행시 필요한 파일, 실행 커맨드 등도 작성한다는 것을 알게 되었다.

  이미 많은 라이브러리나 프레임워크 등에서 좋은 ReadMe 파일의 예시를 보여주고 있지만, 앞으로는 현업에서도 실제로 어떻게 사용되고 무엇을 고민해야 할지 나 또한 경험해보고 싶다.

</aside>

📖 table of contents

1. Coding Convention

1-1. 코딩 컨벤션, 왜 사용하는 걸까?

• Leverage common programmer background!
• 대부분의 개발자들에게 이미 익숙한 개념과 방식을 사용함으로써 새로운 개발자가 코드를 더 빨리 이해할 수 있음
• 일반적으로 알려진 디자인 패턴을 사용, 공통된 배경 지식을 활용
• 특정 프로그래밍 언어에서 채택된 코딩 관행을 따르는 것
• 코드 가독성을 높일 수 있고 유지보수를 쉽게 할 수 있다.

1-2. 변수명은 어떻게 작성하면 좋을까?

• 같은 소리가 나는 단어 지양
  • ex. wrap, rap
• 최소 두 글자 이상 차이가 나는 단어 (명확하게 구분)
  • ex. inputFile, outputFile
• 숫자 X
  • ex. file1, file2 ❌
• 불필요한 부분(시제) 제거
  • ex. -ing, -ed ❌