프로그래밍의 정석

Gisele·2021년 3월 16일

책

전제 : 프로그래밍 불변의 사실

프로그래밍에 은제 탄환은 없다 : 소프트웨어는 본질적으로 난해하다
코드는 설계서다
코드는 반드시 변경된다 : 변경에 강한 코드를 작성

원칙 : 프로그래밍의 가이드라인

KISS(Keep It Short and Simple) : 간결하고 단순하게
DRY(Don't Repeat Yourself) : 중복하지 마라
YAGNI(You Aren't Going to Need it) : 코드는 지금 필요한 것만
PIE(Program Intenly and Expressively) : 의도를 표현해서 프로그래밍하라
SLAP(Single Level of Abstraction Principle) : 추상화 수준의 통일
OPC(Open-Closed Principle) : 개방-폐쇄의 원칙

확장에 대해서 열려있다 : 코드의 동작을 확장할 수 있다
수정에 대해서 닫혀있다 : 코드의 동작을 확장하더라고 그 밖의 코드는 전혀 영향을 받지 않는다

명명이 중요하다

사상 : 프로그래밍의 이데올로기

프로그래밍을 이끄는 가치관 - 의사소통, 단순함, 유연성
의사소통 : 코드를 읽기 쉽게 만들어야 한다
단순함
유연성 : 변경이 용이한 코드, 코드의 확장성을 높인다

프로그래밍 이론을 실현하는 6가지 원칙

결과의 국소화 : 변경의 영향을 억제하기 위해 관계가 밀접한 코드를 한데 모은다(모듈화)
반복의 최소화 : 수정의 영향을 국소화시킬 수 있음. 코드를 분할해서 관리한다
대칭성

추가 메서드가 있다면 대응하는 삭제 메서드를 작성한다
특정 그룹에 있는 함수는 같은 파라미터를 갖도록 한다
특정 모듈 안의 데이터는 전부 생존 기간이 같아지게끔 한다
특정 함수 안에서 호출하는 함수의 추상도는 같은 수준으로 한다

선언형의 표현
변경빈도(코드를 수정하는 시점)가 같은 것끼리 그룹핑

단일 책임의 원칙 : 모듈을 변경하는 이유가 여러개 존재해서는 안된다

로직과 데이터의 일체화 : 로직과 해당 로직이 존작하는 데이터를 서로 가까이서 배치

아키텍처 기본 기법

추상
캡슐화 : 관계성이 강한 데이터와 로직을 모듈이라는 껍질로 감싸는 것, 관련 있는 데이터와 로직을 그룹핑해서 하나의 모듈을 정의.

관련 없는 요소가 섞이지 않기 때문에 코드가 읽기 쉬워진다
변경 시의 영향이 모듈 안으로 한정된다
영향도가 명확해지므로 코드의 변경이 쉬워진다
각각 독립된 부품이므로 재사용성이 높아진다
작은 단위로 분할되므로 복잡한 문제에 대처할 수 있다

정보은닉 : 클라이언트에서는 최소한으로 공개된 함수를 통해서만 조작할 수 있다, 모듈의 데이터는 외부에서 직접 접근할 수 없다, 모듈의 함수는 최대한 비공개로
패키지화 : 모듈을 그룹핑
관심의 분리

관심이란 소프트웨어의 기능이나 목적을 뜻한다. 관심을 분리한다는 것은 각각의 관심에 관련된 코드를 모아 독립된 모듈로 만드렁 다른 코드로부터 분리한다는 뜻이다. 분리된 모듈의 기능 공개는 소수로 제한하고 다른 모듈과의 결합을 최소한에 머물게 한다

충족성, 완전성, 프리미티브성 : 표현하고 있는 추상을 정확히 전한다
정책과 구현의 분리

정책 : 해당 소프트웨어의 전제에 종속되는 비즈니스 로직이나 그 밖의 모듈에 대한 파라미터를 선택하는 부분
구현 : 해당 소프트웨어의 전제에 종속되지 않는 독립된 로직.

인터페이스와 구현의 분리
참조의 단일성 : 정의는 한번만

참조 투과성 : 호출결과가 파라미터에만 종속된다, 호출이 다른 기능의 동작에 여향을 주지 않는다

분할 정복 : 문제가 커다라면 해결하지 어려워지고 시간이 많이 걸리기때문에 커다란 문제를 잘게 나눈다

아키텍처 비기능 요구사항

변경 용이성 : 소프트웨어의 수명은 의외로 기므로 코드를 쉽게 변경할 수 있어야한다 / 보수성, 확장성, 재구축, 이식성
상호운용성 : 소프트웨어는 다른 시스템이나 환경과 빈번하게 상호작용하므로 표준 규격을 선택함으로써 다른 소프트웨어와 정보를 주고받을 수 있어야 한다
효율성 : 리소스를 적극적으로 활용한다
신뢰성 : 장애가 발생했을 때도 정상적인 동작이 가능하게끔, 부정한 사용이나 입력 실수로부터 소프트웨어를 보호
테스트 용이성
재사용성 : 기존 구조나 모듈에 플러그인할 수 있게

7가지 설계 원리

단순 원리
동형 원리
대칭원리
계층원리
선형원리 : 분기가 적은 코드를 작성한다
명증 원리 : 로직이 명료한 코드를 작성한다
안전원리

UNIX 사상

묘듈화의 원칙

모듈이 제공하는 인터페이스는 불필요한 것은 제외하고 가장 적게 만든다
모듈의 구성 요소는 관계성이 높은 것만 모아 놓도록 한다

명확성의 법칙
구성의 원칙(?)

필터 : 입력으로 데이터 스트림을 받아들여 가공한 다음 다른 데이터 스트림으로 출력하는 소프트웨어

분리의 원칙 : 정책과 메커니즘을 분리
단순성의 원칙
절약의 원칙 : 큰코드는 작성하지 않는다
투명성의 원칙

소프트웨어의 동작에 관해 한눈에 봐도 곧바로 무엇을 어떻게 하고 있는지를 이해할 수 있을 것

안정성의 원칙 : 소프트웨어를 안정시키기 위해 코드를 투명화하고 단순화한다
표현성의 원칙 : 정보는 로직이 아닌 데이터에 모아서 표현한다
충격 최소의 법칙 : 인터페이스는 사용하는 사람이 상상하는 형태대로 동작하도록 설계한다
침묵의 원칙 : 반드시 알려야 하는 예상외의 상황이 아니면 표시를 최소한으로 줄인다
복구의 원칙 : 동작 중 오류 복구에 실패했다면 처리를 중단
경제성의 원칙
생성의 원칙 : 코드를 작성하기 위한 코드를 작성한다
최적화의 원칙 : 빠른 코드보다 바른 코드
다양성의 원칙 : 선택의 다양성을 수용한다
확장성의 원칙 : 연결하능하게 설계

UNIX 철학

작은 것이 아름답다 : 소프트웨어는 작게 만들고 작게 유지한다
한 번에 하나의 작업
즉시 프로토타입 진행
효율성보다 이식성
데이터는 텍스트로
레버리지 소프트웨어(?)
셸 스크립트 활용(?)
대화형 인터페이스 회비(?)
필터화 : 스프트웨어를 필터로 설계

관점 : 프로그래머가 보는 시각

응집도 : 응집은 강하게
결합도 : 모듈끼리 갖는 관계의 밀접함을 의미, 결합은 약하게
직교성 : 각 코드간 독립성과 분리성
가역성 : UNDO 가능한 선택
코드의 구린내 : 중복, 길다, 크다, 많다, 이름이 맞지 않는다
기술적 부채

습관 : 프로그래머의 일상

프로그래머의 3대 미덕 : 태만, 성급, 오만 = 자동화, 서식화, 모듈화
보이 스카우트 규칙 : 코드를 청소하고 돌아간다

단위테스트작성, 목적에 적합하지 않은 기존 시스템을 억지로 사용하지 말것, 부적절한 라이브러리가 선택되어 있다는 사실을 알고도 방치한다

성능 튜닝에 관한 금언 : 빠른 코드 보다 좋은 코드
비자아적 프로그래밍 : 자신이 작성한 코드를 적극적으로 동료에게 보여주면서 개선점을 지적해 달라고 한다
한 걸음씩 조금씩 : 절대 한 번에 여러 가지 작업을 하지 않고 작은 작업을 한씩 수행하고 결과를 제대로 확인한 뒤에 다음 작업으로 넘어간다
방법은 하나가 아니다

기법 : 프로그래머의 도구상자

예광탄 : 최종 형태에도 남는 골격코드
계약에 의한 설계 : 함수를 호출하는 쪽은 올바른 파라미터를 전달하고, 함수는 호출 후에 보증되어야 할 조건을 갖춰야한다
방어적 프로그래밍

외부 소스에서의 데이터 입력값을 확인한다(상정 내의 오류를 검출)
함수의 입력 파라미터 값을 확인한다(상정 외의 오류검출)
오류 처리

개밥 먹기 : 자기가 개발한 소프트웨어는 본인이 직접 사용
고무 오리 : 코드를 누군가에게 설명하는 디버깅 방법을 사용하면서 자체 해결을 촉진한다
컨텍스트 : 문맥 대화와 문맥사고

법칙 : 프로그래밍의 안티패턴

브룩스의 법칙 : 일정이 늦어지고 있는 소프트웨어 개발 프로젝트에서 지연을 만회하기 위해 후반에 사람을 추가하면 오히려 더 늦어진다
콘웨이의 법칙 : 소프트웨어의 구조는 그것을 만든 조직을 반영한다 - 아키텍처 설계 후에 조직을 편성하라
깨진 유리창 법칙 : 소프트웨어의 깨진 유리창, 즉 나쁜 설계, 잘못된 의사 결정, 나쁜 코드를 방치하면 그것이 아무리 작은 것이라도 소프트웨어 전체를 매우 단기간에 부패시킨다
엔트로피 증가의 법칙 : 코드 부패의 징후를 포착해 신속하게 처리한다
80:10:10의 법칙 : 사용자가 요구하는 것의 80%는 단시간에 실현할 수 있다. 나머지 10%는 실현가능하지만 상당한 노력이 필요하다, 나머지 10%는 완전히 실현이 불가능하다
조슈아 나무의 법칙 : 이름이 없는 것은 보이지 않는다. 그러므로 해당 문제 영역의 각 요소를 정확하게 표현하는 팀 공통언어를 사용한다.
세컨드 시스템 증후군 : 첫 번째 버전을 배포한 프로그래머가 설계한 두 번째 버전 소프트웨어는 기능을 너무 잔뜩 집어넣어 품질이 나쁘고, 기느의 사용성도 떨어지는 경향이 있다