오르막길

우연히 노마드코더 클린코드 챌린지를 접해 약 3주정도 챌린지에 참여하게 되었다.아직 완독한건 아니지만 미루던 클린코드를 읽을 수 있었다.내용이 어렵지 않은건 아녔다. 하지만 작가도 예시코드도 나에게 이해해주려고 노력한 부분이 많았다.대부분 자바를 메인으로 한 코드 같았다. 싸피 과정에서 자바를 접하긴 했어서 어느정도 이해하는데 도움이 됐다!하지만 그런 부분이 아쉽기도 했다. 좀 더 다양한 시각에서 바라보고 싶다는 욕심도 생겼다.그런 점에서는 클린코드 챌린지를 한 게 다행이었다. 다른 사람들의 소감이나 정리를 읽어보면서 이렇게 생각할 수 있고, 현업에서는 이렇게 응용하고, 등등 알게 됐다!덕분에 나도 진행중인 프로젝트 코드를 되돌아 보았다. 중복되는 코드를 줄이고 함수를 쪼개면서 리팩토링을 해봤다.확실히 ..

10장클래스 책에서 기억하고 싶은 내용클래스의 체계변수 순서: 정적 공개 상수 - 정적 비공개 변수 - 비공개 인스턴스 변수공개 변수가 필요한 경우는 거의 없다변수 이후 공개 함수 - 비공개 함수(자신 호출하는 공개함수 직후)의 추상화 단계가 순차적으로 내려간다테스트 코드가 함수 호출이나 변수 사용이 필요한 경우 protected로 선언하거나 패키지 전체로 공개한다.하지만 비공개 상태를 유지하는 것이 최우선클래스는 작아야 한다.클래스 설명은 if, and, or, but을 사용하지 않고 25단어 내외여야 한다SRP(단일 책임 원칙): 클래스나 모듈을 변경할 이유가 하나여야 한다.돌아가는 소프트웨어에 초점을 맞추다 보니 수많은 책임을 떠안은 클래스가 생긴다.작은 클래스는 각자 맡은 책임이 하나, 변경할 이..

9장단위 테스트 책에서 기억하고 싶은 내용TDD 법칙실패하는 단위테스트를 작성할 때까지 실제 코드를 작성하지 않는다.컴파일은 실패하지 않음녀서 실행이 실패하는 정도로만 단위테스트를 작성한다.현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.깨끗한 테스트 코드테스트 코드는 실제 코드 못지않게 중요하다유연성, 유지보수성, 재사용성을 제공하는 버팀목이 바로 단위테스트이다!테스트케이스가 있다면 별다른 우려 없이 변경할 수 있게 된다가독성이 제일 중요하다최소의 표현으로 많은 것을 나타내야 한다.테스트당 assert 하나테스트를 분리하면 중복되는 코드가 많아진다.Template method 패턴을 사용하면 중복을 제거할 수 있다.테스트당 개념 하나FIRST빠르게: 테스트는 빨리 돌아야 한다.독립적으로: ..

7장오류처리  책에서 기억하고 싶은 내용오류 코드보다는 예외를 사용하자 - 호출자 코드가 더 깔끔해지고 오류처리코드와 뒤섞이지 않는다.Try-Catch-Finally 문부터 작성하자 - 프로그램 상태를 일관성있게 유지할 수 있는 방법미확인 예외를 사용하자 확인된 예외는 OCP를 위반한다메서드 모두가 선언부에 해당 예외에 대해 정의해야하고 하위를 바꾸면 상위를 다 고쳐야하고 ...최하위 함수에서 새로운 오류가 추가되면 연쇄적인 수정이 필요하게 된다예외에 의미를 제공하자호출자를 고려해 예외 클래스를 정의하자오류를 정의한다는 것은 오류를 잡아내는 방법이라는 것감싸기 기법정상 흐름을 정의하자 - 특수 사례 패턴(클래스를 만들거나 객체를 조작해 특수 사례를 캡슐화해서 처리)null을 반환하거나 전달하지 말자깨끗한..

6장객체와 자료구조 책에서 기억하고 싶은 내용자료 추상화추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 클래스다자료를 세세하게 공개하기 보다는 추상적인 개념으로 표현하는 것이 좋다.자료/객체 비대칭객체지향코드에서 어려운 변경은 절차적코드에서 쉬우며, 절차적코드에서 어려운 변경은 객체지향코드에서 쉽다디미터 법칙모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다.잡종 구조절반은 객체, 절반은 자료 구조인 잡종 구조 탄생자료 전달 객체공개 변수만 있고 함수만 없는 클래스 => 자료 구조체의 전형적 형태객체는 동작을 공개하고 자료를 숨긴다.오늘 읽은 소감여지껏 읽은 내용중에 제일 어려워서 여러번 읽었다. 사실 추상화라는게 개념적으로만 이해하고 제대로 적용해볼 기회가 없었..

