DEVOCEAN

📚 선정 도서 📚

『 Clean Code(클린 코드):애자일 소프트웨어 장인 정신 』 - 로버트 C. 마틴

『 Clean Architecture(클린 아키텍처):소프트웨어 구조와 설계의 원칙 』 - 로버트 C. 마틴

✔️ 저희 조는 2명이 각각 클린 코드, 클린 아키텍처 책을 선정하여 책 스터디를 진행했습니다!

총 4번의 스터디를 통해 각자 읽을 수 있는 범위를 설정하였고, 스터디를 진행하며 서로 책을 통해 무엇을 배우게 되었는지 인상 깊었던 내용을 공유했습니다.

이 과정을 공유해 보고자 합니다!😊

✔️ 책 선정 배경

클린 코드 -이민지

컴퓨터학부에 다니면서 처음 1년은 워낙 작은 프로젝트만 하거나 교수님이 내주시는 과제들만 하다 보니 그냥 잘 돌아가기만 하면 장땡이었습니다. 그런데 2학년부터 점점 프로그램 규모가 커지고 팀 프로젝트들을 하며 잘 돌아가는 것뿐만 아니라 이해하기 쉽고 짜임새 있게 코드를 짜는 것의 중요성을 느꼈습니다. 이에 클린 코드에 대한 관심이 높아졌습니다. 코딩을 하다 보면, 특히 프로젝트를 하다 보면, 내가 짠 코드임에도 헷갈릴 때가 있고 주석을 많이 달면 더 지저분해 보이기도 해서 이런 부분에서 항상 한계를 느꼈습니다. 제가 고른 책 『클린 코드』는 워낙 유명한 책이기도 해서 꼭 한 번쯤은 읽어봐야지 했던 책입니다. 따라서 데보션영 책 스터디를 진행한다고 했을 때 가장 먼저 생각이 났습니다!! ✨

클린 아키텍처 -임도연

대학 강의를 통해 처음 접한 OOP를 바탕으로 안드로이드 개발에 대해서 학습하면서 MVC, MVP, MVVM과 같은 아키텍처 설계에 대해 많은 관심을 가지게 되었습니다. 데이터와 뷰를 분리하는 것을 중요시하면서 더 나은 구조와 더 나은 유지 보수를 위한 설계 방식에 대해 학습하고자 하는 의지가 있었고, 그 과정에서 클린 아키텍처에 대해 알게 되었습니다. 처음에는 여러 아티클들을 통해 기본적인 이론이나 방법론에 대해 접하게 되었으나, 해당 아키텍처를 제시한 사람의 글을 읽는 것도 의도를 파악하고 더 나은 소프트웨어를 설계하는데 큰 도움이 될 것이라고 생각하여 다독다독의 도서로 선정하게 되었습니다.

✔️ 도서 소개

애자일 소프트웨어의 혁명적인 패러다임을 제시하는 책이다. 저자 로버트 마틴은 오브젝트 멘토(Object Mentor)의 동료들과 힘을 모아 ‘개발하며’ 클린 코드를 만드는 최상의 애자일 기법을 정제하여 『Clean Code 클린 코드』 에 담았다. 아주 많은 코드를 읽고 그 코드의 무엇이 옳은지, 그른지 생각하며 전문가로서 자신이 지니는 가치를 돌아보기 위해 꾸준히 노력한다면, 이 책을 통해 여러분의 프로그래밍 실력은 한층 더 높아질 것이다.

『클린 코드』와 『클린 코더』의 저자이자 전설적인 소프트웨어 장인인 로버트 C. 마틴은 이 책 『클린 아키텍처』에서 이러한 보편 원칙들을 설명하고 독자들이 실무에 적용할 수 있도록 도와준다. 본서는 소프트웨어 아키텍트가 해내야 할 일과 그 일을 해내기 위한 규율과 실천법을 설명하였다. 기능, 구성요소 분리, 데이터 관리를 위한 소프트웨어 설계 핵심 원칙을 숙달하고 프로그래밍 패러다임이 규율을 강제하기 위해 개발자의 자유를 어떻게 제약하는지 알아본다. 또한, 웹, 데이터베이스, 리치 클라이언트, 콘솔, 임베디드 애플리케이션의 고수준 구조를 최적화하고, 아키텍처가 잘못되는 이유와 잘못된 결과가 나오지 않게 예방하거나 고치는 방법을 설명하였다.

