The practice of Programming 수련법

The practice of Programming(프로그래밍 수련법) – 인사이트 

스타일 

전역변수는 서술적으로 길게, 지역변수는 최대한 짧게해라 

루프변수 i/j, 포인터 p/q, 문자열 s/t
함수 이름에는 능동형을 쓰라.  

일관적이고, 정확한 이름을 쓰라 

불리언 리턴하는 함수는 명확하게 이름지어라 

들여쓰기로 알아보기 쉽게 하고 복잡한 식은 잘게 쪼개라 

부정의 부정은 어렵다 

애매한건 괄호로 감싸라. 

중괄호 쓰는 스타일 일관적이게 유지하라. ( 뭐가 좋은것은 존재하지 않는다. ) 

관용적 사용되는 문장을 쓰라. 

다중결정시 if/else로. switch - case로 묶는 경우는 동작이 완전 같은경우. 

매크로는 아주 필요하다싶지 않으면 멀리하라

매직넘버는상수,배열크기 등.. 이름붙여 관리하면 쉬워진다.

숫자는 매크로 말고 상수로 하라(C)

객체크기랑 관련된 매직넘버라면 sizeof를 쓰자

주석은 코드에서 바로 알아볼 수 없는 정보를 덧붙이거나 소스 여기저기에 있는 정보를 한 데 모우는 데 사용한다.
변수이름으로 기능 알 수 있으면 다시 설명하지 마라.

함수와 전역데이터에는 주석을 달아라.

나쁜 코드 설명하다가 주석이 꼬일거같으면, 코드를 새로 짜라.
주석과 코드는 일치시켜라.

주석은 동작방식을 간단히 요약하고 표준정의가 뭔지 알려줘라. 

알고리즘과 데이터구조 

순차검색, 이진검색(정렬된경우), 퀵소트, O표기법, 가변길이배열, 리스트, 트리, 해시테이블

상황에 따라 적당한 데이터구조를 사용해야한다.

설계와 구현 

어떤 문제를 해결하는 설계를 하고자 할 때, 어떤 데이터 구조를 쓸 것인지 고민해라

사용할 알고리즘에 대한 지식을 토대로 데이터구조를 상세하게 설계하라.

C

빠르지만, 피바다를 만들 수 있다.

자바

컴포넌트(오브젝트/클래스) 사이의 인터페이스에 주로 관심을 가져야 한다. 
 

인터페이스 

다른사람이 쓰기 위한 라이브러리 설계에서 프로토타입은 쓰고 버리는 것. 한 번 만들어보고 무엇이 부족한지 알아보도록 하자. 일어날 수 있는 상황을 충분히 생각해서. 타인은 헤더만 본다. 라이브러리는 에러났다고 뒤져서는 안된다. 

목표에 어울려야 한다 – 단순,범용,규칙적,결과예상가능,튼튼,유연성 

개발명세서 - http://www.talk-with-hani.com/archives/162 Needs, 기간, 돈. 

명세서는 자세할수록 좋다. 함수원형,동작방식,책임,가정한 사항등을 포함 

Realloc은 기존 할당한 공간을 늘였다줄였다. 텍스트파일 입력받을 때 씀. 

인터페이스원칙 

구현에 대한 정보는 숨겨라(정보은닉,캡슐화,추상화,모듈화) 

압축적인 인터페이스. 필요한 기능만 만들라. 더 할수있어도 하나만 제공해라. 

입력데이터 바꾸지마라-버그가능성. 단일 인터페이스로 끝내라. 하나만 인클루드 하면 되게 

함수 변수순서, 클릭횟수, 균일한 STL 인터페이스 등. 

메모리, 사본/포인터 관리, 종료시 반환 

결자해지 책임을 강제한다. 

쓰레드라면 재진입가능하게-동시수정 불가능하게 

복구불가능한 에러 

함부러 뒤져서 저장도 못하는상황 되면 안된다. 에러 발생 후에도 라이브러리가 돌아가도록 설계하라. 로그 써라. 

