[독서] 코드 컴플리트
매일 그래도 꾸준하게 읽으려고 생각을 했었는데 산 이후로 많이 읽지 못해서 아직 70페이지까지 밖에 읽지 못했다.
읽은 부분마다 중요하다고 생각한 것이나 강조하는 것에 대해서 내 생각을 좀 써보려고 한다.
읽은 날짜 : 11월 25일 50p~74p
3장에서는 선행 조건에 대해 강조하며 설명한다.
"Code Complete 2"는 코드를 작성하기 전에 수행하는 선행 조건이 프로젝트의 성공 여부를 결정짓는다고 강조한다.
건물을 지을 때 설계와 기초가 중요하듯, 소프트웨어도 요구사항과 설계 단계에서 모든 것이 정해진다는 것이 핵심이다.
만약 초기에 잘못된 요구사항으로 시작하면, 이후의 개발 과정은 반복된 수정과 손실로 이어질 수밖에 없다고 설명한다.
마치 좋은 음식을 만들기 위해서는 신선한 재료가 필요하듯, 소프트웨어 개발도 초기 요구사항이 명확하고 정확해야 한다고 강조한다.
초기 요구사항이 부정확하면 프로젝트는 여러 번 수정되거나 실패할 가능성이 커진다.
나는 책에서 말하는 '선행 조건'의 중요성을 몰랐지만 선행 조건을 건축 또는 자동차와 비유하며 설명해주어 선행 조건이 굉장히 영향력이 있있을 수 있다는 것에 공감을 한 것같다.
따라서 개발을 할 때 초기 요구사항을 제대로 파악하지 않으면, 이후에 아무리 완벽한 코드를 작성해도 큰 손실이 발생할 수 있기에
저도 프로젝트 초반에 기획을 철저히 해야겠다는 생각이 들었다.
오염된 요구사항이 결국 소프트웨어 전체를 망친다는 비유가 있었다.
이는 마치 오염된 물이 먹이사슬을 타고 올라가 최종 소비자에게 치명적인 영향을 미치는 과정과 같다.
물속 곤충이 핵폐기물에 노출되고, 이를 먹는 청어는 PCB에 오염되며, 청어를 먹는 연어는 석유에 노출된 상태로 바다를 헤엄친다.
최종적으로, 갈매기는 이 모든 오염물을 섭취하게 된다.
프로그래밍에서도 요구사항이 잘못되면 아키텍처, 설계, 구현이 연쇄적으로 오염되어, 결국 결점 투성이의 소프트웨어가 만들어지는 것이다.
또한 3장에서는 소프트웨어 특성상 반복적인 방법이 순차적인 방법보다 훨씬 유용하다고 한다. 비용과 연관지어 설명해 주었는데 재작업을 할 때 순차적인 방법은 전체를 다시 재작업 해야하지만 반복적인 방법으로 개발을 진행을 할 때 재작업을 하더라도 작은 단위이기 때문에
전체적인 총액은 결국 반복적인 작업으로 진행을 할 때 더 효율적이라고 말을 한다.
순차적인 방법 (Sequential Approach)
이 방법은 순서대로 단계를 한 번에 끝내는 방식이다. 흔히 폭포수 모델(Waterfall Model)로 알려져 있다.
- 단계적 진행: 요구사항 → 설계 → 구현 → 테스트 → 배포
- 각 단계를 완료한 후에야 다음 단계로 넘어간다.
- 이전 단계로 되돌아가는 일이 거의 없다.
- 예시: 프로젝트 요구사항을 모두 문서로 정리한 후 설계하고, 설계가 완료되면 구현하고, 구현 후 테스트하고 배포한다.
특징:
- 명확한 구조로 계획이 쉬운 편이다.
- 변경이 어렵고 초기 실수가 치명적일 수 있다.
반복적인 방법 (Iterative Approach)
반복적인 방법은 한 번에 모든 걸 끝내지 않고 여러 번의 작은 사이클로 개발을 반복하는 방식이다. 애자일(Agile), 스프린트(Sprint) 개념과 유사하다.
- 작은 단위로 개발하고 피드백을 반영해 개선한다.
- 각 반복(iteration)마다 요구사항을 검토하고 코드와 설계를 수정한다.
- 점진적 개선을 통해 점점 완성도를 높인다.
- 예시: 기본적인 기능을 먼저 구현하고, 테스트와 피드백을 통해 개선한 후, 새 기능을 추가하고 또 반복한다.
특징:
- 유연하고 변경에 빠르게 대응할 수 있다.
- 작은 실패를 통해 점차 더 나은 결과로 발전할 수 있다.
계산기 예시에서는, 개발자적인 생각을 벗어난다는 의미는 개발자가 문제를 해결할 때 종종 지나치게 자동화나 복잡한 알고리즘을 고민하는 경향이 있다는 점을 말한다. 예를 들어, 간단한 계산을 할 때도 새로운 프로그램을 작성하거나 복잡한 코드로 해결하려 할 수 있다. 하지만 이 경우:
- 단순한 방법이 더 효율적이라는 점을 강조한다.
- 새로운 코드를 작성할 필요 없이, 계산기와 간단한 수작업으로도 충분히 빠르고 정확한 결과를 얻을 수 있다.
핵심: 문제를 해결할 때 항상 복잡한 프로그래밍이 필요한 것은 아니다. 오히려 가장 단순하고 효율적인 방법이 무엇인지 생각하는 것이 중요하다.
"Code Complete 2"를 읽으면서, 소프트웨어 개발의 성공은 초기 단계에서 결정된다는 것을 다시금 깨달았다.
저자는 소프트웨어를 건축에 비유하며, 건물을 지을 때 기초가 중요하듯이 소프트웨어도 요구사항 분석과 설계가 중요하다고 설명한다.
특히, 책에서 언급된 "오염된 요구사항이 결국 소프트웨어 전체를 망친다"는 비유가 인상 깊었다. 마치 오염된 물에서 시작된 문제가 먹이사슬을 타고 올라가 최종 소비자에게 큰 영향을 미치는 것처럼, 초기 요구사항이 잘못되면 후속 과정에서 큰 문제가 될 수 있다는 것이다.
"선행 조건이 잘못되었을 때 구현 과정에서 할 수 있는 것은 손해를 최소화하는 것뿐이다"는 문장은 앞으로 프로젝트 초기 단계에 더욱 집중해야겠다는 교훈을 주었다.