*도서 정보 관련 출처 : http://www.yes24.com/Product/Goods/77283734 / http://www.yes24.com/Product/Goods/11681152

📚 1차 다독다독 📚

클린 코드 -이민지

[2장 의미 있는 이름]

<자신의 기억력을 자랑하지 마라>

독자가 코드를 읽으면서 변수 이름을 자신이 아는 이름으로 변환해야 한다면 그 변수 이름은 바람직하지 못하다. 루프를 제외하고 문자 하나만 사용하는 변수 이름은 문제가 있다. 똑똑한 프로그래머와 전문가 프로그래머 사이에서 나타나는 차이점 하나만 들자면, 전문가 프로그래머는 명료함이 최고라는 사실을 이해한다. 전문가 프로그래머는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓는다.

<한 개념에 한 단어를 사용하라>

예를 들어 동일 코드 기반에 controller, manager, driver를 섞어 쓰면 혼란스럽다. 이름이 다르면 독자는 당연히 다르다고 생각한다. 일관성 있는 어휘는 코드를 사용할 프로그래머가 반갑게 여길 선물이다.

[3장 함수]

<작게 만들어라!>

함수를 만드는 첫째 규칙은 '작게!'다. 함수를 만드는 둘째 규칙은 '더 작게!'다.

<한 가지만 해라!>

함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다.

<서술적인 이름을 사용하라!>

이름이 길어도 괜찮다. 길고 서술적인 이름이 짧고 어려운 이름보다 좋다. 서술적인 이름을 사용하면 개발자 머릿속에서도 설계가 뚜렷해지므로 코드를 개선하기 쉬워진다. 이름을 붙일 때는 일관성이 있어야한다. 모듈 내에서 함수 이름은 같은 문구, 명사, 동사를 사용한다. includeSetupPages, includeSetupAndTeardownPages, includeSetupPage 등이 좋은 예다.

<함수를 어떻게 짜죠?>

소프트웨어를 짜는 행위는 여느 글짓기와 비슷하다. 논문이나 기사를 작성할 떄는 먼저 생각을 ㅣㄱ록한 후 읽기 좋게 다듬는다. 초안은 대개 서투르고 어수선하므로 원하는 대로 읽힐 때까지 말을 다듬고 문장을 고치고 문단을 정리한다. 함수를 짤 때도 마찬가지다. 처음에는 길고 복잡하다. 이후에 코드를 다듬고, 함수를 만들고, 이름을 바꾸고, 중복을 제거한다. 메서드를 줄이고 순서를 바꾼다. 이 와중에도 항상 단위 테스트를 통과한다. 최종적으로는 이 장에서 설명한 규칙을 따르는 함수가 얻어진다. 처음부터 탁 짜내지 않는다. 그게 가능한 사람은 없으리라

[4장 주석]

<주석은 나쁜 코드를 보완하지 못한다> <좋은 주석>

코드에 주석을 추가하는 일반적인 이유는 코드 품질이 나쁘기 때문이다. 자신이 저지른 난장판을 주석으로 설명하려 애쓰는 대신에 그 난장판을 깨끗이 치우는 데 시간을 보내라! 명심하기 바란다. 정말로 좋은 주석은, 주석을 달지 않을 방법을 찾아낸 주석이라는 사실을!

<코드로 의도를 표현하라!>

나는 항상 코드를 위에 처럼 써놓고 주석을 달곤 했어서 이 부분에서 많이 찔렸다..ㅎㅎㅎ

항상 나도 개선 방법을 모르겠어서 골치 아팠었는데 앞으로는 함수로 만들어서 표현해봐야겠다!

<TODO 주석>

때로는 '앞으로 할 일'을 //TODO 주석으로 남겨두면 편하다. 당장 구현하기 어려운 업무를 기술한다.

<닫는 괄호에 다는 주석> <주석으로 처리한 코드>

둘 다 피하는 것이 좋다. 닫는 괄호에 다는 주석은 잡음이 될 뿐이다.  주석으로 처리된 코드는 다른 사람들이 지우기를 주저한다. 쓸모없는 코드가 쌓이게 된다.

