본문으로 건너뛰기

· 약 2분
karais89

book image

기간

3일

목적

프로그래밍의 정석

책 제목에 이끌려서 구입함.

리뷰

동서고금 프로그래밍 달인들의 지혜를 한 권에 응축하여 쉽게 풀어 쓴 책

  • 프로그래밍에 대한 101가지 원칙 소개
  • 실용적인 예제 코드는 존재 하지 않음

사실 책을 읽으면서 도움이 된다는 생각을 크게 하지 못했다.

정말 얇게 그리고 넓은 지식??

그리고 반복되는 법칙들...

101가지 법칙을 중복되는 것들을 다 제거하고 30가지 법칙 정도로 압축해서 설명하고, 실용적인 예제 코드를 넣는게 어땠을까? 라는 생각을 함.

책을 읽으면 아 이런 것들이 있구나에서 어떻게 활용할까로 넘어갈 수는 없을 것 같다.

많이 기대한거에 비해서는 좀 실망이었다.

평점 및 한줄평

넓고 얇은 지식

3/5

· 약 50분
karais89

프로그래밍의 정석 요약

책에서의 용어 설명

  • 모듈
    - 함수나 변수를 어떤 책임 단위로 묶어낸 것은 모듈로 통일한다.
    연관성이 높은 코드를 한데 묶었다는 의미에서 클래스, (함수나 변수를 모은 하나의) 파일, 컴포넌트, 부품, 라이브러리라는 용어도 있는데, 이 용어들을 모두 포함해서 모듈이라고 부른다.
  • 함수
    - 코드 일부를 떼어내어 호출할 수 있게 만든 것은 함수로 통일한다.
    루틴, 함수, 프로시저, 메시지, 메서드, 멤버 함수 등 용어는 세부적으로 나뉘는데, 이 용어들은 모두 포함해서 함수라고 한다.

책에서의 참고 서적

