感情タグBEST3
Posted by ブクログ
# 1周目 読み終えた
タイトルである「CODE COMPLETE」からは、どうやって優れたコードを書くかに書かれた本であるかのような印象を与えられる。それに間違いはないけど、こういうところこうかくべきとか、直接的な指示を与えるようなものではない。最終的には品質の高いソフトウェア、すなわちコードを生み出すのが目的となる。それには、単にプログラミング言語のルールを覚えて、盲目的にコードを書けばいいというわけではない。最終的なコードに至るまでの道のりは、思っている以上に長い。この本は、それらを体系的にまとめてあって、信頼できるガイドラインとして利用できる。読み終えて、コードに対して違った見方をするようになったかもしれない。大きな組織で大人数で開発する場合でも、小さな組織で少人数で開発する場合でも、一人で開発する場合であっても、役に立ちそうなことが書かれていた。
## 35章を読んだ
「さらに情報を得るには」
参考文献、というか、参考程度ではなく、読むべきであるという推奨文献の紹介になっている。著者の会社では、開発者の段階によって読まないといけないものが読書計画として組み込まれているらしい。初級、実践、プロフェッショナルという段階になっていて、この本は初級に位置している。
この本で利用された本当の意味での参考文献は、最後にリストとして大量に掲載されている。読者を誘導するためというより、情報の正確さを裏付けるためのものではあるだろうが、情報源の広さに驚かされる。
## 34章を読んだ
「ソフトウェア職人気質とは」
実質最後の章となる。これまでの長い旅の総まとめみたいな内容になっている。これから先、読み直したいけど時間がないというときは、この章をまず読むと良さそうだ。
プログラミングは芸術か科学かという問が上巻の最初の方にあった。ここで、完全な芸術でも科学でもなく、どちらにも分類されない職人技だと答えを出している。そうしたラベル付がさして重要なわけではないが、芸術家気分で、芸術作品を作るほどには独創的にはいられないし、科学者気分で、厳密な実験と検証のプロセスによってプログラミングをすることもできないことを考えれば、職人技に分類するのは的を得ている。どちらにせよ、プログラミングはプログラミングであって、どのような職人仕事とも違っている。別のところから、そのまんま仕事の鉄則を持ってくることなどできない。しかし、職人気質というと根本的なところで、何か共通するものがあると思わされる。
## 33章を読んだ
「個人の資質」
ただ資質といわれてもよくわからない。才能と混同してはいけないようだ。才能と資質はあまり関係が内容で、才能は重要ではない。自分に才能があると思い込んでいるようなのは、そこら中にありふれている。そして、たいていそれらの資質はひどいように思う。謙虚さや知的な誠実さが完全に欠けてているからだと、そういうことだと思う。自分はどうなのかというと、控えめに言っても才能も資質もなく、正式な教育を受けたわけでもなく、適正が高いとは言い難い。それでも、好き好んで楽しくソフトウェアに関わっているのだから、別にいいかと思う。
プログラマーの3大美徳という名称で、傲慢、怠惰、短気というのが知られている。謙虚さや知的な誠実さに一見相反するようにも思える。しかし、それほど相性が悪いものではないように思える。本当にだめなのは、奮闘や努力のようなものらしい。
この章は、自己啓発的な内容で、ちょっと戸惑う部分があった。普段、自己啓発など全くしないし、そのような本を読む機会がない。読みたいとも思わない。それじゃだめだということで、もし必要であるなら、この章をベースにしとくのが良さそうだ。
## 32章を読んだ
「読めば分かるコード」
コメントの書き方を中心に議論されている。ここまで徹底的にやっているのを他に見つけるのは難しいだろう。悪いコードをコメントで説明するな、コードを直せというのが基本になる。ただし、これはコメントを全く書かないでも良いということを意味するのではない。単純なget/set以外のルーチンには、その簡単な概要をつけるべきとある。ファイル、クラスなども同じで、全体像を把握するのに役立つ概要を添えるべきとなっている。コメントは多すぎても少なすぎても逆効果になりうる。常識的な範囲でやれば良いようだけど、常識というのは人によって異なるところもあり、あまり当てにならない。この章はそのガイドラインとなるだろう。
最近Pythonを少し書いているのだけど、テキストエディタにflake8というコードを検査するツール、要はLintみたいなのが統合されている。それによって、すべてのファイル、クラス、メソッドにdocstringという文書化されるコメントのようなものを記述することが要供される。エラーになるわけではないけど、書かないとその場所がハイライトされて見苦しいので、無視するのは得ではない。鬱陶しいと思わずに、良いコメントを書く練習にすると良いかもしれない。
## 31章を読んだ
「レイアウトとスタイル」
レイアウトとスタイルとは、代表的なのはインデントをどうするかとか、空白文字をどこに入れるかとか、ブロックの始まりと終わりのカッコをどこに置くかとか、そういう厄介な話。ほとんどは美的感覚や、よく見かけるコードをお手本として経験を積んでいくうちに形成される嗜好と、それほどかけ離れたものは推奨されていない。加えて、単に好みや感覚からだけ良い悪いを判断するのでなく、きっちりとなぜ良いのか、悪いのかの理由が示されている。C++のレイアウトスタイルは、開発者によってかなりばらつきがある。別々の個人やプロジェクトが、全く同じレイアウトとスタイルになっているもののほうが稀だろう。clang-formatのような整形ツールでも、細部まで細かく調整できるようになっていることからも、細部までこだわるプログラマの習性が反映されている。何も考えずにGoogleスタイルを選択するケースのほうがまれかもしれない。
この章では、きっちり理由をしめして、いくつかのスタイルを推奨している。しかし、全部に賛同できるような人はまれだろう。最初に「ここでは読者の同意をえることよりも、フォーマットスタイルの問題について検討してもらうことに重点をおいている。」と書かれている。今、自分が採用しているスタイルが本当に優れているのか意識しておくきっかけになれば良い。ある種の原則のようなものを確立して、それに一貫して従うことの方がずっと重要になる。
## 30章を読んだ
「プログラミングツール」
これまでとちょっと毛色が違う章で、話題が順に展開されていくのではなく、箇条書き的に各ツールが担当する役割を紹介していっている。具体的な製品名は挙げられていない。
あまり、あるいは全く馴染みのないもの：
設計ツール
テンプレート
相互参照ツール
測定結果を報告するツール
再構築ツール
コード翻訳ツール
データディクショナリ
コード生成ウィザード
テストツールにリストアップされているうちの多く
実行プロファイラ
最後に、画期的なツールの登場によってプログラミングが不要になるかという点にかかれている。最初にそのようなことが言われたのはFORTRANの登場で、FORTRANによってプログラマが不要になって、科学者やエンジニアが自由にプログラムを書けるようになるといわれていたらしい。実際にはそうはなっていない。現代ではAIがプログラミングを不要にするかどうかという面白い話題があるが、おそらく同じところに行き着くのではないかという感じがする。何かしら良い方向での影響はあるだろうけど、AIを利用したプログラミングスキルが求められるようになるというところでとどまるのではないかと思っている。
## 29章を読んだ
「統合」
「統合」とは一体なんなのか。「分割されているソフトウェアコンポーネントを一つのシステムに統合するソフトウェア開発のアクティビティを指す。」と書かれている。一番愚直な方法は、コンポーネントを個別に完成させて、全部出来上がったらばーんとくっつけてうまくいくことを祈るというもので、フェーズ型と名付けられている。これはほとんど良い方法ではない。どこでエラーが発生したのか、発見が困難になる。それに対して、少しずつ統合していく方法をインクリメンタル型といって、これが現実的な方法になっている。さらにインクリメンタル統合は、システムのどの部分から順番に統合していくかによって、いくつかの手法が考案されている。どれも利点と欠点があって、常に最適となるものはない。各手法をミックスさせたハイブリッドなアプローチが好まれているらしい。
統合をどのように行うかというと、デイリービルドとスモークテストによって行う方法が挙げられている。デイリービルドは、そのまんま、毎日ビルドすることで、スモークテストは、煙が出ていないかをテストするという意味で、比較的簡単な検査のことだ。デイリービルドは1日1回のビルドを推奨している。それ以上、つまりcontinuousだとやり過ぎだと書かれている。最近の流行は継続的インテグレーションで、頻繁にビルドを行うことが流行している。この本の書かれた当時はまだ地位を築いていなかったようで、もし、改訂版が出るとしたらそのことにも触れられるのだろう。スモークテストは軽視してはならず、これなしではデイリービルドは意味がないらしい。具体的な方法までは書かれてないので、気になるところだった。
## 28章を読んだ
「コンストラクションの管理」
プログラマとしては、管理しようとするものとどうやって向き合っていくかのヒントになる。そのような管理しようとする力には違和感を覚えることが多く、そうでなければ幸運だ。かといって、全く力を加えずに無秩序であるほうが良いということは意味しない。たとえプログラマ一人だけのプロジェクトであっても、自分自身でプロジェクトを管理しなければいけないわけで、その場合、管理の失敗は自分の責任であって、影響は少ないが、やはりないよりはマシだ。管理者を管理する必要があり、自分自身の場合を除いて、割と高度な人間スキルが要求される。管理と称して現場で力を振りかざしているのは、「技術的な進化が遅れているものー単細胞生物と氷河期に絶滅したマンモスの中間にある何かー程度」でしかなかった。この章でも、コードチューニングで出てきたように、測定をすることが重要だと説かれれている。測定に反対することは、プロジェクトに何が起きている知らない方が良いといっているようなものだ、とまで書かれている。ただ、プログラムの性能と違って、プロジェクトの測定というのにはあまり馴染みがない。この章は興味深い。プロジェクトが遅れたらどうするかに対して、「プロジェクトが失った時間は、取り戻すことはできない。ますます遅れるだけである。」と書かれているのは記憶に残った。
## 27章を読んだ
「プログラムサイズが及ぼす影響」
プロジェクトの規模が大きくなると、エラーの数が多くなる。このことは直感的に理解できる。しかし、さらに悪いことに、プロジェクトの規模をコードの行数で考えたとして、同じ量のコードあたりのエラーの割合、言い換えればエラーの密度も高くなるので、単純に規模に比例してエラーが増えるわけではない。例えば、1000行あたりのエラーの数は4倍以上にもなることがある。また、プロジェクトの規模が大きくなると、生産性も落ちる。エラーはコンストラクションだけでなく、それ以外のアクティビティでの方もエラーの発生が大きくなり、その増加倍率はコンストラクションよりも高い。
これらのことから、小規模なプロジェクトの実績から類推して、単純に大規模な掛け算でプロジェクトのコストを見積もると、少なく見積もることになってしまうことになる。
プログラマが50人もいるような、そんな大規模なプロジェクトに従事したことがないし、これからもおそらくないだろうからあまり危機感がわかない、というのが本音だ。
## 26章を読んだ
「コードチューニングテクニック」
前章を踏まえて、本当にコードに手を加える必要があるのかどうかかを検討した上で、必要ならばやっていく。ここでも絶対に忘れてはいけないのは、必ず測定をするということだ。測定をしていないチューニングは効果は全く見込めず、コードを見にくくして保守性を下げる効果がついてくる。測定を行って最適化が必要なポイントが明らかにする。そして、禁断の扉を開けると、チューニングを行うためのテクニックはたくさん存在している。しかし、どのようなテクニックでも画一的に適用できるものではなく、ある環境では改善するが、別の環境では待った効果がなかったり、悪化してしまうことすらある。直感は全く当てにならない。必ず結果も測定しなければいけない。この章で紹介されているテクニックは、かなり簡単に施せるものだけど、言語の環境によって効果が予測困難であることを、データで見せてくれている。個々のテクニックを道具として引き出しに入れておくことは良いことだけど、どのようなテクニックも、いつでも使えるものではないことをしっかりと認識しておくことのほうが重要だ。
## 25章を読んだ
「コードチューニング戦略」
コードチューニングとは、大雑把に言うとコードの最適化のことを指している。2章に分けられていて、この章ではどういう姿勢で望むべきか、何をチューニングするのか、その判断基準は何なのかなど、一歩下がったしてから見たガイド、要は見出しにあるとおり「戦略」が語られている。最適化に移動もうとするときに思い出される「早まった最適化は諸悪の根源である」という定番の警句が例にもれず、ここでも掲載されていた。これまで最適化を扱うところでこの名言が引用されなかったものを見たことがない。また、コードをチューニングすることよりも、要求、設計、アルゴリズムの選択を変えることの方が効果が高いことが多いこと、プログラムの実行時間の大半を占めているのがコードの僅かな部分であること、パフォーマンスの測定をせずに行うチューニングは全く持って無意味である、むしろ逆効果であることなど、直感に反するが、プログラマの間では広く浸透しているアドバイスが書かれている。さらにデータも提示されているので反論するところは殆どない。
面白い段落があった。「完璧さを追求すると、完成にたどり着けないことがある。まず完成させてから、完璧なものにする。完璧でなければならない部分は通常わずかである。」この本のタイトルるに反するようで皮肉だが、これが正しい現実の認識だろう。
## 24章を読んだ
「リファクタリング」
この章はかの有名なマーチン・ファウラーの本を要約したものになっているらしい。2019年に第2版が出版されていて、所有しているのだけど、読まないといけないなと思いつつ未読なままだ。リファクタリングという言葉は独り歩きしている感がある。少なくともその本を読んでちゃんとトレーニングを積んでからでなければ、自分は今リファクタリングをしているのだと自信を持って言うことはできないだろう。うまく行くことを願って、手当り次第に変更を加えていくだけのことをリファクタリングと呼ぶことはできない。せっかく本も買ったので、今年中に一度しっかりと取り組んでおきたい。
## 23章を読んだ
「デバッグ」
デバッグは関心の高いアクティビティだ。プログラムの誤りをすぐに見つけて、原因を特定する能力が上がれば、プログラミングの生産性もずっと向上するのに、と思わせられることが幾度もある。それ以上に、プログラムの動作を徹底的に調べ上げるというのはなかなか楽しいものでもある。ただし、これはあくまで個人的な楽しみとしてプログラミングをしている場合のみ、好意的な嗜好だといえる。納期が迫っている状況で、謎のエラーと戦うことを楽しいと思っているなら、正常さを疑われかねない。良いデバッグと悪いデバッグには10倍以上のパフォーマンス差があると書かれている。できれば良いデバッグを行う側に立ちたいものだ。
## 22章を読んだ
「デベロッパーテスト」
この本のサブタイトルは、「完全なプログラミングを目指して」だけど、プログラミングでエラーが一切発生しないことを目指すものではない。必ずエラーは紛れ込むものであって、テストは不可欠なプロセスであることを前提としている。そのテストに対する考え方は、一口で語れるような軽いものではない。単にテスティングフレームワークを採用して、ユニットテストを書いておけばいいというだけには済まない。よく知られたテストファーストの方針を推奨してはいるけど、それが全てではなく、何をテストすればいいのか、どのような手順でテストを実行すればいいのか、そもそもテストとは何かを知っておかないといけない。
## 21章を読んだ
「コラボレーティブコンストラクション」
なかなか高度な話題だ。複数人での活動になるので、一人ではトレーニングすることができない。企業で活動しているとしても、環境によってはトレーニングのためだけにそのようなことをする決定権を持たない場合もあるし、実験的に取り入れてもすぐに効果が出るとは思えないので、採用に至るまでの道のりはなかなか険しいものだろうと思われる。大きな企業では、一部を除いて、プログラマの思いつきでで現状のやり方を変えることは難しいだろう。結局の所、経営に関わる政治的な力と向き合わなければならない。この章が「コードの改良」というパートに含まれているのは皮肉だ。もちろん全てが悪いことばかりではなく、積極的かつ慎重にソフトウェアの品質を高めるためにとっくにこの古い本に書かれているようなことはとっくに実行済みで、より優れた方法を開発している集団や組織もたくさんあるだろうけど。
## 20章を読んだ
「ソフトウェアの品質」
品質と言っても様々な特性がある。ある特性は別の特性と結びつきがあって、一方を上げると別の方が下がるということもあり、すべての特性を同時に完璧にすることができない。
品質を改善するコストを下げるためには、できるだけ早い段階、つまり、コ
ンストラクションより前の段階ででエラーを検出するのが良い。
というようなことが書いてあった。久しぶりに、約3ヶ月ぶりに読み進めるので微妙に飲み込みが悪い。
## 下巻 はじめにを読んだ
上と同じ内容と思われる。
コンストラクションの重要性、コンストラクションに関する書籍が殆どないこと、研究において軽視されている状況などについての鋭い指摘がなされている。
Posted by ブクログ
下巻で扱われるのはコードの改良、システムの考察、そしてソフトウェア職人気質だ。
テスト、コラボレーティブな開発(ペアプログラミング)にコードチューニング、リファクタリングが一つの書籍という体系に纏められているのは改めて素晴らしいことだ。「コンプリート」の名の通り、優れたコードコンストラクションを実現するために必要な要素がギュッと詰まっている。たとえばよりよいコメントの書き方、Lint使用の推奨など現代のプログラミングの礎となっている。
もちろん、時代柄古びてしまっているところはある。
それを補ってあまりあるほど本書は魅力的であり、また現代のエンジニアにとっても変わらず必修科目であるといえるだろう。
Posted by ブクログ
全てのプログラマにとって有益な本と思います。この本に記された具体的なアドバイスに従うことこそ、高品質ソフトウェアへの一歩になるに違いありません。
なお、テストエンジニアは「第20章 ソフトウェアの品質」、「第22章 デベロッパーテスト」、「第23章 デバッグ」、「第27章 プログラムサイズが及ぼす影響」、「第30章 プログラミングツール」、「第34章 ソフトウェア職人気質とは」等々がある下巻の方が興味深く読み進めることができるかもしれません。
Posted by ブクログ
チューニング・リファクタリング・レイアウトなど高度な技術を詳細に解説
よりよりプログラミングを行う方法について書かれた本の下巻。下巻では，ソフトウェアの品質や管理についての言及が多くなっており，より高度で上級者向けの内容になっていた。その中で，チューニングやレイアウトについて書かれていて興味を持った。
例えば，if文やfor文を書くときの波括弧をどう書くか？ステートメントの開始と終了という概念から，どういうふうに考えるのかということがかなり詳しく書かれている。チューニングやその他の話題についても，筆者の主観であったとしても，なぜこれがだめでこれがいいのかという点が非常に詳しく書かれており，考え方がとても参考になった。
自分の経験がまだあまりないのもあり，名前の命名規則などよりコーディングについて直接的な内容が多かった上巻に比べて，有用度は劣るがそれでも手元においておきたいと思える有用な本だった。
Posted by ブクログ
昔仕事で読んだ本。業界ではよくある「より綺麗なプログラムを書く本」だ。この手の本は、数年に1回バズる印象を私は持っている。
この本はマイクロソフト公式を売りにしている。どこまで社内で活用されているかは分からないが、しっかりした内容はさすがあのソフトウェア"Windows"を作っているだけある、と思わせる構成。
一つ一つは深い話ではない。されど、それを組織で徹底して意識統一できるかが重要な気がしている。
下巻はコード改良・システムの考察・職人気質。
Posted by ブクログ
すぐれたプログラムを書く上で必要なスキルのうち、ドキュメント化やデバッグ、ビルドなど、直接的にコードを書く以外のスキル・ノウハウについて述べている。
この辺を念頭に置いた上でコードを書くと、よいコードを書けるのでやっぱりプログラミング中に手元に置いておきたい本。
Posted by ブクログ
上巻のコーディングから若干はなれて入るが、必読には代わりはない。
コーディングから少し距離を置いて若干抽象的な内容を扱うので辛いかもしれないが、むしろこちらのほうが必読度は上。
Posted by ブクログ
基礎テストに最低限必要なテストケース数
1.ルーチンの直線パスを1とする。
2.if,while,repeat,for,and,orで1追加。
3.case分のcaseごとに1追加。defaultがなければ1追加。
境界分析は有効。1つ違いエラーはよくある。値に最小値や最大値がある場合もテストが必要。
悪いデータ
・データが小さすぎる(またはデータがない)
・データが大きすぎる
・データの種類が正しくない
・データのサイズが正しくない
・データが初期化されていない
テストは自動化が重要。今ならJenkinsかな。
