Slide 1
Slide 1 text
The Principles of
Programming
Part 2
Slide 2
Slide 2 text
自己紹介
・千葉 直樹 33歳
・業界10年くらいのシムネットで働くエンジニア
・仕事はWEBアプリ開発からサーバーインフラまでITっぽい分野はだいたいカバー
・他に開発環境や技術に関連した改善に取り組む
・座右の銘は「長い物には巻かれよ！」
・悪く言えば臆病で、よく言えば慎重派な何事も石橋をたたいて渡るタイプ
Slide 3
Slide 3 text
今日のお話
● 第1章 前提 ～ プログラミングの変わらぬ真実 ～
● 第2章 原則 ～ プログラミングのガイドライン ～
● 第3章 思想 ～ プログラミングのイデオロギー ～
● 第4章 視点 ～ プログラマの観る角度 ～
● 第5章 習慣 ～ プログラマのルーティーン ～
● 第6章 手法 ～ プログラマの道具箱 ～
● 第7章 法則 ～ プログラミングのアンチパターン ～
Slide 4
Slide 4 text
第4章 視点
プログラマの観る角度
Slide 5
Slide 5 text
凝集度 (モジュール強度)
Slide 6
Slide 6 text
凝集度 (モジュール強度)
● モジュールとは、ある処理をひとつの機能としてまとめたもの
● モジュール強度とはモジュール内の処理の関連性を示す強さを表し、強いほど優れている
優れたモジュール強度とは
● ひとつの役割を実現するモジュールであること
脆いモジュールとは
● 複数の関連性の弱い処理を担っている場合、そのモジュールの修正を行うと呼び出す関連モジュールへ
の影響が大きくなる。
Slide 7
Slide 7 text
結合度
Slide 8
Slide 8 text
結合度
● モジュール間で受け渡しするデータの依存度の高さ
● 結合度は弱いほど優れている
優れた結合度とは
● 単純なデータの受け渡しで完結している
よくない結合度とは
● 他モジュールのデータに依存したり、グローバル変数を使用している
Slide 9
Slide 9 text
直交性
Slide 10
Slide 10 text
直交性
● ある機能を実現するために別の機能を利用しており、それぞれの機能を修正しても、お互いに影響をしな
いようにすること
● テストコードを書きやすくできるため、修正によるリスクが軽減できる
例えば
● 別の機能を呼び出す際にインターフェースを共通化して、内部実装を変更する仕組みを実現する
● 身近な例だとフレームワークによって提供されるデータベースへの接続や利用が、データベースの種類
が異なっても外部の設定によって切り替えられる仕組み
Slide 11
Slide 11 text
可逆性
Slide 12
Slide 12 text
可逆性
● 仕様は変わるので、変更に柔軟に対応できるようにすること
● 例えば特定のフレームワークに特化した設計を避けること
Slide 13
Slide 13 text
コードの臭い
Slide 14
Slide 14 text
コードの臭い
● コピペコードが散見している
● 関数などの処理がとにかく長い
● 機能の役割が多すぎる
● 変数などの命名がずさん
これらを見つけて改善を図る
● コピペがあればひとつの機能にまとめる
● 関数が長ければ、関連性の強い処理を別の関数にまとめる
● 命名がずさんならば、適切に改名する
● これらの改善作業を「リファクタリング」と呼ぶ
Slide 15
Slide 15 text
技術的負債
Slide 16
Slide 16 text
技術的負債
何も考えずとりあえず動くコードを書く、もしくはリリースを優先して素早く汚いコードを書く
● 修正がしにくい構造になりがち
● 理解が困難になる
負債を早期に返済する(リファクタリング)
● 一時的に抱えた負債はコードに対する理解が及んでいる間や、担当者がいる間に返済する
● 必ずしも負債が悪いということではなく未来永劫残さない努力をする
● 返済する時間が与えられなければ、コメントを残す
Slide 17
Slide 17 text
４章のまとめ
● モジュール強度
関連性の高い処理をまとめて強くする
● モジュール結合度
外部依存を小さくして弱くする
● 直交性
他のモジュールの関数などを参照していても、その他のモジュールを修正しても影響が出ないようにする
● 可逆性
仕様は変わることを想定して、変更を容易にすること
● コードの臭い
コピペだらけ、関数が長い、変数名が直感的じゃないものを見つけたらリファクタリングする
● 技術的負債
負債は早期に返済する
Slide 18
Slide 18 text
第6章 手法
プログラマの道具箱
Slide 19
Slide 19 text
曳光弾(えいこうだん)
曳光弾とは、通常の弾丸との間に数発置きに装てんされていて、打ち出すと軌跡がわかるもの
Slide 20
Slide 20 text
曳光弾(えいこうだん)
曳光弾とは、通常の弾丸との間に数発置きに装てんされていて、打ち出すと軌跡がわかるもの
どういうことか？
● 検証したい部分を優先してプログラミングをすること
どのように役立つか？
● ユーザーからのフィードバックが得られる
● プログラマが活躍できる舞台を早めに整えられる
● デバッグやテストが早く正確にできる
● デモ可能なソフトウェアを確保できる
● 進捗が明確になる
Slide 21
Slide 21 text
曳光弾(えいこうだん)
それってプロトタイプじゃないの？
● プロトタイプ開発と異なる点は、作り終えてもアプリケーションとして継続する
● 簡易的な機能を優先して作り込み、徐々に機能が追加される
● 前章のKISSとかYAGNIの原則である
Slide 22
Slide 22 text
契約による設計
Slide 23
Slide 23 text
契約による設計
● プログラムで関数の呼び出し側と、される側での契約
(ルール)を交わすこと
● 呼び出す側は正しい値のみ呼び出され側に渡すことを守る
● 呼び出された側は正しい値のみ受け入れて、正しい値のみ返すことを守る
Slide 24
Slide 24 text
契約による設計
呼び出す側の責任
● 外部入力値の妥当性を検証する
● 正しい値のみ関数へ引き渡す
Slide 25
Slide 25 text
契約による設計
呼び出され側の責任
● 引数が契約通りかチェックする
● 引数が契約に適合しなければ例外処理をする
● 引数を契約の条件に適合するように改変してはならない
● 契約通りの値を返すこと
Slide 26
Slide 26 text
契約による設計
思い違いの早期発見
● 呼び出され側は要求されたこと以上、以下のことをしないコード
● 呼び出され側は、事前条件が満たされていると仮定しコードをシンプルにできる
● 呼び出す側のパラメータが呼び出される側で、処理の実行を継続できない場合は例外を発生させて早期
に処理を終了する
Slide 27
Slide 27 text
防御的プログラミング
Slide 28
Slide 28 text
防御的プログラミング
「かもしれない」と想定しながら、安全にプログラミングを行うこと
● 外部からのデータを信頼しない
● 関数の使い方が誤っている場合は、例外とする（契約による設計と同様）
● 信頼できないデータをもつレイヤーと信頼可能になったデータをもつレイヤーに分ける
例えば
● Webプログラミングならばブラウザからの入力は、制御文字などの危険な文字を除去したり無力化してか
らやりたい処理を行う
Slide 29
Slide 29 text
ドッグフーディング
名称の由来は、実際にドッグフードを開発して、
愛犬に食べさせて反応をみてみること
Slide 30
Slide 30 text
ドッグフーディング
● リリース前に自身でユーザー目線に立って使ってみること
● 自社ではカスタマーサポートチームを含めて、バグや使用感の悪い機能のフィードバッグをしてもらってい
る
Slide 31
Slide 31 text
ラバーダッキング
Slide 32
Slide 32 text
ラバーダッキング
由来はテディベアや、お風呂に浮かべたアヒルに話しかけることからついた
● プログラミングにおける問題などを他の「誰か」に説明すること
● 説明しているうちに、問題の整理がついて自己解決することができる
● 聞き手は相づちだけで、特に何かを言う必要はない
Slide 33
Slide 33 text
コンテキスト
Slide 34
Slide 34 text
コンテキスト
● 周りの状況や背景のことで、文脈と言ったりする
● コードが「何」のためにあるのか、必要なのかを明確にするもの
● 「合計を求める処理」だけだと、何の合計か分からない
● 先に「カート商品」などのコンテキストがあれば明確になる
Slide 35
Slide 35 text
コンテキスト
コンテキストが示されない場合
● こきひう
● させんく
● ちつてか
● いたよう
● わりまひ
Slide 36
Slide 36 text
コンテキスト
コンテキストが「食べ物」の場合
● おれつむ
● りきとや
● かおぴた
● あかげら
● てからす
きっと「食べ物」から連想する言葉を簡単に引き出せたはず
Slide 37
Slide 37 text
６章のまとめ
● 曳光弾
関連性の高い処理をまとめて強くする
● 契約による設計
関数を呼び出す側は正しい値を渡し、呼び出され側は正しい値を返すこと
● 防御的プログラミング
「かもしれない」と考えながらプログラミングすること
● ドッグフーディング
ユーザー目線でプログラムを動作させてみること
● ラバーダッキング
問題箇所を「誰か」に話しながら解決を模索すること
● コンテキスト
なぜそのコードが必要かの背景や状況を伝えること
Slide 38
Slide 38 text
ご清聴ありがとうございました！