Code Completeのどの部分が時の試練に耐えていませんか？[閉まっている]

「神話の月の外で、これは時の試練に耐える数少ない大衆市場ソフトウェア工学の本の一つかもしれない」と考えて、私は棚の上のCode Completeを見ていました。この理由で、私はそれを読み直すために飛び込むことを考えています。

私は興味があります-他の誰かが最近それを再確認しましたか？私は、彼が非常に間違っていることを見ましたか？

これは攻撃ではなく、書評の依頼でもありません。長年にわたってどのアイデアが変わったかにもっと興味があります。

そして、どうぞ-「Demarco / Spewak / Zachmanは時の試練に耐えました...」についてのコメントはありません。私はCode Completeに特に興味があります。

Code Completeは、次のような多くの時代を超越した概念をカバーしています。

• 強い結束
• 疎結合
• 良いルーチン名
• 防衛的プログラミング
• 自己文書化コード
• ソフトウェアレビュー
• 単体テスト

確かに今日関連しています。

CCで支持されている概念の一部は、新しい言語で構文的に実施されています。たとえば、C＃では、サブスコープの変数をスーパースコープの定義を隠す方法で定義できません。

変数名のハンガリー語表記などのその他の概念は、メインストリームプログラミングの途中で落ちています（ただし、Win32 APIをまだ使用している人は、変数が生きていることを強く主張します）。それでも、変数の命名規則の背後にある本当の概念は、必要な意味を伝え、コードを明確にすることです。私が主張する概念も時代を超越しています。

私が思い出すことができるものから（そして私のCCの由緒あるコピーの簡単な覗き見から）、私はそれが確かにレビューする価値があると言うでしょう。

しかし、「神話の男月」の真に時代を超越した性質に上昇するとは思わない。MMMは、誰が作業を行っているのか、どのように、なぜ作業を行っているのかという問題に対処しています。（人間の）コミュニケーションのコストと複雑さも同様です。MMMは、私たちが行うすべての基本である問題に対処します。それに対して、CCは、私たちがそれを行う方法の実際的かつ実用的な問題に焦点を当てています。別の言い方をすれば、プロジェクトが予定より遅れており、マネージャーがチームに100人を追加することを決めた場合、わかりやすいコードを書いても実際には違いはありません。

CCは、私たちの業界を悩ませている重要な問題に実際には対処していません。しかし、多くの場合不可能な状況で最良の結果を得るために努力するための良い基盤を提供します。

ソフトウェア開発を気にする人には必ず読む必要があると思います。復習が必要な場合は、MMを再読することをお勧めします。開発チームを率いたり、グループの標準を設定したり、新しい開発者をトレーニングしたりする場合は、CCを読み直す価値があります。それ以外では、個人的にはずっと前に資料をCCに内面化し、日常的に実践していることがわかりました。

それが役に立てば幸いです。確かに私のお気に入りの2つです。

全体的に、本はまだ良いです。ただし、いくつかの小さな問題があります。

• 第17章（「異常な制御構造」）では、ガードステートメントが関数から早期に戻ることについて言及していますが、「if」ステートメントに関する第15章で与えられている例は、ガードステートメントに対するアドバイスです。（ガード条項/本の早期返還と呼ばれる）
• セクション14.2の例は、矛盾しているようです。最初に「悪い」コードの例と、それを「良い」ようにする方法を示します。次に、関連するステートメントをグループ化する場合、データまたはタスクの類似性のいずれかで「良好」になると述べています。「悪い」例も「良い」と見なされるべきです-そして、すべてのデータが同じレートで計算されているため、「良い」例よりもはるかに読みやすいと思います-頭の中に保持する状態が少ない。
• 第23章「デバッグ」。印刷ステートメントは箇条書きで説明されています。これらが唯一のツールであってはならないことに同意しますが、バグが発生するコードの範囲を減らすのに非常に役立ちます。全体にいくつかを振りかけて、データが突然予期したものではない場所を確認し、作業しているコードに応じて、デバッグの開始点として適切です。

関数の引数を含む別の漠然とした記憶がありますが、現時点では見つかりません。別の本だったかもしれません。