프로그래밍의 정석

26 posts

POP_part26(법칙 - 프로그래밍 안티패턴)

법칙 프로그래밍 안티패턴 깨진 유리창 법칙 빌딩같은 건물에 수리되지 않은 깨진 유리창이 한 장이라도 있다면, 사람들은 빌딩 주인이 자기 건물에 관심이 없는줄 안다. 이렇게 되면 곧 다른 유리창도 깨진다. 그리고 건물 전체에 심각한 파손이 일어난다. 소프트웨어도 똑같은 현상이 일어난다. 소프트웨어에서 깨진 유리창 즉 나쁜

7 min read

POP_part25(법칙 - 프로그래밍 안티패턴)

법칙 프로그래밍 안티패턴 브룩스 법칙 일정이 늦어지고 있는 소프트웨어 개발 프로젝트에서 지연을 만회하기 위해 후반에 사람을 추가하면 오히려 지연이 한층 더초래 된다. 맨먼스(man month)로 프로젝트 일정을 환산하는데 man과 month는 교환 불가능이다. 이유는 다음과 같다. 종속 관계에 따른 오버헤드가 발생한다.

4 min read

POP_part24(관점 - 프로그래머가 보는 시각)

관점 프로그래머가 보는 시각 개밥먹기 자신이 개발한 소프트웨어를 직접 사용해 봐야 된다.이렇게 되면 사용자의 관점을 얻을수 있다. 본인이 사용해서 편리함을 증명해야된다. 고무오리 디버깅 기법이다. 발생한 문제를 누구한테 설명하므로써 문제의 원인을 스스로 깨닫고 자체 해결할수있다.자체 해결을 촉진한다. 무생물에게 먼저 적용

4 min read

POP_part23(관점 - 프로그래머가 보는 시각)

관점 프로그래머가 보는 시각 계약에 의한 설계 함수와 함수를 호출하는 쪽이 서로 계약을 맺고 있다고 간주하고 프로그래밍 하는것을 가리켜 계약에 의한 설계라고 한다. 계약한 내용을 미리 함수의 주석으로 알려주자 계약이행의 확인을 위한 코드는 단정문으로 표현하자. 주의점 함수쪽에서는 파라미터를 조정하지 않는다 함수쪽의 단정문

3 min read

POP_part22(관점 - 프로그래머가 보는 시각)

관점 프로그래머가 보는 시각 비자아적 프로그래밍 프로그래밍 할때는 자아를 버려야 된다. 자존심과 자만을 버리고 동료에게 협력을 구하자 코드를 작성할때는 자기 능력을 뽐내는것이 아니라 코드가 더 좋아지는 것에 초점을 맞추어야 한다. 자기 자신도 실수를 저지른다는 점을 이해하고 받아들인다. 작성한 코드는 자기 자신이 아니다.

4 min read

POP_part21(관점 - 프로그래머가 보는 시각)

관점 프로그래머가 보는 시각 프로그래머의 3대 미덕 태만 반복적인 작업은 시스템화 하자 성급 일어날수 있는 일은 먼저 작업하자 오만할것 남에게 부끄럽지 않게끔 작업하고 보수하자. 프로그래머는 중노동에 대해서는 보상받지 못한다. 자기가 일하는 시간이나 노력을 줄이면 줄일수록 프로젝트에 대한 기여는 커진다. 보이 스카우트 규

3 min read

POP_part20(관점 - 프로그래머가 보는 시각)

관점 프로그래머가 보는 시각 직교성 코드에 변경은 다른코드에 영향을 주면 안된다. 즉 코드간에 독립성과 분리성을 갖도록 하자. 직교성을 가진 코드는 견고하다. 변경이 국소화 되면 생산성이 향상된다. 문제가 생겨다 해당부분을 격리 가능해서 코드가 더 견고해진다. 모듈간에 결합도를 최소화 시키자 불필요한 정보는 다른 모듈에

2 min read

POP_part19(결합도)

관점 프로그래머가 보는 시각 결합도 내용 결합 공통 결합 외부 결합 제어 결합 스탬프 결합 데이터 결합 상호 종속 되는 모듈은 깨지기 쉽다 저결합 모듈을 지향 해야 된다. 데이터 결합방식을 맹목적으로 지향하기 보다는 결합하려는 대상과의 친밀도에 따라 단계를 결정하자 하이브리드 결합 데이터가 여러 의미를 지니는 경우 세율의

2 min read

POP_part17(UNIX 철학)

