[좋은 코드란 무엇인가] 한기용 강사님

data_hamster·2023년 4월 20일

특강 프로그래머스

앞으로 특강란을 따로 만들어서 다시 보기 편하게 하려고 한다.
velog도 조금씩 익숙해지고 있다.

학습내용

다음주
Git,Github

실제 데이터 엔지니어로 취직했을 때 어떤 것이 힘들었는가?

깃, 깃허브를 좀 더 잘 썼으면 편했을 것 같다.
깃/깃허브을 코드베이스로 하여 공동작업하기 편리함.
툴을 자유롭게 쓸 수 있느냐

내 코드에 쓰인 코멘트를 보고 감정적으로 반응 할 수 있음
CI/CD 에 대한 간단한 설명

3. 구글에서 사용하는 코딩규칙
5. 좋은 코드는 항상 테스트가 있음.

하드스킬, 소프트스킬

잘하는 사람을 롤모델로 삼기.
75살까지 일할 수 있다고 하면, 상당히 긴 커리어임. 너무 조급해하지 말자.
질문을 잘 하기 위해선, 개인적인 노력도 있지만 환경적인 요소도 있음.
면접은 서로가 맘에 들때가 좋은 환경임. 나도 질문을 많이 해서 얻어낼 수 있어야 함. 대체로 잘 대답해주는 면접관이 계실수록 좋은 환경일 확률이 높음. 팀의 분위기도 유추할 수 있음.
작년 매출을 얼마인지 등 작은 회사일수록 많이 물어봐라.

기술적 부분

데이터 분야면 Python
더 나아간다면 Java나 스칼라

일을 하면서 배우는 것이지, 프로그래밍 언어를 다 배우고 나서 일을 하는 것은 부적절.
알고리즘, 자료구조를 풀어보면서 프로그래밍 언어를 익히는 것도 좋지만, 실제 프로젝트를 진행하면서 만들어보는 것이 좋음.
그러다보니 생산성 툴을 익혀두는 것이 좋음.
소스 코드 에디터, 깃허브, Copilot, Chat-GPT 등

고급 문법은 조금씩 조금씩 필요에 따라 배워나가는 것이 좋음
코딩테스트 하면서도 배우고,
프로젝트를 하면서도 배우면 좋다.

그룹 프로젝트를 하면서 남의 코드를 보면서 배우고, 남의 피드백도 받아봐야함.

코드 리뷰를 잘 받을 수 있으면, 빠르게 성장할 수 있음. -> 좋은 멘토.
그러나, 그정도로 여유가 있는 시니어가 많지는 않음. 그런 경우엔 오픈소스 코드를 보면서 배우기. 작게나마 한줄이라도 보고 바꿔나갈 수 있다면 이력서에 좋은 이력이 됨.

나 역시 VS Code를 파는 것이 좋아보임.

Copilot 한달에 만원 정도인데 구독하는게 좋아보임. 에디터에서도 도움 받을 수 있음.

이름 정하는 것도 쉽지 않은데, chat gpt한테 물어보면 됨.
경험이 없는 개발자의 경우 함수 하나로 다양한 일을 처리시키는 경우가 있음.
코드를 복붙하면서 쓰고 있다면 잘못되고 있다는 것, loop를 사용하거나 보다 효율화 해야함.
코드는 아무리 생각을 잘 하고 작성해도 100% 버그를 피할 수 는 없음. 서비스 중간에도 오류가 뜨기도 함. 이 사고를 피할 수는 없음. 오류처리 하기위한 로그를 잘 남겨두면 나중에 사고가 나더라도 쉽게 대처가 가능.
다른 사람이 볼 수 있다고 가정하고, 사용자가 내 코드를 봤을 때 읽기 좋아야 함.
중요하지 않은 일에 너무 올인하는 것은 좋지 않음.

코드 작성 원칙

DRY: 중복되는 코드 방지
KISS: 함수나, 클래스는 하나의 일을 해야함.

코드를 반복해서 쓰면, 고쳐야할 때 여러번 고치다보면 실수할 확률이 높고 생산성도 떨어짐.

만일 formula가 바뀔 때 일일이 접근해줘야함.

멀티 라인 주석을 달아줄 수도 있음. 이건 무엇을 하는 함수인지.
보통 이 함수는 무엇인지, 파라미터는 무엇인지, 리턴은 무엇인지.

