바위타는 두루미

코드의 표현력과 그 코드로 이루어진 함수에 아무리 신경을 쓰더라도 더 높은 차원의 단계까지 신경쓰지 않으면 깨끗한 코드를 얻기 어렵다. 이 장에서는 깨끗한 클래스에 대해 다룬다. - 클래스 체계 - 자바의 경우 정적공개상수 -> 정적 비공개상수 ->비공개 인스턴스변수 ( 공개 변수가 필요한 경우는 거의 없음 ) 순으로 나오고 - 변수 다음에는 공개함수, 비공개함수는 자신을 호출하는 공개 함수 직후에 넣는다. - 캡슐화 - 변수와 유틸함수는 공개하지 않는 편이 낫지만, protected로 선언해 테스트 코드에 접근을 허용하기도함. - 클래스는 작아야 한다. - 얼마나 작아야하는가 ? -> 클래스가 맡은 책임을 센다. - 클래스 이름은 그 클래스의 책임을 기술해야하고 간결해야한다 ( 책임의 크기가 작도록 )..

TDD 법칙 세가지 1. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위테스트를 작성한다. 3. 현재 실패하는 테스트를 통과할 정도만 실제 코드를 작성한다. => 이렇게 일하면 테스트케이스가 너무많아지고, 많은 테스트케이스는 관리 문제를 유발하기도 한다. 깨끗한 테스트 코드 유지하기. - 지저분한 테스트 코드일수록 실제 코드가 변경할때 함께 변화하기 어렵다. 테스트는 유연성, 유지보수성, 재사용성을 제공한다. - 이를위해서는 단위테스트가 필요하다. 단위테스트가 없다면 수정이 두렵다. 깨끗한 테스트코드란 ? - "가독성" - 테스트는 명확히 세부분으로 나뉨 : 테스트자료를 만들기 -> 테스트자료 조작하기 -> 결과가 올바른지..

오류처리 때문에 프로그램의 논리를 이해하기 어렵다면 그것은 깨끗한 코드가 아니다. -오류코드보다 예외를 사용하라. - Try-Catch-Finally 문부터 작성하라 강제로 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통과하게 코드를 작성하는 방법을 권장한다. - 미확인 예외를 사용하라. 확인된 예외는 OCP를 위반한다. 하위단계에서 코드를 변경하면 상위단계 메서드 선언부를 전부 고쳐야한다. 아주 중요한 라이브러리를 작성한다면 확인된 예외를 이용해 모든 예외를 잡아야하지만, 일반적인 어플리케이션은 의존성이라는 비용이 매우크다. - 예외의 의미를 제공하라. -예외를 던질때에는 정보를 담아 예외와 함께 던지자. - 실패한 연산 이름과 실패 유형도 언급한다. - logging을 사용한다면 catch블록..

단순히 get, set함수를 만들어 변수를 다룬다고 class가 아니다. 그보다는 추상 인터페이스를 이용해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 class이다. 객체 vs 자료구조 - 자료구조를 사용코드 : 자료구조 변경없이 새 함수를 추가하기 쉽다. | 함수 변경없이 새로운 자료구조 추가하기 어렵다. - 객체지향 코드 : 함수 변경없이 class 추가하기 쉽다. | class변경없이 새로운 함수 추가하기 어렵다. - 분별있는 프로그래머는 모든 것이 객체라는 생각이 미신임을 잘 안다. 때로는 단순한 자료구조와 절차적인 코드가 적합한 상황이 있다. 디미터 법칙 -> 모듈은 자신이 조작하는 객체의 속사정을 몰라야한다. 클레스 C의 메서드 f는 다음과 같은 객체의 메서드만 호..

형식을 맞추는 일은 매우 중요하다 기능은 바뀌더라도, 맨 처음 잡아둔 구현 스타일과 가독성수준은 유지보수 용이성과 확장성에 계속 영향을 미친다. 좋은 형식은 무엇일까? 1. 적절한 행길이를 유지하라 - 큰 파일보다 작은 파일이 이해하기 쉽다. - 신문기사처럼 작성하라 : 상단은 고차원 , 하단으로 갈수록 저차원 (세부구현) - 개념은 빈 행으로 분리하라 - 수직거리 : 밀접한개념은 세로로 가까이 두어야한다. - 변수는 사용하는 위치에 최대한 가까이 선언한다. - 인스턴스 변수는 모아라 : 자바는 상단에, c++는 하단에 선언하는 편 - 종속함수 : 함수가 다른함수를 호출한다면 두 함수는 세로로 가까이, 가능하다면 호출하는 함수가 먼저! - 개념적 유사성이 높으면 가까이 2. 가로형식 맞추기 - 짧은 행이..

