좋은 코드란...(코드리뷰, 클린코드, 협업하기 좋은코드)

최근에 문득 좋은 코드에 대해서 고민하게 되면서 여러 블로그 글을 읽어봤다.

 

#코드 리뷰

https://blog.linewalks.com/archives/7128

» 코드 리뷰를 대하는 개발자의 자세

현업에서 일하시는 백엔드 개발자분이 생각하는 코드 리뷰에 대해서 알 수 있었던 글이다.

이게 혼자 공부하는 입장에서는 팀프로젝트를 진행하는 기간이 아닌이상, 혼자서 코딩을 하기 때문에 코드 리뷰할 일이 많이 없었다. 그런데 최근에는 코딩 스터디를 들어가 매주 2일씩 정해진 문제를 풀어오고 같이 문제를 푼 후에 작성한 코드를 서로 보면서 발표하고 질문하는 코드리뷰 느낌의 시간을 갖게 되었다. 사실 처음에는 이런 시간이 비생산적이라는 생각을 했다. 굳이 내 코드도 잘 돌아가는데 남의 코드를 힘들게 이해해가면서 읽어보면서까지 할 필요가 있냐는 생각이였다.. 하지만 문제 난이도가 올라가서인지, 어느 순간부터는 한 문제에 대한 대한 다양한 접근 방식, 그리고 문제 해결 방식, 변수 및 매개 변수 설정 등 조원들의 아이디어를 보고 이해하는게 나름 재밌어졌다. 그리고 각자의 코드들을 비교해가며 어떤 코드가 읽기 쉽고 직관적인지, 그리고 어떤 코드가 더 시간적으로 빠르게 동작할 지 얘기해보면서 현업에서 다른 사람과 같이 협업할 때의 좋은 코드를 작성하려고 노력했던 것 같다.  위 블로그 글을 통해 내가 코테 스터디에 코드 리뷰에 임하는 마인드 셋에 대한 조언을 얻을 수 있었다. 위 글에서 더 와닿았던 소제목들은 '리뷰어가 항상 옳지 않다.' , '적극적으로 의견을 내라' , '사소한 것이라도 물어봐라' 가 있다. 이처럼 코드 리뷰를 통해서 성장할 수 있고, 특히 적극적인 질문을 통해 그 코드의 좋은 점을 내것으로 흡수 해야할 수 있어야겠다.

 

 

#클린코드

 

https://www.samsungsds.com/kr/story/cleancode-0823.html

클린코드란 무엇인가?

 

프로젝트 수정을 하기 위해서 실제 개발하는 시간은 10%로라고 한다.. 그럼 나머지 90%는???

즉 100시간 중 90시간은 기존 코드를 읽는 데 사용 된다고 한다.. 결국 읽기 어려운 코드는 유지보수와 협업에 있어서 치명적이다..

위 그래프는 이상적인 변경 비용이 현실과 차이나는 Technical Debt 에 관한 그래프 이다. 

개발자가 해결해야 할 부채라는 뜻인데,, 

이러한 현상이 발생하게 되는 이유가 프로젝트 초기에 오지게 빠르고 쉬운 개발(ex..copy&paste)와 같은 방법을 선택해서 단순 완성에만 의의를 두고 개발이 진행되기 떄문이다.

결국 이같은 문제를 막고 순조로운 협업을 위해서는 Clean Code가 중요하겠다.!!

클린코드의 주요원칙이라고 한다. 뭔가 표를 보니 추상적이다. 더 인터넷을 뒤져가며 찾아봣다. 클린 코드에 관한 책(Clean Code , 저자 :로버트 C.마틴 )에 목차가 단순명료하게 써있어 받아드리기 쉬운 것 같다.

• 읽기 쉬워야한다.
• 의미 있는 이름(실행 의도에맞게)
• 한 함수당 하나의 동작 ( 매개변수, 조건문은 줄일수록 좋다 )
• 주석은 줄이고 간단해야 한다.( 코드로 표현 )
• 형식을 맞춰라 ( 행 길이, 가로 길이 줄여서 읽기 쉽게 )
• 객체의 동작은 공개하고 자료는 숨긴다
• 오류 코드보다는 예외를 사용한다
• 단위 테스트 사용
• 작고 변경하기 쉬운 클래스
• 시스템 제작과 사용을 분리
• 표준 명칭 사용, 클래스 메소드 줄이기, 중복 없애기

나도 처음에 팀프로젝트를 처음 할 때, 함수와 변수 의미 없는 이름으로 (ex.. gg1, gg2) 작성하다가 팀원이 내 코드를 잘 이해 못해서 하나하나 설명해주느라 의미없는 시간을 소비했던 경험이 떠올랐다. 변수 이름 작성과 같은 단순한거 부터 팀을 위한 코드 작성이 이루어 져야 좋은 코드(클린 코드)가 되는 첫걸음이지 않을까 싶다.

 

함께 일하고 싶은 개발자가 되자!!