달력

10

« 2021/10 »

  •  
  •  
  •  
  •  
  •  
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  •  
  •  
  •  
  •  
  •  
  •  

'클린 코드'에 해당되는 글 2건

  1. 2010.06.30 Chapter 3. 함수
  2. 2010.06.30 Chapter 2. 의미 있는 이름
2010. 6. 30. 23:48

Chapter 3. 함수 책상 위 컴퓨터/Clean Code2010. 6. 30. 23:48


# 작게 만들어라 
# 한 가지만 해라 
# 함수 당 추상화 수준은 하나로 
# Switch 문 
# 서술적인 이름을 사용하라 
# 함수 인수 
# 부수 효과를 일으키지 마라 
# 명령과 조회를 분리하라 
# 오류 코드보다 예외를 사용하라 
# 반복하지 마라 
# 구조적 프로그래밍 


작게 만들어라 ... 당연하다. 가능하다면 ... 
한 가지만 해라 ... 당연하다. 여러가지를 한다면, 그리고 하나의 함수가 기능이 많다면 그만큼 관리하기 어렵고 관계가 너무 많아진다. 함수가 가진 부담이 많아짐. 
함수 당 추상화 수준은 하나로 ? TODO(주석) 읽는 것처럼 함수가 스스로 세부 사항을 포함시키지 않도록(되도록이면 ... ex: 인수를 넣는 것) 노력하라. 
Switch 문 ... 되도록이면 한가지 기능을 하되 유해한 구문 제거 
서술적적인 이름을 사용하라 ... 이책에서 줄창 강조하는 내용 
함수 인수 ... 인수가 여러개라면 해당 메소드나 함수를 사용할때 오해나 분석해야 되는 시간이 많아진다. 되도록이면 인자가 없되, 있어도 1개에서 2개선에서 하도록 함. Flag 를 사용하는 것은 피하고 3항 이상은 만들지 마라고 한다. 흠... 저번에 인자 6개짜릴 만든적이 있어서 좀 반성해야 되는 부분 ... 그리고 함수는 되도록 동사 + 명사 형태로 하되, write(name)과 같이 사용자가 직관적으로 알 수 있도록 하면 더욱 좋다고 한다. 
부수 효과를 일으키지 마라 ... 하나의 함수가 하나의 Action을 해야지 만약 저장하는 함수가 저장기능을 수행하고 파일을 삭제하는 일까지 해버리는 일은 하지 말라는 말. 함수를 사용하는 사람이 자신이 의도하지 않은 파일도 사라질 수 있으므로 ... 
명령과 조회를 분리하라 ... isSuccess 같이 조회 기능을 하는 함수와 order 같이 명령하는 함수는 분리해서 사용하라고 한다. 
오류 코드보다 예외를 사용하라 ... boolean isSuccess(상태) 보다 ... 그냥 예외를 통해서 처리하는게 원래 코드와 분리되어 코드가 깔끔해진다고 한다. 
반복하지 마라 ... "하위 루틴을 발명한 이래로 소프트웨어 개발에서 지금까지 일어난 혁신은 소스 코드에서 중복을 제거하려는 지속적인 노력으로 보인다" 
구조적 프로그래밍 ... 음 ... 이건 패쓰 ? 


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


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

저작자표시비영리
TAG Clean Code, 클린 코드
Trackback (0) : Comment (0)
Posted by 잡학 저장소 잡학저장소

댓글을 달아 주세요

2010. 6. 30. 23:34

Chapter 2. 의미 있는 이름 책상 위 컴퓨터/Clean Code2010. 6. 30. 23:34


# 의도를 분명히 밝혀라 
# 그릇된 정보를 피하라 
# 의미 있게 구분하라 
# 발음하기 쉬운 이름을 사용하라 
# 검색하기 쉬운 이름을 사용하라 
# 인코딩을 피하라 
# 자신의 기억력을 자랑하지 마라 
# 클래스 이름 
# 메소드 이름 
# 기발한 이름은 피하라 
# 개념 하나에 단어 하나를 사용하라 
# 말장난을 하지 마라 
# 해법 영역에서 사용하는 이름을 사용하라 
# 문제 영역과 관련 있는 이름을 사용하라 
# 의미 있는 맥락을 추가하라 
# 불필요한 맥락을 없애라 



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

프로그래머는 대부분의 시간을 자신의 코드 혹은 타인의 코드를 읽으며 프로젝트 혹은 작업을 진행하게 된다. 이런 작업을 할때, 보다 빠르게 이해하고 진행하기 위해서 보다 의미 있는 이름을 작성해야 된다고 적혀 있다. 물론 옳은 말이며 대부분의 시간이 오류나 잘못된 구문을 찾기 위해 코드 리뷰는 ... 거의 필수다.(설계가 퍼팩트 하지 않는 이상) 
해당 챕터를 보면서 다시금 작명의 중요성을 깨닳게 된다. 작명 ... 그러기 위해선 많은 코드를 접해 보아야 하며 많은 이름을 만들어 보며, 그리고 스스로 반성하는 시간을 가져야 되겠다. 


※ 위의 내용은 "Clean Code" 내용의 일부를 발췌했음을 밝힙니다. 
저작자표시비영리
TAG Clean Code, 클린 코드
Trackback (0) : Comment (0)
Posted by 잡학 저장소 잡학저장소

댓글을 달아 주세요