주석은 코드로 의도를 표현하지 못해서 사용하므로 실패이다. 주석은 거짓말을 하는 경우가 많다. 진실은 오직 code! 그럼 좋은 주석은? 1. 법적인 주석 : file 첫머리에 저작권정보와 소유권정보 ->Good 2. 의미를 명로하게 밝히는 주석 : 인수나 반환값이 표준 라이브러리나 변경하지 못하는 코드에 속한다면 의미를 명료하게 밝히는 주석이 유용하다. 3. 경고하는 주석 4. todo주석 느낀점 - 이 책에서 말하는 나쁜 주석들은 이제는 형상관리툴로 커버가 가능한 부분들이고, 책 앞부분에 언급된 대로 함수를 쪼개고 이름을 잘 짓는 것 만으로도 없앨수 있는 부분들이 매우 큰 것 같다. 가능하다면 최대한 작성하지 않도록 하는것, 이전에 주석들은 이제는 다른 적절한 방법들로 개선하는 부분이 필요해 보인다.

좋은 함수를 만드는 법 1. 작게만들기 - if/else문 , while문 등에 들어가는 블록은 한줄이여야한다. - 장점 : 바깥을 감싸는 함수가 작아지고, 함수명이 적절하다면 코드 이해도 쉽다. 2. 한가지만 하기 - 함수가 한가지만 하는지 확인하는 방법 - 추상화 수준이 1개인지 - 의미있는 이름으로 다른함수를 추출할 수 있다면 그것은 여러작업을 하고있다! - 섹션으로 나뉘어지는지 확인 3. 함수의 추상화 수준은 하나로! - 이유 : 근본개념인지 세부사항인지 알기 어렵고, 사람들이 세부사항을 점점 더 추가한다. - 코드는 위에서 아래로 읽히도록, 아래로 갈수록 추상화 수준을 낮추기 4. Switch문 - switch문은 길고, 본질적으로 여러작업을함 - 꼭 써야한다면 추상 factory에 꽁꽁숨겨서 ..

기억하고 싶은 내용 Naming 이름지을때 생각해보아야 할 규칙 - 의도를 분명히 하기. thelist ( X) , gameBoard (O) -그릇된 정보를 피하기 - 개발시 이용하는 용어 주의하기 List가 아닌데 List사용 X - 흡사한 이름 사용하지 않기 - 한눈에 보기 어려운 이름 - 의미있게 구분하기 : 컴파일러만 통과하는 코드는 x - 연속적인 숫자를 추가하는경우 : 의미없는 이름 - 두 변수가 구분이 안되는 경우 ~Data, ~Info => 구분하기 어렵다 - 발음하기 쉬운 이름 사용하기 - 검색하기 쉬운 이름 - 이름길이는 범위크기에 비례해야한다. -인코딩을 피하라 - 타입표기할 필요없다. - 접두어 붙일 필요없다. -> 클래스, 함수는 작아져야하고, 멤버변수를 다른 색상으로 표시하는 I..

오늘 리뷰해볼 논문은 2012년에 Alex Krizhevsky 님께서 작성한 "ImageNet Classification with Deep ConvolutionalNeural Networks " 입니다. 저자의 이름을 따서 AlexNet으로 더 유명한 CNN 네트워크 구조를 소개하고 있습니다. [Abstract] - ILSVRC 대회는 약 1.2million 고해상도 이미지를 1000개의 class로 분류해 내는 대회인데, 2010년 대회기준 test set에서 top-1, top-5 error rate이 각각 37.5%, 17.0%로 앞선 SOTA보다 확실히 더 나은 성적을 갖는 neural network를 구성함. - 그 neural network는 60 milion 파라미터랑 650,000 뉴런을 ..

자, 그럼 이제는 어떻게 실제 Loss를 줄이는 W를 찾을 수 있는걸까요? 이 질문을 우리는 "최적화 (Optimization) " 라고 합니다. 최적화를 한다는 것은 우리가 다양한 산과 계곡이 있는 엄청 큰 골짜기를 걷고 있는 것입니다.내가 위치하고 있는 곳의 높이가 Loss가 되는것이고 우리의 임무는 이 골짜기의 밑바닥을 찾는 것입니다. 하지만 이문제는 매우 어렵습니다. 그래서 우리는 다양한 iterative한 방법을 사용합니다. 가장 먼저 생각할 수 있는것은 "Random search(임의 탐색)" 입니다. *매우 구린방법입니다. CIFAR-10에서는 클래스가 10개니까 임의확률은 10%가 되고, 무작위 시행을 거치게 되면 약 15%의 정확도를 보이는군요.최신 알고리즘의 성능 SOTA가 95%인것을..