1. 효과적인 학습 방법

  • 긍정적인 감정 이입하기
    • 잘 모르는 용어나 개념도 반복해서 듣고 사용하다 보면 익숙해짐
    • 계속해서 새로운 개념들이 나오는 분야이기 때문에 모르는 용어, 주제도 긍정적으로 바라보는 자세를 가져야 함!
  • 긴 호흡으로 바라보기
    • 공부해야 할 내용이 굉장히 많다보니 시간이 부족할 수 있음
    • 한번 뒤쳐졌다고 포기하지 말고 늦게라도 계속해서 따라가기
    • 경우에 따라서는 2번 듣는다고 생각하기
      • 처음은 빠르게 듣고, 다시 한번 조금 느리게 따라가보기
  • 그냥 열심히 하기!
    • 큰 방향을 가지고 하루하루 열심히 하기
  • 긍정적인 자세
  • 남과 비교하지 않기
  • 커리어를 길게 보기
  • 질문 잘하기
  • 의사소통 잘하기
  • 문제 정의 잘하기
  • 결과 내기


  • 프로그래밍 언어 선택하기
    • 하나의 언어를 깊게!
  • 구문 및 데이터 유형 이해하기
    • 기본 문법 이해 -> 고급 문법 이해
    • 상황에 맞게 적합한 구문과 데이터 유형 사용
    • 많이 코딩 해보기 + 고민해보기
    • 남의 코드 보고 배우고 내 코드 리뷰 받기
      • 리뷰해줄 사람이 없다면 chatGPT 이용!
  • 깔끔하고 읽기 쉬운 코드 작성
    • 많이 코딩 해보면서 리뷰 받는 것이 핵심
    • 팀에 시니어가 없다면 오픈소스 코드 보기
  • 생산성 툴 익히기
    • Git, Github
      • 커맨드라인에서 자유롭게 커밋하고 브랜치만들고 PR 만들기
    • 소스코드 에디터 (IDE)
      • 단축키 많이 사용해보기
      • 플러그인 많이 사용해보기

2. 좋은 코드

  • 깔끔한 코드는 읽고 이해하고 수정하기 쉬움
  • 코드는 명확한 이름, 일관된 형식, 의미 있는 주석으로 체계적으로 구성
    • chatGPT 활용!
  • 좋은 코드는 테스트가 가능하며, 코드와 함께 유닛 테스트를 작성해야 함
  • 클래스와 함수는 분명한 하나의 일을 하도록 구현해야 함
  • 코드는 모듈화 되어야 하며 중복을 피해야 함
    • 모듈화 - 하나 하나의 기능은 완전해야 함!
  • 오류 처리는 코드베이스 전체에서 철저하고 일관성 있게 이루어져야 함 (로깅)
  • 코드는 작성자가 아닌 사용자를 염두에 두고 설계해야 함
  • 단, 중요한 일에 더 완벽을 기할 것!

코드 작성 원칙

  • DRY (Don’t Repeat Yourself)
    • 같은 코드 여러번 작성 X
    • 한 번 작성하여 필요한 곳에 재사용할 수 있는 방법을 찾아야 함!
    • 반복되는 작업이라면 함수
    • 동일한 일이 반복된다면 반복문으로
    • 비슷한 클래스를 반복해서 만든다면 클래스 계승 구조를 사용해볼 것
  • KISS (Keep It Simple, Stupid)
    • 불필요한 복잡성을 피하고, 코드를 가능한 한 단순하게 유지
      • 코드를 꼭 짧게 작성해야 한다는 것이 아님 (특히 lambda 함수)
      • 내장 함수 사용
    • 너무 많은 기능을 하나의 함수로 구현하지 말 것
    • 한 함수가 너무 길어지면 이를 다수의 함수로 나눌 것
    • 결국 읽기 쉽고 이해하기 쉬운 코드를 작성하기 위해 노력
      • 다른 사람들이 사용하기 쉽고 테스트가 쉬워짐

3. 기술 부채와 스타트업

  • 스타트업의 경우 기술 부채가 점점 커짐
    • 의도적으로 코드의 품질보다는 속도에 초점을 맞추게 됨
    • 스타트업 코드에 기술 부채가 없다면 뭔가 잘못된 것
  • 어느 시점에는 이를 갚기 위해 코드/서비스 리팩토링을 시작해야 함
    • 어느정도 생존하게 되었는데, 이제는 기술 부채로 인해 회사의 운명이 위험해지는 경우
    • 서비스 관련 사고들의 빈도수와 심각성 트래킹 -> 대형사고 발생 -> 기술 부채를 갚아야 하는 시점
      • 테스트 작성 노력 -> 테스트 범위 (Test Coverage) 늘리기
      • CI/CD 도입
    • 새 기능 개발과 기존 코드 리팩토링을 적절히 밸런스 (60:40 정도)

4. 코딩 원칙

