The principles of programming part.2

Transcript

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