Clean Code

2021-02-04(목), 0-38pg

읽는 목적 :
1. 어느 정도 코드를 짤 수 있다고 생각했는데, 의외로 다른 사람이 내 코드를 보는게 어렵다고 해서
2. (c언어) 함수 모듈화에 대한 고민을 했었다. 단순 반복작업을 함수로 나누는 것이 좋은 코드인가?
  설령 그것이 가독성을 해치는 코드일지라도?
3. 리팩토링을 한번 해봤었는데, 전혀 좋지 않은 경험이었다. 내가 짠 코드 구조를 처음부터 다시 수정하는 건 고쳐야 할 코드임을 자각하고 있음에도 마치 내 작업을 부정하는 것 같아서.. 좀 힘들었다.
  그래봐야 정말 스몰 프로젝트였기 때문에, 고치는데는 이틀밖에 걸리지 않았지만.
4. 추후에 회사에 가면 읽은 경험이 도움이 되지 않을까.

Book Intro

책 제목은 Clean Code : Agile 소프트웨어 장인.

Agile을 따르는 프로젝트나, 적용하는 소프트웨어 개발자에게만 한정된 책은 아니다.

코드는 Readable하며, Maintainable해야 함을 설파한다.

이와 함께, Clean한 Code를 유지하는 작업은 산업경영분야에서 이어져온 개념인 Total Production Management와 유사함을 논한다.

용어

TPM :

Treating the equipment as its everybodies' own.

Reduce the gap btw Operators and Maintainance.

시스템 효율화를 극한으로 추구.

사람과 설비의 체질 개선에 의한 기업의 체질 개선 추구.

TPM의 5S 활동

TPM의 기본을 이루는 활동

정리 : 변수
정돈 : 함수
청소 : 주석
청결 : 표준
생활화 : 실천

휴리스틱 :

직관적으로 따라하기

대충 어림짐작하기.

mental shortcuts

단위 테스트 케이스(Unit Test):

기계 테스트

인수 테스트 케이스(Acceptance Test):

기능 요구자 테스트.

Clean Code Intro

모두는 쓰레기 코드 손대길 망설인 뒤, 나중으로 미룬 경험이 있을 것이다.

그 쓰레기 코드를 수정한 경험은..?

Leblanc's Law :

그런 쓰레기 코드를 수정하지 않은 대가는 어떻게 되는가?

유지보수를 위한 인력과 비용이 커지는 대가로 소프트웨어의 발전을 희생해야 한다.

쓰레기 코드를 만들 수 밖에 없는 상황이라면? 프로젝트를 위한 자원이 주어지지 않는다면? 경영부에서 프로젝트를 만들 기한을 매우 짧게 준다면?

소프트웨어를 만드는 "코더"는 개발에 참여하며 Project Manage를 할 의무가 있다.

개발 일정과 요구사항을 밀어붙이는 "책임"이 필요하다.

메소드 추출 기법 :

여러 일을 하는 메소드나 메소드의 기능을 나눌 수 있다면 잘게 쪼개어 기능을 분리하는 기법.

https://martinfowler.com/books/refactoring.html

집합의 추상화를 사용해라.
- STL과 비슷한 개념으로 Abstraction / Interface를 만드는 것을 말하는 듯..?

전부 당연하게 지켜야 할, 원칙처럼 들리지만, 업계에 몇십년을 종사한 전문가들의 생각을 요약한 파트이기에,
시대를 관통하는 정석과 같겠다. 머리로는 알고 있는데 막상 실천은 제대로 못하는...?

변수

변수 작성에는 의미가 명시적으로 이름에 드러나야 한다.
```
for(int[] x: theList)
{
    if (x[0] == 4)
        list1.add(x);
    return (list1);
}
```
한눈에 무슨 역할을 하는 기능인지 알 수 있는가?
1. theList는 어떤 역할을 하는 자료구조인가?
2. 4는 어떤 특별한 숫자인가? 그냥 일반적인 숫자? 일반적인 숫자면 굳이 조건문에서 x[0]이 4임을 명시할 이유가 없지 않은가?
3. x는 뭔가?
4. 왜 list1을 리턴하는가?
다른 의미로 널리, 통용되는 특정 단어를 변수에 왜곡해서 사용하지 마라.

ex) String studentList의 List.
중복된 이름을 피하여 길이를 줄이고, 가독성을 높여라.
발음하기 쉬운 이름을 지어라.
Manager, Helper, Process, Data, Info 등의 모호한 접미사를 붙이지 마라.

개인 프로젝트 진행 시, print_manager(), print_helper() 등의 함수를 만들었었는데, 반성한다.

두 함수 모두, 개선이 가능하고, 어떻게 managing, helping이 되는지 명시하지 않고 있다.
Solution Domain VS Problem Domain

소프트웨어 공학 언어.

Solution Domain : Design - 설계의 영역

Problem Domain : Requirement-요구사항 분석 의 영역
컴퓨터공학도들이 알만한 변수 이름을 지으라는 말이다.

정리

Readablility는 그나마 이해가 가기는 하는데

소프트웨어의 maintainance는 솔직히 잘 와닿지 않는다.

현재 수준에서는 maintainance를 접할 일이 그닥...없는것같다.

Clean Code 에서 주장하는 바와 내 코드를 비교해보면,

int        print_handler(t_info *info, va_list *ap, int *len);    // 애매모호한 handler 네이밍.
char    *printer_type_p_helper(t_info *i, char *p) // 역시. Controler, Driver, Helper같은                                                             최악의 네이밍센스! 
char    *xud_substr_maker(t_info *info, long num);    //무슨 역할을 하는지 애매한 변수 이름
char    fill;        // 역시 무슨 역할? Fill? 채우다? - > 빈칸을 채우기 위해 선언된 변수이지만, 한눈                        에 봤을 때 알기 힘듬
#define F_LJUST 2    //발음하기 힘들다. 엘저스트?


void                tb_dynamic_add_helper(t_tb *tb_node, char *temp)
{
    free(tb_node->tb_arr);
    tb_node->tb_arr = NULL;
    tb_node->tb_arr = temp;
    tb_node->tb_size *= 2;
    return ;
}
// 위 함수 역시 지적받았었다. tb_node가 하는 역할을 알기 힘들다면서.. 당시에는 왜? Temp_buffer를 줄인 말이데 대체 뭐가 문제인가 싶었는데, 결국은 readability의 문제였다. 한눈에 보면 특정 역할을 하는 변수/함수인가를 알 수 있어야했다.

많이 부족함을 알 수 있다.

아직 변수파트까지밖에 오지 았았는데.

20210204(목) - CleanCode

Clean Code

2021-02-04(목), 0-38pg

Book Intro

용어

TPM의 5S 활동

Clean Code Intro

변수

정리