1장 시작하기 전에
코딩 스타일이란 무엇인가
코딩 스타일에 대한 교육이 부족하다
코딩 스타일을 익혀야 할 시기
코딩 스타일을 왜 배워야 하나
코딩 스타일은 수학이나 영어보다 더 중요하다
모든 언어에 코딩 스타일이 필요하다
C 언어로 코딩 스타일을 설명하는 이유
코딩 스타일은 컴파일 방식과 하이브리드 방식에 유용하다
컴포넌트 기반 개발 방식과 코딩 스타일
2장 프로그램 설계 시에 알아야 할 좋은 코딩 스타일
최신 표준을 따르라
개발 인원을 적정한 규모로 한정하라
프로그램을 새로 만드는 것보다 유지보수하는 경우가 많다
프로그램을 쉽게 수정할 수 있다는 생각을 버려라
새로운 기법을 도입할 때는 신중히 하라
'Run and Fix' 전략을 피하라
3장 띄어쓸 때 좋은 코딩 스타일
한 줄에 한 문장만 써라
선언문과 실행문을 구분하라
단락을 구분하라
제어문들 사이를 구분라라
함수들 사이를 구분하라
연산자의 앞뒤로 빈 칸을 두라
단항 연산자를 피연산자에서 띄어쓰지 마라
4장 들여쓸 때 좋은 코딩 스타일
중괄호의 위치
중괄호의 위치를 통일시켜라
내부 블록은 들여써라
피제어부를 들여써라
쓸데없는 들여쓰기를 하지 마라
5장 주석을 작성할 때 좋은 코딩 스타일
다양한 주석의 형태
한 줄 주석과 상자 주석을 구분하라
변수 사전 작성용 주석을 달아라
의사 코드를 프로그램에 기입하라
프로그램의 목적을 주석으로 달아라
프로그램의 앞부분에 머리 주석을 꼭 달아라
6장 식별자 이름을 지을 때 좋은 코딩 스타일 Ⅰ
변수 이름을 체계적으로 지어라
헝가리안 표기법으로 변수 이름을 지어라
변수의 자료형을 변수 이름에 접두사로 표기하라
기억 영역 계층을 접두사로 활용하라
함수의 역할을 접두사로 활용하라
자신만의 접두사를 만들어 활용하라
7장 식별자 이름을 지을 때 좋은 코딩 스타일 Ⅱ
이름을 의미 있게 지어라
비슷한 변수 이름을 사용하지 마라
의미를 잃지 않는 범위에서 짧게 지어라
이름이 길면 밑줄 또는 대소문자로 구분하라
변수 이름을 밑줄로 시작하지 마라
밑줄을 과도하게 사용하지 마라
대소문자를 적절히 배합해서 만들어라
C 언어가 대소문자를 구분한다는 것을 악용하지 마라
8장 연산자를 사용할 때 좋은 코딩 스타일
조건 연산자가 경우에 따라서 효율성을 발휘한다
연산자의 우선순위에 의존하는 식을 만들지 마라
포인터 연산자를 변수 이름쪽에 붙여서 써라
시프트 연산 대신 산술 연산을 사용하라
극단적으로 효율성을 추구하지 마라
9장 명료한 프로그램을 만들기 위한 좋은 코딩 스타일
약삭빠른 코드 대신에 명료하고 이해하기 쉬운 프로그램을 작성하라
while 문에서 관계/대입 연산자의 우선순위를 혼동하지 마라
묵시적인 'non zero test'를 하지 마라
조건식에 대입문을 사용하지 마라
부작용이 나타나지 않도록 주의하라
함수의 원형에도 인수의 자료형을 표시하라
가인수에도 이름을 기입하라
반환 자료형을 반드시 표시하라
결과값에 주의하라
10장 이식하기 쉬운 프로그램을 만들기 위한 좋은 코딩 스타일
파일 이름의 길이를 14자로 제한하라
파일 이름에 특수 문자를 사용하지 마라
조건부 컴파일을 활용하여 이식성을 높여라
컴파일러의 한계를 인식하라
자료형의 크기가 달라질 수 있다는 점을 고려하라
절대 경로를 지정하지 마라
11장 정밀한 프로그램을 만들기 위한 좋은 코딩 스타일
컴퓨터는 생각보다 정밀하지 않다
정밀한 계산이 필요하다면 부동 소수점 연산을 피하라
정밀한 계산에는 float형보다 double형을 쓰라
정수형의 크기를 확인하라
계산 단위를 반드시 명시하라
나눗셈 연산에는 주의를 기울여라
자료형의 변환이 이루어지지 않도록 하라
12장 성능 향상을 위한 좋은 코딩 스타일
성능이 중요하다면 될 수 있는 한 출력하지 마라
연산을 단순한 형태로 바꿔라
효율성이 요구되는 큰 파일을 다룰 때는 바이너리 파일을 사용하라
팩키드 구조체와 언팩키드 구조체의 장단점을 인식하고 사용하라
실행 환경을 고려하여 언어를 선택하라
13장 이해하기 쉬운 프로그램을 만들기 위한 좋은 코딩 스타일
goto 문을 사용하지 마라
C의 구성 요소를 선행처리기로 치환하지 마라
긴 자료형은 짧은 이름으로 바꾸어 사용하라
조건식보다는 if 문을 사용하라
배열의 차원을 3차원으로 한정하라
14장 사용자 인터페이스를 처리할 때의 좋은 코딩 스타일
입력 값을 저장할 변수의 크기를 충분히 확보하라
변환 지정자와 매개변수의 개수를 일치시켜라
scanf() 함수보다는 fgets()와 sscanf() 함수를 사용하라
fflush() 함수를 사용해 표준 입출력 장치의 버퍼를 비워라
15장 오류 없는 프로그램을 만들기 위한 좋은 코딩 스타일
배열의 첨자는 0부터 시작한다는 것을 잊지 마라
치환 문자열을 반드시 괄호로 씌워라
파일을 열었다면 반드시 닫아라
컴파일러의 경고(warning error)를 무시하지 마라
런타임 에러를 인식하고, 그것이 발생하지 않도록 코드를 작성하라
배열이 큰 경우에는 정적 변수로 선언하라
부록: 참고할 만한 웹 페이지들과 검색 방법
참고 문헌
코딩스타일의 중요성에 대해서 설명하고 어떻게 코딩스타일을 만들어야 좋은지 여러가지 방법과 이유를 알려준다.
대게 오픈소스를 많이 보거나 본인이 짠 소스 코드를 깔끔하게 정리하는 습관을 가지신 분들
그리고 개발자 관련 도서를 많이 보신 분들은 책의 예제를 통해서 많이 접하셨을 듯한 내용입니다.
대게 API 책들이나 MFC책들 그리고 프로그래밍 언어 책들을 보면서 간간히 언급되는 부분들을
모두 모아놓은 책이라고 보시면 됩니다. 책도 그다지 두껍지 않고 사설도 별로 없이 빠른 속도로 읽어나갈 수 있습니다.
1장. 개발자의 다음 단계
프로그래머의 소망
시스템 전체를 바라보는 재미
프로젝트에서 아키텍트의 역할
아키텍트와 다른 업무 담당자의 관계
아키텍트의 주요 업무
10년 후에도 기술자로 활약하기 위해
2장. 요구사항 정의에 참여
요구사항 정의에 대한 기술적 지원
아키텍트의 요구분석 단계 업무
사용자 중심의 명세 설계
플랫폼 선정의 현실
팀원을 고려하여 개발 계획을 세운다
아키텍트가 있다면 당연히 순조롭게 진행되는가?
3장. 아키텍처 설계
아키텍처는 초기에 설계한다
아키텍처는 요구사항에서 만들어진다
기술 문제를 정리하자
항상 누가 아키텍처 설계서를 읽을지 고려한다
아키텍처 설계서를 써 본다
앞으로 어떤 작업이 이루어질지를 그려낸다
개요를 확실히 이해해야 한다
기술 요소를 정확하게 설명한다
막히기 쉬운 부분은 상세하게 설명해 놓는다
의도를 전달하는 것이 중요하다
4장. 프레임워크를 준비한다
소프트웨어에 요구되는 품질
아키텍처를 프로젝트 팀에 침투시킨다
개발팀 킥 오프
아키텍트는 기술과 사람의 중개자
프레임워크를 준비하자
팀원들의 의견을 이끌어내다
적절한 리뷰로 설계를 제어한다
칼럼: 프레임워크로 편안하고 간단하게 개발한다
프레임워크는 아키텍처의 구체적인 실체
할리우드의 법칙
프로젝트의 프레임워크
프레임워크를 이용할 때의 장점과 단점
5장. 말썽 많은 프로젝트 되살리기
전화 벨소리
문제는 어디에 있는가?
문제는 아키텍처에도 있다
아키텍처에서 해결할 수 있는 부분을 확인한다
6장. 테스트를 즐기자
개발자와 테스트 담당자 사이의 깊은 골
빈틈없는 테스트로 품질을 향상시키는 것은 불가능하다
TDD로 공격적인 테스트를 한다
단위 테스트
테스트하기 쉬운 아키텍처
아키텍트의 도움이 필요한 테스트
다양한 테스트 방법을 이해하자
7장. 개발 현장 밖에서 활약한다
문제를 해결하기 위해 필요한 기술
기술로 이해할 수 없는 것들
비기술자가 기술적인 결정을 내린다
위험요소를 줄이기 위해
일의 영역을 넓혀 보자
어떤 시스템을 만들어야 하는가?
아키텍트에게 요구되는 것
기술을 몸에 익히기 위해
8장. 애자일 프로젝트의 아키텍트
뛰면서 생각한다
문서를 버리고 사람과 대화한다
사전 설계는 손해다
점진적인 설계
사전에 설계해야 하는 경우도 있다
프레임워크는 나중에 추출한다
Architectus Oryzus와 Architectus Reloadus
9장. 아키텍트가 되고 싶다!
해커와 아키텍트
아키텍트가 왜 돌파구인가?
비즈니스 애플리케이션 개발은 사회 활동
프로 개발자
프로그래머로서 코딩 이외에 자신이 앞으로 경력을 쌓아가면서 변신해야할 기회가 생긴다.
누군가는 프로그래머를 그만두고 다른 업종을 하겠지만 누군가는 프로젝트 관리자로 또 누군가는 기획자로
등등 여러 부분으로 갈라져 나간다.
이 책에서 소개하는 아키텍트는 프로젝트 설계와 프로그램 개발을 동시에 수행하며
다른 사람들보다 깊고 넒은 안목을 가지며 프로젝트의 뼈대를 다지는 직종을 말한다.
대게 한국에서는 보기 힘든 명함이지만 외국 IT서적들을 살펴보면 IBM 수석아키텍트 등의
아키텍트 관련 직함을 볼 수 있다. 한국에서 이러한 명함을 보기 힘든 이유는 IT의 시작이 외국보다
늦은 감도 있지만 정확히 말하자면 아키텍트가 필요할 만한 프로젝트가 적었거나 아키텍트가 없어도
주먹구구식으로 프로젝트를 개발해 왔다는 것이다. 특히 한국은 프로젝트 실패율이 거의 없다시피 할 정도로
무조건 돌아가기만 하면 프로젝트는 장떙이다 라는 식이다. 이는 사업자 논리나 사용자의 입장에서는
큰 문제가 없어 보이지만 정작 직접 개발한 개발자나 IT관련 업계 사람들이 보기에는 눈살을 찌푸리게 된다.
물론 책에나 나올법처럼 모든것이 완벽한 프로젝트는 없지만 적어도 퀄리티라는 개념을 유지할 정도의 프로젝트는
유지해야 한다는 개인적인 생각이다. 이 책에서는 성공하는 프로젝트와 바로 앞에서 언급한 퀄리티 면에서
적절한 조율을 할 수 있는 위치, 아키텍트에 대하여 알려주고 어떠한 일들을 하는지 예를 들어 자세히 설명하고 있다.
개발자로서 경력이 쌓일 어느 시점에서는 무엇을 하던 결정을 내려야 한다. 그 결정을 내릴 당시 자신이 어떤
자기개발을 해왔느냐에 따라 더 높은 곳으로 갈 수도 있고 더이상 가지 못하고 그만두어야 할 때도 생길 것이다.
다만 이 책의 도움은 아키텍트라는 부분이 있음을 알 수 있게 하고 이를 위해 어떤 방향으로 경력개발을 해야 하는지
