프로그래밍정석(2)
KISS
(Keep It Simple, Stupid / Keep It Short and Simple)
간단하게 해라, 어리석은 녀석아 / 간결하고 단순하게 해라.
코드를 작성할때 최우선 가치는 단순성과 간결성으로 둔다.
코드는 무질서를 향한다.
- 점점 무질서 해지고 복잡해진다.
- 품질이 떨어진다.
- 간결해지면 의사소통 유지보수 비용을 줄일 수 있다.(결국 코드로 대화)
코드에 불필요한것을 하지 않는다.
- 최근에 배운 코드, 기술들을 적용하고 싶을때가 있지만 참아라..
- 미래를 대비하고 싶을때가 있지만, 확실하지 않다면 미래에 대비하는것이 더 좋을 수도 있다.
- 멋대로 요구사항을 추가하지 말라
KISS 적용범위
- 코드 뿐 아니라 엔지니어링 전반에 적용 가능
less is more(단순한것이 더 아름답다)
오컴의 면도날
- 어떤 사항을 설명하는데 필요이상으로 많은 전제를 가정해서는 안된다.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Dry(Don’t Repeat Yourself)
- 중복하지 마라
코드 복사는 금물
- 정수리터럴을 직접 코드에 내장하는 것은 코드 중복에 해당한다
- 주석도 중복에 포함
코드를 개선할 수 없다.
- 코드를 읽기가 어려워짐
- 수정작업이 어려워짐
- 테스트가 없다
코드 추상화
- 코드를 묶고 이름을 붙여 함수화, 모듈화
- 데이터라면 이름을 붙여 상수로 정의
반복되는 작업의 자동화
- 지속적통합: 소프트웨어이 테스트 / 빌드 / 배포 등 정확하고 빈번하게 발생되는 것들에 대한 자동화
Dry프로그래밍 기술
- 객체지향 프로그래밍
- 중복의 제거 (사고의 중복 제거)
- 낮은 결합성, 높은 응집성
임피던스 불일치
- 임피던스(저항값) 불일치 : 전기 용어, 소재간 저항값이 달라지기때문에 반사가 발생해 에너지가 제대로 전달되지 않음
- DB와 프로그래밍 클래스가 만났을때 테이블 정의, 매핑설정 파일 등 중복되는 정복들을 작성이 필요하다.
WET(Write Everything Twice)
- Dry에 대비되며, 안되있는 코드들에 대해 비꼬는데 사용한다.
OFOP(One Fact in One Place)
- 한곳에 하나의 사실
- 데이터 중복이나 부정합(갱신이상)을 방지
OAOO(Once and Only Once)
- 한번만, 단 한번만
레거시코드
- 중복코드는 대부분 테스트가 없다.
- 옛날에 만들어진 이해할 수 없는 변경하기 힘든 코드 -> 테스트가 없는 코드
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
YAGNI(You Aren’t Going to Need it)
- 그것은 분명 필요 없어진다
코드는 필요할때 최소한으로
- ‘아마 필요하겠지, 필요해질지 몰라’는 없다.
코드 예측은 빗나간다.
- 확장을 염두해두더라도 막상 확장할때 그 코드를 사용할 확률은?
코드는 지금 필요한 것만
- 범용성보다는 단순성, 우선 사용 할 수 있는 가치에 집중
DTSTTCPW(Do The Simplest Thing That Could Possibly Work)
- 효과가 있는 방법 중 가장 간단한 방법으로 하라
- 오늘 단순하게 하고 내일 변경이 필요해졌을때 변경비용을 지불하는 것이 오늘 복잡하게 하고 결국 사용하지 않는 것보다 좋은 결과를 낳는다.
- 어쩌면 변경비용이 급상승 할 수도 있다. 이럴땐 정석을 떠올리고 되돌아올 필요가 있다.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
PIE(Program Intently and Expressively)
- 의도를 표현해서 프로그래밍
코드의 의도를 전달한다
- 컴파일러가 읽을 것이 아닌 사람이 읽는 것
- 직관적으로 작성
코드가 유일한 실마리
- 코드는 소프트웨어 동작을 정확하게 알기 위한 유일한 실마리
코드는 읽기 쉬운것이 최우선
- `작성하기 쉬움`보다 `읽기 쉬움`을 중시
두더지잡기식 개발 피한다
주석작성
- 주석없이 읽을 수 있는것이 가장 이상적이지만 아닐경우 작성이 도움이 된다
- what, how는 있지만 why는 없는게 대부분이기 때문에 작성
문학적 프로그래밍
- 코드는 곧 문서, 문서는 곧 코드다
- 전체적으로 코드기반 문서가 단 하나만 존재하는것처럼 보장
- 유지보수 단계에서 진가를 발휘
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
SLAP(Single Level of Abstraction Principle)
- 코드수준을 맞춘다.
- 고수준 추상화 개념과 저수준 추상화 개념을 분리
- 개념의 단계에 따라 추상화 단계를 통일
function high(){
middle()
middle()
}
function middle(){
low()
low()
}
function low(){
처리
}코드의 요약성과 열람성을 가져다 준다.
- 같은곳에서 같은 추상도를 처리해야 막힘없이 흐르고 이해가 쉬워진다.
- 반대로 추상도가 달라지면 흐름이 끊긴다.
함수를 구조화
- 추상화단계를 일치시킨 작은 단계의 함수로 변환
- 함수를 구조화하면서 각 함수는 자신보다 한단계 낮은 수준의 함수를 호출
SLAP 적용범위
- 추상클래스는 높은 수준을 갖게 하고, 해당 상속 클래스는 낮은 수준의 개념을 갖게 함으로써 실현
- 코드의 양이 많다면 섹션으로 나누기보단 파일로 나누는게 좋을 수 있다.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
OCP(Open-Closed Principle)
- 개방-폐쇄의 원칙
코드의 변경은 파급시키지 않는다.
- 확장에 열려있다 : 코드의 동작은 확장 할 수 있다.
- 수정에 닫혀있다 : 코드의 동작은 확장하더라도 그 밖의 코드는 전혀 영향을 받지 않는다.
코드의 변경에 유연하게 대처한다.
- 코드의 수명이 길어질수록 중요
코드에 인터페이스를 사용
- 직접 호출보다는 인터페이스를 통한 구현
OCP의 적용범위
- 모든 코드에 적용하는 것은 과한 방식. 변경되지 않는다면 코드 복잡도 가중
- 핵심은 `변화할 법한 부분을 예측`
OCP 구현과 설계
- 대표적으로 다형성
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
명명이 중요
코드에서 가장 중요한 과제
- 이름을 붙이는 행위
- 이름 자체
- 프로그래머는 코드로 대화, 직접 마주할일을 극히 드물다
코드는 읽는 사람에 대한 사용자 인터페이스
- 읽으면 곧바로 의미를 알 수 있는 좋은 사용자 인터페이스
- 읽기 어려우면 코드를 한줄 한줄 읽어나가도록 강요 당함
코드는 우선 이름을 정한다
- 읽는 사람의 관점에서 이름을 명명
- 이름을 오해하지 않도록 주의
- 이름을 검색 가능하도록 작성
마인드 매핑 회피
- 어떤 정보로부터 기억속에 있어야할 모습의 이미지로 변환하는 것
- 마인드 매핑을 최대한 피하도록
-> 복잡하고 집중력이 떨어짐(마인드 매핑 자체가 부하)
루프백 확인
- `이름 가역성` 이란 명명의 기반이 된 내용의 설명문을 복원 할 수 있어야한다.
- 설명문->이름->설명문
가능하도록, 가능하지 않다면 주의가 필요
//음성을 사용해서 소프트웨어를 조작하는 기능
음성인식기능 --- Ⅹ(조작한다 는 부분이 전달되지 않음)
음성조작기능 --- △(음성과 조작과의 관계가 전달되지 않음)
음성컨트롤기능--- △(음성을 제한하는 기능으로 오해가 가능)
음성명령기능 --- O (음성을 조작한다, 음성에 대해 조작을 가한다는 오해가 사라짐)
