THE RED 백명석, 최범균 - 백발의 개발자를 꿈꾸며 : 코드리뷰, 레거시와 TDD : 강의 회고 및 개인 요약 정리(1)

회사 아이디로, FastCampus의 모든 강의를 들을 수 있지만, 남은기간이 얼마 남지않아

적응한다는 핑계로 미뤄두고있던 걸 부랴부랴 듣기시작 했습니다...ㅠㅠ

 

어떤 강의를 들을까 고민하다가, 사수님이 추천해준 The Red 들의 강의를 찾아보았고, 그 중에 지금의 내가 가장 흥미를 가지고 있는 TDD 와, 코드리뷰, 레거시 코드 리펙토링과 관련된 주제를 다루는 강의를 찾아서 보게 되었습니다

 

결론적으론, 굉장히 흥미롭게 볼 수 있던 강의였고

3가지 큰 분야를 딥하게 다루지는 않지만, 11번가 MSA 마스터(?) 백명선님과 TDD의 사나이(?) 최범균님의 전문성있는, 실전 압축 지식을 넓고 가볍게 필요한 부분만 들을 수 있어서 좋았습니다.

 

가장 크게 배웠던 건, 레거시 코드의 리펙토링 진행과정과 통합테스트에서 단위테스트까지 뽑아내는 TDD의 과정들을 라이브 코딩으로 볼 수 있던 것이 정말 인상깊고, 많이 배울 수 있었습니다.

 

재밌게 들었던 강의를 짧게나마,, 기록으로 남겨둡니다.

 

 

---

1부 백발의 개발자 - 개발자의 성장

 

1) 세상은 배우는 사람과, 배우지 않는 사람으로 분류할 수 있다.

 

2) 겸손하게 내 실력에대해 평가해 보도록 하자.. 아래의 3가지 예시를 들었을 때, 못했던 것은 분명히 나의 실력이 부족한것이다.

• 못하는 것 - 실력이 부족
• 할수있는 것 - 환경이 주어지면, 어찌저찌 해볼수 있음
• 하는것 - 환경이 부족해도, 내 실력이 되니까 할 수 있음

 

3) 개발자로 성장하기 위해서, 빠른 변화에 대응해야하며 그러기 위해선, 빠르게 배울 수 있어야하고 사고를 열어야한다.

4) 외적인 자극보다, 내적인 성취에 집중해라 (사실 어느정도는 공감하지만, 100프로 공감안됨)

 

---

 

2부 개발자가 성장하는 방법 - 코드리뷰

 

 

1)  왜 코드리뷰를 해야하나

1 - 시장과 비지니스의 요구사항

• 시장의 변화에 맞춰 사업은 더 빨리 혁신해야하고
• 개발은 더 바르게, 자주 배포해야한다. (이것은 굉장히 어려운 일 - 안정적인 배포의 중요성이 높아짐)

 

배포가 지속될수록 사업의 성장성은 떨어짐 (새로운 개발보다 - 유지보수에 집중하기 때문)

---

2 - 엉클 밥이 말하는 소프트웨어의 설계

• UML 다이어그램 같은 기획서가 아닌(같은걸 봐도 다른 결과가 나오기 때문)
• 항상 같은결과가 나오는 소스코드가 진정한 설계가 아닐까? (빌드 할 때마다 같은 결과가 나오니까)

 

결론은 그만큼 소스 코드 자체가 중요해졌다.

---

 

3 - 가장 빠르게 가는방법은 잘하는 것 이다...!!!

SW의 2가지 가치

1. It's Behavior : 현재 sw가 현재 사용자의 현재 요구사항을 만족
2. it's soft : 지속적으로 변화하는 요구사항 수용

---

 

4 - 애자일 관점에서 더 나은 코드란

• 애자일은 고칠 수는 없지만 지금 돌아가는 SW 보다,
• 지금은 돌아가지 않지만 고칠 수 있는 SW에 더 중요한 가치를 둔다.
• 즉, 깨끗하게 변경가능한 코드가 더 좋은 코드다.

 

Test 코드의 중요성

애자일 컨퍼런스, Production 코드와 Test 코드 둘 중 하나가 깨졌을 때, 무엇이 더 크리티컬 한가?

라는 토론에서 Test를 골랐다고 한다.

 

즉, 그만큼, Test 코드가 있으면, 프로덕션 코드는 작성하기 쉽다는 것 - Test의 중요성

Test 코드만 있다면, 가이드가 있기에 그것에 맞춰 더 나은 소스코드가 나올 수 도 있다.

 

---

결론 - 코드리뷰의 중요성

SW 장인정신을 가지자

• 어떻게 장인이 될 수 있어? - 지식공유와 전문성의 공유
• 코드리뷰는 - 가벼운 댓글이라고 생각하자
• Kent Beck - 자신은 위대한 개발자가 아니라 위대한 습관을 가진 개발자다. (코드리뷰와 TDD)

 

---

코드리뷰의 목적

1. 주목적 : 품질 문제 검수(버그, 장애)

2. Better Code quality : 아키텍처 속성 개선을 위한 코드 개선

3. Learning / Knowledge transfer : 코드, 해결책 등과 관련된 지식 공유에 기여

• - 주고받는 학습을 통한 역량 증대 및 성장
• - 참여한 모든 사람들의 배움의 기회
• - 대개의 경우 리뷰어들은 리뷰 과정에서 지식을 얻게 됨

 

4. 팀원들끼리의 관심 : 코드리뷰를 하면서, 서로간의 일에 관심을 가져보자

5. 개발문화 계선 

 

---

 

2) 코드리뷰의 절차

저자가 PR을 하면, 리뷰어들이 코드 리뷰를 해준다.

 

 