일반적인 원칙

  • 일관된 포맷 및 이름 지정 규칙
  • 의미있고 설명적인 변수 이름 사용
  • 적절한 주석 및 문서화
  • 제어 구조와 알고리즘의 효율적인 사용
  • 구글 파이썬 스타일링 가이드

제어 구조와 알고리즘의 효율적인 사용

  • Generator 함수
  • List Comprehension
  • Lambda 함수

5. 코드 리뷰

  • 주니어 개발자나 새로 온 개발자들을 트레이닝 시키는 최선의 방법
  • 단점은 리뷰를 해야 하는 사람들이 이미 바쁜 사람들이라는 점
    • 스프린트 플래닝 시 이를 고려하여 태스트 할당
  • 코드리뷰를 하는 이유
    • 교육
    • 심각한 버그 예방
    • 보안 상의 문제가 있는 코드 등 방지
    • 누가 언제 코드를 바꿨는지 기록 -> trouble shooting
    • 읽기 쉬운 코드 유지
  • 코드리뷰를 요청하는 이
    • 요청시 되도록 조금씩 자주 요청 (Unit test와 같이 요청하면 최상)
    • 주석을 최대한 추가하고, 무슨 이유에서 뭘 하려고 하는 것인지 설명
    • 리뷰에 대한 피드백을 너무 감정적으로 받아들이지 않기
  • 코드리뷰를 하는 이
    • 코딩 스타이렝 대한 것보다는 코드 자체에 대해 이야기
    • 객관적으로 쓰고, 비판적인 어조는 피하기
    • 충분히 시간을 들여 도움이 되는 리뷰 제공
  • 코드 리뷰에 편리한 툴 사용

구글 코드 리뷰

  • 코드 리뷰는 1명이어도 괜찮음, but 꼭 1명 이상의 리뷰를 받아야 merge 할 수 있음
  • Readability가 가장 중요
  • 본인의 스타일이 아닌, 레포 주인의 스타일을 따라야 함

  • 리뷰어는 꼭 시니어가 아니어도 괜찮음
    • readability를 충족하도록

6. Test

  • Unit Test
    • 모듈의 특정 기능(함수) 테스트
  • Integration Test
    • 여러 모듈을 통합하여 하는 한 차원 위의 테스트
  • Acceptance Test
    • 트래픽 등을 생성하여 시스템에 로드를 주고 견디는지 보는 테스트
  • UI Test
    • 요즘은 Selenium 등의 툴을 이용하여 웹페이지 자체의 기능을 테스트하는 것이 대세

테스트의 중요성

  • 많은 회사들이 코드 변경의 일부로 Unit Test를 의무적으로 요구
    • 테스트가 없으면 아예 코드 체크인이 실패하는 회사도 있음
  • 테스트가 많을수록 이점 증대
    • 시스템의 안정성 증대
    • 나중에 리팩토링할 경우 혹은 신입 엔지니어가 코드를 수정할 때 굉장히 편리
  • 어떤 경우에는 테스트를 작성하기가 너무 힘든 경우들이 있음
    • 이 경우 스프린트 플래닝 때 시간을 넉넉히 배당

Test Coverage

  • 실행 가능 경로 중 몇 퍼센트나 테스트가 되어있는지 그 퍼센트를 나타냄
  • Test Coverage가 높을수록 시스템이 안정됨은 물론이고 부수적인 효과가 존재
    • 해당 모듈을 리팩토링시 굉장히 유용
    • 새 엔지니어가 들어와서 작업 시 또한 유용

Unit Test

  • 자신이 만든 소프트웨어의 특정 기능을 테스트하는 것
    • 많은 경우 특정 함수를 테스트하는 것
    • 특정 입력에 대해 예상되는 특정 출력이 나오면 성공, 아니면 실패 / 혹은 나오지 말아야 할 출력이 나오면 실패하는 식으로 작성
  • Integration Test나 Functional Test에 비해 가장 낮은 레벨의 기본 테스트

Python에서 Unit Test

  • unittest 모듈
  • 요즘은 pytest

  • 테스트 클래스 내의 test_* 함수
  • 출력의 타입에 따라 다른 함수들을 사용해서 테스트 성공 여부 결정
    • assertEqual(a, b) : a와 b 두 객체가 같으면 True, 다르면 False
    • assertTrue(a) : a가 True면 성공, False면 실패
    • assertRaises : 주어진 입력에 대해 예상한 Exception이 나는지 확인

7. CI/CD 프로세스를 구현하려면

  • Software Engineering Practice의 하나
  • 하나의 코드 repository를 유지
  • 코드 변경을 계속해서 위의 코드 repository에 반영
  • 유닛 테스트를 추가
    • Repository의 Test Coverage를 70% 이상으로 유지
  • 안정적인 테스트 환경 준비
  • 빌드 생성 자동화 (테스트 포함)
    • Commit Build vs. Nightly Build
  • 빌드 배포 자동화 (CD)