루틴을 점잖게 실패한다. 에러내지않고 널값 리턴한다든지. 호출자가 에러를 어떻게 할 지 결정할 수 있게. 

에러 래퍼(wrapper)을 만들어서 어디서 무슨에러인지 

예외 남발 금물. 일반적인 경우는 예외 쓰지마라. 

사용자 인터페이스 

진단용 출력은 죽은 출처와 이유를 알 수 있게. 

대화상자는 별로다. 에러 저장이 힘들다. 

방어적 프로그래밍-비정상 입력이 들어와도 버텨라 

디버깅 

디버깅 상황으로 안가는게 상책이다. 예방해라 – 좋은설계와 스타일, 경계조건테스트, 단정문, 정상성, 방어적 프로그래밍, 인터페이스, 한정된 글로벌, 검사도구 

언어적 버그예방-잠재적인 위험요소 인식 

자기검증코드로 대체하는 것이 낫다. 엥간하면 그거보고 디버깅하지마. 

감이 오는 버그 

죽기직전의 출력은? 스택은? 봣던놈 아냐? 최근에 고친놈은 봤어? 같은실수 두번한건 아냐? 

스택추적값은 봤어? – 보는 법 배워야한다. 

수정하기전에 읽어봐. 코드 설명해봐. 

감이 안오는 버그 

버그 재현가능하도록 포장해라. 어떻게하면 잘 일어나나? 

버그 가능성이 있는 곳을 차례로 줄여나가라(divide and conquer. 각개격파) 

버그가 관련된 숫자의 패턴을 파악해라 

출력을 많이 내서 어디서 뒤질지 보라 

자가검증코드-관련변수 출력하는 함수. 감시용 로그. 

로그 내보낼 때 flush를 꼭 하여 버퍼를 비워서 출력하라. 

그림-그래프로 패턴 보라, 툴, 바꿀때 메모 

아무래도 안되는 버그 

단순한 오해인 경우가 많다-연산자우선순위,틀린연산자(=,==),이름침범,변수순서,변경된포인터반환 

휴식, 정 안되면 툴 탓하기, 저엉말 안되면 하드웨어 탓. 

재현불가능한 버그 

프로그램 실행할때마다 바뀌는 어떤 정보를 이용하는 부분에서 에러가 난다 

메모리 할당에서 가능성이 높다. 비결정적 버그는 툴을 써라. 일관성 검사를 수행하라. 

타인의 버그최신버젼인가? 확실히 버그인가?-두줄안에 버그를 내봐라. 

테스트 

테스트는 버그가 존재함을 보여줄 수는 있으나 부재함을 보여 줄 수는 없다. 

코딩하며 테스트하기 

경계조건테스트(boundary codition testing)-대부분의 버그는 경계에서 발생(off by one). 조건분기여부, 루프반복횟수등 확인 

사전/사후조건 테스트-기대값인지 확인. 입력값에 대한 검증. 

방어적 프로그래밍-논리적으로 불가능하지만 그래도 생길수 있는 상황도 고려 

리턴값을 감시한다 

체계적으로 테스트하기 

하나하나 테스트해가면서 작성-프로그램 자체,기능 확장 

결과를 검증하라. 가능한 출력인가? 

다른 구현에서 같은 결과가 나와야 한다 

자동화하여 테스트하기 

회귀 테스트(regression testing) 

테스트를 불려나가고 지우지마라. 팀플에도 적용. 테스트 워크벤치로 활용 

부하테스트-입력은 생각보다 크고 많을 수 있다. 

테스트 팁-배열크기 줄여서 경계 에러 발생가능성을 높여본다 

 

성능 

성능개선을 꼭 해야 할 지를 먼저 고민한다. 성능이 정말 중요한가? 충분히 빨라지면 손을 떼라. 

속도효울성 

느린코드를 분리하고(병목을 찾고), 빠르게 만들자

시간측정 