클린 아키텍처 -임도연

[1부: 소개]

개발 조직은 더 나은 소프트웨어 품질을, 더 나아가 장기간 수익 창출을 위한 비용 최소화를 이끌어내기 위해서는 아키텍처에 대해 고민할 필요가 있다.

소프트웨어 개발자는 자신의 책임을 다하기 위해 투쟁해야 한다. 긴급한 다른 무언가로 인해 아키텍처를 반복해서 후순위로 미루게 된다면 결국 시스템 개발 비용이 더 많이 들게 된다.

📚 2차 다독다독 📚

클린 코드 -이민지

[5장 형식 맞추기]

<팀 규칙>

프로그래머라면 각자 선호하는 규칙이 있다. 하지만 팀에 속한다면 자신이 선호해야 할 규칙은 바로 팀 규칙이다. 팀은 한 가지 규칙에 합의해야 한다. 그리고 모든 팀원은 그 규칙을 따라야 한다. 그래야 소프트웨어가 일관적인 스타일을 보인다. 어디에 괄호를 넣을지, 들여쓰기는 몇 자리로 할지, 클래스와 변수와 메서드 이름은 어떻게 지을지 등이 있다. 좋은 소프트웨어 시스템은 읽기 쉬운 문서로 이뤄진다는 사실을 기억하기 바란다. 스타일은 일관적이고 매끄러워야 한다.

[7장 오류 처리]

<null을 반환하지 마라>

우리가 흔히 오류를 유발하는 행위에는 null을 반환하는 습관이 있다. 한 줄 건너 하나씩 null을 확인하는 코드로 가득한 애플리케이션이 가득하다. null을 반환하는 코드는 일거리를 늘릴 뿐만 아니라 호출자에게 문제를 떠넘긴다. 누구 하나라고 null 확인을 빼먹는다면 애플리케이션이 통제 불능에 빠질지도 모른다.

<null을 전달하지 마라>

메서드에서 null을 반환하는 방식도 나쁘지만 메서드로 null을 전달하는 방식은 더 나쁘다. 정상적인 인수로 null을 기대하는 API가 아니라면 메서드로 null을 전달하는 코드는 최대한 피한다.

클린 아키텍처 -임도연

[2부: 벽돌부터 시작하기:프로그래밍 패러다임]

구조적 프로그래밍, 객체지향 프로그래밍, 함수형 프로그래밍은 프로그래머에게서 권한을 박탈한다. 무엇을 해도 된다가 아닌, 무엇을 하면 안된다는 것을 규칙으로 정하고 행동을 제한하는 역할을 한다.

객체지향 프로그래밍을 통해 시스템을 구조화하고 독립적으로 개발할 수 있는 형태를 구축할 수 있다.

📚 3차 다독다독 📚 

클린 코드 -이민지

[9장 단위 테스트]

* TDD란?

Test Driven Development의 약자로 '테스트 주도 개발'이라고 한다. 반복 테스트를 이용한 소프트웨어 방법론으로, 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현한다고 한다.

<TDD법칙 세 가지>

1. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.

2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.

3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

<깨끗한 테스트 코드 유지하기>

테스트 코드는 실제 못지 않게 중요하다. 실제 코드 못지 않게 깨끗하게 짜야 한다.

테스트는 유연성, 유지보수성, 재사용성을 제공한다. 테스트 케이스가 있으면 변경이 두렵지 않다! 테스트 케이스가 없다면 모든 변경이 잠정적인 버그다.

[12장 창발성]

* 창발성이란?

하위 계층(구성 요소)에는 없는 특성이나 행동이 상위 계층(전체 구조)에서 자발적으로 돌연히 출현하는 현상이다.

<창발적 설계로 깔끔한 코드를 구현하자>

착실하게 따르기만 하면 우수한 설계가 나오는 간단한 규칙 네 가지가 있다면?

켄트 벡이 제시한 단순한 설계 규칙 네 가지. 켄트 벡은 다음 규칙을 따르면 설계는 '단순하다'고 말한다.

1. 모든 테스트를 실행한다

2. 중복을 없앤다. 

3. 프로그래머의 의도를 표현한다.

