우아한테크세미나 코드리뷰편을 보고 난 후 느낀점

 

이번에 새롭게 회사를 이직하게되면서 1인 개발이 아닌 팀단위 iOS 개발 프로젝트를 참여하게 될 예정이였기에

기존에 코드리뷰를 해본 경험이 적은 나는 새로운 팀에가서 빠르게 적응을 하기위해 코드리뷰에 대해 찾아보고 있었고 그러던 와중 
우아한 테크 세미나에 코드리뷰편을 진행한다는 소식을 듣고 온라인으로 풀로 시청을 하며 코드리뷰에 자세히 알 수 있었다.

 

전체적인 내용을 적으면서 내가 느낀점을 적겠습니다.

 

좋은 설계를 유지해야 생산성을 만들 수 있다.

리팩토링 2판을 읽고있는데 해당책의 저자가 했던 말과 동일한 이야기를 시작으로 세미나가 시작이 되었다.

공학의 특성은?

공학 = 설계 + 빌드

설계 : 예측하기 어렵고 , 급여가 비싸고 창의적인 사람들이 필요

빌드 : 좀 더 예측하기 쉬움

 

설계와 빌드가 분리됨

빌드 비용이 비쌈(건축 90%)

유지보수 비용이 상대적으로 낮음

 

SW 공학의 특성은?

 

공학 활동의 최종 목적은? 빌드 할 수 있는 어떤 종류의 “재생산” 가능한 문서

SW 공학의 설계와 빌드

설계 = 완전한 “소스 코드”

SW빌드 = 컴파일

 

좋은 설계 = “클린코드”

SW 엔지니어 : 설계를 잘하는 사람 → 코드를 잘 작성하는 사람

 

클린코드의 중요성

 

SW의 진정한 비용 = 유지보수 (전체의 80% 이상)

한번 작성한 코드는 10번 이상 읽음. 작성보다 이해에 10배의 노력 소요

90% 이상의 시간을 어떤 코드를 이해하는데 사용함

클린코드의 중요성 , 개발자에게 중요한 것은 좋은 설계를 기반으로 좋은 코드를 작성하는 사람이라고 이야기를 하는 것 같다.
공감하는 부분이 코드를 개발하면서 시간이 지나면 지날수록 어떻게 만들어야 나중에 "이거랑 관련된 기능을 수정할때 오류가 안생길까", "새로운 기능을 추가할때도 영향이 없이 짤려면 어떻게 코딩을 해야하나 라는 고민을 많이 했다."

 

그리고 공감하는 내용이 내가 만든 코드더라도 1주 , 2주 후에 보면 남이 만든것처럼 형편없어 보이고 이해하기 어려운 부분들이 발견되는 경우가 많다.

 

SW 개발의 단순한 진리

빨리 갈 수 있는 유일한 방법은 “잘”가는거다 (The only way to go fast , is to go well) - robert c martin

 

시간이 흘러도 생산성 저하, 비용 증가를 막을 수 있는 유일한 방법

SW 품질에 신중해야

SW의 비용과 품질의 관계는 비정상적 , 비관적

향후 변경 비용을 낮춤으로써 익순한 트레이드 오프를 역전시킴

(높은 품질의 제품은 비싸다)

개발자의 전문가 정신? 비즈니스 혁신?

→ 항상 코드는 비즈니스와 연관을 지어서

→ 테스트 커버리지를 높이고싶어요 X

→ 테스트 커버리지를 높이게 된다면 추후 업데이트와 기능의 안정성을 높이기 때문에 기간이 필요해요

흔히 테스크코드를 작성하고 리팩토링을 하는 이유를 많은 개발자들이 개발자적인 관점에서 CEO들을 설득할려고 하는 경우가 많다고 한다. 하지만 그것은 잘못된 생각이라고 이야기한다 좋은 개발 , 클린코드를 진행하는 이유는 모두 개발자의 성장이 아닌 비즈니스적인 측면에서 고려가 되어 진행이 되는 것이다 (생산성 증가) 단순히 코드 커버리지를 늘리고 싶어요 라고 이야기하는 것을 어떤 CEO가 좋아하겠냐? 모든 개발의 고려사항은 비즈니스적인 측면에서 생각을 해야한다고 이야기 해주었거고 이런 부분은 나도 생각하지 못했던 것 같다.

애자일

VUCA 시대에 더 좋은 SW 개발 방법론

단순 절차 변경 ? 개발 역량 ?

장인정신

지식과 경험의 공유 만이 전문성을 갖춘 개발자 육성

후배들에게 지식과 경험을 공유(도제관계)

현재 많은 회사들이 애자일한 방식으로 프로젝트를 진행하는데 애자일을 제대로 하는 회사가 많이 적다고 한다 이름만 애자일이라고 하고 나도 이전의 회사에서 제대로된 애자일을 진행하지 못했던것 같았기에 이번에 애자일도 제대로 경험해보고 싶어 이직을 결심하게되었고 이론적으로는 이해가되지만 실제로 경험을 해보지 않았으니 어떤 느낌인지 아직은 잘 감이 오지 않는다.