사상 프로그래밍 이데올로기 UNIX 철학 효율성보다 이식성 개발 효율성보다는 이식성을 중요시 선택하자 소프트웨어의 성공을 가늠하는 잣대중 하나로 몇개의 플랫폼에서 실행되는가? 라는 척도가 있다. 소프트 웨어의 가치를 지속시키는것은 하드웨어가 경쟁력을 갖는동안 유지할수 있는데 다른 하드웨어로 이식이 필요한다 여기에 시간을

2 min read

POP_part18(UNIX 철학)

사상 프로그래밍 이데올로기 UNIX 철학 대화형 인터페이스 회피 구속적 인터페이스라고도 하는데 이렇게 되면 사용자도 머신도 소프트웨어에 구속당한다. 소프트웨어별로 독자적인 대화 방법을 기억해야 된다. 소프트웨어끼리 대화 할수 없다. 대기 시간이 많아진다. 입력부분에 대한 해석 코드가 많아지고 흉해진다. 큰것이 아름다운 접

3 min read

POP_part16(UNIX 사상)

사상 프로그래밍 이데올로기 UNIX 사상 복구의 원칙 소프트웨어 동작중에 오류복구에 실패 했다고 하면 처리는 계속하면 안된다 그리고 오류는 한눈에 띄도록 발생시킨다. 소프트웨어 동작은 평상시 뿐만 아니라 오류시에도 투명해야 한다. 오류를 복구하지 못했는데 계속 동작시키면 피해를 확대시킨다. 그리고 오류는 가능한 요란하게

6 min read

POP_part15(UNIX 사상)

사상 프로그래밍 이데올로기 UNIX 사상 표현성의 원칙 정보는 데이터에 모아 표현 정보를 데이터에 표현하면 로직은 읽기 쉬워진다. 왜냐고 하면 데이터는 로직보다 다루기 쉽다.그래서 데이터가 복잡해야 되는지 아니면 로직이 복잡해야 되는지 고민하지 말고 데이터를 복잡하게 하자. 충격 최소의 원칙 인터페이스는 예상대로 동작하도

2 min read

POP_part14(UNIX 사상)

사상 프로그래밍 이데올로기 UNIX 사상 절약의 원칙 큰 코드는 작성하지 않는다. 큰 코드는 제어 불능 코드를 덧붙이지 않는다. 투명성의 원칙 소프트웨어 동작의 시각화 투명성 소프트웨어 동작에 관해 한눈에 봐도 곧바로 무엇을 어떻게 하고 있는지 이해할수 있을것 개시성 소프트웨어 내부 상태에 관해 감시할 수 있거나 보여줄

2 min read

POP_part13(UNIX 사상)

사상 프로그래밍 이데올로기 UNIX 사상 UNIX의 근간이 되는 암묵적인 지식 UNIX는 엄청난 생명력이 있다 1969년에 등장했다. 모듈화의 원칙 소프트웨어는 복잡하다 하지만 복잡도 정도는 낮출 수 있다. 코드중 관계성이 높은 요소를 모아 모듈을 작성한다. 복잡한 정도를 제어하는게 원래 프로그래밍 본질이다. 모듈이 제공

3 min read

POP_part12(7가지 설계 원리)

사상 프로그래밍 이데올로기 7가지 설계 원리 단순 원리 단순함을 중시한다. 버그는 복잡한곳에서 나온다 동형 원리 형태를 중요시한다. 코드에 일관성을 가지게 하자 대칭 원리 형태의 대칭성을 중시한다. 참일때 처리가 있으면 거짓일떄 처리가 있어야 된다 계층 원리 구조의 계층성을 중시한다. 코드각각의 추상 수준을 의식해서 계층

2 min read

POP_part11(아키텍처 기본 기법)

사상 프로그래밍 이데올로기 아키텍처 기본 기법 상호 운영성 소프트웨어는 시스템의 일부이며 독립해서 존재하는것이 아니고 다른 시스템이나 환경과 빈번하게 상호작용한다. 외부 기능이나 자료구조로의 접근이 명확하게 정의된 아키텍처를 설계 표준 규격을 선택해야 된다. 효율성 시간 효율성 자원 효율성 리소스는 한정적 간접화를 고려해

2 min read

POP_part10(아키텍처 기본 기법)

사상 프로그래밍 이데올로기 아키텍처 기본 기법 변경 용이성 소프트웨어에 수명은 의외로 길다. 그래서 변경 용이성을 해야 된다. 보수성 오류가 발생한 코드 수정이 용이 확장성 신규 기능 추가, 모듈 교체, 모듈의 제거 작업의 용이함 재구축 모듈의 구현에는 영향을 미치지 않고 유연하게 배치할수있는 구조 이식성 하드웨어 종속성

2 min read

POP_part8(아키텍처 기본 기법)

