클린코드

20 posts

클린코드(Smells and Heuristics)-part2

클린코드 냄새와 발견법(Smells and Heuristics) part2 함수 부정 조건은 피하라. 부정 조건은 긍정 조건보다 이해하기 어렵다 가능하면 긍정 조건으로 표현하라. 위에 코드가 아래 코드 보다 낫다. 함수는 한가지 일만 해야 한다. 함수를 짜다 보면 한 함수 안에다 여러 단락을 이어서 일련의 작업을 수행하고

9 min read

클린코드(Smells and Heuristics)-part1

클린코드 냄새와 발견법(Smells and Heuristics) part1 주석 부적절한 정보 다른 시스템(svn, git, 이슈트렉커 등등)에 저장될 정보는 주석으로 부적절하다. 주석은 코드의 설계에 기술적인 설명을 부연하는 수단이다. 쓸모 없는 주석 오래된 주석, 엉뚱한 주석, 잘못된 주석은 더이상 쓸모가 없다. 중복

10 min read

클린코드(Successive Refinement, JUnit Internals, Refactoring SerialDate)

클린코드 Successive Refinement(점진적 개선) 프로그래밍은 과학보다 공예에 가깝다. 클린코드를 짜려면 먼저 지저분한 코드를 짠 뒤에 정리해야 한다는 의미 점진적 개선을 하기 위해 TDD를 실천 하였고 그래서 하나 씩 개선해 나간 내용이다 이부분은 책으로 꼭 읽어 봐야 할듯 하다 책의 내용이 전체적으로 리펙

3 min read

클린코드(Concurrency)

클린코드 Concurrency(동시성) 동시성이 필요한 이유 동시성은 결합을 없애는 전략이다. 즉 무엇과 언제를 분리하는 전략이다. 스레드가 하나인 프로그램은 무엇과 언제가 서로 밀접하다. 그래서 호출스택을 살펴보면 프로그램 상태가 곧바로 드러난다. 단일 스레드를 디버깅하는 프로그래머는 정지점을 정한후 어느 정지점에 걸렸

17 min read

클린코드(Emergence)

클린코드 Emergence(드러나다, 창발성) 켄트백의 간단한 설계규칙 4가지 모든 테스트를 실행한다. 중복을 없엔다. 프로그래머의 의도를 표현한다. 클래스와 매소드 수를 최소로 줄인다. 간단한 설계규칙 : 모든 테스트를 실행하라. 문서로는 시스템을 완벽하게 설계했지만 시스템이 의도한대로 돌아가는지 검증할 방법이 없다면

4 min read

클린코드(Systems)

클린코드 Systems 이장에서는 높은추상화 수준에서 즉 시스템 수준에서 클린 코드를 구현하는 방법을 살펴 본다. 시스템 제작과 시스템 사용을 분리하라. 소프트웨어 시스템은 응용프로그램 객체를 제작하고 의존성을 서로 연결하는 시작단계와 시작단계 이후 이어지는 실행 단계를 분리해야 한다. 시작단계는 모든 응용 프로그램이 풀

8 min read

클린코드(클래스)

클린코드 클래스 코드의 표현력과 그 코드로 이루어진 함수에 아무리 신경을 써도 좀더 높은 차원까지 신경을 쓰지 않으면 클린코드를 얻기 어렵다. 클래스 체계 정적 공개 상수 그담으로 정적 비공개 변수 이어서 비공개 인스턴스 변수 공개 변수가 필요한 경우는 거의 없다. 캡슐화 변수와 유틸리티 함수는 가능한 공개하지 않는 편이

5 min read

클린코드(단위테스트)

클린코드 단위테스트 TDD 법칙 3가지 1. 실패하는 단위 테스트를 작성할 때까지 실제코드를 작성하지 않는다. 1. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 1. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 위 세가지 규칙을 따르면 개발과 테스트가 대략 30초 주기로

5 min read

클린코드(경계)

클린코드 경계 소프트웨어 경계를 깔끔하게 처리하는 방법 외부 코드 사용하기 Map과 같은 경계에 있는 코드를 외부로 노출하지 마라. 경계 살피고 익히기 곧바로 외부 코드를 우리코드에 넣어 작성하는 대신 외부코드의 테스트 코드를 작성하면 어떻까? 이것을 학습테스트라고 한다. 학습 테스트는 API를 사용하는 목적에 초점을 맞

2 min read

클린코드(오류처리)

클린코드 오류처리 오류 코드를 처리 하는것은 클린코드와 연관이 있다. 흩어진 오류처리 코드때문에 코드를 이해하기 어려워진다면 클린코드라고 하기 어렵다. 오류처리 보다 예외를 사용하라 얼마전까지만 해도 예외를 지원하지 않는 프로그램 언어들이 많았다. 오류 플래그를 설정하거나 호출자에서 오류코드를 넘기는것이 다였다. 오류코드

4 min read

클린코드(객체와 자료구조)