4. 클래스와 메서드 수를 최소로 줄인다.

*중요도 순이다.

<표현하라>

소프트웨어 프로젝트 비용 중 대다수는 장기적인 유지보수에 들어간다. 코드를 변경하면서 버그의 싹을 심지 않으려면 유지보수 개발자가 시스템을 제대로 이해해야 한다. 하지만 시스템이 점차 복잡해지면서 유지보수 개발자가 시스템을 이해하는데 보내는 시간이 점점 늘어나고 코드를 오해할 가능성도 점점 커진다. 개발자가 코드를 명백하게 짤수록 다른 사람이 그 코드를 이해하기 쉬워진다. 그래야 결함이 줄어들고 유지보수 비용이 적게 든다.

1. 좋은 이름을 선택한다.

2. 함수와 클래스 크기를 가능한 줄인다.

3. 표준 명칭을 사용한다.

4. 단위 테스트 케이스를 꼼꼼히 작성한다.

그렇지만 무엇보다 노력!! 이 중요하다. 흔히 코드만 돌린 후 다음 문제로 직행하는 사례가 너무도 흔하다. 나중에 읽을 사람을 고려해 조금이라도 읽기 쉽게 만들려는 충분한 고민을 하자. 낮우에 코드를 읽을 사람은 바로 자신일 가능성이 높다는 사실을 명심하다. 그러므로 자신의 작품을 조금 더 자랑하고 주의를 기울이자. 주의는 대단한 재능이다.

클린 아키텍처 -임도연

[5부 : 아키텍처 - 15장 아키텍처란?]

좋은 아키텍처는 시스템을 쉽게 이해하고, 쉽게 개발하며, 쉽게 유지보수하고, 또 쉽게 배포하게 해준다. 이를 통해 시스템의 수명 비용은 최소화하고, 프로그래머의 생산성은 최대화한다.

유지보수의 가장 큰 비용은 어디를 어떻게 고칠지 결정할 때 드는 데에 있다. 시스템을 컴포넌트로 분리하고, 안정된 인터페이스를 두어 서로 격리한다.

좋은 아키텍트는 결정되지 않은 사항의 수를 최대화한다. 정책이 세부사항과 결합되지 않도록 엄격히 분리하는 것이 중요하다.

📚 최종 다독다독 📚 

클린 코드 -이민지

[14장 점진적인 개선]

<점진적으로 개선하다>

프로그램을 망치는 가장 좋은 방법 중 하나는 개선이라는 이름 아래 구조를 크게 뒤집는 행위다.

테스트 주도 개발 (Test-Driven Development, TDD) 기법을 이용한다. TDD는 언제 어느 때라도 시스템이 돌아가야 한다는 원칙을 따른다. 다시 말해, TDD는 시스템을 망가뜨리는 변경을 허용하지 않는다. 변경을 가한 후에도 시스템이 변경 전과 똑같이 돌아가야 한다는 말이다.

아침에 엉망으로 만든 코드를 오후에 정리하기는 어렵지 않다. 더욱이 5분 전에 엉망으로 만든 코드는 지금 당장 정리하기 아주 쉽다. 그러므로 코드는 언제나 최대한 깔끔하고 단순하게 정리하자. 절대로 썩어가게 방치하면 안 된다.

[17장 냄새와 휴리스틱]

* 휴리스틱 이론이란?

휴리스틱(heuristics) 또는 발견법(發見法)이란 불충분한 시간이나 정보로 인하여 합리적인 판단을 할 수 없거나, 체계적이면서 합리적인 판단이 굳이 필요하지 않은 상황에서 사람들이 빠르게 사용할 수 있게 보다 용이하게 구성된 간편추론의 방법이다.

다음과 같은 예들이 나왔는데 앞서 책에 나온 내용들을 정리하는 느낌이었다!!

모두 적기엔 너무 많으니 일부만 써보았다.

<주석>

C1 : 부적절한 정보

C2 : 쓸모 없는 주석

C3 : 중복된 주석

C4 : 성의 없는 주석

C5 : 주석 처리된 코드

<환경> 

E1 :여러 단계로 빌드해야 한다

E2 : 여러 단계로 테스트해야 한다

<함수>

