📚 클린코드 3장 함수 및 4장 주석 을 읽고 생긴 궁금증을 정리해 보았습니다
< 짧은 서두 >
어느덧 해당 활동도 2주차에 접어들었다!
아무래도 주제별로 클린코드에 대한 것을 이야기하다 보니까
생각보다는 궁금증이라든가 생각할 만한 포인트가 많이 나오지 않아
더 깊게 곱씹을 수 있어서 좋았던 것 같기도 하다 ㅎㅎ
1. 프로그래밍 초창기 시스템의 루틴과 하위 루틴 개념
프로그래밍 초창기에는 이러한 시스템으로 함수를 사용하지 않고 제작했다고 해서
어떠한 느낌으로 짰는지 궁금해졌다!
서치해 보니 OS 즉 운영체제에서 사용하는 시스템과 아주 유사한 느낌인 듯하다
routine and subroutine ; 루틴과 서브 루틴
컴퓨터 프로그래밍에서 루틴과 서브 루틴은 어떤 프로그램이 실행될 때 불려지거나 반복해서 사용되도록 만들어진 일련의 코드들을 지칭하는 용어이다.
이를 이용하면 프로그램을 더 짧으면서도 읽고 쓰기 쉽게 만들 수 있으며, 하나의 루틴이 다수의 프로그램에서 사용될 수 있어서 다른 프로그래머들이 코드를 다시 작성하지 않도록 해준다.
프로그램 로직의 주요 부분에서는 필요할 경우 공통 루틴으로 분기할 수 있으며, 해당 루틴의 작업이 완료되면 분기된 명령의 다음 명령으로 복귀한다.
어셈블러 언어에서는 매크로 명령어라 불리는 인터페이스를 가진 매크로 정의 부분에 변수의 입력을 필요로 하는 루틴이 코딩될 수 있다. 프로그래머는 루틴을 포함하거나 그 루틴으로 분기하는 대신 매크로 명령어를 사용할 수 있다.
매크로 정의 및 명령어는 다수의 프로그램 특히, 소프트웨어 개발 프로젝트에 참여한 프로그래머 사이에서 공유되는 경우가 많다.
고급 프로그래밍 언어에서는 공통적으로 필요한 많은 루틴이 미리 함수로 만들어진다. 어떤 함수는 프로그램의 다른 코드와 함께 컴파일 되고, 어떤 함수는 프로그램이 실행될 때 시스템 서비스를 위한 동적 호출(dynamic call)을 하는 부분에서 컴파일 되기도 한다.
함수들은 때때로 라이브러리 루틴이라고도 불린다. 컴파일러와 라이브러리 루틴은 대체로 관련 소프트웨어 개발 패키지의 일부분이 된다.
윈도우와 같은 PC의 운영체계에서는 특정 입출력 장치와 상호작용 하는 기능을 수행하는 시스템 루틴을 동적 링크 라이브러리(DLL) 루틴이라 한다.
이 루틴들은 처음 불려질 때 비로소 메모리에 실제 로딩되기 때문에 앞에 동적(動的)이라는 말이 붙는다.
비교적 최근에 쓰이기 시작한 용어인 "프로시저"도 의미상으로는 루틴과 거의 비슷하다.
출처 : http://www.terms.co.kr/routine.htm2. OCP 개념 정리
OCP 규칙이란 Open-Closed Principle 규칙, 즉, 개방 폐쇄의 원칙으로서
확장에는 개방적이어야 하고 수정에 대해서는 폐쇄적이어야 한다는 원칙이다.
즉 확장은 용이하되 수정은 최소화하는 규칙으로 객체 지향 5원칙 중 하나이다.
해당 글이 공부하기에 용이한 것 같아 첨부한다!
3. 실무에서 코드 리뷰 문화
사실 글을 쓰려고 여러 주제를 뽑아 놓았는데... 적다 보니 너무 바보 같은 주제가 아닌가? 하는 생각이 들어 다 줄이고 벌써 이것밖에 안 남았다
이 주제가 사실 이번 글의 메인이 될 것 같기도 한데... 아무튼 함수랑 주석 파트를 공부하면서 코드를 짜고 나서 이런 것들을 같이 체크해 줄 동료들이 필요하지 않을까? 그렇다면 어떤 토론 절차와 내용을 거칠까? 라는 생각이 들어서 이것저것 알아 보았다
(1) 뱅크샐러드
뱅크샐러드의 코드 리뷰에는 기술 조직이 일하는 방식, 문화가 녹아 있습니다.
타협하지 않고 순리를 추구하는 문화
저 문맥 커뮤니케이션 지향하는 문화
커뮤니케이션 비용을 비싼 비용이라고 여기는 문화
Blocker 가 되는 것을 부끄럽게 생각하는 문화
비동기 커뮤니케이션을 지향하는 문화해당 글을 읽으며 타협하지 않고 순리를 추구하는 문화가 가장 인상 깊었다.
실제로 프로젝트를 진행하면 시간에 쫓기기도 하고 좀 더 쉬운 길을 택하려고 하기도 해서 적당한 선에서 타협을 하기도 하는데 결국 순리를 따르는 게 제일 쉬운 길이 아닐까 싶다
리뷰어와 리뷰이이가 소통이 잘 될 수 있도록 모든 맥락을 제공하며 리뷰하는 사람은 최대한 좋은 방향으로 나아갈 수 있도록 템플릿이 마련되어 있다는 점은 다른 회사들도 진행 중인 공통적인 부분이니까 적용하면 좋을 듯하고!
Pn룰의 경우 다른 글을 읽더라도 꼭 나오는 부분이었는데 확실히 중요한 정보와 아닌 정보를 빠르게 캐치할 수 있어서 좋은 듯하다
(2) 구글 코드 리뷰
원본은 영어로 제공하지만 많은 분들이 번역서를 제공해 주셔서 그중 하나를 갖고 왔다
CL이 완벽하지 않더라도 전체적인 코드 품질을 증가시키는 상태에 도달했다면 리뷰어는 해당 CL을 승인하는 방향으로 생각한다.
언제나 기술적인 사실을 개인적인 견해나 선호도보다 우선시 한다.
코드 스타일에 관해서는 스타일 가이드를 절대적으로 따른다.
정해진 가이드가 없으면 작성자를 따른다.
소프트웨어 설계에 관한 사안에서는 절대 스타일이나 개인 선호를 기준으로 결정하지 않는다.
정해둔 규칙이 없을 때는 기존 코드와 일관성을 유지하도록 한다.코드 리뷰의 대원칙과 소원칙은 다음과 같다고 한다. 외에도 글을 읽으면서 기능, 복잡도, 테스트, 이름, 주석에 대한 규칙이 있었는데 이번 파트에서 주석에 관한 글을 읽었으니 또 갖고 와서 첨부해 본다.
주석이 명료하고 도움이 되는가?
정말 필요한 주석만 있는가?
유용한 주석은 코드가 어떤 일을 하는지가 아니라 왜 존재하는지를 담고 있다.
코드만 봐서는 어떤 일을 하는지 이해가 잘 안 된다면 코드를 더 간단하게 고쳐야한다.
정규 표현식이나 복잡한 알고리즘에 대해서는 예외로 어떤 일을 하는지를 적어도 좋지만 일반적으로는 코드에 담을 수 없는 정보를 주석에 남기는 편이 좋다.일반적으로는 코드에 담을 수 없는 정보를 담자! 라는 표현이 인상 깊었다.
또한 일부만 보지 말고 전체를 봐야 한다는 점과 꼭 좋은 점은 언급하자는 점이 마음에 들었는데 사실 코드를 짜다 보면 날카로운 리뷰에 감정이 상하는 경우도 있어서 꼭 필요한 점 중 하나라고 생각한다.
(3) 우아한 형제들
위와 비슷한 내용이 담겨 있지만 해당 내용들에는 시행착오 과정을 좀 더 친절하게 볼 수 있어서 한번쯤 참고하면 좋을 듯하다!
멋있어요!