원리 원칙 리스트

  • 프로그래밍에 은제 탄환은 없다
    • 프로그래밍에 마법 같은 해결책은 없다.
  • 코드는 설계서다
  • 코드는 반드시 변경된다
    • 코드가 변경된다는 사실은 코드를 작성할 때 다양한 판단, 선택, 결단을 하는 데 있어서 최우선으로 고려해야 한다.
  • KISS (Keep It Simple, Stupid / Keep It Short and Simple)
    • 간단하게 해라, 어리석은 녀석아 / 간결하고 단순하게 해라
    • 코드를 작성할 때는 최우선 가치를 단순성과 간결성에 둔다.
  • DRY (Don't Repeat Yourself 중복하지 마라)
    • 똑같은 코드를 중복해서 작성해서는 안된다
  • YAGNI (You Aren't Going to Need it 그것은 분명 필요 없어진다)
    • 정말로 필요해졌을 때 필요한 코드만을 작성한다는 방침으로 프로그래밍에 임해야 한다
  • PIE (Program Intently and Expressively 의도를 표현해서 프로그래밍하라)
    • 코드를 작성할 때는 의도를 명확하게 표현해야 한다는 점이 중요하다
    • 코드는 컴파일러가 아닌 사람이 읽기 위한 것이기 때문이다
    • 코드를 작성할 때는 작성하기 쉬움 보다는 읽기 쉬움을 중시하자.
  • SLAP (Single Level of Abstraction Principle 추상화 수준의 통일)
    • 추상화 단계를 분리할 때는 기능의 복잡도에 따라 여러 계층으로 분리한다.
  • OCP (Open-Closed Principle 개방-폐쇄의 원칙)
    • 코드는 확장에 대해서 열려 있고 수정에 대해서 닫혀 있는 2가지 속성을 동시에 충족하도록 설계한다
    • 확장에 대해서 열려 있다는 말은 코드의 동작을 확장할 수 있다는 의미이다.
    • 수정에 대해서 닫혀 있다는 말은 코드의 동작을 확장하더라도 그 밖의 코드는 전혀 영향을 받지 않는다는 의미이다.
    • 코드에 인터페이스를 사용한다
    • OCP의 대표적인 패턴 (스트레티지, 옵저버, 탬플릿 메서드,데코레이터)
  • 명명이 중요하다
    • 이름을 붙이는 행위와 그런 과정을 통해 생겨난 이름 자체에 모두 중요한 가치가 있다.
    • 다음 사항에 주의한다.
      • 이름에는 더 많은 정보를 담도록 한다. 이름을 짧은 주석이라고 생각한다.
      • 이름을 오해받지 않도록 주의한다. 다른 의미와 혼동되지 않도록 몇 번이고 자문자답해야 한다.
      • 이름이 효과와 목적을 설명하도록 한다.
      • 이름은 발음 가능한 것으로 한다
      • 이름은 검색 가능하도록 붙인다.
  • 프로그래밍 이론
    • 최고의 코드란 확장 방법이 다양하게 존재하고 불필요한 요소가 존재하지 않으며 읽기 쉽고 이해하기 쉬운 코드다.
      • 의사소통
        • 코드는 남에게 보여주는 문서다. 그리고 문서의 본질은 의사소통 수단이다.
        • 프로그래밍에서 의사소통이 원할하다는 것은 코드를 읽은 사람이 코드를 이해할 수 있고, 코드를 수정할 수 있으며, 코드를 사용할 수 있다는 뜻이다.
      • 단순함
        • 코드가 단순하다는 것은 코드에서 불필요한 복잡성이 제거된 상태를 가리킨다.
      • 유연성
        • 코드에서 유연성이란 코드 변경이 용이함을 뜻한다.
  • 결과의 국소화
    • 변경이 미치는 영향이 국소에 머무르도록 코드를 구성한다.
  • 반복의 최소화
    • 반복이란 중복을 뜻한다. 즉 중복을 최대한 제거한다는 뜻이다.
  • 로직과 데이터의 일체화
    • 로직과 해당 로직이 조작하는 데이터를 서로 가까이에 배치시키는 것을 뜻한다.
    • 여기서 가까이란 같은 함수 혹은 같은 모듈이며 가까우면 가까울수록 좋은 코드다.
  • 대칭성
    • 대칭성이란 일반적으로 어떤 변환에도 변하지 않는 성질을 가리킨다.
  • 선언형의 표현
    • 선언형의 표현이란 코드의 의도를 전하고자 할 때 가능한 한 명령형보다는 선언형으로 표현하는 것을 뜻한다.
    • 명령형 프로그램은 문제의 해법, 즉 자료구조와 알고리즘을 기술한다.
    • 반면에 선언형 프로그래밍은 문제의 정의, 즉 해결해야 할 문제의 성질이나 이때 충족해야 할 제약을 기술한다.
  • 변경빈도
    • 변경 빈도란 코드를 수정하는 시점이 같다는 의미이다. 즉 변경 이유가 같다는 뜻이다.
    • 같은 시점에 변경되는 요소는 같은 곳에 두고, 다른 시점에 변경되는 요소는 다른 곳에 분리해 두도록 한다.
  • 아키텍처 기본 기법
    • 소프트웨어 아키텍처를 적절하게 구축하는 데 필요한 기초 원리
    • 추상
      • 추상이란 개념적으로 명확한 선 긋기를 수행하는 것이다.
      • 추상은 사상과 일반화라는 2가지 관점에서 정리된다.
        • 사상 : 복잡한 대상의 몇 가지 성질을 버리고 특정한 성질에 주목하는 것
        • 일반화 : 구체적인 대상으로부터 공통 성질을 추출해서 더욱 범용적인 개념으로 정싱화하는 것
    • 캡슐화
      • 관계성이 강한 데이터와 로직을 모듈이라는 껍질로 감싸는 것을 캡슐화라고 부른다.
    • 정보 은닉
      • 모듈의 구현을 해당 모듈을 사용하는 클라이언트로부터 은닉한다.
    • 패키지화
      • 모듈을 의미 있는 단위로 모은 다음 그룹화한다.
    • 관심의 분리
      • 관심이란 소프트웨어의 기능이나 목적을 뜻한다.
      • 관심을 분리한다는 것은 각각의 관심에 관련된 코드를 모아 독립된 모듈로 만들어 다른 코드로부터 분리한다는 뜻이다.
      • 대표적인 패턴 MVC
    • 충족성, 완전성, 프리미티브성(원시성, 순서성)
      • 모듈이 담당하는 추상에 대한 표현은 충분하고 완전하며 프리미티브여야 한다.
      • 충족성
        • 모듈이 표현하고자 하는 추상이 그것을 전하기에 충분한지를 뜻한다.
        • 모듈이 컬렉션을 표현하고 있을 때 remove가 제공된다고 해도 add가 제공되지 않는다면 컬렉션이라는 점을 전하기에는 불충분하다.
      • 완전성
        • 모듈이 표현하고자 하는 추상이 모든 특징을 갖추고 있는지를 뜻한다.
        • 모듈이 컬렉션을 표현하고 있을 때 요소의 개수를 구하는 size가 제공되지 않는다면 완전하다고 할 수 없다.
      • 프리미티브성
        • 모듈이 표현하고자 하는 추상이 모두 순수한지 아닌지를 의미한다.
        • 모듈이 컬렉션을 표현하고 있을 때 아이템을 1개 추가하는 add가 제공된다면 아이템을 10개 추가하는 add10은 필요하지 않다.
    • 정책과 구현의 분리
      • 모듈은 정책 혹은 구현을 다룬다. 다만 하나의 모듈에서 양쪽 모두를 다루어서는 안 된다.
    • 인터페이스와 구현의 분리
      • 모듈은 인터페이스 파트와 구현 파트 2개의 분리된 부분으로 구성한다.
        • 인터페이스 파트 : 모듈이 가진 기능을 정의하고 모듈의 사용 방법을 정하는 부분 클라이언트에서 접근할 수 있는 함수의 원형으로 구성된다.
        • 구현 파트 : 구현 파트란 모듈이 가진 기능을 실현하는 코드 부분. 모듈이 내부에서 사용하는 로직과 데이터가 포함된다. 구현 파트는 클라이언트에서 접근할 수 없다.
      • 사용자는 인터페이스만 알면 된다.
    • 참조의 단일성
      • 모듈의 요소에 관한 선언과 정의는 1회로 제한한다
      • 정의가 1회라는 말은 예를 들어 변수값을 초기화했다면 이후 값은 변경하지 않는다는 뜻이다.
      • 이렇게 하면 변수값의 변화를 추적하지 않아도 되므로 직관적인 코드가 된다.
    • 분할 정복
      • 그대로는 해결하기 어려운 커다란 문제는 여러 개의 작은 문제로 분할해서 개별적으로 해결한다
  • 아키텍처 비기능 요구사항
    • 정의: 기능 외적인 면 전반에 관한 요구사항
    • 변경 용이성
      • 변경 용이성이란 해당 소프트웨어를 얼마나 쉽게 개선할 수 있는지에 대한 능력
      • 해당 소프트웨어를 쉽게 수정할 수 있는지, 쉽게 확장할 수 있는지, 쉽게 재조직할 수 있는지, 쉽게 다른 플랫폼으로 이식할 수 있는지 등의 능력
    • 상호 운용성
      • 상호 운용성이란 소프트웨어가 다른 소프트웨어와 정보를 주고받을 수 있는 능력
    • 효율성
      • 효율성이란 소프트웨어가 실행되면서 동반되는 리소스 사용에 있어서 적절한 성능을 끌어내는 능력
      • 시간 효율성
      • 자원 효율성
    • 신뢰성
      • 신뢰성이란 소프트웨어가 예외적인 상황 혹은 예기치 못한 방법이나 부정한 방법으로 사용된 상황에서도 기능을 유지하는 능력
    • 테스트 용이성
      • 테스트 용이성이란 소프트웨어에 대해 효과적이면서 효율적으로 테스트를 수행하는 능력
    • 재사용성
      • 재사용성이란 소프트웨어를 전체가 됐든 일부가 됐든 다른 소프트웨어 개발에 재사용하는 능력을 뜻한다.
  • 7가지 설계 원리
    • 7가지 설계 원리란 결함을 만들어 내지 않기 위해 고려해야 할, 코드 구조상의 7가지 핵심 관점을 뜻한다.
    • 단순 원리
      • 단순 원리란 단순함을 중시한다는 원리다.
      • 극단적으로 말하자면 프로그래밍 생초보도 읽을 수 있을 만큼 일관되고 단순한 코드를 작성해야 한다.
    • 동형 원리
      • 동형 원리란 형태를 중시한다는 원리다.
      • 어떤 모듈에서 다루는 숫자의 단위, 공개 함수의 파라미터 수, 사용 순서 등이 통일된다는 것을 의미한다.
      • 일관성 있는 코드를 작성하자.
    • 대칭 원리
      • 대칭 원리란 형태의 대칭성을 중시한다는 원리다.
      • 어떤 플래그가 참일 때의 처리가 있다면 거짓일 때의 처리도 있어야 한다.
      • 명명의 대칭성에도 신경 쓰자. set/get, start/stop, begin/end, push/pop 등
    • 계층 원리
      • 계층 원리란 구조의 계층성을 중시한다는 원리다.
      • 리소스를 할당했다면 같은 계층에서 리소스를 해제해야 한다.
      • 배타 제어를 위해 플래그를 걸었다면 같은 계층에서 플래그를 해제해야 한다.
    • 선형 원리
      • 선형 원리란 처리의 직선적 흐름을 중시한다는 원리다.
      • 오류는 복잡한 조건문이나 반복문에서 많이 발생한다.
      • 위에서 아래를 향해 한 방향으로 내려가는 코드 흐름은 단순명쾌하고 이해하기 쉽다.
      • 분기가 적은 코드를 작성한다.
    • 명증 원리
      • 명증 원리란 로직의 명증성을 중시한다는 원리다.
      • 명증성이란 확실하게 증명한다는 의미다.
    • 안전 원리
      • 안전 원리란 안전성을 중시한다는 원리다.
      • 필연성이 없는 곳이나 모호한 곳은 안전한 쪽으로 설계하고 프로그래밍해 두는 것이다.
  • UNIX 사상
    • UNIX 사상이란 뛰어난 프로그래밍을 수행할 수 있는, 경험에 기반을 두고 있는 실천적인 노하우의 집합이다.
    • 모듈화의 원칙
      • 명료한 인터페이스로 결합한 단순한 모듈들로 소프트웨어를 조립해야 한다
      • 코드 중에 관계성이 높은 요소를 모아 모듈을 작성한다
      • 모듈이 제공하는 인터페이스는 불필요한 것은 제외하고 가장 적게 만들자
      • 모듈의 구성 요소는 관계성이 높은 것만 모아 놓도록 한다.
    • 명확성의 원칙
      • 코드는 교모하게가 아니라 명확하게 작성해야 한다
    • 구성의 원칙
      • 소프트웨어는 다른 소프트웨어와 조합할 수 있도록 만든다
    • 분리의 원칙
      • 메커니즘에서 정책을 분리한다.
      • 정책
        • 해당 소프트웨어의 전제에 종속되는 부분
        • 비즈니스 로직이나 사용자 인터페이스
      • 메커니즘
        • 해당 소프트웨어의 전제에 종속되지 않는 독립된 부분
        • 그래픽 처리의 래스터 변환 등 엔진 역할을 수행하는 부분
    • 단순성의 원칙
      • 코드가 단순해지도록 설계한다
    • 절약의 원칙
      • 큰 코드는 작성하지 않도록 한다
      • 코드의 분량이 큰 것과 코드 내부의 복잡도가 큰 양쪽을 의미한다.
    • 투명성의 원칙
      • 소프트웨어의 동작을 바깥에서 이해하기 쉽게 보이도록 설계한다
    • 안전성의 원칙
      • 일반적인 조건뿐만 아니라 예상외의 조건에서도 적절하게 동작되는 것
    • 표현성의 원칙
      • 코드에서 정보를 표현할 때는 로직이 아닌 데이터에 모아 작성하는 방식으로 한다
    • 충격 최소의 원칙
      • 인터페이스는 사용하는 사람이 상상하는 형태대로 동작하도록 설계한다
    • 침묵의 원칙
      • 소프트웨어는 표시를 최소한으로 줄이고 과묵하게 작업을 수행해야 한다
    • 복구의 원칙
      • 소프트웨어 동작 중 오류 복구에 실패했다면 처리를 계속해서는 안 된다
      • 나아가 해당 오류는 가능하면 한눈에 띄도록 발생시킨다
    • 경제성의 원칙
      • 프로그래머의 시간을 절햑해야 한다
      • 시간 낭비가 되는 리스트
      • 빈약한 하드웨어
      • 사용 소프트웨어에 대한 제한
      • 환경에 관한 규제와 제한
    • 생성의 원칙
      • 코드를 작성하기 위한 코드를 작성한다
      • 코드 생성기를 만든다
    • 최적화의 원칙
      • 빠른 코드보다 바른 코드
    • 다양성의 원칙
      • 소프트웨어에서는 선택의 다양성을 수용한다
      • 소프트웨어에 관한 모든 상황에서 유일하게 바른 방법은 존재하지 않는다
      • 더 좋은 방법을 계속 찾는다
    • 확장성의 원칙
      • 확장성을 고려한 설계를 수행한다
  • UNIX 철학
    • UNIX적인 사고방식
    • 작은 것이 아름답다
      • 작게 만들고 작게 유지하도록 한다
      • 장점
        • 이해가 쉽다
        • 보수가 쉽다
        • 머신 자원에 부담을 주지 않는다
        • 다른 소프트웨어와 조합하기 쉽다
    • 한 번에 하나의 작업
      • 하나의 소프트웨어에는 하나의 작업만 제대로 시킨다
      • 가장 좋은 소프트웨어란 생애 중에 단 하나의 작업만을 제대로 완수하는 소프트웨어다
    • 즉시 프로토타입 진행
      • 가능한 한 빨리 프로토타입을 작성한다
      • 어떤 아이디어가 성공할 것 같은지, 눈에 보이는 형태로 현실화 할 수 있는지를 확인하려면 시험 삼아 만들어보는 방법이 가장 좋다
    • 효율성보다 이식성
      • 소프트웨어 설계는 선택의 연속이다
      • 이식성과 개발 효율성이라는 이율배반적인 선택을 해야되는데 이때는 이식성을 우선시해야 한다
    • 데이터는 텍스트로
      • 데이터는 텍스트 파일로 저장한다
      • 데이터의 이식성도 중시해야 한다
      • 거의 모든 면에서 바이너리 파일보다 뛰어나다
    • 레버리지 소프트웨어
      • 레버리지(지렛대)
      • 코드를 대량으로 작성하는 가장 좋은 방법은 빌려 오는 것이다
      • 각각이 단일 기능이며 단일 가치에 집중하는 작은 소프트웨어를 작성하자
    • 셸 스크립트 활용
      • 셸 스크립트를 통해 지렛대 효과와 이식성을 높인다
      • 셸 스크립트는 이식성이 높다
    • 대화형 인터페이스 회피
      • 대화형 인터페이스 회피
      • 지나친 대화형 인터페이스를 피하도록 한다
      • 대화형 인터페이스의 문제
        • 소프트웨어별로 독자적인 대화 방법을 기억해야 한다
        • 소프트웨어끼리 대화할 수 없다
        • 대기 시간이 많아진다
        • 입력 부분에 대한 해석 코드가 많아지고 흉해진다
        • 큰 것이 아름다운 접근법으로 변질된다
    • 필터화
      • 모든 소프트웨어를 필터로 설계한다
      • 필터란 입력 스트립을 데이터로 받아들여 어떤 형태로든 가공한 다음 가공된 데이터를 출력 스트림으로 송출하는 것이다
      • 소프트웨어의 본질은 데이터를 처리하는 것이지 생성하는 것이 아니다
  • UNIX 철학과 작은 정리
    • 환경 커스터마이즈
    • 작고 가벼운 커널
    • 소문자 사용
    • 자연 보호
    • 침묵은 금
    • 병령 사고
    • 부품 협력
    • 90%의 해
    • 열등해야 뛰어나다
    • 계층 지향
  • 응집도
    • 응집도란 모듈에 포함된 기능의 순수함을 나타내는 척도로, 모듈의 강도를 측정하는 단위다
    • 응집도의 단계는 7단계다.
    • 단계가 높을수록(숫자가 클수록) 순수하고 강하며 좋은 모듈이다.
    • 1단계: 암합적 강도
      • 모듈 내 요소 간 특별한 관계가 인정되지 않는다
      • 암합이란 우연히 요소가 일치한다는 의미다
    • 2단계: 논리적 강도
      • 어떤 기능을 추상적으로 파악해서 모은 것이다
    • 3단계: 시간적 강도
      • 특정 시점에 연속해서 실행되는 여러 개의 기능을 하나의 모듈로 모은 것이다.
    • 4단계: 순서적 강도
      • 문제를 처리하기 위해 관계된 여러 개의 기능 중 몇 가지를 실행한다
    • 5단계: 연락적 강도
      • 기본적으로 순서적 강도의 특성을 갖는다
      • 순서적 강도와의 차이점은 모듈 내 기능 사이에서 데이터를 교환(연락)하거나 같은 데이터를 참조한다는 점이다.
    • 6단계: 정보적 강도
      • 특정 자료구조를 다루는 여러 개의 기능을 하나의 모듈로 모은 것이다.
    • 7단계: 기능적 강도
      • 모듈 내의 모든 명령이 하나의 역할(기능)을 실행하기 위해 서로 관련된 모듈로, 응집도가 가장 높은 모듈이다
  • 결합도
    • 결합도란 모듈끼리 갖는 관계의 밀접함을 나타내는 척도로, 어떤 결합의 굵기를 측정하는 단위다
    • 결합도의 수준은 6단계다.
    • 단계가 높을수록(숫자가 클수록) 관계가 약하고 느슨한 결합이며 좋은 모듈이라고 할 수 있다
    • 1단계: 내용 결합
      • 한 모듈과 다른 모듈이 일부를 공유하는 모듈 결합 방식
      • 다른 모듈 내의 외부에 선언되지 않은 데이터를 직접 참조하거나 명령의 일부를 공유하는 경우
    • 2단계: 공통 결합
      • 공통 영역에 정의된 데이터를 몇 개 모듈이 공동으로 사용하는 모듈 결합 방식
      • 공통 영역에 정의된 데이터란 이른바 전역 변수를 말한다
    • 3단계: 외부 결합
      • 외부에 선언된 데이터를 공유하는 모듈 결합 방식
      • 외부에 선언된 데이터란 예를 들면 public으로 선언된 변수를 말한다
    • 4단계: 제어 결합
      • 호출하는 모듈 쪽에서 호출받는 모듈의 제어를 지시하는 데이터를 파리미터로 넘겨주는 모듈 결합 방식
    • 5단계: 스탬프 결합
      • 공통 영역에 없는 자료구조를 2개의 모듈에서 교환하는 모듈 결합 방식
    • 6단계: 데이터 결합
      • 모듈 간의 인터페이스로 스칼라형 데이터 요소만을 파라미터로 교환하는 모듈 결합 방식
      • 모듈 A는 모듈 B의 입력으로 X를 넘겨주면 출력으로 Y를 받는다는 점만 알고 있다
    • 느슨한 결합을 지향하자
      • 데이터는 가능한 한 파라미터로 넘겨준다
      • 데이터는 가능한 한 전역 변수로 두지 않는다. 특정 시점에만 필요한 데이터라면 지역 변수로 두도록 한다
      • 넘겨주는 값에 따라 동작이 바뀌는 코드를 작성하지 않는다. 예를 들어 파라미터로 건네받는 플래그의 내용이 A라면 추가, D라면 삭제하는 식의 함수는 결합도가 강해진다
  • 직교성
    • 직교는 기하학에서 그래프의 좌표축과 같이 직각으로 교차하는 2개의 선분이 갖는 성질이다
    • 코드 간에는 독립성과 분리성을 갖도록 만든다
    • 2개 이상의 코드 덩어리가 있으면서 한쪽을 변경해도 다른 쪽에 영향을 주지 않는다면 해당 코드는 직교하고 있다
    • 직교하고 있는 코드는 변경에 강한 코드다
    • 장점
      • 생산성 향상
      • 위험 경감
  • 가역성
    • 가역이란 어떤 변화가 발생해도 특정 조건을 가하면 원래 상태로 돌아오는 성질
  • 코드의 구린내
    • 코드의 구린내란 코드 중에서 이해하기 어렵고, 수정하기 어렵고, 확장하기 어렵다고 느껴지는 부분
    • 프로그래머는 이런 구린내를 식별해 내서 적절한 코드로 개선해야 한다
    • 코드의 구린내 징후
      • 자주 보인다
        • 똑같은 코드가 여기저기 흩어져 있는 상태
      • 너무 길다
        • 함수가 너무 길어 스크롤을 몇 번이나 내려도 끝나지 않는 상태
      • 너무 크다
        • 모듈이 너무 컷거 관리 불능인 상태
        • 모듈이 너무 크다는 말은 해당 모듈이 담당하는 역할이 너무 크다는 뜻
      • 너무 많다
        • 모듈이 너무 많아서 관리 불능인 상태
        • 모듈이 크다는 이유로 지나치게 분해해서는 안 된다
      • 이름이 맞지 않는다
        • 이름과 실제 코드가 맞지 않는 상태
        • 이름은 중요하다
  • 기술적 부채
    • 문제 있는 코드는 '빚'이다
    • 프로그래밍의 2가지 길: 시간이 좀 걸리더라도 깨끗한 코드 or 신속하지만 지저분한 코드
    • 신속하고 지저분한 코드를 선택한다면 소프트웨어는 이른바 부채를 떠안는 셈이되는데 이를 기술적 부채라고 부른다
    • 기술적 부채는 코드에서 수정하기 어렵고 이해하기 어려운, 문제 있는 지저분한 코드 부분을 뜻한다
  • 프로그래머의 3대 미덕
    • 태만
      • 전체의 노력을 줄이기 위해 수고를 아끼지 않는 기질
      • 나중에 모두가 편해지도록 지금 유용한 코드를 작성한다
      • 반복 업무를 시스템화하자
      • 수작업에 관해서는 코드를 작성하고 툴을 만들어서 자동화 한다
    • 성급
      • 컴퓨터가 놀고 있는 것에 분노를 느끼는 기질
      • 일어날 수 있는 문제를 상정해서 업무를 하자
    • 오만
      • 천벌을 받을 정도로 넘치는 자존심을 지닌 기질
      • 높은 자존심을 갖고 남에게 내놓아도 부끄럽지 않은 코드를 작성한다
      • 남에게 부끄럽지 않게끔 작업하고 보수하자
  • 보이 스카우트 규칙
    • 코드는 자기가 왔을 때보다 깨끗이 하고 나서 자리를 떠나야 한다
    • 처음 코드를 작성한 사람이 누구인지와는 상관없이, 조금씩이라도 코드를 개선하려는 노력을 계속해야 한다
  • 성능 튜닝에 관한 금언
    • 프로그래밍에서는 빠른 코드보다 우선 바르고 읽기 쉬운 것에 주안점을 둔 좋은 코드를 작성하는 데 노력해야 한다
  • 비자아적 프로그래밍
    • 프로그래밍할 때는 자아를 떨쳐 버려야 한다
    • 자만과 자존심을 버리고 동료에게 협력을 구하도록 한다
    • 자신이 작성한 코드를 적극적으로 등료에게 보여주면서 개선점을 지적해 달라고 한다
    • 비자아적 프로그래밍의 십계
      • 자기 자신도 실수를 저지른다는 점을 이해하고 받아들인다
      • 작성한 코드는 자기 자신이 아니다
      • 아무리 끝까지 간 것 같아도 위에는 그 이상이 있다
      • 상담 없이 코드를 재작성하지 않는다
      • 자기보다 기술이 떨어지는 사람에게도 존경과 경의, 인내를 갖고 대한다
      • 세상에서 유일하게 변하지 않는 것은 변한다는 사실뿐이다
      • 진정한 권위는 지위가 아니라 지식에서 생겨난다
      • 신념을 위해 싸운다. 다만 패배는 깨끗이 수용한다
      • 방에 틀어박혀 있어서는 안 된다
      • 사람에게는 관대하고 코드에는 엄격하게, 사람이 아닌 코드를 비평한다
  • 한 걸음씩 조금씩
    • 프로그래밍은 한 번에 작은 하나만을 수행한다
    • 하나씩 조금씩 단차가 작은 계단을 올라가듯이 작업한다
    • 절대 한 번에 여러 가지 작업을 상대하지 말고 하나씩 처리한다
  • TMTOWTDI (There's more than one way to do it 방법은 하나가 아니다)
    • 다른 사람이 사용할 툴을 설계할 때는 달성하고자 하는 것의 수단을 여러 개 준비한다
    • 여기서 말하는 툴이란 프로그래밍 언어나 DSL, API를 가리킨다
  • 예광탄
    • 예광탄이란 빛을 발산함으로써 탄도의 궤적을 알 수 있게끔 만들어진 탄환을 말한다
    • 예광탄은 즉시 피드백을 가져다 준다
    • 프로그래밍에서의 예광탄이란 우선적으로 검증하고 싶은 부분을 선행적으로 프로그래밍하는 것이다
  • 계약에 의한 설계
    • 각각의 함수는 뭔가의 작업을 수행하는 것이다
  • 방어적 프로그래밍
    • 이렇게 될 것이다라고 결정짓지 말고 프로그래밍한다
    • 자동차의 방어 운전과 같은 사고방식이다
    • 외부 소스에서의 데이터 입력값을 확인한다
    • 함수의 입력 파라미터값을 확인한다
  • 개밥 먹기
    • 자기가 개발한 소프트웨어는 본인이 직접 사용해 봐야 한다
  • 고무 오리
    • 고무 오리는 일종의 디버깅 기법이다
    • 프로그래밍 중에 발생한 문제, 혹은 문제를 품고 있는 코드를 누군가에게 설명한다
    • 그러다 보면 문제의 원인을 스스로 깨닫고 자체 해결할 수 있을 때가 있다
  • 컨텍스트
    • 컨텍스트란 주위의 상황이나 배경을 뜻하며, 문맥이라고도 한다
    • 코드의 읽고 쓰기에 사용
    • 생각의 도구로 사용
  • 브룩스의 법칙
    • 일정이 늦어지고 있어 후반에 사람을 추가하면 오히려 지연이 한층 더 초래된다
  • 콘웨이의 법칙
    • 소프트웨어의 구조, 즉 아키텍처는 그것을 만든 조직을 반영한다
  • 깨진 유리창 법칙
    • 나쁜 설계, 잘못된 의사 결정, 나쁜 코드를 방치하면 그것이 아무리 작은 것이라도 소프트웨어 전체를 매우 단기간에 부패시킨다
  • 엔트로피 증가의 법칙
    • 엔트로피란 물리학 용어로 무질서한 정도를 나타낸다
    • 코드는 그대로 두면 한계를 뛰어넘을 만큼 무질서함이 증대된다
    • 코드의 부패 징후
      • 경직됨
        • 변경하기 어렵다
      • 깨지기 쉬움
        • 단 하나의 변경으로 인해 다른 많은 부분이 망가져 버리는 정도
      • 이식성 없음
        • 다른 환경으로 이식하기 어렵다
      • 다루기 어려움
        • 코드를 다루기 어려움과 개발 환경을 다루기 어려움이 있다
      • 복잡함
        • 불필요한 요소가 많음을 뜻한다
      • 반복
        • 똑같은 코드가 어러 번 반복해서 나타난다는 뜻이다
      • 불투명함
        • 코드를 이해하기 어렵다
  • 80:10:10의 법칙
    • 소프트웨어를 개발하면 사용자가 요구하는 것의 80%는 놀랄 만큼 단기간에 실현할 수 있다
    • 그러나 나머지 20% 중 10%는 실현은 가능하지만 상당한 노력이 필요하다
    • 더욱이 나머지 10%는 완전히 실현이 불가능하다
  • 조슈아 나무의 법칙
    • 사람은 이름을 아는 순간 그것이 보인다. 반대로 이름이 없으면(모르면) 그것은 보이지 않는다
  • 세컨드 시스템 증후군
    • 첫번째 버전을 배포한 프로그래머가 설계한 두번째 버전 소프트웨어는 해당 프로그래머가 설게하는 가장 위험한 버전이다
    • 두 번째 버전에는 기능을 너무 잔뜩 집어넣어 품질이 나쁘고, 기능의 사용성도 떨어지는 경향이 있다
  • 수레바퀴의 재발명
    • 이미 세상에 존재하는 수레바퀴를 일부러 수고를 들여 다시 한번 발명하는 것과 같은 쓸데없는 작업
    • 수레바퀴의 재발명을 피하고 본래 해야 할 작업에 주력하자
    • 코드를 작성하기 전에 똑같은 기능이 표준 라이브러리에 없는지, 오픈 소스 라이브러리에 없는지, 표준 프로토콜이 없는지를 반드시 확인하도록 한다
    • 수레바퀴를 재발명해야 될때
      • 비즈니스 목적
      • 학습 목적
  • 야크의 털깍기
    • 어떤 문제를 해결하려고 봤더니 다른 문제가 계속 나와 좀처럼 몸통, 즉 기본 문제(의 해결)에 도달하지 못하는 것이다
    • 야크의 털깍기는 기본적으로 피해 가야 한다

· 약 4분
karais89

리디북스 책 목록

  • 파이썬 웹 프로그래밍
  • 실전 개발을 위한 파이썬 디자인 패턴
  • 유지보수 가능한 코딩의 기술 자바편
  • 포프TV 1권
  • 파이썬 웹 프로그래밍 (실전편)
  • 개발자를 위한 파이썬1
  • 자바로 배우는 리팩토링 입문
  • 유니티 5 3D 게임 제작 입문
  • 유니티로 배우는 게임 수학
  • 유니티 게임 제작 입문
  • 애자일 & 스크럼 프로젝트 관리
  • 해커와 화가
  • 누워서 읽는 알고리즘
  • 소프트웨어 악취를 제거하는 리팩토링
  • 코딩의 기술
  • [리얼타임] 레거시 코드를 클린 코드로 누구나 쉽게, 리팩토링
  • 파이썬으로 웹 크롤러 만들기
  • 초보자를 위한 파이썬 200제
  • 소프트 스킬
  • 훌륭한 프로그래머 되는 법
  • 소프트웨어 장인
  • 뇌를 자극하는 파이썬 3
  • 게임 프로그래밍 패턴
  • The Nature of Software Development
  • 유니티 2D 게임 공작소
  • 만들면서 배우는 HTML5+CSS3+jQuery
  • 인사이드 자바스크립트
  • 게임개발자가 대우받는 북미취업가이드북 2판
  • [리얼타임] 유니티 개발자를 위한 C#으로 온라인 게임 서버 만들기
  • Blog2Book, 아는 만큼 보이는 데이터베이스 설계와 구축
  • 코딩 인터뷰 퀘스쳔
  • 행복한 프로그래밍
  • 피, 땀, 픽셀
  • Head First C#

실제 소유 책 목록

  • 헤드 퍼스트 OOAD
  • 헤드 퍼스트 디자인 패턴
  • Effective C#2
  • 시작하세요 C# 7.1 프로그래밍
  • 파이썬 프로그래밍으로 지루한 작업 자동화하기
  • 파이썬으로 데이터 주무르기3
  • 클린소프트웨어
  • 클린 코드
  • 테스트 주도 개발
  • 코드
  • 실용주의 프로그래머
  • 생각하는 프로그래머
  • 실용주의 사고와 학습
  • UML 실전에서는 이것만 쓴다
  • 고급 객체지향 프로그래밍
  • 코드 컴플리트 2판
  • UML DISTILED
  • 3D 게임 프로그래밍 (해골책)
  • API 정복
  • 윈도우 프로그래밍
  • 2D/3D 멀티플랫폼 게임을 위한 유니티 2018

  1. 파이썬 잡학다식 느낌.. 다양한 분야를 소개하는 건 좋았는데.. 난이도 조절을 실패한 느낌(어려운 쪽으로).. 물론 개발자를 위한 파이썬의 책 제목과 같이 관련 기술들을 전부 알고 있다는 가정하에.. 파이썬에 다양한 분야를 맛 볼 수 있다는 점이 좋을 수 있을 수도 있지만... 난 별로 였다.
  2. item 37. 까지 읽다가 포기.. C# 기본서를 보고 다시 봐야 될듯..
  3. 1장을 보고 책 자체는 괜찮은 듯 하나 나에게는 필요하지 않을 것으로 보아 보지 않을 예정 입니다. 책 리뷰도 하지 않을 예정

· 약 1분
karais89

Udemy 강의 목록

한글

  • Retr0의 유니티 (Unity C#) 게임 프로그래밍 에센스
  • 누구나 쉽게 배우는 Git(깃) & Github(깃허브)
  • [유니티] 2D RPG 쯔꾸르풍 만들기
  • [유니티 3D] 쉽고 재밌게! 생존 게임 제작하기 - Advanced

영어

  • build-your-own-first-person-shooter-survial-game-in-unity
  • Learn to Code by Making Games - Complete C# Unity
  • Learn to Code Trading Card Game Battle System With Unity
  • Learn Unity 3D by coding a complete game start to finish
  • Make a Match - Three Puzzle Game in Unity
  • Master Unity By Building 6 Fully Featured Games From Unity
  • Unity Game Development Academy : Make 2D & 3D
  • Unity : From Master To Pro By Building 6 Games

· 약 3분
karais89

book image

기간

5일

목적

영어 공부에 대한 팁을 얻기 위해? 항상 계획만 하고 실천을 하지 못해서 도움을 받기 위해? 이북으로 구입 했다.

리뷰

기초 회화책 한 권을 통째로 외우면 말문이 트입니다.

초반부에는 영어 공부의 필요성에 대해 얘기한다. 그리고 가장 먼저 해야 되는 것은 일단 영어책 한 권을 외워 보는 것. 그리고 영어책 한 권을 외운 후에 해야 되는 것들에 대해 설명한다. 결국 책을 읽다 보면, 누구나 아는 얘기에 대해 얘기하고, 자기 계발서의 한계에 대해 다시 한번 생각을 하게 된 책.. 조금은 실망했다.

  • 기초 회화책 한 권을 통째로 외우면 말문이 트입니다.
  • 영어회화 100일의 기적을 추천합니다.
  • 암송 공부를 할 땐, 책을 보지 말고 눈을 감고 문장을 외우세요. 그게 진짜 공부입니다.
  • 영어를 공부한다면 영영사전을 권합니다.
  • 단권화 작업이란 한 권의 책을 골라 그 책만 반복해서 읽으며 공부한다는 뜻입니다.

결국 저자의 결론은 기초 영어 회화 책을 보고, 매일 하루에 10문장씩 외우자가 결론이다. 암송 공부를 할 땐 책을 보지 말고 눈을 감고 문장을 외우고, 개별 문장을 외우기보다는 전체 상황을 이해 하면 암기가 쉽다는 말도 한다. 매일매일 하다 보면 결국엔 영어 실력이 늘게 된다는 말을 전하고 싶은 것 같다. 무조건 적인 비판은 하고 싶지 않다. 영어 공부에 자극을 주는 책 정도라고 생각하면 읽을만한 것 같다. 이 방법에 대해 비판을 하려면, 정말로 영어책 한 권을 외외 본 후 가 아닌가 싶기도 하다.

평점 및 한줄평

영어 기초 회화책을 한권 외워라!

3.5/5

· 약 2분
karais89

book image

기간

7일

목적

리디북스에서 무료로 15일 대여를 해서 대여한 책이다.

리뷰

독자를 속이는 맥거핀 기법의 진수를 보여주다!

리디북스에서 무료로 대여한 책이라 읽었다.

클라우디아는 간절히 바라던 아기를 임신하고, 사랑하는 남편과 같이 살고있다.

아기를 낳기전 가정부 조를 고용했다. 하지만 클라우디아는 조를 수상한 행동으로 인해 미덥지 않게 생각한다.

한편 그들이 사는 지역에서 임신한 미혼 여성을 대상으로 한 무자비한 연쇄 살인 사건이 발생한다.

과연 범인을 잡을 수 있을까? 클라우디아의 아기는 무사할까?

사실 읽다보면 어느정도 내용이 어떻게 흘려갈지 보인다...

개인 적으로는 그렇게 까지 극찬받을 정도로 재미있게 읽지는 않았던 것 같다.

평점 및 한줄평

그냥 저냥..

3/5

· 약 2분
karais89

book image

모든 이가 부러워하는 부유한 커플,
그리고 그들의 화려한 세계를 차지하기 위해
짙은 그늘 속으로 걸어 들어가는 한 여자…

목적

리디북스 무료 ebook 이벤트로 읽은 책

무료 대여 서비스는 참 좋은 것 같다.

리뷰

처음에는 출퇴근에만 읽을 목적으로 읽어 나갔다.

읽으면서 내용 자체가 너무 재미있고, 중반부를 넘어가면서 상상하지 못했던 또 다른 국면으로 치닫는 게 재미있어

주말을 이용해 단숨에 읽었다. 예전에 읽었던 비하인드도어가 생각나기도 했다.

결말 자체도 책 표지 그대로 만족스러운 결말이었다. (너무 뻔한 결말일 수도 있겠지만..)

책 자체는 크게 3부로 구성되어 있다.

1부는 앰버의 이야기

2부는 대프니의 이야기

3부는 두여자의 이야기

1부에서는 앰버가 잭슨 패리시의 부인이 되기 위해 (대프니의 남편) 행하는 계획들에 대해 다루고 있고,

2부에서는 대프니의 관점에서 이야기가 전개되고 있다.

2부부터 진정한 이야기의 시작이라고 볼 수 있다.

과연 앰버는 목적을 달성할 수 있을까?

평점 및 한줄평

스릴러 장르를 좋아하는 분이라면 재미있게 읽을 수 있는 책

4/5

· 약 8분
karais89

방송대 3학년 편입 후 1년

2번째 학기를 마친 후...

2학기 편입으로 시작하여 이제 2번째 학기를 끝마쳤다.

앞으로 남은 1년 동안 잘 할수 있을지 모르겠다.

첫학기에 성적 자체는 만족스럽지 않은 성적으로 끝마쳤다.


두번째 학기에 선택한 과목

  • 이산수학 (2학년)
  • Visual C++ 프로그래밍 (2학년)
  • Java 프로그래밍 (3학년)
  • 데이터베이스 (3학년)
  • 컴퓨터그래픽스 (4학년)
  • 소프트웨어공학 (4학년)

각 과목의 선택 이유 및 느낀점

이산수학

게임 프로그래머로서 수학이 부족하다고 생각하여, 수강하게 되었다.

교수님 자체가 재미있으시고, 강의 자체도 재미있게 잘 가르치셨던 것 같다.

성적 자체도 생각보다는 좋게 나와서 좋았던 과목.

다음 학기의 선형대수도 들을 예정이다.

문제 자체는 방송대 성격상 시험 시간의 제약이 있기 때문에 문제 풀이에 대해 많은 시간이 주어지지 않아서 그런지 몰라도, 개념만 어느정도 알면 풀 수 있는 수준의 문제 였다.


Visual C++ 프로그래밍

학부 과정에서 이미 들었던 과목이고, C++이라 학점용으로 들었던 것 같다.

API및 MFC에 대해 잘 알지 못했기 때문에 해당 내용에 대해 알고 싶어서 선택한 부분도 있다.

방송대의 거의 모든 책들이 두껍지 않아서, 각 항목에 대해서는 정말 가볍게 훑어 보는 식으로 구성되어 있다.

유일하게 강의 자체를 보다 안봤던것 같다.

강의의 질 자체는 나쁘지 않았던것 같은데..

거의 실습 위주라.. 책을 보면서 실습을 했던것 같다.

나중에 MFC와 API에 대해서는 자세히 다뤄야 될 것 같다.

문제 자체는 거의 기출문제와 유사한 문제들 위주로 나온것 같다.


Java 프로그래밍

학부때 부터 이미 알고 있던 프로그래밍 언어이고, 솔직히 이건 성적용으로 넣었다.

그리고 다음 학기 때 JSP를 수강하기 위해 넣어둔 과목.

이 글을 쓰면서 순간 흠칫했던게 다음 JSP 과목도 이 교수님의 강의인지 확인 하였다.

사실 이 교수님에 대해 그렇게 좋게 생각은 들지 않는다.

솔직한 평의로는 거의 PPT를 읽는 수준의 강의 였다고 본다. 강의 자체도 재미가 없었다.

그리고 가장 큰 문제는 시험 자체에 있는 것 같다.

시험 자체의 문제가 몇몇은 너무 말장난 같은 식의 문제가 있어서 솔직히 납득이 되지 않았던 것들이 있다.

문제 자체를 보면 개념을 알고 있어도 순간적으로 헷갈리거나 하면 틀릴만한 식으로 문제를 내는게 꽤 많았던 것 같다. (다른 과목에서는 개념만 정확히 알면, 최소 헷갈리게 문제를 내는

경우는 거의 없었던 것 같다) 이게 시험 변별력을 위해서라면, 조금 다른 식으로 접근해야 되지 않나? 란 생각이 들었다..

뭐 유일한 장점이라면 시험볼때 힌트를 제공한다는 점??

솔직히 말해서 별로 추천하고 싶지는 않는 과목인것 같다..


데이터베이스

클라이언트 프로그래머라 DB 관련 과목에 대해 관심이 있어서 듣게 된 과목

DB에 관심이 있거나, 이미 알고 있는 분들이라면 학점용으로라도 아님 다시 돌아보는 용도로라도 꼭 듣길 바란다. 교수님 자체가 열정적이시고, 딱 이해 되게 잘 가르치시는 것 같다.

시험 문제에 대한 난이도도 높지 않아 부담되지 않았던 것 같다.

제일 만족했던 과목 이었던 것 같다.

다음 학기 데이터베이스설계및구현 과목을 듣기 위해 들었던 선수 과목 이다.


컴퓨터그래픽스

게임 프로그래머라면 컴퓨터 그래픽스에 대해 알아야 된다라는 말은 어디서든 들었을 것 같다.

사실 그래픽스에 대한 개념이 없어서, 기대하면서 들었던 과목이다.

그래픽스 API는 dx와 openGL이 있는데, 이 책에서는 OpenGL로 강의를 가르킨다.

강의 자체에 대해서는 대체적으로 만족하면서 들었고, 책만 봤을때는 몰랐던 내용들은 강의를 보면 거의 파악이 될정도로 괜찮았던 수준이었다.

문제 자체도 기출문제 위주로 내주셨던것 같아서 생각보다는 학점이 좋게 나왔다.

나중에 용책이나, 해골책을 보고 더 깊게 그래픽스에 대한 공부를 해야 될것 같다.


소프트웨어공학

과목 자체가 이론적인 내용이라 그런지 상당히 지루하다.

그리고 강의 자체도 그냥 정말 지루하고, 머리속에 들어오는게 없었다.

소프트웨어 설계나 리팩토링 쪽에 관심도 많고, 재미있을것 같아서 수강했던 과목인데.

솔직히 많이 실망했던 것 같다.


느낀점

방송대 강의를 느끼면서 드는 생각은 과목 별로 사실 전부 학부 과정이라 그런지.. 아니면 사이버 대학이라 그런지 깊이 있게 들어가는 과목이 별로 없는것 같다. 결국은 내가 관심 가지는 과목은 따로 다시 한번 공부해야 될거 같다는 생각을 했다. 물론 방송대 과목이 이런 발판 역활을 해주는것으로서도 충분히 가치 있는것 같기도 하다.

· 약 2분
karais89

book image

기간

2일

목적

리디북스에서 무료로 60일 대여를 해서 대여한 책이다.

리뷰

일단 한국 소설이고, 표지에서 보듯이 2015 대한미국 전자 출판대상 대상 수상작이다.

소재 자체가 신선한 소재라서, 기대를 많이 하고 봤다. 주인공 자체는 교통 사고로 부모님을 모두 잃고, 다른 사람의 생명의 남은 날짜를 볼 수 있는 능력을 얻었다. 이 빽넘버에 대한 얘기이다.

자기 자신의 생명은 볼 수 없다. (등 뒤에 눈이 달리지 않았으므로)

사신과의 만남도 있고.. 여러가지 위험도 감지할 수 있다. 갑자기 빽넘버가 1로 변하는 사람들을 보고, 위험을 판단한다..

마지막에 약간의 반전도 있었다.

조금은 책 자체의 분량이 짧지 않나라는 생각이 들긴 했다.

어쨋든 가볍게 읽을만했다.

평점 및 한줄평

킬림 타임용으로 볼만 했다.

4/5