경과시간-시계시간, CPU시간-CPU가 실제 실행한 시간, 시스템시간-OS에서 소비한 시간 

함수에 시간측정함수를 삽입 

프로파일러-어디서 많은시간 쓰는지 알려주는 툴. 핫스팟을 잡아라. 

매개변수에 따른 실행시간 그림을 그려보라. 

속도증가 전략 

알고리즘 더 나은걸로-O연산 

컴파일러 최적화 켜라. 전역 최적화기란것도 있다. 최적화 후에는 다시 테스트. 

미세조정-루프와 표현식을 점검. 

루프 안에서 변하지 않는 연산은 꺼내라 

싼 연산으로 대체하라 

루프 언롤링 

로컬리티 캐싱 

입출력 버퍼링하여 한참에 수행 

똑같은크기로 여러개 만드는 메모리를 만든담에 나눠줘라 

결과 계산해놓고 꺼내써라 

수치 근사화. 더블플롯보단 싱글플로팅 

로우코딩 

(다 컴파일러에서 해주니까 이것들은 상관없는거 아냐?) 

공간효율성 

신경 안쓰는게 상책 

데이터타입을 작게 

계산가능한 작은연산은 저장하지마 

실행시간하고 엿바꿔먹어라. 

비용추정 

연산이 얼마나 오래 걸릴것인가 벤치마크 

입출력은 비싸다. 요즘 실수랑 정수랑 연산시간 비슷.(안드로이드에서도?) 

호환성 

호환성Portability 다른환경에서도 잘 돌아가는거. 플랫폼 옮길 때 더 적게 고치게 만들자. 

언어 

표준을 유지한다. 주류를 따른다. 

데이터타입,연산자 우선순위,부호 맞춰라. 시스템마다 다를 수 있다. 

자바는 정수타입에는 부호가 있고 char타입에는 부호가 없다. 

리틀엔디안, 빅엔디안 –hw 

여러 개의 컴파일러로 돌려봐라. 표준라이브러리를 사용하고 네임스페이스 겹침을 전처리로 확인하라. 쓰는 기능만 ifndef로 가져와라. 소스엔 ifndef보다는 조건문을 써라. 호환성문제 있으므로 시스템의 공통된 기능만을 사용하도록 한다. (C,C++,ANSI C,C99 C)(근데 컴파일러에서 알아서 라이브러리에서 메소드만 가져오지 않나??) 

시스템 의존성은 별도의 파일에 지역화해 담는다. 시스템 의존성을 인터페이스 뒤에 숨긴다. 변경 필요없게. 

데이터 교환 

텍스트를 사용하라. 바이너리는 안됭. 

그치만 개행문자땜에 호환깨질 수 있음. PC-\r\n(CRLF), Unix-\n.. 표준을 따르라. 변환 프로그램 필요. 

바이트순서 

바이너리 데이터 순서. 

자바는 바이트 순서를 숨긴다. Serializable 인터페이스에서 관리한다. (그래서 내가 블루투스로 비트연산할 때 개지랄했나..) 

호환/업데이트 

호환불가능한 프로그램들은 불행히도 다른 버전에도 이름이 같다. 

호환성, 역방향 호환성 

국제화 

아스키가 아닐 수 있다. 영어가 아닐 수 있다. 날짜형식이 다를 수 있다. 

표기법 

표기법

패킷같이 타입이 들쭉날쭉인 녀석은 변수이름안에 타입을 넣는다

정규표현식 적절히 써보등가..

 

 

 

 

===정리 

스타일 

알고리즘과 데이터구조 

설계와 구현 

인터페이스 

초록 

다른사람이 쓰기 위한 라이브러리 설계에서 프로토타입은 쓰고 버리는 것. 한 번 만들어보고 무엇이 부족한지 알아보도록 하자. 일어날 수 있는 상황을 충분히 생각해서. 타인은 헤더만 본다. 