코드리뷰

개발자가 지금부터 당장 행할 수 있는 공유 활동

Code SNS 댓글 놀이

배움을 주고 받으며 지속가능한 SW 개발자가 될 수 있는 실천법

 

코드리뷰의 주된 목적

1. 코드의 버그 , 장애 검수
2. 더 나은 코드 품질 : 아키택처 속성 개선을 위한 코드 개선(향후 변경 비용을 개선시켜줌 OOP의 Open / Closed Principle 과 관련)
3. 학습 및 지식 전달 (코드 , 해결책 등과 관련된 지식 공유에 기여 )
   1. 공유를 통한 역량 증대 및 성장
      1. 대개의 경우 리뷰어들도 리뷰 과정에서 지식을 얻게 됨(하드스킬 소프트스킬)
   2. 동기부여

코드리뷰의 주된 목적만 봐도 내가 하고 싶었던 것을 모두 담은 것 같다. 아직 주니어개발자인 나는 항상 코드를 짜면서 분명 더 좋은 코드가 있었을 것 같고 누군가가 나에게 코드를 다른 방향으로 지도? 생각의 전환? 을 시켜줄만한 계기를 만들어 주었으면 했고 아는 만큼 보인다고 내가 아는 지식선에서 항상 코드를 만들었던것 같았다 하지만 다른 경험을 가진 주니어 , 나보다 더 많은 경험을 한 시니어 개발자분들에게 코드리뷰를 받으면 개발자로써 좀 더 성장하고 내가 놓친 부분들이 무엇이었는지 느낄 수 있을것같다.

코드리뷰의 장점

1. 상호 책임감 증가
   1. 집단 코드 오너십 및 결속 증대
   2. 내가 하고 있는 일에 관심을 가져주는 것
   3. 팀에서 일어나는 일 공유. 내 동료는 지금 무엇을 하나?
2. 설계 개선 제안
3. 개발 문화 개선

코드 리뷰의 절차

저자 (코드 작성자 , 리뷰요청)

리뷰어 (코드를 읽고 , 머지 가능한지 결정)

변경내역 (리뷰 시작 전에 작성)

• 리뷰 시작 전에 작성
• 저자가 머지를 원하는 소스 코드에 대한 일련의 변경(잘 한것 , 아쉬운 것 , 눈여겨 볼것)에 대해 기술

“저자가 고생하면 리뷰어의 시간이 준다”

이번에 이직을 해 코드리뷰가 처음인 나는 팀의 규칙에 맞게 최대한 어떻걸 테스트 해야하고 어떤걸 작성했고 어떤 포인트로 만들었는지를 최대한 상세하게 적어야 팀원들이 가진 피로도가 적을 것 같다. 나는 고생을 해도된다 하지만 팀원들을 고생 시키면 안된다.

코드리뷰하게되면

코드에 대한 비판을 자신에 대한 비판이 아니다

좀 더 좋은 방향으로 나가기 위한 팀워크이다

그러니 상처 받지 말자... 모르면 공부하면되고 알려주면 고마운거지 지금까지 혼자했는걸 ㅠㅠ

코드리뷰에서 가장 중요한점은 코드리뷰는 공격이 아니다 서로 보완해가는 과정 “서로서로가 성장”해가는 과정이다.

 

코드리뷰도 “글로 전달하는 과정이다”

코드리뷰는 절대 XX님 코드를 이따구로 짜면 쓰레기에요 라고 말하는게 아니다.

XX님 코드도 잘짜셨지만 이걸 이렇게 수정이 가능하고 이렇게하면 좀 더 읽기 편한거 같아요~
그러니 이렇게 바꿔보시는게 어때요? 라는 자연스러운 코드 리뷰의 과정이다

글을 못쓰는 나로써 상대방과 오해가 생기지 않도록 코드리뷰를 쓰는게 몹시 중요하다 아마 처음에는 흐음 코드 잘만드셨다 어떻게 리뷰를 진행해야할까? 라는 고민만 하겠지만

 

이 후에도 세미나에서 나온 좋은 내용들이 정말 많았다

 

효율적인 리뷰 방법 , 효율적인 피드백 방법 , 효율적인 PR방법등 경력이 많고 성숙한 개발자가 이야기해주는 코드리뷰에 대한 이야기를 

들을 수 있다는게 정말 좋은 세미나였다 위의 내용들에 관련해서도 글을 쓰고 싶지만 아직 직접 해본 경험이 없기에 느낀점을 적기에는 뭔가 

맞지 않다고 판단이 되어 앞부분의 내용만을 적었다.

 

아직 코드리뷰를 진행해보지도 않았고 경험도 없지만 이 영상을 보면서 코드리뷰란 어떤것인가? 좋은 코드리뷰란 어떤것인가?

왜 코드리뷰를 하는가를 배울 수 있었기에 나처럼 코드리뷰에대해 궁금함을 가진 사람이라면 이 영상을 정독을 해보는것을 추천합니다.

 

https://www.youtube.com/watch?v=ssDMIcPBqUE