4장주석 책에서 기억하고 싶은 내용주석은 나쁜 코드를 보완하지 못한다표현력이 풍부하고 깔끔하며 주석이 거의 없는 코드가 훨씬 좋다.많은 경우 주석에 달려는 설명을 함수로 표현해도 충분하다.좋은 주석계약 조건, 법적 정보, 표준 라이선스, 외부 문서 등의 표기기본적인 정보 제공 - 하지만 함수 표기가 더 낫다의도 설명의미 명료 - 인수나 반환값 자체를 명료하게 하는 것이 더 낫지만 못할 때결과 경고 - 더 나은 해결책이 있을 수 있겠지만, 주석이 합리적일 때도 있다.앞으로 할일 - 핑계가 되어서는 안된다.중요성 강조나쁜 주석이해가 안되는 주석같은 이야기를 중복하는 주석 - 코드가 더 깔끔하다오해할만한 주석의무적인 주석이력 기록용 주석, 공로나 저자 표시, 주석처리한 옛날 코드 - 소스 코드 관리 시스템을 ..

3장함수 책에서 기억하고 싶은 내용의도를 분명히 표현하는 함수를 어떻게 구현할 수 있을까?함수 크기는 작게, 더작게함수는 한가지만 잘해야 한다 (다른 의미있는 이름으로 추출할 수 있다면 여러개)내려가기 규칙 - 위에서 아래로 읽히는서술적인 이름 - 길어도 좋으니 일관성있게부수적인 효과를 일으키지 않도록명령과 조회를 분리오류코드보다는 예외를 사용하기 (그렇지만 try-catch 보다는 해당 블록을 함수로 뽑도록)오류처리도 한가지씩 => try로 시작했다면 catch/finally로 끝내도록중복을 없앤다함수를 어떻게 짜지?서투른 코드를 짠다다듬고, 함수를 만들고, 이름을 바꾸고, 중복을 제거한다.메서드를 줄이고 순서를 바꾸고 클래스를 쪼갠다.단위테스트를 항상 통과한다.진짜 목표는 시스템이라는 이야기를 풀어가..

2장의미있는 이름 책에서 기억하고 싶은 내용의도/의미/차이가 분명한, 구분/발음/검색하기 쉬운, 솔직한 이름클래스 이름 : 명사, 명사구메서드 이름 : 동사, 동사구 (접근자: get, 변경자: set, 조건자: is)오늘 읽은 소감처음 했던 유니티 클론코딩 때 controller, manager, driver를 섞어서 썼어서 좋은 습관인 줄 알았는데이 책을 읽어보니 동일 코드 기반에서는 피하라고 하니 앞으로 주의하는 게 좋을 것 같다는 생각이 처음 들었다.어디까지가 매니저고 컨트롤러인지 나도 곰곰히 생각해보니 구분하기 어려운 것 같다.궁금하거나 더 공부해야할 내용헝가리안 표기법: 변수 이름에 그 변수의 타입을 포함시키는 관습intCount (여기서 int는 정수형이라는 것을 나타냄)strName (여기..

추천사 ~ 1장깨끗한 코드 책에서 기억하고 싶은 내용추천사소프트웨어 설계에서 재작업은 가치를 가져온다.설계는 과정이지 고착된 종착점은 아니다0장 들어가면서사례 연구에서 코드를 정리하면서 내린 각 결정과 휴리스틱 사이의 관계를 이해함으로써원칙, 패턴, 실기, 휴리스틱을 자신의 지식으로 만들 수 있도록 깊게 읽어보자1장코드는 요구사항을 명시하는 언어이다.르블랑의 법칙 - 나중은 결코 오지 않는다.기한을 맞추는 유일한 방법은 코드를 최대한 깨끗하게 유지하는 습관이다.문학적 프로그래밍 - 인간이 읽기 좋은 코드중복을 피하라. 한 기능만 수행하라. 제대로 표현하라. 작게 추상화하라.깨끗한 이름/함수/클래스 만드는 법을 소개한다.이 책을 읽는다고 뛰어난 프로그래머가 된다는 보장은 없다.단지 뛰어난 프로그래머가 사용..