35장 더 많은 정보를 얻으려면 목차 35.1 소프트웨어 구현에 관한 정보 35.2 구현 외의 주제 35.3 정기 간행물 35.4 소프트웨어 개발자의 독서 계획 35.5 전문가 단체에 가입하기 이번 장에서는 도서와 간행물을 추천해준다. 내가 다음으로 읽을 책은 실용주의 프로그래머이다. 이 책에서도 추천해주었고, 몇 개월 전에 구매했는데 빨리 읽어보고 싶다. 내용만 932 페이지에 달하는 부분을 다 읽었다는 성취감이 정말 크다. 이 책의 내용중 10%도 제대로 이해한 것 같진 않지만 그래도 끈기 있게 주말마다 읽어온 나에게 칭찬을 해주고 싶다. 이 책을 읽으면서 내 개발 태도에 대해서 많이 반성하게 되었다. 증상만을 고치기 위한 프로그래밍을 해왔고, 가독성이라곤 1도 없었다. 그리고 설계라는 것을 할 생각..
개발 도서/Code Complete
34장 소프트웨어 장인정신에 대한 주제 목차 34.1 복잡성 정복 34.2 자신에게 맞는 프로세스 선택 34.3 컴퓨터보다 사람을 위한 프로그램을 작성하라 34.4 언어에 제약을 받지 않고 언어를 활용한 프로그래밍 34.5 규약을 활용하여 핵심에 집중 34.6 문제 중심의 프로그래밍 34.7 낙석을 주의하라 34.8 반복, 반복, 또 반복 34.9 소프트웨어와 신조를 떼어 놓아라 이번 장에서는 이 책 전체에서 다룬 내용을 조금 정리하는 느낌이 강했다. 이번 장을 읽으면서 지금까지 읽어왔던 부분을 되돌아보는 시간을 가지면 좋을 것 같다. 34.1 복잡성 정복 규약을 정하는 것과 추상화는 복잡성을 관리하는 강력한 도구이다. 34.2 자신에게 맞는 프로세스 선택 혼자서 일하는 것이 아니라면 좋은 프로세스가 높..
33장 개발자의 성격 목차 33.1 성격은 주제를 벗어난 것 아닌가? 33.2 지성과 겸손 33.3 호기심 33.4 지적인 정직함 33.5 의사소통과 협동 33.6 창의성과 훈련 33.7 게으름 33.8 덜 중요한 특성 33.9 습관 소프트웨어 개발에서 성격이 영향이 줄까? 여기서 말하는 성격은 외향적이거나 내향적인 성격이 아니라, 어떤 자세를 갖는가에 대한 내용인 것 같다. 첫 번째 질문이 바로 다음 장에서 나온다. 33.1 성격은 주제를 벗어난 것 아닌가? 프로그래밍의 내적 탐구에서 있어서 개인의 성격이 특히 중요하다. 일단 뛰어난 개발자가 되기로 결정했다면 발전 가능성은 어마어마하다. 프로그램을 작성하는데 드는 시간이 10에서 1 까지의 차이가 있고, 프로그램을 디버깅하는 데 드는 시간과 프로그램의..
32장 스스로를 설명하는 코드 목차 32.1 외부 문서 32.2 문서화를 위한 프로그래밍 스타일 32.3 주석을 작성할 것인가? 작성하지 않을 것인가? 32.4 효과적인 주석을 위한 핵심 사항 32.5 주석 스타일 32.6 IEEE 표준 이번 장에서는 좋은 주석은 어떤 것인지에 대해 다룬다. 나는 주석은 무조건 좋은 것이라 생각했는데 역시 나의 짧은 생각이었다. 주석이 불필요하다는 주장 역시 흥미로웠고, 나는 그동안 코드를 반복하는 주석을 단 것이 아닌지에 대해 생각해보게 되었다. 32.1 외부 문서 단위 개발 일지(Unit Development Folders): 개발자가 구현 중에 사용했던 기록이 담겨있는 비공식적인 문서 상세 설계 문서: 하위 수준의 설계 문서로 클래스 수준 또는 루틴 수준의 설계 시..
31장 레이아웃과 스타일 목차 31.1 레이아웃 기초 지식 31.2 레이아웃 기법 31.3 레이아웃 스타일 31.4 제어 구조 레이아웃 31.5 개별 명령문 레이아웃 31.6 주석 레이아웃 31.7 루틴 레이아웃 31.8 클래스 레이아웃 이번 장에서는 좋은 레이아웃에 대해 다룬다. 사실 대부분의 코드 편집기에서 자동으로 지원하는 것이 대부분이었다. 상당히 많은 페이지에 설명되어 있는 부분이 VSCode의 beautify를 사용하면 자동으로 적용되어지는 부분이었다. 그래서 이번 장에서는 한 장씩 설명하는 대신 전체적인 내용을 요약하는 식으로 글을 적어보려 한다. 좋은 레이아웃 좋은 레이아웃 구조는 아래와 같다. function getMessage( id ) { let message = 'hello'; ....
30장 프로그래밍 도구 목차 30.1 설계 도구 30.2 소스코드 도구 30.3 실행 가능한 코드 도구 30.4 도구 지향적인 환경 30.5 자신만의 프로그래밍 도구 개발 30.6 도구에 대한 환상 최신 프로그래밍 도구는 개발 시간을 줄여준다. 최첨단 도구를 사용하고 그 도구에 익숙해지면 생산성을 50% 이상 향상시킬 수 있다. 또한 프로그래밍 도구는 프로그래밍에 필요한 지루하고 세세한 작업을 줄여준다. 30.1 설계 도구 설계 도구는 대부분 그래픽 도구들이다. 클래스 다이어그램이나 시퀀스 다이어그램을 그리게 도와준다. 일반 그래픽 도구와 차별되는 점은 정렬을 하거나, 한 클래스를 삭제할 경우 연결된 선들이 지워지는 기능이 있는 것이다. 나도 소프트웨어 공학 개론 강의를 들으면서 "starUML"이라는 ..
29장 통합 목차 29.1 통합 접근 방법의 중요성 29.2 통합 빈도-단계별 또는 점증적 접근 방법 29.3 점증적 통합 전략 29.4 일일 빌드와 스모크 테스트 "통합"이라는 용어는 개별적인 소프트웨어 컴포넌트를 하나의 시스템으로 결합하는 소프트웨어 개발 행위를 말한다. 이번 통합에서는 학부 과정 중 "소프트웨어 공학 개론" 과목에서 배운 내용들이 많이 있어서 뭔가 익숙한 느낌이었다. 여러 개의 분할 된 기능 또는 클래스들은 결국 마지막에 하나로 합쳐져야 하는데 어떻게 효율적으로 이를 하나로 만들 수 있을지에 대한 내용을 다룬다. 29.1 통합 접근 방법의 중요성 이 책에서는 워싱턴 대학교 축구장 건립 예제가 사용되었다. 축구장을 짓던 중 축구장이 무너지는 사고가 발생했는데, 축구장이 완성된 후 얼마..
28장 구현 관리 목차 28.1 훌륭한 코딩 장려 28.2 형상 관리 28.3 구현 일정 예측 28.4 측정 28.5 개발자를 사람으로 대우하기 28.6 관리자 관리 28.1 훌륭한 코딩 장려 프로그래밍 표준을 정할 때는 관리자보다 훌륭한 아키텍트가 정하는게 좋다. 아키텍트가 존경받는 위치에 있다면, 개발자들은 표준을 믿고 따를 것이다. 좋은 코딩을 장려하는 기법 프로젝트의 모든 영역에 두 사람을 할당하라. 모든 코드를 검토하라. 코드에 서명하라. 검토를 위해 좋은 예제 코드를 돌려보라. 코드가 공용 자산이라는 것을 강조하라. 좋은 개발 방식에 대해 보상을 하라. 28.2 형상 관리 형상 관리는 시간이 지나면서 시스템이 무결성을 유지할 수 있도록 체계적으로 프로젝트의 부산물을 파악하고 변화를 처리하기 위..
27장 프로그램의 크기가 구현에 미치는 영향 목차 27.1 의사소통과 크기 27.2 프로젝트 크기의 범위 27.3 프로젝트의 크기가 오류에 미치는 영향 27.4 프로젝트의 크기가 생산성에 미치는 영향 27.5 프로젝트의 크기가 개발 활동에 미치는 영향 27.1 의사소통과 크기 팀원의 수가 많아질 수록 의사소통 경로는 이에 제곱에 비례해 증가한다. 팀원이 2명일 경우 의사소통 경로는 1개 뿐이지만, 3명일 경우 3개, 4명일 경우 6개, 5명일 경우 10개와 같이 기하급수적으로 증가하게 된다. 의사소통 경로가 많아질수록 의사소통에서 문제가 발생할 가능성이 커진다. 많은 팀원들간의 효과적인 의사소통을 하기 위해서 보통 문서를 통해 의사소통을 한다. 말하고 싶은 사람이 문서를 쓰고, 다른 팀원들이 이를 읽는 ..
26장 코드 튜닝 기법 목차 26.1 논리 구조 26.2 반복문 26.3 데이터 변환 26.4 표현식 26.5 루틴 26.6 저급 언어를 이용한 재구성 26.7 변경이 많을수록 상태는 그대로 이번 장에서는 이전 장에서 설명했던 코드 튜닝 방법에 대해 쓰여있으나, 반드시 명심해야 할 점은 코드를 튜닝함에 있어서, 성능 테스트는 필수라는 점이다. 당연히 성능이 좋아질 것이라 예상한 코드가, 성능도 떨어지고 가독성도 떨어지는 코드가 될 수도 있기 때문이다. 특히, 코드 튜닝은 가독성을 크게 떨어뜨리기 때문에, 이후 유지보수가 어려워진다. 좋은 코드를 버리고, 성능을 높일 필요가 충분한지 우선 확인하는 과정이 필수이다. 26.1 논리 구조 프로그래밍 언어에 따라 if-then-else와 switch문의 성능에 ..