좋은 PR 예시

한명의 저자가 노력해서 여러명의 시간을 줄여주자

 

 

---

 

코드리뷰가 어려운 이유

1) 저자의 관점에서 PR

• 본인 생각에 멋지다고 생각하는 PR

2) 리뷰어

• 왜 멋지지 않은지 설명해야 함

 

✅ 리뷰어의 코드리뷰를, 코드에 대한 비판을 자신에 대한 비판으로 받아들여서는 안된다,

 

코드리뷰란, 

• 서로의 지식을 공유하며 같이 성장해 나가는 것
• 피드백은, 비판이 아니기에 조심스러운 배려워 숨은 의도가  있을수도 있으니 존중해야한다.
•  

---

 

3) 코드리뷰 기법들 1

효율적인 PR방법 및 코드 리뷰 방법

 

1. 리뷰 받지 않아도 되는 코드는 미리 표시하거나 툴을 이용해서 체크하자 ✅

1. unused import, declation
2. Intellij Analyze code : 커밋 전 체크
3. sonaLint : 컨벤션 및 코드 분석

2. 저자 PR할때, 먼저 궁금한 점을 달아둔다. ✅

3. 리뷰어에 모두를 포함하라✅

• 많은 사람들이 볼 때 버그를 더 잘 볼수있다.
• 팀원들이 어떤 일을 하고있는지, 관심을 가지고 알수있다.

4. 리뷰는 즉시시작✅

• 코드리뷰가 제일 큰 우선순위 - 저자는 리뷰가 종료될 때 까지 대기 (Merge 될 때 까지)
• 코드 피드백은 시간이 걸리더라도, 시작은 바로하라
• PR의 Size와 Complexity가 중요 - 작고 범위가 좋은 PR이 쉽고 상쾌하게 리뷰하기도 좋다

5. 리뷰는 고수준에서, 저수준으로 내려가라✅

• 너무 많은 의견은 저자가 당황할 수 있음
• 하나의 PR에 20~50개의 정도의 의견읜 위험하다
• 벨런스가 좋은 코드예제는 저자를 기분좋게 한다, (단, 너무 가벼운 코드리뷰는 저자를 무시하게 될 수도있음

6. 한두 등급만 코드 레벨을 올리는 것을 목표로 리뷰해보자✅

• 처음부터 완벽할 수 없다.
• 더 나은 코드로 가는게 완벽한 코드로 가는 길
• 단, 통과할 수 없는 코드에는 엄격해야한다.

 

---

3) 코드리뷰 기법들 2

| 피드백 방법 |

 

1. 코드에 집중해라

• 코드리뷰는, "너" 를 빼고 리뷰해라
• ~ 제안합니다. ~하는게 어떨까요?
• 저자를 평가하는게 아닌, 코드를 리뷰해야한다.
• 코드리뷰의 목표는 건전하고 학습적으로, 코드 실수에서 배우고 더 완성도 있는 프로젝트로 가는 것

 

2. 칭찬도 리뷰다!

3. 피드백은 명령이 아니라 요청으로 표현해라

4. 의견이 아니라 원칙에 기반하여 피드백하라

• 제안하는 변경과 변경해야하는 이유를 모두 설명해주어야 더 건설적인 리뷰가 된당
• 반복적인 패턴에 대해서 피드백을 제안하자

 

---

4) 코드리뷰 체크리스트

코드리뷰할 때, 체크해야할 목록들

• 버그 / 장애
• 기능성
• 가독성 / 유지보수 용이성
• 테스트

 

1. 버그 / 장애의 종류 

1. 📌 NPE(NullPointException) 
   • code.equals(null - 매개변수) 보다 null.equals(code) 로 하자!
2. 📌 Thread Safety
   • 멀티쓰레드 환경에 적합한 데이터구조를 사용하나? (아래는 스레드세이프하지 않음)
     • java.test.XXXFormat
     • java.util.LinkedList, uitil.HashMap 등 java.util.concurrent패키지에 존재하지 않으면서 Collection을 구현하는 클래스
     • 모든 output Stream
     • java.util.Calendar
   • lock을 제대로 사용했나
     • Synchronized, lock, atomic variable 등
3. 📌 OOME (OutOfMemoryException)
   • 메모리 누수가 있는지 확인하자
     1. static field - static 은 부모 객체가 참조되지않아도 GC되지 않는다, 범위가 무한정 늘어나서는 안된다.
     2. ThreadLocal
     3. ClassLoader
     4. Memory 가 지속적으로 증가하는 가능성
     5. connection / stream / session 을 close 했는지
     6. resource pool 의 범위가 잘 적용됬는지

---

2. 기능성 

1. 팀과 약속된 패턴
2. 코드가 실제 기대되는 일을 하는 로직인지
3. 미묘한 버그
4. 요구사항에 적합한 로직인지

---

3. 가독성 / 네이밍 + 테스트

1. 매직 넘버 - 단순 숫자는, 의미를 나타내는 상수로
2. 테스트가 예외도 다루는지
3. 나중에 사용될지도 모르는 소스를 삭제해야하는 경우 (commit log에 남기자 - https:/blog.outsider.ne.kr/849)\

1. 단위 테스트 없는 중요 로직
2. 경계값 테스트
3. 외부 UIRL이나 DB를 N번 호출하는 경우
4. 설계
   1. OOP 및 클린코드 준수 했는지
   2. 메타포의 역할을 하는지 (Controller, service, do, vo 등등)
   3. Composed Method - 복잡한 수준의 로직은 메소드로 빼자

 

 

 

---

 

레거시 코드 리펙토링과, TDD는 다음 글에서 정리하겠습니다!