Life Of D22

# 작게 만들어라 

# 한 가지만 해라 

# 함수 당 추상화 수준은 하나로 

# Switch 문 

# 서술적인 이름을 사용하라 

# 함수 인수 

# 부수 효과를 일으키지 마라 

# 명령과 조회를 분리하라 

# 오류 코드보다 예외를 사용하라 

# 반복하지 마라 

# 구조적 프로그래밍 

작게 만들어라 ... 당연하다. 가능하다면 ... 

한 가지만 해라 ... 당연하다. 여러가지를 한다면, 그리고 하나의 함수가 기능이 많다면 그만큼 관리하기 어렵고 관계가 너무 많아진다. 함수가 가진 부담이 많아짐. 

함수 당 추상화 수준은 하나로 ? TODO(주석) 읽는 것처럼 함수가 스스로 세부 사항을 포함시키지 않도록(되도록이면 ... ex: 인수를 넣는 것) 노력하라. 

Switch 문 ... 되도록이면 한가지 기능을 하되 유해한 구문 제거 

서술적적인 이름을 사용하라 ... 이책에서 줄창 강조하는 내용 

함수 인수 ... 인수가 여러개라면 해당 메소드나 함수를 사용할때 오해나 분석해야 되는 시간이 많아진다. 되도록이면 인자가 없되, 있어도 1개에서 2개선에서 하도록 함. Flag 를 사용하는 것은 피하고 3항 이상은 만들지 마라고 한다. 흠... 저번에 인자 6개짜릴 만든적이 있어서 좀 반성해야 되는 부분 ... 그리고 함수는 되도록 동사 + 명사 형태로 하되, write(name)과 같이 사용자가 직관적으로 알 수 있도록 하면 더욱 좋다고 한다. 

부수 효과를 일으키지 마라 ... 하나의 함수가 하나의 Action을 해야지 만약 저장하는 함수가 저장기능을 수행하고 파일을 삭제하는 일까지 해버리는 일은 하지 말라는 말. 함수를 사용하는 사람이 자신이 의도하지 않은 파일도 사라질 수 있으므로 ... 

명령과 조회를 분리하라 ... isSuccess 같이 조회 기능을 하는 함수와 order 같이 명령하는 함수는 분리해서 사용하라고 한다. 

오류 코드보다 예외를 사용하라 ... boolean isSuccess(상태) 보다 ... 그냥 예외를 통해서 처리하는게 원래 코드와 분리되어 코드가 깔끔해진다고 한다. 

반복하지 마라 ... "하위 루틴을 발명한 이래로 소프트웨어 개발에서 지금까지 일어난 혁신은 소스 코드에서 중복을 제거하려는 지속적인 노력으로 보인다" 

구조적 프로그래밍 ... 음 ... 이건 패쓰 ? 

마무리로 ... "프로그래밍의 기술은 언제나 언어 설계의 기술이다" 

※ 위 내용은 "Clean Code" 책에서 내용을 발췌하였습니다. 

 별다른 내용은 없다. 의도가 불분명한(변수를 a, b, s 등으로 짓는) 변수 및 함수(foo(x))를 사용하지 말고, 발음하기 쉽고 검색하기 쉬운(setPoint(int x, inty)) 것, 그리고 자신의 기억력을 믿지 말것이며(코드가 몇 만라인이 넘어가는 자신이 작성한 메소드 혹은 함수를 기억하는가?) 자신만이 알아 보는 변수 및 말장난, 단어를 사용하지 말것.(hellobaby, suxxx 등?). 그리고 함수나 메소드를 사용할 때(일반적으로 IDE(통합 개발툴)을 사용한다 치고) 굳이 주석이 없더라도 메소드의 기능 및 역할을 알 수 있는 이름으로 작성. 메소드나 함수 작성시 불필요한 내용, 혹은 불필요한 정보가 담긴 이름을 사용하지 마라(accountAddres와 customerAddress는 클래스 인스턴스로 적합하지 않음. 보면 바로 알 수 있는 이름으로 작성하라. 예를 들면 MAC, PortAddress, URI 같은 이름. 물론 그 의미가 다른 의미와 중첩되면 안된다) 

 

프로그래머는 대부분의 시간을 자신의 코드 혹은 타인의 코드를 읽으며 프로젝트 혹은 작업을 진행하게 된다. 이런 작업을 할때, 보다 빠르게 이해하고 진행하기 위해서 보다 의미 있는 이름을 작성해야 된다고 적혀 있다. 물론 옳은 말이며 대부분의 시간이 오류나 잘못된 구문을 찾기 위해 코드 리뷰는 ... 거의 필수다.(설계가 퍼팩트 하지 않는 이상) 

해당 챕터를 보면서 다시금 작명의 중요성을 깨닳게 된다. 작명 ... 그러기 위해선 많은 코드를 접해 보아야 하며 많은 이름을 만들어 보며, 그리고 스스로 반성하는 시간을 가져야 되겠다. 

프로그램 세계의 여러 노련한 프로그래머들로부터 그들이 생각하는 Clean Code란 무엇인가에 대한 생각을 적은 페이지. 

비야네 스트롭스트룹(Bjarne Stroustrup), C++ 창시자이자 "The C++ Programmer Language"의 저자

그래디 부치(Grady Booch), "Object Oriented Analys is and Design with Application" 저자 

"큰 형님" 데이브 토마스(Dave Thomas), OTI 창립자이자 Eclipse 전략의 대부 

마이클 페더(Michael Feather), "Working Effectively with Legacy Code"의 저자 

론 제프리(Ron Jeffries), "Extreme Programming Installed"와 "Extreme Programming Adventure in C#"의 저자 

워드 커닝엄(Ward Cunningham), Wiki 창시자, Fit 창시자, eXtreme Programming 공동 창시자, 디자인 패턴을 뒤에서 움직이는 전문가, SmallTalk와 OO(Oriented Object ??)의 정신적 지도자, 코드를 사랑하는 프로그래머들의 대부 

코드를 누가 보더라도 읽기 쉽고, 중복성이 적으며, 처음 코드를 접하였을 때와 코드 수정을 끝냈을 때 조금이라도 개선이 있을 것, 그리고 작은 크기의 코드와 테스팅과 철저한 오류처리를 위의 분들이 언급하였다. 

※ 위의 내용은 Clean Code (Rovert C. Martin 著)의 내용 중 일부분을 개인의 생각과 같이 작성하였습니다.