\(@^0^@)/

오늘 읽은 범위 : 8장, 경계 (p. 144 ~152) 외부에서 가져온 패키지를 사용하고 싶다면 우리 자신을 위해 우리가 사용할 코드를 테스트하는 편이 바람직하다. 문서를 읽으며 사용법을 결정하고, 우리쪽 코드를 작성해 라이브러리가 예상대로 동작하는지 확인한다. 학습 테스트 우리쪽 코드를 작성해 외부 코드를 호출하는 대신 먼저 간단한 테스트 케이스를 작성해 외부 코드를 익히는 것. 학습 테스트는 이해도를 높여주는 정확한 실험. 학습 테스트를 이용한 학습이 필요하든 그렇지 않든, 실제 코드와 동일한 방식으로 인터페이스를 사용하는 테스트 케이스가 필요하다. 이런 경계 테스트가 있다면 패키지의 새 버전으로 이전하기 쉬워진다. 그렇지 않다면 낡은 버전을 필요 이상으로 오랫동안..

오늘 읽은 범위 : 7장, 오류 처리 (p. 130 ~ 142) 오류 코드보다 예외를 사용하라 오류가 발생하면 예외를 던지는 편이 낫다. 그러면 호출자 코드가 더 깔끔해진다. 논리가 오류 처리 코드와 뒤섞이지 않으니까. Try-Catch-Finally 문부터 작성하라 미확인(unchecked) 예외를 사용하라 예외에 의미를 제공하라 예외를 던질 때는 전후 상황을 충분히 덧붙인다. 그러면 오류가 발생한 원인과 위치를 찾기가 쉬워진다. 호출자를 고려해 예외 클래스를 정의하라 정상 흐름을 정의하라 null을 반환하지 마라 null을 반환하는 코드는 일거리를 늘릴 뿐만 아니라 호출자에게 문제를 떠넘긴다. null을 전달하지 마라 깨끗한 코드는 읽기도 좋아야 하지만 안정성도 높아..

오늘 읽은 범위 : 6장, 객체와 자료 구조 (p. 118 ~128) 객체 지향 코드에서 어려운 변경은 절차적인 코드에서 쉬우며, 절차적인 코드에서 어려운 변경은 객체 지향 코드에서 쉽다. 새로운 자료 타입이 필요한 경우에는 클래스와 객체 지향 기법이 가장 적합하다. 새로운 함수가 필요한 경우에는 절차적인 코드와 자료 구조가 좀 더 적합하다. 디미터 법칙 : 휴리스틱으로, 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙. 잡종 구조는 중요한 기능을 수행하는 함수도 있고 공개 변수나 공개 조회/설정 함수도 있다. 잡종 구조는 새로운 함수는 물론이고 새로운 자료 구조도 추가하기 어렵다. 자료 전달 객체 자료 구조체의 전형적인 형태는 공개 변수만 있고 함수가 없는 ..

오늘 읽은 범위 : 5장. 형식 맞추기 (p. 96 ~116) 형식을 맞추는 목적 코드 형식은 의사소통의 일환이다, 의사소통은 전문 개발자의 일차적인 의무. 오랜 시간이 지나 원래 코드의 흔적을 더 이상 찾아보기 어려울 정도로 코드가 바뀌어도, 맨 처음 잡아놓은 구현 스타일과 가독성 수준은 유지보수 용이성과 확장성에 계속 영향을 미친다. 적절한 행 길이를 유지하라 일반적으로 큰 파일보다 작은 파일이 이해하기 쉽다. 신문 기사처럼 작성하라 : 아래로 내려갈수록 의도를 세세하게 묘사한다. 개념은 빈 행으로 분리하라 : 각 행은 수식이나 절을 나타내고, 일련의 행 묶음은 완결된 생각 하나를 표현한다. 생각 사이는 빈 행을 넣어 분리하는 것이 좋다. 빈 행은 새로운 개념을 시작..

오늘 읽은 범위 : 4장. 주석 (p. 68 ~) 우리는 코드로 의도를 표현하지 못해, 실패를 만회하기 위해 주석을 사용한다. 주석을 달 때마다 자신에게 표현력이 없다는 사실을 푸념해야 마땅하다. 코드는 변화하고 진화한다. 불행하게도 주석이 언제나 코드를 따라가지는 않는다. 아니, 따라가지 못한다. 주석이 코드에서 분리되어 점점 더 부정확한 고아로 변하는 사례가 너무도 흔하다. 부정확한 주석은 아예 없는 주석보다 훨씬 더 나쁘다. 부정확한 주석은 결코 이뤄지지 않을 기대를 심어준다. 코드만이 정확한 정보를 제공하는 유일한 출처이다. 주석은 나쁜 코드를 보완하지 못한다. 표현력이 풍부하고 깔끔하며 주석이 거의 없는 코드가, 복잡하고 어수선하며 주석이 많이 달린 코드보다 훨..

프리온보딩 코스를 하는 동안 너무 바빠서 노개북을 참여하지 못하고 한달이 넘는 시간이 지났다ㅠ 지금이라도 진짜 꾸준히 해보자! 오늘 읽은 범위 : 3장. 함수 (p. 40 ~) 어떤 프로그램이든 가장 기본적인 단위가 함수다. 작게 만들어라! if 문/ else 문/ while 문 등에 들어가는 블록은 한 줄이어야 한다. 중첩 구조가 생길만큼 함수가 커져서는 안 된다는 뜻. 그러므로 함수에서 들여쓰기 수준은 1단이나 2단을 넘어서면 안 된다. 한 가지만 해라! 함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다. 함수 당 추상화 수준은 하나로! 함수가 확실히 '한 가지' 작업만 하려면 함수 내 모든 문장의 추상화 수준이 동일해야 한다. 코드는 위에서 아래로 이야기처럼 읽..

[ 클린 코드 DAY 3 ] 오늘 읽은 범위 : 2장. 의미 있는 이름 (p. 21 ~) 의미 있는 이름을 짓기 위해서는 의도를 분명히 밝혀라 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다. 그릇된 정보를 피하라 나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용하지 말아라. ex) hp, aix, sco 의미 있게 구분하라 연속적인 숫자를 덧분인 이름(a1, a2, a3...)은 의도적인 이름과 정반대. Info나 Data는 a, an, the와 마찬가지로 의미가 불분명한 불용어. 발음하기 쉬운 이름을 사용하라 검색하기 쉬운 이름을 사용하라 인코딩을 피하라 자신의 기억력을 자랑하지 마라 전문가 프로그래머는 명료함이 최고 기발한 이름을 피하라 재미난 이름보다 명료한 이름을 선택하라 한 ..

[ 클린 코드 DAY 2 ] 오늘 읽은 범위 : 1장 깨끗한 코드 (p. 01 ~) 앞으로도 코드가 사라질 가망은 전혀 없다. 어느 수준에 이르면 코드의 도움 없이 요구사항을 상세하게 표현하기란 불가능하다. 추상화도 불가능하다. 기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업이 프로그래밍이며, 그 결과가 바로 코드이다. 나쁜 코드는 개발 속도를 크게 떨어뜨리며, 나쁜 코드가 쌓일수록 팀 생산성은 떨어진다. 기한을 맞추는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관. 깨끗한 코드를 작성하려면 '청결'이라는 힘겹게 습득한 감각을 활용해 자잘한 기법들을 적용하는 절제와 규율이 필요하다. '코드 감각'이 있으면 좋은 코드와 나쁜 코드를 구분한다. 깨끗한 ..