【ちゃんなるぶろぐ】社会人1年生が日々の学びをアウトプット!

>>> 読書・遊び・プログラミング・アプリ開発などを通して学んだことを、文章という形で出力 <<<

5分でわかる!「プログラマが知るべき97のこと」その②④

読み終えるまで約5分

 

 

どうも、ちゃんなるです! 

今日も”デキる”プログラマになるべく勉強していきましょう!

 

今回は、次の書籍の一部を要約します。

プログラマが知るべき97のこと』

 

下の記事の続編です↓↓

chan-naru.hatenablog.com

 

今回選択した3つのテーマ

本書はタイトル通り97のことについて書かれています。

今回は、70~72番目の項目についてまとめます。

  1. シングルトンパターンの誘惑に負けない(No. 70)
  2. パフォーマンスへの道は地雷コードで敷き詰められている(No. 71)
  3. シンプルさは捨てることによって得られる(No. 72)
①シングルトンパターンの誘惑に負けない

このテーマで述べられていたことは、

「シングルトンのデメリットを認識した上で、今後シングルトンを採用するか検討できるようになろう!」

ということです。

 

以下、要約です。

シングルトンパターンは多くの問題の解決に役立つパターンです。

しかし、短所がたくさんあることはご存知でしょうか?

短所を知らないが故に長所しか見えず、それによってシングルトンパターンを安易に採用している場合が多いです。

それを避けるためにシングルトンパターンにどのような具体的な問題があるかを次に示します。

  • 要件の変化を織り込んでいるとはいえないこと:クラスを作った時は「インスタンスは1つで良いだろう」と考えていても、要件の変化によって変更を強いられる場合があります。そのため、至る所でシングルトンパターンを多用していると、どこかで大きな問題が生じて困難な改修を強いられる可能性があります。
  • 論理的には独立しているコードの間に暗黙の依存関係を生んでしまうこと:依存関係がわかりにくくなります。例えば、ユニットテストの際にモック実装に差し替えようとしても依存関係が裏に眠っていてユニットテストコードを書くのが困難になってしまう場合があります。
  • シングルトンは永続化された状態を暗黙のうちに伴うことユニットテストは、どんな順序でもテストできるように、互いに独立である必要があります。そしてどのテストも実行前には、必ずプログラムを既知の状態に設定できるはずです。不変でない状態を伴うシングルトンを導入すると、それが困難になります。そこに、グローバルにアクセス可能で、かつ永続化された状態があると、状態の推測がかなり困難です。これは特にマルチスレッド環境で顕著になります。
  • マルチスレッド環境での使用は特に危険が大きいこと:マルチスレッドでは、シングルトンオブジェクトへのアクセスにはロックが必要になります。いわゆるDCLP(Double-Checked Lockingパターン)を使うことが多いです。しかしDCLPは多くの言語でスレッドセーフでないということがわかっており、危険性を高めてしまうのです。
  • シングルトンを明示的に殺す機能がないこと:これは例えば、全てのオブジェクトをクリーンアップするまで安全にアンロードできない、というプラグインアーキテクチャプラグインにとって大きな問題になります。
  • プログラムの終了時に、シングルトンも自動的にクリーンアップされること:しかし、複数のシングルトンがある場合は、どのような順序でクリーンアップされるかは決まってません。相互依存関係を持つシングルトンが含まれる場合、あるシングルトンがアクセスした先のシングルトンが既にクリーンアップ済みであるという事態になる可能性があります。

まず、シングルトンは、インスタンスが絶対に1つしかいらないと確信を持てるクラス以外には使わないようにしましょう。

そして、シングルトンはグローバルにアクセスされないように、アクセスはインターフェースを経由するようにしましょう。

シングルトンの実装やシングルトンへのアクセスを検討する時があれば、一度立ち止まり、ここに書いた内容を意識してみてください。

②パフォーマンスへの道は地雷コードで敷き詰められている

このテーマで述べられていたことは、

「地雷コードの改修を始める前に、「どのくらい複雑でどのくらい依存度の高い地雷コードなのか」を調べる仕組みを導入し、円滑に改修作業に臨めることが理想である。」

ということです。

 

以下、要約です。

パフォーマンスチューニングでは、ほとんどの場合コードの変更が必要です。

どんなコードにも、複雑すぎる部分依存度が高すぎる部分が含まれているのが事実です。

そんなコードはいわゆる『地雷』で、この地雷の炸裂によって第一にプロジェクトのスケジュールが犠牲になります。

初期見積もり時では数日だったが、いざ改修を始めると複雑な依存関係が見つかり、気づいたら改修を終えるまでに数週間・数ヶ月かかる場合もあるでしょう。

作業担当のチームは信用も立場もなくなってしまうのではないでしょうか。

 

事前にリスクの存在を察知する手段、あるいはリスクの大きさを評価する手段でもあればいいのですが、、、

コードの依存性、複雑さを計測するための手法や、それをコントロールするための手段というのはいくつかあります。

例えば、『ソフトウェアメトリクス』です(詳細は省く)。

 

ソフトウェアメトリクスには扱うべき数値が膨大になるというデメリットがありますが、コードをクリーンにする上で非常に役立つ手段ではあります。

パフォーマンスチューニングの作業に深刻な悪影響を及ぼす前に、コードの『地雷』を発見するのに役立ちます。

③シンプルさは捨てることによって得られる

このテーマで述べられていたことは、

「「いかに少ない修正を既存コードに加えるだけで問題を解決するか」だけでなく、「既存のコードが良質ではないなら丸ごと作り直してしまう」という考えを持ち、常にプロジェクトをシンプルな状態に保つべし!」

ということです。

 

以下、要約です。

既存のコードに最低限の修正だけを加えるだけで問題解決をする、ことが理想でしょう。

しかし、これは既存のコードが良質な場合にのみ理想となります。

 

既存のコードがひどい場合は、いっそのこと既存のコードを削除して新たなコードを書いた方がいいです。

しかし、こうすると修正を追記するより遥かに労力がかかると思い、多くの人はやりたがらないでしょう。

 

既存のコードが良質なら作り直しより修正の方が楽ですが、質の悪いコードはあってもなんの役にも立ちません。

即座に破棄しましょう。

まとめ

①シングルトンのデメリットを認識した上で、今後シングルトンを採用するか検討できるようになろう!

②地雷コードの改修を始める前に、「どのくらい複雑でどのくらい依存度の高い地雷コードなのか」を必ず調べられるようにしておこう!

質の悪いコードは全て破棄し、綺麗なコードに書き直す!という姿勢がとても大切です!

 

*より深く知りたい方は、ぜひ本書を手にとってみてください!

書籍情報

プログラマが知るべき97のこと [ ケブリン・ヘニー ]

価格:2,090円
(2021/5/13 11:12時点)
感想(1件)

【中古】 プログラマが知るべき97のこと /ケブリンヘニー【編】,和田卓人【監修】,夏目大【訳】 【中古】afb

価格:825円
(2021/5/13 11:12時点)
感想(0件)

【書籍名】プログラマが知るべき97のこと

【著者名】ケブリン・へニー、夏目大(訳)

【出版社】オーム社

【出版日】2010年12月

【ページ数】243ページ