이유 1. #define은 전처리기에서 작업하기 때문에 컴파일러가 모르게 된다. 2. 1번의 사항으로 이식성이 떨어지게 된다. 3. 1번의 사항으로 다른 파일의 헤더파일로 들어가면, 이것으로 인한 디버깅이 어려워진다. 4. 매크로함수의 버그 찾기가 어려워진다. 해결방법 변수 하나 더 주고, const를 사용 해라. 해결방법의 주의점 두가지 1. 상수 포인터를 정의할 때, - const char* const authorName = "Scoot Meyers"; 식으로 어떤 변경도 못하게 해라. 2. 클래스 범위안에서의 상수일때 - static const int NUM_TURNS=5; // 클래스 내부 private에다가 선언 이렇게 하면, 클래스의 전역구역(?)에 1개만 올라가서 클래스 내부에서만 접근 가능..
책 정리 검색 결과
내 수준으로 조금 벅차다. 왜냐하면 읽는 도중 "3판이 나왔는데, 3판을 볼까?" 란 생각으로 집중력이 흐트러진다. 집중을 할수 없을 정도의 어려움이 따른다. .. 이럴때는 예전에 만들었던 알고리즘을 적용해 하나씩 공략해 나간다. 이 방법은 수능때 썼었고 나름데로 쓸만했고, 마음이 편했고 필요한 집중만 할수 있었다. 그래서 이번 Effectve C++ 의 테스크를 하나 만든다. ㅋㅋ #include const int YES = 1; const int NO = 0; BOOL IsAllRead(BOOK& _BOOK) { return _BOOK; } knowledge Algorithm(BOOK& _BOOK) { IsUndersand(IsDoRead(_BOOK))) { --_BOOK; } if(YES == Do..
소프트웨어 아키텍처란 소프트웨어 설계의 총괄적인 부분이면서 세부 사항을 포함하고 있는 틀이라고 필자는 정의한다. http://www.ibm.com/developerworks/kr/library/feb06/eeles/index.html (설명이 부족하여 링크를 첨부 한다, 우선 아키텍처란 구조이며, 이 구조는 다른 구조와의 연결이고, 이 관계이다, 소프트웨어 아키텍처란 각각의 시스템이고 이 시스템의 연결관계.. 뭐 구조이다.. 사실 정확하게 아키텍처에 대해서 정의하기 보다는, 세부 설계를 하기전 전체적인 틀이라고 생각된다.) 프로그램 구조 수천 개의 세목들이나 수 십 개의 모듈로부터 그림을 그린다면, 힘들지만, 이런것을 전체적인 틀을 만들고, 연관을 생각하며 그린다면 보다 편할것이다. (물론 .. 이것도 ..
요구 분석은 문제 해결의 첫 번째 단계이고, 시스템 소프트웨어가 무엇을 요구하는지를 자세하게 설명하는 것이다. 왜 요구 분석을 정형화하는가? 1. 명확한 요구 분석은 명확한 프로그램을 만들수 있게 해주기 때문이다. 2. 논쟁을 피하는데 도움을 준다. (이 논쟁이 프로그래밍에 있어서 사소하다고 생각하면 나중에 상처입거나 입힐수 있다는 점이 떠오른다;;) 3. 요구 분석에 기울이면 개발을 시작한 이후에 시스템 수정을 최소화 하는데 도움을 준다. (이 부분도 막강하게 좋다, 초기 요구에 대해서 생각해두지 못하고 개발을 하게 되면, 나중에 요구가 생겼을때 힘들어지게 되었다.) 입증된 자료 대표적인 사례들을 예로 들며, 요구분석을 지나 아키텍처 단계에서 요구분석 에러가 발생되면 5배 정도의 비용 손해 코드 작성 ..
"컨스트럭션(구축, 설계, 이하 컨스트럭션으로 통일한다.)의 시작 전에 수행해야 할 첫 번째 필요조건은 시스템이 해결해야 할 문제를 확실히 정의하는 것" 이라고 필자는 설명한다. 이 책은 컨스트럭션에 관한 책이므로 문제 정의가 빠짐없이 모두 기술되어 있는지와 그 기술된 것들이 컨스트럭션의 기초가 되기에 충분한지 알려준다. 문제정의하는 방법으로는 1. 우리는 해외 주문은 수행할 수 없어요. 2. 우리는 해외 주문을 수행하기 위해서 자동화된 데이터 입력 시스템을 최적화할 필요가 있아요. 이렇게 두가 방법이 있는데, 필자는 1번째 방법으로 문제를 기술하라고 한다. 2번은 문제 해결책이기 때문이다. (해결책이 나쁘다는것이 아니라, 이 해결책은 컨스트럭션 단계이기 때문이다. 단계는 밑에 따로 쓰겠다.) 문제 정의..
필요조건이 왜 중요한가? 프로젝트 진행중, 질적 수준(어떤것에 대한 최적화)을 강조가 되는데, 이런 질적향상이 어느때 발생하는지에 따라서, 효율이 다르다고 필자는 설명한다. 프로젝트 마무리 단계에서 질적 수준을 강조한다면, 테스트에 중점을 두어야 하지만, 테스트는 잘못된 소프트웨어(원래의 목적)를 개발했을때는 문제를 찾아 낼수 없다고 설명한다. 이러한 테스트는 컨스트럭션(구축,설계)가 시작되기 전에 수행해야 한다고 설명한다. (이 부분은.. 매우 공감한다. 마무리 단계에서 테스트는 단지 버그가 있는지 없는지 밖에 파악을 못한다.) 이런 질적 향상을 하기 위해서는 필요조건을 충분히 만족시켜야 한다고 설명하고 있다. 그렇다면 불완전한 준비의 원인은 무엇일까? 가장 큰 이유는 개발기간에 있다고 필자는 설명한다..
최근댓글