사상 프로그래밍 이데올로기 아키텍처 기본 기법 인터페이스와 구현의 분리 인터페이스 기능 정의 및 모듈 사용 방법 정의(?) 구현 실제 기능을 실현하는 코드 클라이언트는 인터페이스만 알면 되서 기능이 바껴도 코드를 수정할일이 없다. '구현이 아닌 인터페이스에 맞춰 프로그래밍 하라' 참조의 단일성 모듈의 요소에 관한 선언과

3 min read

POP_part9(아키텍처 기본 기법)

사상 프로그래밍 이데올로기 아키텍처 기본 기법 충족성 완전성 프리미티브성 충족성 추상이 그것을 전하기 충분한지(remove가 있는데 add가 없으면 불충분) 완전성 추상이 모든 특성을 가지고 있는지(콜렉션인데 size 구하는게 없으면 안됨) 프리미티브성 추상이 순수한지 아닌지(add가 있는데 add10은 필요 없다.) 정

2 min read

POP_part7(아키텍처 기본 기법)

사상 프로그래밍 이데올로기 아키텍처 기본 기법 패키지화 모듈을 의미있는 단위로 모운후 그룹핑 한다. 소프트웨어 전체가 패키지라는 작은 단위로 분활되므로 복잡도가 낮아진다 패키지 않에 관련 없는 모듈이 섞이지 않으므로 모듈을 관리하기 쉽다. 수정에 대한 영향도가 패키지 안에 머무를 가능성이 높으므로 코드를 변경하기 쉬워진다

2 min read

POP_part6(아키텍처 기본 기법)

사상 프로그래밍 이데올로기 아키텍처 기본 기법 좋은 코드의 기초원리 추상 캠슐화 정보 은닉 패키지화 관심의 분리 충족성, 완정성, 프리미티브성(원시성, 순수성) 정책과 구현의 분리 인터페이스와 구현의 분리 참조의 단일성 분활정복 좋은코드에는 패턴이 있다. 추상 추상이란 개념적으로 명확한 선 긋기를 수행하는 것이다. 추상은

4 min read

POP_part5(프로그래밍 이론)

사상 프로그래밍 이데올로기 프로그래밍 이론 프로그래밍을 이끄는 가치관 1. 의사소통 2. 단순함 3. 유연성 가치관을 기술의 선택 기준으로 '어쨰서 이런 것을 할 필요가 있는가?', '이것은 어떤 가치가 있는가?', '언제 이것을 사용하면 좋은가?' 가치관은 원칙을 통해 코드에 적용 1. 결과의 국소화 2. 반복의 최소화

5 min read

POP_part4(OCP(Open-Closed Principle)/Naming is important)

원칙 프로그래밍 가이드 라인 OCP(Open Closed Principle) 코드는 확장에 열려 있고 수정에 대해서는 닫혀있는 2가지 속성을 동시에 충족하도록 설계한다. 확장에 대해서 열려있다는 말은 코드의 동작을 확장할 수있다는 의미이다. 수정에 대해서 닫혀 있다는 말은 코드의 동작을 확장하더라도 그 밖의 코드는 전혀

5 min read

POP_part3(SLAP(Single Layer of Abstraction Principle))

원칙 프로그래밍 가이드 라인 SLAP(Single Layer of Abstraction Principle) 추상화 수준의 통일 코드수준을 맞춘다. 코드에서 추상화 수준을 분리할 때는 상하 2계층이 아니라 기능 복잡도에 따라서 여러계층으로 분리된다. 각각의 계층에서 자신의 계슻에 속하는 요소에 대해 추상화 수준을 일치시킨다

6 min read

POP_part2(PIE(Program Intently and Expressively))

원칙 프로그래밍 가이드 라인 PIE(Program Intently and Expressively) 의도를 표현해서 프로그래밍 해라. 코드는 컴파일러가 아닌 사람이 읽기 위한것이다. 그래서 어떻게 하면 다른사람이 잘 이해하게 직관적으로 코딩하자. 코드는 소프트웨어 동작을 정확하고 완벽하게 알기 위한 유일한 실마리다. 소프트

4 min read

POP_part1(전제 프로그래밍 불변사실)

the principles of programming 전제 프로그래밍 불변사실 프로그래밍에서는 은총알은 없다. 왜? 본질적으로 소프트웨어는 난해하다. 1. 복잡성 규모가 크면 수천 수만라인의 코드도 존재 하고 각 컨퍼넌트간에 종속성도 비선형적으로 증가함 2. 동조성(호환성) 실세계랑 끊임없이 동조 해야 된다. (네트워크,

10 min read