F1 : 너무 많은 인수

F2 : 출력 인수

F3 : 플래그 인수

F4 : 죽은 함수

<이름>

N1 : 서술적인 이름을 사용하라

N2 : 적절한 추상화 수준에서 이름을 선택하라

N3 : 가능하다면 표준 명명법을 사용하라

N4 : 명확한 이름

N5 : 긴 범위는 긴 이름을 사용하라

N6 : 인코딩을 피하라

N7 : 일므으로 부수 효과를 설명하라

<테스트>

T1 : 불충분한 테스트

T2 : 커버리지 도구를 사용하라!

T3 : 사소한 테스트를 건너뛰지 마라

T4 : 무시한 테스트는 모호함을 뜻한다

T5 : 경계 조건을 테스트하라

클린 아키텍처 -임도연

[5부 : 아키텍처 - 22장 클린 아키텍처]

클린 아키텍처는 지금까지 등장한 수많은 시스템 아키텍처의 목표인 “관심사 분리”를 중심으로 구성되었다. 프레임워크 독립성, 테스트 용이성, UI 독립성, 데이터베이스 독립성, 외부 에이전시에 대한 독립성을 하나의 아이디어로 통합하였다.

동심원으로 구성된 클린 아키텍처에서 가장 중요한 규칙은 “소스 코드 의존성은 반드시 안쪽으로, 고수준의 정책을 향해야 한다”는 것이다.

엔티티는 핵심 업무 규칙을 캡슐화하며, 외부의 무언가가 변경되어도 엔티티가 변경될 가능성은 지극히 낮다.

유스케이스 계층은 애플리케이션 특화 업무 규칙을 포함한다. 엔티티로 들어오고 나가는 데이터 흐름을 조정한다. 이 계층의 변경이 엔티티에 영향을 주어서는 안된다.

인터페이스 어댑터 계층은 데이터를 유스케이스와 엔티티에게 가장 편리한 형식에서 외부 에이전시에게 가장 편리한 형식으로 변환한다. GUI의 MVC 아키텍처의 경우 모두 포괄한다.

더 많은 계층으로 개념을 분리할 수도 있지만, 가장 중요한 규칙인 의존성 규칙을 지켜야한다.

아키텍처 경계를 횡단할 때는 의존성 역전 원칙을 사용하여 해결하는 등의 방식을 통해 규칙을 준수해야한다.

✔️ 다독다독 후기

[이민지] : 책을 읽으면서 평소 저의 코딩 습관들을 되돌아보며 동시에 개선 방향을 잡을 수 있었습니다! 특히 책의 앞부분이 가장 기본적이지만 많이 놓치고 있는 부분들이라 인상 깊었어요. 또한 팀 프로젝트 시에 코딩 스타일을 정해놓아야 한다는 부분에서 깊은 통찰을 느꼈고, 토이 프로그램이 아닌 실제 서비스에 관한 개발을 할 때 어떠한 태도를 가지고 개발을 해야 하는지 이해가 잘 되었습니다. 아쉬운 점은 저는 C언어, Python, Java 순서로 익숙한데 책이 Java 기반이라 이해하기 어려운 코드들도 있어 놓친 이야기들이 많이 있었을 것 같다는 점이에요. 그래서 추후에 제가 Java 언어에 많이 익숙해졌을 때쯤 다시 읽어보고 싶습니다!! 그 이후에는 도연님이 읽으신 클린 아키텍처도 꼭 읽어보고 싶어요! ✨

[임도연] : 다독다독을 통해 클린 아키텍처를 읽으면서 가장 인상깊고 잘 이해하고 싶었던 부분 일부를 정리해보았습니다. 클린 아키텍처가 유명하고 인기있는 방법론이기에 무조건 옳다고 받아들이는 태도가 아닌, 계속해서 저자의 의견을 되짚어보며 정말 이 행동이 관심사 분리에 적절한 행동인지를 파악하고 이해하는 태도가 되려고 노력하고 있습니다.

많은 분량이기도 하고, 복잡한 내용을 담고 있어 책을 전부 읽어보지는 못했지만 앞으로도 계속해서 더 나은 소프트웨어 설계 방법을 고민하기 위해 끝까지 읽어보도록 하겠습니다!👍