Code Complete의 어떤 부분이 시간 테스트를 거치지 않았습니까? [닫은]

나는 선반에서 Code Complete를보고, "신화적인 남자의 달 밖에서, 이것은 시간의 시험을 견뎌 낼 수있는 대량의 소프트웨어 엔지니어링 서적 중 하나 일 수 있습니다." 이런 이유로, 나는 그것을 다시 읽기 위해 뛰어들 생각이다.

궁금합니다. 최근에 다른 사람이 다시 한 번 살펴 봤습니까? 그래서, 그가 매우 잘못한 것을 보았습니까?

이것은 공격이 아니며 책 검토 요청이 아닙니다. 몇 년 동안 어떤 아이디어가 바뀌 었는지 더 관심이 있습니다.

"Demarco / Spewak / Zachman은 시간의 시험을 견뎌냈습니다."

Code Complete는 다음과 같은 많은 영원한 개념을 다룹니다.

• 강한 응집력
• 느슨한 결합
• 좋은 일상적인 이름
• 방어 프로그래밍
• 자체 문서화 코드
• 소프트웨어 리뷰
• 단위 테스트

확실히 오늘 관련이 있습니다.

CC에서 채택 된 일부 개념은 이제 새로운 언어로 구문 적으로 적용됩니다. 예를 들어 C #에서는 하위 범위의 변수를 슈퍼 범위 정의를 숨기는 방식으로 정의 할 수 없습니다.

변수 이름에 대한 헝가리어 표기법과 같은 다른 개념은 주류 프로그래밍의 길가에 떨어졌습니다 (Win32 API로 여전히 작업하는 사람은 여전히 ​​살아 있고 잘 주장하고 있음). 그럼에도 불구하고 변수 명명 규칙의 진정한 개념은 필요한 의미를 전달하고 코드를 명확히하는 것입니다. 내가 주장 할 개념도 시대를 초월합니다.

모두 내가 기억할 수있는 것 (그리고 존경하는 CC 사본 내에서 살짝 엿봄)에서 나는 그것이 검토 할 가치가 있다고 말할 것입니다.

그러나 나는 그것이 신화 적 인 달의 진정한 영원한 시간으로 떠오르고 있다고 생각하지 않습니다. MMM은 누가 작업을 수행하는지, 어떻게, 왜 그들이 작업을 수행하는지에 대한 문제를 해결합니다. (인간) 커뮤니케이션의 비용과 복잡성. MMM은 우리가하는 모든 일에 근본적인 문제를 해결합니다. CC는 이와 비교하여 실용적이고 실용적인 문제에 중점을 둡니다. 달리 말하면, 프로젝트가 일정보다 늦어지고 관리자가 100 명을 팀에 추가하기로 결정하면 이해하기 쉬운 코드를 작성해도 실제로 차이는 없습니다.

CC는 실제로 업계를 괴롭히는 중요한 문제를 다루지 않습니다. 그러나 종종 불가능한 상황에서 최상의 결과를 얻기 위해 노력하는 좋은 기반을 제공합니다.

소프트웨어 개발에 관심이있는 사람에게는 반드시 읽어야 할 것이라 생각합니다. 새로 고침이 필요할 때마다 MM을 다시 읽는 것이 좋습니다. CC는 개발 팀을 이끌거나 그룹 표준을 설정하거나 새로운 개발자를 훈련시키는 경우 다시 읽을 가치가 있습니다. 그 외에는 개인적으로 오래전에 CC의 자료를 내재화하고 매일 연습하는 것을 발견했습니다.

희망이 도움이됩니다. 그들은 확실히 내가 좋아하는 두 가지입니다.

전반적으로이 책은 여전히 ​​좋습니다. 그러나 몇 가지 작은 문제가 있습니다.

• 17 장 ( "비정상적인 제어 구조")에서는 가드 문을 함수에서 일찍 반환한다고 언급하지만 "if"문에 대한 15 장의 예제 는 가드 문 에 대해 조언 합니다. (이 책에는 콜드 가드 조항 / 초기 반품)
• 14.2 절의 예는 그 자체와 모순되는 것으로 보인다. 먼저 "나쁜"코드의 예와 "좋은"코드를 만드는 방법을 제공합니다. 그런 다음 관련 문을 함께 그룹화 할 때 데이터 또는 작업 유사성에 따라 "양호"할 것이라고 말합니다. "나쁜"예제는 "좋은"것으로 간주되어야합니다. 그리고 모든 데이터가 같은 비율로 계산되기 때문에 "좋은"예제보다 훨씬 더 읽기 쉽습니다. .
• 23 장, 디버깅-글 머리 기호로 인쇄 명령문이 표시됩니다. 그것들이 유일한 툴이 아니어야한다는 데 동의하지만 버그가 발생하는 코드 범위를 줄이는 데 큰 도움이됩니다. 데이터가 갑자기 예상치 못한 위치를 파악하기 위해 몇 가지를 뿌려 작업하고있는 코드에 따라 디버깅을위한 좋은 출발점이됩니다.

함수 인수와 관련된 다른 것에 대한 모호한 기억이 있지만 현재는 찾을 수 없습니다. 다른 책이었을 수도 있습니다.