일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 프로그라피
- 개발자회고
- 서구동구예비군훈련장
- graphicdriver
- jaypark.dating
- 심플소프트웨어
- 인하멘토링
- 쇠막대기
- CrossAngle
- intell
- Xangle
- 개발자를위한파이썬
- 봉사활동
- 로그남기기
- 한빛미디어
- 신영준
- 노트북덮개
- tacotron
- 놀이동산의슈퍼컴퓨터를작동시켜라
- texttospeech
- machinelearning
- 타코트론
- 인천남중
- 서버로그
- 프로그래머스
- 나는리뷰어다
- 우분투비트확인
- 인하대학교
- 2019회고
- 결과를얻는법
- Today
- Total
jc.jang
좋은 코드를 작성하고 싶다. - 프로그라피 알고리즘 스터디 개인 발표 자료 본문
들어가며
프로그라피에서 알고리즘 스터디를 하고 있다. 시즌 2를 맞이하여 몇 가지 추가된 내용이 있다. 문제 푸는 것 외에도 각자 개발하면서 재밌었던, 힘들었던, 기억에 남았던 경험을 공유하는 시간을 갖도록 했다. 무엇을 발표할까 고민하다가 최근에 내가 공부하고 있는 것에 대해 발표하기로 했다.
좋은 코드 작성하기
좋은 코드를 작성하는 방법은 '클린 코드'에 잘 나와있다. 근데 그 책의 내용을 발표하는 건 아니고 내가 어떻게 수련하고 있는지 말해보고 싶었다. 나는 참고하는 게 몇 가지 있다.
- [우아한테크세미나] TDD 세미나 by 자바지기 박재성 (https://youtu.be/bIeqAlmNRrA)
- 목적의식 있는 연습을 통한 효과적인 학습 (https://brunch.co.kr/@javajigi/8)
- 클린 코드를 위한 테스트 주도 개발 (http://www.yes24.com/Product/Goods/16886031)
- 파이썬 코드 컨벤션 (https://www.python.org/dev/peps/pep-0008/)
- 짝 프로그래밍 코딩 도장 (https://github.com/dal-lab/coding-dojo)
이 주제로 발표하는 이유
알고리즘 스터디 시즌2를 시작하면서 개인적으로 보완하고 싶었던 부분은 '코드 리뷰'였다. 나는 생각보다 남의 코드를 읽는 시간이 많지 않았다. 그리고 회사에서 일하다 보면 남의 코드를 보고 리뷰 할 수도 있는데 이를 대비해서라도 코드 리뷰를 해보는 게 좋지 않을까?라는 생각이 들어서 적극 제안했다.
막상 코드리뷰를 해보니 좋은 코드를 작성해야 읽는 사람이 코드 리뷰하기도 좋을 것 같다고 생각했다. 내가 짠 코드를 나만 알아보면 되지 않겠냐라고 반문하는 사람도 있겠다. 그렇다면 6개월 전에 자신이 작성한 코드를 보도록 하자. 6개월 전의 나는 내가 아니다.
박재성 님의 자료를 참고하여 내가 제안하는 것은 다음과 같다.
좋은 코드를 만들기 위해 다음의 규칙을 지키자.
- 파이썬 코드 컨벤션을 지키자. (잘 모른다면 lint를 사용해서 정적 분석을 해보자.)
- 들여 쓰기 depth를 3이 넘지 않도록 구현하자. 2까지만 허용하자. 아래 코드가 들여 쓰기 depth 2이다.
for person in range(len(persons)):
if persons[person] == max(persons):
top_score_person.append(person+1)
- 함수는 한 가지 일만 하도록 만들어라. (너무 긴 함수를 만들지 말고 가능하면 코드를 분리하라.)
- 변수명에 약어, 의미없는 단어를 사용하지 말자. (a, i, foo 등)
- 최대한 파이썬 API를 잘 활용하자. (이미 있는 API와 똑같은 기능을 하는 코드를 직접 작성하지 말자.)
- else 예약어를 쓰지 않는다.
어떻게 위의 규칙을 지킬까?
위의 규칙을 지키며 개발하면, 좋은 코드를 작성할 수 있다는 것에 이견 없을 것이라고 생각한다. 하지만 개발을 시작할 때부터 위의 규칙을 지키려고 하면 어려울 것이다. 그래서 나는 일단 작성하고 코드를 리팩터링하는 것을 추천한다. 이 쯤에서 소개하고 싶은게 바로 TDD인데, 테스트 주도 개발을 의미한다. 테스트가 개발을 주도하는 개발 방법론이다. 방식은 간단하다.
- 테스트 코드를 작성한다.
- 실패하는 테스트 코드를 통과 시키는 가장 단순한 코드를 작성한다.
- 코드를 리팩토링한다.
이 방법을 반복적으로 하면 된다. 테스트 코드를 작성하는 것의 장점은 일종의 안전장치를 갖고 개발할 수 있다는 것이다. 함수를 나눠서 개발할 때도 함수마다 테스트를 작성하면 어느 함수에서 문제가 발생했는지 알 수 있다. 리팩터링할 때도 의도치 않은 부작용이 생길 수 있는데 테스트 코드가 이를 방지해준다. 괴물 같은 100줄 짜리 함수를 만들지 말자.
이렇게까지 해야되나?
그깟 알고리즘 문제 하나 푸는데 이렇게 고생해야되나? 라고 생각할 수 있지만 문제를 푸는 목적에 따라 다르다고 할 수 있다. 내가 알고리즘 문제를 푸는 이유는 첫째로 문제해결 능력을 기르기 위한 것이다. 두번째로는 좋은 코드를 작성하는 훈련을 하기 위함이다.
물론 알고리즘 코딩 테스트를 통과하기 위한 목적이라면 통과에만 의미를 둬도 된다고 생각한다. 하지만 누군가가 '알고리즘 문제 풀 때는 시간이 부족해서 좋은 코드를 작성할 수 없어요.' 라고 말한다면 나는 '당신은 주어진 시간안에 좋은 코드를 짤 만큼 훌륭한 개발자는 아니군요.'라고 생각할 것 같다.
시간이 없다는 핑계를 대기 전에 좋은 코드를 작성하는 것에 습관을 들이는 것이 중요하다.
그래서 결론은 위의 규칙을 지키며 좋은 코드를 작성하도록 노력하자는 것이다. 그리고 그 시작을 알고리즘 문제 풀이에서 시작하자는 하자는 것이다.
'개발 > 행사 후기' 카테고리의 다른 글
3월에 쓰는 2019년 회고 (부제: 취업에 관하여) (0) | 2020.03.04 |
---|---|
파이썬 메모리 이모저모 - 프로그라피 알고리즘 스터디 개인 발표 자료 (0) | 2020.02.01 |
개발자, 한 달에 책 한권 읽기 2019년 12월 모임 후기 (0) | 2019.12.25 |
달랩 - 코딩 도장#8 후기 (0) | 2019.12.13 |