【プリンシプルオブプログラミング】手法
目次
はじめに
この記事は「プリンシプルオブプログラミング」を読んで自分なりにまとめた学習メモです。
プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則
- 作者: 上田勲
- 出版社/メーカー: 秀和システム
- 発売日: 2016/03/23
- メディア: 単行本
- この商品を含むブログ (11件) を見る
手法 〜プログラマの道具箱〜
曳光弾
プログラミングにおける「曳光弾」とは、優先的に検証したい部分を、先行的にプログラミングすること。簡易で構わないので、実際の環境下で動作して、確認できる、エンド・ツー・エンドのソフトウェアを作成する。
ここで作成するコードは、フレームワークであり、土台となる。
【メリット】
【やるべきこと】
最初に動作する土台を作る。
土台のコードは最小限に留める。
【プロトタイプとの違い】
- プロトタイプ：ソフトウェアのコンセプトや最終形態についての「理解を検証する」ためのもの。
- 曳光弾：ソフトウェア全体がどのように連携するのかを明らかにする。ユーザーに対して、どのような使い勝手になるのかを提示する。
契約による設計
「契約による設計」とは、関数と、関数を呼び出す側で、互いに「契約」結んでいると見なしてプログラミングすること。
【やるべきこと】
コメントとアサーションで契約する。
【注意点】
- 関数側では、引数の調整を行わない
- 関数側のアサーションを、ユーザーの入力チェックに使用しない
- 関数側では、想定は厳格に、確約は寛容に
防御的プログラミング
関数に不正なデータが渡された時に、それが他の関数のせいであったとしても、被害を受けないよう「防御的な」コードを書いておく。
【考慮すべき点】
- 外部ソースからのデータ入力の値を確認する（「想定内のエラー」を検出）
- 関数の入力引数の値を確認する（「想定外のエラー」を検出）
【意識すべきこと】
「バリケード戦略」を取る。バリケードを構築して、被害を封じ込める。
ドッグフーディング
自分で開発したソフトウェアは、自ら使用するようにする。
人に使ってもらうものなので、自ら率先して「味見」して、その塩梅を確かめる責任がある。
【意識すべきこと】
リリース前に、自分でユーザーのように使う。
ラバーダッキング
プログラミングにおいて、発生している問題や、問題を抱えているコードを「誰か」に説明する。すると、問題の原因に自ら気付き、自己解決できることがある。
【意識すべきこと】
問題解決が停滞した場合、「誰か」にそれを説明する。
コンテキスト
コンテキストとは、周りの状況や背景のこと。文脈とも言う。
【２つの側面】
- コードの読み書きに利用：コードを書く人と、コードを読む人とのコミュニケーション。
- 思考のツールとして利用：プログラミングは問題解決の作業。
【意識すべきこと】
コードを書く時、コンテキストを先に示すようにする。