다른사람들이 읽기 쉽고 이해하기 쉬워야, 사용하기 쉽고 테스트가 쉬워짐. 기본 라이브러리에서 지원하는 기능이 있으면 쓰기. 코드가 꼭 짧을 필요는 없음. lambda함수는 강력하긴하나, readability가 좋지는 않음. 팀바팀.
내가 짠 코드라도 1주일 지나면 기억이 안 날 수 있음.
테스트 붙히기 쉬운 코드여야 함.

강사님은 lambda함수를 그렇게 선호하시진 않음.
1. x가 숫자라는 전제 하에, 그 값이 1보다 같거나 작은 경우 1을 리턴, 그 경우가 아니라면, 재귀적으로 x*f(x-1) 리턴.

이미 기본 라이브러리에 함수가 있을 경우, 굳이 짤 필요는 없음.

보통 코드리뷰를 할 정도로 여유롭지 않은 회사가 많음.

기술 부채의 경우 어느 포인트를 넘어가게 될 경우, 큰 문제가 됨. 작은 스타트업은 청산이 불가능함. 스타트업이 어느정도 성장하게 되면 기술 부채를 갚아나가야함.
유데미의 경우 블랙 프라이데이 때 매출이 엄청 나옴. 교육 사업이다보니, 1월 첫째주에 많이 팔림. 새해 결심을 하다보니. 유데미도 이 때 평균 트래픽의 50배가 들어오다보니, 온갖 종류의 이슈가 발생함. 그 때 payment 시스템이 하루정도 동작하지 않았음. -> 몇십억 손해가 발생.

보통의 개발자는 9:1 로 새 기술, 버그 수정을 함. 이를 6:4 정도로 기존 코드를 리팩토링 해나가야함. 맥스님의 데이터팀의 경우 6:4로 정책을 함.
Test Coverage를 늘려야함 -> 추후 기술

https://yosseulsin-job.github.io/Google-Python-Style-Guide-kor/#s1.1
구글 파이썬 스타일 가이드

코딩 규칙과 모범 사례 따르기

예를 들어 indentation을 누구는 스페이스, 누구는 탭, 누구는 스페이스 두번. 이렇게 하면 안됨.
변수의 이름이 다소 길더라도, 직관적으로 지어야 함.

이전에 배웠던, 스네이크 케이스, 캐멀 케이스(클래스), 상수는 대문자.

규칙 예외

for loop 돌 때 i, j, k 사용 가능.

에러 내용을 as e: 로 해줌. 일반적임.
변수 이름에 type을 적어주는게 좋을 수 있으나, 남발하지 말기. (ex: id_to_name_dict)

is 가 앞에 나올경우 bool type임

구체적으로 Google Python Styling Guide를 따라달라고 요청해주면 구체적으로 잘 짜줌.

적절한 주석 및 문서화

함수에 대한 적절한 설명 예시.

코드 리뷰

팀이 속도가 나려면, 코드 리뷰하는 사람들이 많아지는 것이 좋음.
구글이 코드리뷰 하는 이유.
1. 학습기회 제공
2. 버그 사고를 막음. 코드 리포지토리가 쌓임
3. 개인정보 유출
5. 읽기 쉬워짐.

하루에 한번정도는 바꾼 코드를 cheking, test, review 요청.
주석을 최대한 추가해서 리뷰하기 쉽게 함.
어느정도 context를 알고있는 동료와 리뷰하는 것이 좋음. 시간 절역

코드 리뷰에 편리한 툴 사용 -> 깃허브

리뷰어는 한명이면 된다.
가독성이 가장 중요함.
원래 있는 코드 주인 스타일을 따라가줘라.
구글 문화 특성상 다른 팀이 작성한 코드도 다 볼 수 있음.
코드 리뷰는 가볍고 빠르게 하는 작업
그렇다보니, 작은 작업물을 가지고 와야함.

코드 리뷰 예(1)

일단 주석이 없음. doc_string 형태로, 함수가 무엇인지, 파라미터가 무엇인지, 리턴 값은 무엇인지
-numbers가 불문명하기에 list_of_numbers로
이미 numpy에 관련 기능을 수행하는 모듈이 있음.
이 리스트가 비어있는 경우, 리스트의 길이는 0, 0을 밑으로 하면 에러 발생. 또 리스트형이 아닌 것을 넣으면 에러 발생.
에러처리에 관한 부분 해결해야함.