목표에 어울려야 한다 – 단순,범용,규칙적,결과예상가능,튼튼,유연성 

인터페이스 뒤의 코드는 숨겨라 

개발명세서 - http://www.talk-with-hani.com/archives/162 Needs, 기간, 돈. 

명세서는 자세할수록 좋다. 함수원형,동작방식,책임,가정한 사항등을 포함 

Realloc은 기존 할당한 공간을 늘였다줄였다. 텍스트파일 입력받을 때 씀. 

 

 

개관 

인터페이스란? 일관성, 사용성, 충분한 서비스 

정보은닉? 드러낼정보와 숨길 정보는? 접근경로 있으되 세부구현정보는 숨겨야. 

자원관리 어디서 할것인가, 에러는 어떻게 처리하고 보고하나. 

예제 – CSV 

예제설명 : Comma-separated values 

디버깅 

테스트 

성능 

호환성 

표기법

출처:[프로그래밍 수련법] 읽고 정리(1차)

스타일

FFF(Form Follows Function) – 형태는 기능을 따른다

전역은 서술적, 지역은 짧고 관용적으로, 일관적이고 정확한 이름을 쓸 것

애매한 우선순위는 괄호를 꼭 칠 것

매직넘버

의미를 갖는 상수는 이름을 꼭 써줘서 무슨뜻인지 알게 하라

주석

함수와 전역데이터에는 주석을 달 것

틀린 주석 달지 말 것. 주석이 복잡해지지 말 것. 틀린코드를 설명하기위해 코드달지 말고 새로 짤 것

기능을 요약하고 분산된 정보를 한 데 모으는 것이 주석이다

(JavaDoc)

알고리즘과 데이터구조

..

설계와 구현

(2)를 목적과 기능에 맞게 사용하여 설계하라

인터페이스

모두가 쓰기위한 라이브러리를 만든다고 생각하라.

목표 수행을 위해 단순해야 한다

일어날 수 있는 모든 경우를 생각해야 한다

에러났다고 멋대로 죽으면 안된다. 적절한 리턴을 해야한다.

구현정보는 숨겨라

명세서

고객과

하나하나가 돈이다

수요를 분석. 기간 산정. 의사소통

개발자들은

함수원형과 시나리오 설정

책임귀속과 적절한 가정

예외상황

결자해지하여 미연에 방지해라

점잖은 실패를 하라. 호출자가 처리할 여지를 남겨줘라

에러 래퍼(wrapper)클래스를 만들어서 추적할 수 있게 하라

디버깅

엥간하면 하지마라

예방이 더 중요하다.

경계조건을 유의하라

방어적 프로그래밍을 하라

방법

흔한 버그, 자주죽는 곳

Divide & Conquer

수정하기 전에 읽는 습관을 들여라

휴식을 해라(모두 알지만 간과하고 있는 것)

테스트

코딩하며

경계조건 테스트

기대값 확인

방어적 프로그래밍(이 방 온도가 100도다!)

코딩후에

기능별로 확장하며

회귀하며

성능

엥간하면 하지마라. 할 필요 있는지 물어봐라.

속도

병목을 잡아라. 알고리즘을 변경하고 컴파일러 최적화를 켜서 해봐라.

용량

실행시간을 잡아먹으면 됨

호환성

표준(주류)를 따르라

시스템 의존성은 별도 파일에 담는다. 인터페이스 뒤에 숨겨라.

텍스트가 데이터 교환에 좋다. CRLF만 조심해라.

표기법

...

‘Do’s and ‘Do not’s

하지마라

디버깅

필요없는곳의 성능증가를 위한 시간낭비

디버깅 시 읽기전에 손을 먼저 뻗는 짓

해라

적절히 주석을 달라

설계할 때 기능에 맞도록 알고리즘과 데이터 구조를 설계하라

그것을 코드로 짜기전에 설계하라. 그리고 고칠 것은 덮어두지말고 빨리 고쳐라.

출처:[프로그래밍 수련법] 2차 정리