클린코드 객체와 자료구조 변수를 private으로 선언하는 이유가 있다 남들이 변수에 의존하지 않았으면 싶어서 이다. 자료 추상화 자료를 세세하게 공개하는것 보다 추상적인 개념으로 표현하는 편이 낫다. 인터페이스나 get/set함수만으로 추상화가 이뤄지지 않는다. 아무 생각 없이 get/set함수를 추가하는것이 가장 나쁘

3 min read

클린코드(형식 맟추기)

클린코드 형식 맞추기 프로그래머라면 형식을 깔끔하게 맞춰서 코드를 짜야 된다. 형식을 맞추려는 목적 코드 형식은 중요하다. 코드 형식은 의사소통의 일환이다. 적절한 행 길이를 유지하라. 일반적으로 큰파일 보다 작은 파일이 이해하기 쉽다. 신문기사 처럼 작성하라. 신문은 다양한 기사로 이뤄진다. 대다수 기사가 아주 짧다.

5 min read

클린코드(주석)

클린코드 주석 우리가 코드로 의도를 표현할때 주석은 필요 없다. 주석은 코드가 아니라 썩는다. 부정확한 주석은 독자를 현혹하고 모호하게 만든다. 주석은 나쁜코드를 보완하지 못한다. 코드에 주석을 추가하는 일반적인 이유는 코드가 나빠서이다. 이런 주석을 달아야 겠어가 아니라 코드를 수정해야 겠어가 맞다. 코드로 의도를 표현

6 min read

클린코드(함수)5

클린코드 함수 반복하지마라 코드에서 중복을 없에면 가독성이 올라간다. 객체 지향 프로그래밍은 코드를 부코 믈래스로 몰라서 중복을 없엔다. AOP, COP 모두 어떤면에서는 중복을 제거하는 전략이다. 구조적 프로그래밍 엣저 데익스트라의 구조적 프로그래밍 원칙을 따른다. 데익스트라는 모든 함수와 함수내 모든 블록에 입구와 출

2 min read

클린코드(함수)4

클린코드 함수 오류코드 보다는 예외를 사용하라 오류코드를 반환하는 방식은 명령과 조회를 분리하라라는것을 미묘하게 위배한다. 차라리 예외를 사용하는것이 깔끔하다. try catch블록은 별도로 함수로 분리하는것이 좋다. 오류처리도 한가지 작업이다. 함수는 한가지 일만해야된다. 참조

1 min read

클린코드(함수)3

클린코드 함수 명령과 조회를 분리 하라. 함수는 먼가를 수행하거나 먼가를 답하거나 둘 중 하나만 해야 된다. 위에 set이라는 메소드가 있다. 설계자의 의도는 attribute있는지를 찾고 있으면 값을 바꾸고 true 없으면 false를 리턴한다는 의도이다. 하나의 메소드에서 두가지 일을 하니 이름도 모호하고 어색하다.

2 min read

클린코드(함수)2

클린코드 함수 서술적인 이름을 사용하라 이름이 주는 가치는 아무리 강조해도 지나치지 않다. 이름이 길어도 상관없다. 함수의 인수 함수에서 이상적인 인수갯수는 0개이다. 다음은 1개 그담은 2개 3개이상은 피하는것이 좋다. 많이쓰는 단항형식 인수로 질문을 던지는경우 인수를 먼가로 변환해 결과를 반환하는경우 플래그인수 플래그

4 min read

클린코드(함수)1

클린코드 함수 작게 만들어라 다시 말해 if 문과 while 문등에 들어가는 블록은 한줄이여야 된다. 함수는 중첩구조가 생길만큼 커져서는 안된다. 한 가지만 해라 함수는 한가지만 해야 된다 함수당 추상화 수준은 하나로 내려가기 규칙 코드는 위에서 아래로 이야기처럼 읽혀야 된다. 한함수 다음에는 추상화 수준이 낮은 함수가온

3 min read

클린코드(의미 있는 이름)

클린코드 의미 있는 이름 검색하기 좋은 이름을 사용하라 위에 asis코드와 tebe코드중 어느것이 검색에 더 편하겠나? 일단 숫자형식은 검색하기 매우 까다롭다 이름을 의미 있게 지으면 검색하기 편해진다. 인코딩은 피하라 헝가리식 표기법 옛날 원도우 C API는 헝가리식 표기법을 매우 중요하게 생각했다. 실제로 컴파일하기

5 min read

클린코드

클린코드 클린코드 몇년만에 다시 클린코드를 읽으려고 한다. 또 다른 느낌을 줄수 있을것같다. 태도가 중요하다. 시간에 쫓겨서 아님 관리자 때문에 요구사항이 바껴서 이유를 되는데 문제는 프로그래머에 있다. 우리가 전문가 답지 못해서 이다. 우리는 저자다. 코드는 짜는 시간보다 읽는 시간이 훨씬 길다. 보이스카웃 규칙을 지키

3 min read